Hello Genodians,

    It's been a while, but I decided to try out Sculpt 24.04. I have mostly good news: the ps2 issue I mentioned last time seems to be resolved, thanks for that. The system boots up nicely and looks to have a lot of cool features. However, I can't get the nvme driver to work. It reads the partition table, but following any access to a partition, the platform_drv component fails with the message:

Error: Uncaught exception of type 'Genode::Final_table<Intel::Level_1_descriptor<12u> >::Double_insertion'

So I am able to trace this a little, the exception is thrown within Driver::Session_component::alloc_dma_buffer(unsigned long, Genode::Cache), specifically within Genode::Registry<Driver::Io_mmu_domain>::for_each<...>(...), so I assume this is related to IO_mmu in some way. If it helps, the address it attempts to allocate is 0x800000 with size 0x400000.

Interestingly an exception is thrown twice when attempting to allocate that region, the first time on startup. In that case, based on the log this is probably happening when the nvme partition table is read. However, this exception is not fatal, because it's of type Genode::Out_of_ram. The second time is when trying to use a partition and the exception is Double_insertion. One theory is that, prior to the first exception, the page table in IO_mmu gets partially filled, but the allocator ignores that this happened due to the exception. So, when another request is made, the table is partially full, although the allocator thinks it's a free region.

I considered giving more RAM to various components (platform_drv and nvme), but that didn't help, and no component appears to be actually close to its limit. The next step in my debugging would be to try to figure out where/why the Out_of_ram is thrown. I suppose that this is in a higher level page allocator during allocation of space for a lower level page table? But, why isn't this fixed by increasing the quota? I'm curious if anyone here can offer insights.

Best regards,

CP