USB transfer_buffer allocations on 64bit systems
in [Kernel]
|
Prev: mfd: Initialise WM831x IRQ masks on chip even if interrupts not in use
Next: INFO: task apache2:7601 blocked for more than 120 seconds.
From: Chris Wright on 14 Apr 2010 18:30 * Pedro Ribeiro (pedrib(a)gmail.com) wrote: > Turns out CONFIG_DMAR was disabled because of PREEMPT_RT. I disabled > the later and enabled _DMAR. It took a long time to boot, something > wrong with the usb ports. You can see it in the appended dmesg from > time 11s to 100s. > > Then after it booted, I could barely move my USB mouse and lots of > errors appeared on dmesg. I tried to connect the DVB card but it > wouldn't even initialize. [ 316.360045] DMAR:[DMA Write] Request device [00:02.0] fault addr 23c00000 [ 316.360046] DMAR:[fault reason 05] PTE Write access is not set That's your video device. Do you have CONFIG_DMAR_BROKEN_GFX_WA=y? > Enabling it with iommu=pt seemed to make no difference. It should (it should at least eliminate the video device problem). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pedro Ribeiro on 14 Apr 2010 19:00 On 14 April 2010 23:25, Chris Wright <chrisw(a)sous-sol.org> wrote: > * Pedro Ribeiro (pedrib(a)gmail.com) wrote: >> Turns out CONFIG_DMAR was disabled because of PREEMPT_RT. I disabled >> the later and enabled _DMAR. It took a long time to boot, something >> wrong with the usb ports. You can see it in the appended dmesg from >> time 11s to 100s. >> >> Then after it booted, I could barely move my USB mouse and lots of >> errors appeared on dmesg. I tried to connect the DVB card but it >> wouldn't even initialize. > > [ 316.360045] DMAR:[DMA Write] Request device [00:02.0] fault addr 23c00000 > [ 316.360046] DMAR:[fault reason 05] PTE Write access is not set > > That's your video device. Do you have CONFIG_DMAR_BROKEN_GFX_WA=y? > Where do I find this option in make menuconfig? Doesn't seem to be available... >> Enabling it with iommu=pt seemed to make no difference. > > It should (it should at least eliminate the video device problem). > You are right, it does eliminate that problem. However I can't get any of the USB devices to work, and the mouse is terribly slow. One more dmesg attached. Pedro
From: Chris Wright on 14 Apr 2010 19:40 * Pedro Ribeiro (pedrib(a)gmail.com) wrote: > On 14 April 2010 23:25, Chris Wright <chrisw(a)sous-sol.org> wrote: > > * Pedro Ribeiro (pedrib(a)gmail.com) wrote: > >> Turns out CONFIG_DMAR was disabled because of PREEMPT_RT. I disabled > >> the later and enabled _DMAR. It took a long time to boot, something > >> wrong with the usb ports. You can see it in the appended dmesg from > >> time 11s to 100s. > >> > >> Then after it booted, I could barely move my USB mouse and lots of > >> errors appeared on dmesg. I tried to connect the DVB card but it > >> wouldn't even initialize. > > > > [ �316.360045] DMAR:[DMA Write] Request device [00:02.0] fault addr 23c00000 > > [ �316.360046] DMAR:[fault reason 05] PTE Write access is not set > > > > That's your video device. �Do you have CONFIG_DMAR_BROKEN_GFX_WA=y? > > Where do I find this option in make menuconfig? Doesn't seem to be available... It's hidden behind CONFIG_BROKEN. The iommu=pt test puts all devices in a 1:1 mapping (the broken graphics workaround does that just for all graphics devices). > >> Enabling it with iommu=pt seemed to make no difference. > > > > It should (it should at least eliminate the video device problem). > > You are right, it does eliminate that problem. However I can't get any > of the USB devices to work, and the mouse is terribly slow. One more > dmesg attached. Thanks. It works for me here. I just booted 2.6.33-rt4 on my T400 w/ iommu on, and an external USB mouse is working fine (I don't have the same number of devices plugged in as you do). You are not seeing DMA faults which suggest that the IOMMU mappings are correct w.r.t. the DMA transactions that the controller is initiating. thanks, -chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pedro Ribeiro on 14 Apr 2010 21:30 On 15 April 2010 00:37, Chris Wright <chrisw(a)sous-sol.org> wrote: > * Pedro Ribeiro (pedrib(a)gmail.com) wrote: >> On 14 April 2010 23:25, Chris Wright <chrisw(a)sous-sol.org> wrote: >> > * Pedro Ribeiro (pedrib(a)gmail.com) wrote: >> >> Turns out CONFIG_DMAR was disabled because of PREEMPT_RT. I disabled >> >> the later and enabled _DMAR. It took a long time to boot, something >> >> wrong with the usb ports. You can see it in the appended dmesg from >> >> time 11s to 100s. >> >> >> >> Then after it booted, I could barely move my USB mouse and lots of >> >> errors appeared on dmesg. I tried to connect the DVB card but it >> >> wouldn't even initialize. >> > >> > [ 316.360045] DMAR:[DMA Write] Request device [00:02.0] fault addr 23c00000 >> > [ 316.360046] DMAR:[fault reason 05] PTE Write access is not set >> > >> > That's your video device. Do you have CONFIG_DMAR_BROKEN_GFX_WA=y? >> >> Where do I find this option in make menuconfig? Doesn't seem to be available... > > It's hidden behind CONFIG_BROKEN. The iommu=pt test puts all devices in > a 1:1 mapping (the broken graphics workaround does that just for all > graphics devices). > >> >> Enabling it with iommu=pt seemed to make no difference. >> > >> > It should (it should at least eliminate the video device problem). >> >> You are right, it does eliminate that problem. However I can't get any >> of the USB devices to work, and the mouse is terribly slow. One more >> dmesg attached. > > Thanks. It works for me here. I just booted 2.6.33-rt4 on my T400 w/ > iommu on, and an external USB mouse is working fine (I don't have the > same number of devices plugged in as you do). You are not seeing DMA > faults which suggest that the IOMMU mappings are correct w.r.t. the DMA > transactions that the controller is initiating. > > thanks, > -chris > I enabled CONFIG_DMAR_BROKEN_GFX_WA=y and the result is the same. A delay in the boot process and usb devices don't work properly, including my USB mouse. Strange, since you have the same platform as me. The extra usb devices you were seeing are because of my docking station - but it makes no difference whether I'm docked or not for the purposes of the original bug or this situation right now. The dmesg I'm attaching is without the computer being docked. Pedro
From: Alan Stern on 14 Apr 2010 22:00
On Wed, 14 Apr 2010, Pedro Ribeiro wrote: > On 14 April 2010 22:01, Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com> wrote: > > On Wed, Apr 14, 2010 at 04:29:22PM -0400, Alan Stern wrote: > >> On Wed, 14 Apr 2010, Chris Wright wrote: > >> > >> > So dma_map_single is the case that's failing, but you think the mask is > >> > correct? �What about the direction? > >> > >> The mask and direction are unquestionably correct. �The mask is set up > >> by pci_setup_device() and not changed thereafter. �Furthermore, the > >> audio works okay until another device (a DVB tuner) is plugged in. > > > > Could the driver for the DVB tuner change the PCI mask? That is, change > > the pci mask way after it has been initialized (don't laugh, this did > > happend - as I remember 4 months fix was posted on the DRM mailing list > > for this). > > > > I can also trigger the bug on mount and unmount of a USB stick, albeit > its not as intensive. In addition, it's worth pointing out that the DVB tuner is another USB device, not a PCI device. Hence it doesn't have a PCI driver, and it seems most unlikely that its driver would modify the DMA mask of a different device. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |