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: Pedro Ribeiro on 14 Apr 2010 13:30 On 14 April 2010 17:36, Daniel Mack <daniel(a)caiaq.de> wrote: > On Wed, Apr 14, 2010 at 10:08:47AM -0400, Alan Stern wrote: >> On Wed, 14 Apr 2010, Pedro Ribeiro wrote: >> > On 14 April 2010 11:09, Daniel Mack <daniel(a)caiaq.de> wrote: >> > > Thanks! So the only thing I can do for now is submit exactly this patch. >> > > At least, it helps you and it shouldn't break anything. The question >> > > remains whether this type of memory should be used for all >> > > transfer_buffers. >> > > >> > >> > Is there any chance you could push this to -stable? I don't care >> > because I always use the latest kernel, but the next Debian stable and >> > Ubuntu LTS are going to use 2.6.32. >> >> No! �Please don't do it: Don't submit the patch and _certainly_ don't >> submit it to -stable. �It doesn't fix anything; it only works around a >> bug, and at the moment we don't even know if the bug is in the kernel >> or in Pedro's hardware (and even though it affects two different >> systems of his, nobody else has reported a similar problem). �Papering >> over it will only remove the incentive to fix it properly. > > No worries - I agree. But unfortunately, I'm out of ideas now, and my > initial thoughts about what might cause the trouble were abviously not > able to explain the issue. Does anyone see further steps of tracking > this issue down? > > Thanks, > Daniel > Well if this is a dirty / dangerous hack, what about your first patch? I've been testing it for days and has given me no problems. The best way to trigger the issue is to connect a dib0700 based DVB adapter. All you need is to connect it. Since it polls for the remote control every 50 msec, it causes a constant interference. Beware that on 2.6.34 this behaviour has been corrected. Other DVB adapters may trigger the same issue if they also poll constatly for the rc. Regards, Pedro -- 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: Alan Stern on 14 Apr 2010 14:20 [Removed alsa-devel from the CC: list because this doesn't involve ALSA any more] On Wed, 14 Apr 2010, Daniel Mack wrote: > No worries - I agree. But unfortunately, I'm out of ideas now, and my > initial thoughts about what might cause the trouble were abviously not > able to explain the issue. Does anyone see further steps of tracking > this issue down? Since using mem=4096M or GFP_DMA stopped the symptoms, it seems very likely that a buffer is getting allocated above the 4 GB line and not bounced or IOMMU-mapped correctly. David, do you have anything to suggest? Any ways to check for IOMMU or related errors? The problem, in short, is that USB audio doesn't work properly when Pedro boots a 64-bit kernel on his 4-GB machine. With a 32-bit kernel it works okay, and it also works if we use dma_alloc_coherent(). The host controller is limited to 32-bit DMA, and the DMA addresses generated by dma_map_single() appear to be normal. At the moment we don't even know if this is caused by a bug in the kernel or a bug in Pedro's hardware. But he has observed the same problem on two different machines, both using the ICH9 chipset. 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/
From: Pedro Ribeiro on 14 Apr 2010 14:30 On 14 April 2010 19:23, Alan Stern <stern(a)rowland.harvard.edu> wrote: > On Wed, 14 Apr 2010, Pedro Ribeiro wrote: > >> The best way to trigger the issue is to connect a dib0700 based DVB >> adapter. All you need is to connect it. Since it polls for the remote >> control every 50 msec, it causes a constant interference. Beware that >> on 2.6.34 this behaviour has been corrected. Other DVB adapters may >> trigger the same issue if they also poll constatly for the rc. > > Your computer has two EHCI controllers, doesn't it? �Can you plug the > DVB into a different USB bus from the audio device? �If you do, does > the interference still occur? > > Alan Stern > > It does not matter on which ports I plug into, even if in different buses not sharing IRQ's. Pedro -- 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: Alan Stern on 14 Apr 2010 14:30 On Wed, 14 Apr 2010, Pedro Ribeiro wrote: > The best way to trigger the issue is to connect a dib0700 based DVB > adapter. All you need is to connect it. Since it polls for the remote > control every 50 msec, it causes a constant interference. Beware that > on 2.6.34 this behaviour has been corrected. Other DVB adapters may > trigger the same issue if they also poll constatly for the rc. Your computer has two EHCI controllers, doesn't it? Can you plug the DVB into a different USB bus from the audio device? If you do, does the interference still occur? 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/
From: David Woodhouse on 14 Apr 2010 14:40
On Wed, 2010-04-14 at 14:15 -0400, Alan Stern wrote: > > Since using mem=4096M or GFP_DMA stopped the symptoms, it seems very > likely that a buffer is getting allocated above the 4 GB line and not > bounced or IOMMU-mapped correctly. > > David, do you have anything to suggest? Any ways to check for IOMMU > or related errors? > > The problem, in short, is that USB audio doesn't work properly when > Pedro boots a 64-bit kernel on his 4-GB machine. With a 32-bit kernel > it works okay, and it also works if we use dma_alloc_coherent(). The > host controller is limited to 32-bit DMA, and the DMA addresses > generated by dma_map_single() appear to be normal. > > At the moment we don't even know if this is caused by a bug in the > kernel or a bug in Pedro's hardware. But he has observed the same > problem on two different machines, both using the ICH9 chipset. Pedro's dmesg suggests that his machine has an IOMMU, but his kernel isn't built to support it. So he'll be using swiotlb. Would be interesting to enable CONFIG_DMAR and check whether the problem goes away. If so, we can start looking harder at the swiotlb code. -- David Woodhouse Open Source Technology Centre David.Woodhouse(a)intel.com Intel Corporation -- 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/ |