On Fri, Feb 20, 2009 at 11:57 PM, FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> wrote: > On Fri, 20 Feb 2009 04:20:29 -0700 > Wes Shull <wes.shull@xxxxxxxxx> wrote: > >> On Thu, Feb 19, 2009 at 7:58 PM, Robert Hancock <hancockrwd@xxxxxxxxx> wrote: >> > FUJITA Tomonori wrote: >> >> >> >> On Wed, 18 Feb 2009 17:05:44 -0500 >> >> Chuck Ebbert <cebbert@xxxxxxxxxx> wrote: >> >> >> >>> On Wed, 18 Feb 2009 15:25:16 -0500 >> >>> Chuck Ebbert <cebbert@xxxxxxxxxx> wrote: >> >>> >> >>>> On Tue, 17 Feb 2009 20:22:05 +0900 >> >>>> FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> wrote: >> >>>> >> >>>> >> >>>>>>>>> >> >>>>>>>>> sata_nv 0000:00:0d.0: DMA-API: device driver frees DMA memory with >> >>>>>>>>> different >> >>>>>>>>> size [device address=0x00000000da031000] [map size=4096 bytes] >> >>>>>>>>> [unmap >> >>>>>>>> >> >>>>>>>> That's rather curious. It seems to be saying that the sg length is >> >>>>>>>> different between the map and unmap, but it doesn't look like sata_nv mucks >> >>>>>>>> with that anywhere, and neither does libata core.. >> >>>>>>> >> >>>>>>> Could the SCSI code have merged two requests? >> >>>>>> >> >>>>>> I wouldn't think so.. and if it did it seems like it would have to >> >>>>>> have changed the list after libata got the request somehow.. >> >>>>> >> >>>>> Does this box uses GART IOMMU? >> >>>> >> >>>> I don't think so, but I've asked for the dmesg. >> >>> >> >>> Okay, it _is_ using GART IOMMU: >> >>> >> >>> DMA-API: preallocated 8192 debug entries >> >>> DMA-API: debugging enabled by kernel config >> >>> PCI-DMA: Disabling AGP. >> >>> PCI-DMA: aperture base @ 20000000 size 65536 KB >> >>> PCI-DMA: using GART IOMMU. >> >>> PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture >> >> >> >> Thanks, that makes sense. >> >> >> >> I think that the following patch could fix this: >> >> >> >> http://marc.info/?l=linux-ide&m=123484533504307&w=2 >> > >> > The patch looks reasonable to me. I'm CCing the reporter of the bug. Wes, >> > would you be able to test out Fujita's patch linked above? >> >> I grabbed the srpm for the fedoraized 2.6.29-0.137.rc5.git4 from koji, >> applied the patch, and tested--no joy, I'm still getting the warning. >> Would there be any value to me trying this with a vanilla+dma-debug >> kernel build? >> >> Tomorrow I'm going to bump up the show_num_errors (currently at 1) in >> the dma debug patch to see if maybe that produces anything else >> interesting; > > I think that probably it's not interesting much. Once you get a > dma-debug error, the later errors are not reliable. > > For example, dma-debug finds a dma-debug error about a NIC, you could > get false dma-debug errors about even good device drivers. > > >> I've already got another bug that races with nv_sata to >> get that first warning (in forcedeth, so you probably don't care, but >> if so see https://bugzilla.redhat.com/show_bug.cgi?id=484494 ). > > As I explained above, you can't have other dma-debug error source. Can > you test only nv_sata with my patch again? Ok, I blocked forcedeth from loading, rebooted (still running the kernel I built with your patch--despite these warning messages, it's 100% stable in all my testing), verified that forcedeth hadn't loaded... but I still got the nv_sata warning. So that's not it either :( -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
