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 12 Apr 2010 08:10 On 12 April 2010 11:48, Daniel Mack <daniel(a)caiaq.de> wrote: > On Fri, Apr 09, 2010 at 04:11:52PM -0600, Robert Hancock wrote: >> On Fri, Apr 9, 2010 at 3:23 PM, Alan Stern <stern(a)rowland.harvard.edu> wrote: >> > On Fri, 9 Apr 2010, Konrad Rzeszutek Wilk wrote: >> > >> >> On Fri, Apr 09, 2010 at 03:34:06PM -0400, Alan Stern wrote: >> >> > On Fri, 9 Apr 2010, Pedro Ribeiro wrote: >> >> > >> >> > > > The DMA pointers do indeed look sane. I wanted to take a deeper look at >> >> > > > this and set up a 64bit system today. However, I fail to see the problem >> >> > > > here. Pedro, how much RAM does your machine have installed? >> >> > >> >> > > It has 4 GB. >> >> > >> >> > That means DMA mapping cannot be the cause of the problem. :-( >> >> >> >> That isn't entirely true. The BIOS usually allocates a 256 MB ACPI/PCI hole >> >> that is under the 4GB. >> >> >> >> So end up with 3.7 GB, then the 256MB hole, and then right above the 4GB >> >> you the the remaining memory: 4.3GB. >> > >> > How can Pedro find out what physical addresses are in use on his >> > system? >> >> If you have 4GB of RAM then almost certainly you have memory located >> at addresses over 4GB. If you look at the e820 memory map printed at >> the start of dmesg on bootup and see entries with addresses of >> 100000000 or higher reported as usable, then this is the case. > > Pedro, can you provide your dmesg output, please? I installed 5GB or RAM > to my machine now, and even with your .config, I can't see the problem. > > Daniel > > There you go Daniel. Pedro
From: Andi Kleen on 12 Apr 2010 08:20 > > I'm not putting into question whether something is broken in my > system, but if it is, it must be the ICH9 platform, because I was able > to reproduce it in another laptop. > > My laptop is a Lenovo T400 and I was able to reproduce it in a Acer > Aspire 59xx (I don't remember the exact model, but it is one of the > new ones with 15.6 inch - i think they all use the same base). And the > common thing between them is the ICH9 platform. There are lots of systems around with ICH9 that work fine. I'm typing on one. > > The only which solved this problem was the first patch sent to me by > Daniel Mack. I've been using it for days straight and it works fine. Can you send a full boot log? -Andi -- ak(a)linux.intel.com -- Speaking for myself only. -- 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 12 Apr 2010 08:20 On 12 April 2010 12:53, Andi Kleen <andi(a)firstfloor.org> wrote: >> Which is exactly what usb_buffer_alloc() does already. So at least for >> x86 you say this is the right thing to do? However, we don't necessarily >> need coherent memory on other platforms, which is why I hessitate to >> enforce that type of memory for all transfer_buffer allocations. > > Yes today it's faster at least. > > Probably we should have better interfaces for this, but we don't. > >> >> > Or just use GFP_KERNEL and pci_map_* later. >> >> The USB core does this already, but at least on Pedro's machine, this >> seems unsufficient. Unfortunately, I can't reproduce the issue yet, even >> with more than 4GB of RAM installed. > > Then something must be broken in Pedro's system and likely other drivers > will also not work. I don't think it should be worked around in the USB layer. > > -Andi I'm not putting into question whether something is broken in my system, but if it is, it must be the ICH9 platform, because I was able to reproduce it in another laptop. My laptop is a Lenovo T400 and I was able to reproduce it in a Acer Aspire 59xx (I don't remember the exact model, but it is one of the new ones with 15.6 inch - i think they all use the same base). And the common thing between them is the ICH9 platform. The only which solved this problem was the first patch sent to me by Daniel Mack. I've been using it for days straight and it works fine. 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: Daniel Mack on 12 Apr 2010 08:40 On Mon, Apr 12, 2010 at 02:12:43PM +0200, Andi Kleen wrote: > > I'm not putting into question whether something is broken in my > > system, but if it is, it must be the ICH9 platform, because I was able > > to reproduce it in another laptop. > > > > My laptop is a Lenovo T400 and I was able to reproduce it in a Acer > > Aspire 59xx (I don't remember the exact model, but it is one of the > > new ones with 15.6 inch - i think they all use the same base). And the > > common thing between them is the ICH9 platform. > > There are lots of systems around with ICH9 that work fine. > I'm typing on one. FWIW, the fix that made it work for Pedro was to use usb_buffer_alloc() for the transfer_buffer of the audio module. Another detail I can't explain is that on his machine, the kernel oopses when kmalloc() with GFP_DMA32 is used. The patch to try this also only touched the allocation in sound/usb/caiaq/audio.c. > > The only which solved this problem was the first patch sent to me by > > Daniel Mack. I've been using it for days straight and it works fine. > > Can you send a full boot log? He just did. I put it online here: http://caiaq.de/download/tmp/pedro-dmesg Daniel -- 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: Andi Kleen on 12 Apr 2010 08:50
On Mon, Apr 12, 2010 at 02:32:38PM +0200, Daniel Mack wrote: > Another detail I can't explain is that on his machine, the kernel oopses > when kmalloc() with GFP_DMA32 is used. The patch to try this also only > touched the allocation in sound/usb/caiaq/audio.c. Where did it oops? > > > > The only which solved this problem was the first patch sent to me by > > > Daniel Mack. I've been using it for days straight and it works fine. > > > > Can you send a full boot log? > > He just did. I put it online here: > > http://caiaq.de/download/tmp/pedro-dmesg The system seems to set up the soft iotlb correctly. [ 0.468472] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) [ 0.468539] Placing 64MB software IO TLB between ffff880020000000 - ffff880024000000 [ 0.468610] software IO TLB at phys 0x20000000 - 0x24000000 Also if that was wrong a lot more things would go wrong. I would suspect the driver. Are you sure: - it sets up it's dma_masks correctly? - it uses pci_map_single/sg correctly for all transferred data? -Andi -- ak(a)linux.intel.com -- Speaking for myself only. -- 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/ |