On Sat, Nov 04, 2023 at 10:27:32AM +0100, Mikulas Patocka wrote:
On Fri, 3 Nov 2023, Keith Busch wrote:
On Fri, Nov 03, 2023 at 09:30:07PM +0100, Marek Marczykowski-G'orecki wrote:
On Fri, Nov 03, 2023 at 10:54:00AM -0600, Keith Busch wrote:
On Fri, Nov 03, 2023 at 05:15:49PM +0100, Marek Marczykowski-G'orecki wrote:
On Thu, Nov 02, 2023 at 06:06:33PM +0100, Mikulas Patocka wrote:
Then, try this patch (without "iommu=panic"), reproduce the deadlock and tell us which one of the "printk" statements is triggered during the deadlock.
The "821" one - see below.
Thanks for confirming!
Could you try this patch?
Besides min3() being unhappy about types, it works.
Oops, should have changed the constant to "ul" instead of just "u".
Anyway, the overall idea makes sense to me, but I don't know the swiotlb stuff well.
Christoph, does that patch make sense? For reference:
https://lore.kernel.org/linux-mm/ZUOr-vp0yRkLyvyi@kbusch-mbp.dhcp.thefaceboo...
dma_opt_mapping_size returns "min(dma_max_mapping_size(dev), size)". So you don't have to call dma_max_mapping_size explicitly, you can leave the file drivers/nvme/host/pci.c as it is.
Indeed.
What about the other block device drivers (AHCI, SCSI...)? Should there be some generic framework that restricts max_hw_sectors according to dma_opt_mapping_size?
I think it's just like any other request_queue limits and the individual drivers have to set up these.
Thinking on this again, this feels more like a max_segment_size limit rather than a max_hw_sectors.