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: Alan Stern on 9 Apr 2010 15:40 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. :-( 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: Daniel Mack on 9 Apr 2010 16:20 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. :-( FWIW, as I stated in the first message of this thread, I had very similar bug reports for a Mac OS X driver I'm maintaining, and the solution that fixed everything was to force memory that has a _physical_ buffer address mask of 0x00000000ffffffff. And all machines I've seen the bug on had 4GB of RAM or less. So appearantly, without that force option, memory beyond the 4GB range was provided. But I can't tell whether this effect also counts for Linux, and I must admit I lack a deep enough understanding about the kernel's memory management in 64bit mode and about how the DMA bouncing and remapping logic works. Does anyone have an idea about how to explain that? 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: Konrad Rzeszutek Wilk on 9 Apr 2010 16:30 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. -- 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: Oliver Neukum on 9 Apr 2010 17:00 Am Freitag, 9. April 2010 17:15:43 schrieb Alan Stern: > > > Then usb_submit_urb(urb[i]) will copy the appropriate four bytes to a > > > bounce buffer and map the bounce buffer. Accesses to the other parts > > > of xbuf won't violate the cacheline rules, because xbuf isn't mapped > > > for DMA -- only the bounce buffer is. When urb[i] completes, the > > > bounce buffer contents will be copied back to the original four bytes > > > in xbuf. Again, there is no violation of cacheline rules. > > > > I think you are assuming that either every or no part of the buffer is mapped > > for DMA in place. I don't think you can assume that. > > Yes I can, because the code that makes this decision is part of > usbcore and it is under m It seems to me that in usbcore you can positively know that a buffer will be mapped. However if the mapping is not done in usbcore you cannot know what the HCD driver will do to a buffer, in particular you don't know whether it will be processed by PIO or mapped for DMA. Maybe I understand this wrongly. Which code exactly were you refering to? Regards Oliver -- 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 9 Apr 2010 17:30
On Fri, 9 Apr 2010, Oliver Neukum wrote: > Am Freitag, 9. April 2010 17:15:43 schrieb Alan Stern: > > > > Then usb_submit_urb(urb[i]) will copy the appropriate four bytes to a > > > > bounce buffer and map the bounce buffer. Accesses to the other parts > > > > of xbuf won't violate the cacheline rules, because xbuf isn't mapped > > > > for DMA -- only the bounce buffer is. When urb[i] completes, the > > > > bounce buffer contents will be copied back to the original four bytes > > > > in xbuf. Again, there is no violation of cacheline rules. > > > > > > I think you are assuming that either every or no part of the buffer is mapped > > > for DMA in place. I don't think you can assume that. > > > > Yes I can, because the code that makes this decision is part of > > usbcore and it is under m > > It seems to me that in usbcore you can positively know that a buffer > will be mapped. However if the mapping is not done in usbcore you > cannot know what the HCD driver will do to a buffer, in particular > you don't know whether it will be processed by PIO or mapped for > DMA. The mapping is always done either by usb_buffer_alloc() or by map_urb_for_dma(). Both functions are in usbcore. > Maybe I understand this wrongly. Which code exactly were you refering to? Search for usages of "syncbuf" and "sync_dma" in sound/usb/usbaudio.c. 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/ |