Re: uas: order 7 page allocation failure in init_tag_map()

Hi, On 23-04-16 23:10, Johannes Stezenbach wrote: Hi, I bought a new backup disk which turned out to be UAS capable, but when I plugged it in I got an order 7 page allocation failure. My hunch is that the .can_queue = 65536 in drivers/usb/storage/uas.c is much too large. Maybe 256 would

uas: order 7 page allocation failure in init_tag_map()

Hi, I bought a new backup disk which turned out to be UAS capable, but when I plugged it in I got an order 7 page allocation failure. My hunch is that the .can_queue = 65536 in drivers/usb/storage/uas.c is much too large. Maybe 256 would be a pratical value that matches the capabilities

Re: Page allocation failure (order 7) in UAS code

On ven., 2016-03-04 at 08:18 +0100, Hans de Goede wrote: > Thanks for testing, there shouldn't be any side-effects, I'll turn this into > a proper patch, add a: > > Reported-and-tested-by: Yves-Alexis Perez > > line to the comit msg and submit this upstream. > > Thanks, I

Re: Page allocation failure (order 7) in UAS code

to the correct place if needed] I have an external USB drive (Samsung M3), which apparently uses the UAS code. Starting with 4.4 (from Debian sid, I could retry with vanilla if needed), I can't mount the drive anymore after a while (few hours/days uptime). Just plugging the disk, I get page allocation failure

Re: Page allocation failure (order 7) in UAS code

t me to the correct place if > > needed] > > > > I have an external USB drive (Samsung M3), which apparently uses the UAS > > code. > > Starting with 4.4 (from Debian sid, I could retry with vanilla if needed), > > I > > can't mount the drive anymore after a

Re: Page allocation failure (order 7) in UAS code

On mar., 2016-03-01 at 11:49 +0100, Hans de Goede wrote: > Can you try building a kernel with the following line in > drivers/usb/storage/uas.c : > > .can_queue = 65536, /* Is there a limit on the _host_ ? */ > > (around line 815) Replaced with > > .can_queue = MAX_CMNDS,

Re: Page allocation failure (order 7) in UAS code

with 4.4 (from Debian sid, I could retry with vanilla if needed), I can't mount the drive anymore after a while (few hours/days uptime). Just plugging the disk, I get page allocation failure in kernel logs: Can you try building a kernel with the following line in drivers/usb/storage/uas.c

Page allocation failure (order 7) in UAS code

with vanilla if needed), I can't mount the drive anymore after a while (few hours/days uptime). Just plugging the disk, I get page allocation failure in kernel logs: Feb 22 10:57:56 scapa kernel: [26557.268872] usb 2-2: new SuperSpeed USB device number 3 using xhci_hcd Feb 22 10:57:56 scapa kernel

Re: Page allocation failure

On Mon, Nov 16, 2015 at 01:49:50AM +0100, Steinar H. Gunderson wrote: > Just so we're on the same page, I cleaned up the patch I'm now using, and I'm > attaching it here. You said the next step would be changing the memory > allocation interface; I guess I could give it a shot, but I doubt I would

Re: Page allocation failure

On Sat, Nov 14, 2015 at 12:36:48PM -0500, Alan Stern wrote: > Hmmm. If the shared memory can be accessed by the CPU using ordinary > load and store instructions and it can be kmalloc'ed, then it should be > usable for zerocopy I/O. But again, only if it satisfies the > restrictions imposed by

Re: Page allocation failure

On Fri, 13 Nov 2015, Steinar H. Gunderson wrote: > On Fri, Nov 13, 2015 at 04:02:48PM -0500, Alan Stern wrote: > >> So what is the road from here? I guess the original questions about cache > >> coherency still apply, and that this is what I'm seeing in dmesg. > > What questions? It should be

Re: Page allocation failure

On Sat, Nov 14, 2015 at 12:09:38PM -0500, Alan Stern wrote: > And you probably couldn't use GPU memory for this purpose because (I > assume) the USB host controller wouldn't be able to access it via DMA. I guess that depends a bit; on my particular system, I'm using an Intel GPU, so memory is

Re: Page allocation failure

On Sat, 14 Nov 2015, Steinar H. Gunderson wrote: > On Sat, Nov 14, 2015 at 12:09:38PM -0500, Alan Stern wrote: > > And you probably couldn't use GPU memory for this purpose because (I > > assume) the USB host controller wouldn't be able to access it via DMA. > > I guess that depends a bit; on my

Re: Page allocation failure

On Fri, Nov 13, 2015 at 12:00:53AM +0100, Steinar H. Gunderson wrote: > Interesting. I hacked libusb to get the fd. Then I did USBDEVFS_ALLOC_MEMORY, > which succeeded (well, as soon as I filled mem.size before calling), > then mmap on it as described (which also succeeded), and everything

Re: Page allocation failure

On Fri, Nov 13, 2015 at 10:38:54AM -0500, Alan Stern wrote: >> So, in general I think it's good news, although I don't fully understand why >> I still need the kernel-to-userspace copy for isochronous transfer. > Maybe you can add some debugging to copy_user_enhanced_fast_string(). > Add a flag,

Re: Page allocation failure

On Fri, 13 Nov 2015, Steinar H. Gunderson wrote: > On Fri, Nov 13, 2015 at 12:00:53AM +0100, Steinar H. Gunderson wrote: > > Interesting. I hacked libusb to get the fd. Then I did > > USBDEVFS_ALLOC_MEMORY, > > which succeeded (well, as soon as I filled mem.size before calling), > > then mmap on

Re: Page allocation failure

On Fri, 13 Nov 2015, Steinar H. Gunderson wrote: > On Fri, Nov 13, 2015 at 10:38:54AM -0500, Alan Stern wrote: > >> So, in general I think it's good news, although I don't fully understand > >> why > >> I still need the kernel-to-userspace copy for isochronous transfer. > > Maybe you can add

Re: Page allocation failure

On Fri, 13 Nov 2015, Steinar H. Gunderson wrote: > On Fri, Nov 13, 2015 at 11:24:39AM -0500, Alan Stern wrote: > >> What exactly am I looking for, beyond the stack trace the kernel already > >> gives me? > > Find out where copy_user_enhanced_fast_string is being called from, and > > using that

Re: Page allocation failure

On Fri, Nov 13, 2015 at 11:24:39AM -0500, Alan Stern wrote: >> What exactly am I looking for, beyond the stack trace the kernel already >> gives me? > Find out where copy_user_enhanced_fast_string is being called from, and > using that information, figure out why it was called. That will tell >

Re: Page allocation failure

On Fri, Nov 13, 2015 at 06:50:27PM +0100, Steinar H. Gunderson wrote: > The stack trace is simple enough, although I fear there's some inlining going > on: OK, I guess since copy_user_enhanced_fast_string is an assembler function, the unwinding doesn't work properly. I added a dump_stack() in

Re: Page allocation failure

On Fri, Nov 13, 2015 at 03:20:56PM -0500, Alan Stern wrote: >> I tried just not setting as->userbuffer if usbm == NULL, and lo and behold, >> it actually seems to help. > In fact, there's no need to call copy_urb_data_to_user at all if the > buffer lies in the mmap'ed area. usbm != NULL is meant

Re: Page allocation failure

On Fri, Nov 13, 2015 at 04:02:48PM -0500, Alan Stern wrote: >> So what is the road from here? I guess the original questions about cache >> coherency still apply, and that this is what I'm seeing in dmesg. > What questions? It should be obvious that the user program should not > touch the buffer

Re: Page allocation failure

On Fri, 13 Nov 2015, Steinar H. Gunderson wrote: > On Fri, Nov 13, 2015 at 06:50:27PM +0100, Steinar H. Gunderson wrote: > > The stack trace is simple enough, although I fear there's some inlining > > going > > on: > > OK, I guess since copy_user_enhanced_fast_string is an assembler function, >

Re: Page allocation failure

On Fri, 13 Nov 2015, Steinar H. Gunderson wrote: > So what is the road from here? I guess the original questions about cache > coherency still apply, and that this is what I'm seeing in dmesg. What questions? It should be obvious that the user program should not touch the buffer contents while

Re: Page allocation failure

On Tue, 10 Nov 2015, Steinar H. Gunderson wrote: > On Mon, Nov 02, 2015 at 11:48:36AM -0500, Alan Stern wrote: > > Order 7? Maybe you're trying to put too much data into a single > > transfer and encountering problems with memory fragmentation. Try > > using more frequent, smaller transfers. >

Re: Page allocation failure

On Thu, Nov 12, 2015 at 05:08:32PM -0500, Alan Stern wrote: > You're right; I got the two patch sets mixed up. Considering that it > was written a couple of years ago, you'll probably have to do some work > to get it to apply to the current kernel. Let me know if you need any > help. There

Re: Page allocation failure

On Fri, Nov 13, 2015 at 12:00:53AM +0100, Steinar H. Gunderson wrote: > I guess I should either add some debug printks or else see if there's > anything in the snooping that can help me track it down. Interestingly enough, I get this at startup: [ 3316.681227] x86/PAT: app:4154 map pfn RAM range

Re: Page allocation failure

d if I go even further down, I can't seem to keep up the data stream reliably, even with realtime priority on my USB thread -- perhaps not so strange, since that's ~1000 submits per second already). [209244.299476] nageru: page allocation failure: order:5, mode:0x2040d0 [209244.299486] CPU: 3

Re: Page allocation failure

On Mon, 2 Nov 2015, Steinar H. Gunderson wrote: > > Once the data is in the kernel, the rest of the procedure is basically > > zero-copy. The problem is getting it there from within your program. > > We currently don't have any support for zero-copy data submissions, > > although it has been

Re: Page allocation failure

On Mon, Nov 02, 2015 at 11:48:36AM -0500, Alan Stern wrote: > Order 7? Maybe you're trying to put too much data into a single > transfer and encountering problems with memory fragmentation. Try > using more frequent, smaller transfers. Yes, my transfers are rather big; 512 kB or so. (They used

Re: Page allocation failure

problems on URB submission: > > [82029.656250] nageru: page allocation failure: order:7, mode:0x2040d0 ... Order 7? Maybe you're trying to put too much data into a single transfer and encountering problems with memory fragmentation. Try using more frequent, smaller transfers. > After it's go

Page allocation failure

Hello again, I am (still) using libusb-1.0 to drive an USB 3.0 video card. After I turned off power management (see previous emails :-) ) it seems stable, but after running something like 5–6 hours, I seem to get problems on URB submission: [82029.656250] nageru: page allocation failure: order

Re: Page allocation failure on v3.8-rc5

On Wed, 30 Jan 2013 19:53:22 +0800 Ming Lei ming@canonical.com wrote: The allocation failure is caused by the big sizeof(struct parsed_partitions), which is 64K in my 32bit box, Geeze. We could fix that nicely by making parsed_partitions.parts an array of pointers to a single `struct

Re: Page allocation failure on v3.8-rc5

On Fri, Feb 1, 2013 at 7:43 AM, Andrew Morton a...@linux-foundation.org wrote: On Wed, 30 Jan 2013 19:53:22 +0800 Ming Lei ming@canonical.com wrote: The allocation failure is caused by the big sizeof(struct parsed_partitions), which is 64K in my 32bit box, Geeze. We could fix that

Re: Page allocation failure on v3.8-rc5

On Mon, Jan 28, 2013 at 5:10 PM, Felipe Balbi ba...@ti.com wrote: Hi, The following page allocation failure triggers sometimes when I plug my memory card reader on a USB port. [850845.928795] usb 1-4: new high-speed USB device number 48 using ehci-pci [850846.300702] usb 1-4: New USB

Page allocation failure on v3.8-rc5

Hi, The following page allocation failure triggers sometimes when I plug my memory card reader on a USB port. [850845.928795] usb 1-4: new high-speed USB device number 48 using ehci-pci [850846.300702] usb 1-4: New USB device found, idVendor=0bda, idProduct=0119 [850846.300707] usb 1-4: New USB

v3.8-rc4: Page Allocation Failure

] kworker/u:3: page allocation failure: order:4, mode:0x2000d0 [632214.259071] Pid: 15804, comm: kworker/u:3 Tainted: GW3.8.0-rc4+ #206 [632214.259073] Call Trace: [632214.259083] [810d02a8] ? warn_alloc_failed+0x116/0x128 [632214.259088] [810d31d9

Re: v3.8-rc4: Page Allocation Failure

On Fri, 25 Jan 2013, Felipe Balbi wrote: Hi folks, This now started to happen on my development PC. I'm running v3.8-rc4 with my gadget-specific patches (nothing on the Host side, no gadget code is running here). Below you will find dmesg of the failure which just triggered. Looks like

[150813.679919] kworker/u:2: page allocation failure: order:4, mode:0x2000d0

Hi folks, not sure if someone has seen this before but I'm running v3.8-rc2 and have just gotten a page allocation failure by connecting a usb memory stick to my PC's root hub port. [150217.845632] usb 7-3: new high-speed USB device number 10 using ehci-pci [150218.217559] usb 7-3: New USB