From mboxrd@z Thu Jan 1 00:00:00 1970 From: keith.busch@intel.com (Keith Busch) Date: Tue, 10 Jun 2014 15:21:18 -0600 (MDT) Subject: [PATCH v7] NVMe: conversion to blk-mq In-Reply-To: <5397753B.2020009@fb.com> References: <1402392038-5268-1-git-send-email-m@bjorling.me> <1402392038-5268-2-git-send-email-m@bjorling.me>, <5397636F.9050209@fb.com> <5397753B.2020009@fb.com> Message-ID: On Tue, 10 Jun 2014, Jens Axboe wrote: > On 06/10/2014 03:10 PM, Keith Busch wrote: >> On Tue, 10 Jun 2014, Jens Axboe wrote: >>> On 06/10/2014 01:29 PM, Keith Busch wrote: >>>> I have two devices, one formatted 4k, the other 512. The 4k is used as >>>> the TEST_DEV and 512 is used as SCRATCH_DEV. I'm always hitting a BUG >>>> when >>>> unmounting the scratch dev in xfstests generic/068. The bug looks like >>>> nvme was trying to use an SGL that doesn't map correctly to a PRP. >>> >>> I'm guessing it's some of the coalescing settings, since the driver is >>> now using the generic block rq mapping. >> >> Ok, sounds right. I mentioned in a way earlier review it doesn't look >> like a request that doesn't conform to a PRP list would get split anymore, >> and this test seems to confirm that. >> >> Can we create something that will allow a driver to add DMA constraints to >> a request queue with the rules of a PRP list? > > I haven't even looked at the rules - can you briefly outline them? From > a quick look, seems it does prp chaining for every 512 entries. But > nvme_setup_prps() looks like voodoo to an uninitiated, it could have > used a comment or two :-) Yeah, nvme_setup_prps is probably the least readable code in this driver. Maybe some comments are in order here... There are two rules for an SGL to be mappable to a PRP: 1. Every element must have zero page offset, except the first. 2. Every element must end on a page boundary, except the last.