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 guess it can also be CC: stable@ since it started in 4.4. Regards, -- Yves-Alexis -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Page allocation failure (order 7) in UAS code
Hi, On 04-03-16 08:13, Yves-Alexis Perez wrote: On mar., 2016-03-01 at 11:49 +0100, Hans de Goede wrote: Hi, On 01-03-16 10:42, Yves-Alexis Perez wrote: Hi, [sorry if this is not the right point for reporting bugs, I took the email addresses from MAINTAINERS but please point 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 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 : .can_queue = 65536, /* Is there a limit on the _host_ ? */ (around line 815) Replaced with .can_queue = MAX_CMNDS, That should help as MAX_CMNDS is 256, so claiming that we can queue more is not helpful, and that likely is what is causing this quite high order alloc. After a few days, it seems that it does work fine, although I can't say anything about sides effects. 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. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Page allocation failure (order 7) in UAS code
On mar., 2016-03-01 at 11:49 +0100, Hans de Goede wrote: > Hi, > > On 01-03-16 10:42, Yves-Alexis Perez wrote: > > > > Hi, > > > > [sorry if this is not the right point for reporting bugs, I took the email > > addresses from MAINTAINERS but please point 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 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 : > > .can_queue = 65536, /* Is there a limit on the _host_ ? */ > > (around line 815) Replaced with > > .can_queue = MAX_CMNDS, > > That should help as MAX_CMNDS is 256, so claiming that we can queue more > is not helpful, and that likely is what is causing this quite high order > alloc. After a few days, it seems that it does work fine, although I can't say anything about sides effects. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
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, > > That should help as MAX_CMNDS is 256, so claiming that we can queue more > is not helpful, and that likely is what is causing this quite high order > alloc. Hi, I've rebuilt a 4.4.3 + above patch. I'll report back in few hours to see if I can still reproduce. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Page allocation failure (order 7) in UAS code
Hi, On 01-03-16 10:42, Yves-Alexis Perez wrote: Hi, [sorry if this is not the right point for reporting bugs, I took the email addresses from MAINTAINERS but please point 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 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 : .can_queue = 65536, /* Is there a limit on the _host_ ? */ (around line 815) Replaced with .can_queue = MAX_CMNDS, That should help as MAX_CMNDS is 256, so claiming that we can queue more is not helpful, and that likely is what is causing this quite high order alloc. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Page allocation failure (order 7) in UAS code
Hi, [sorry if this is not the right point for reporting bugs, I took the email addresses from MAINTAINERS but please point 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 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: [26557.285884] usb 2-2: New USB device found, idVendor=04e8, idProduct=61b6 Feb 22 10:57:56 scapa kernel: [26557.285888] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Feb 22 10:57:56 scapa kernel: [26557.285891] usb 2-2: Product: Samsung M3 Portable Feb 22 10:57:56 scapa kernel: [26557.285893] usb 2-2: Manufacturer: Samsung M3 Portable Feb 22 10:57:56 scapa kernel: [26557.285895] usb 2-2: SerialNumber: 826C7DFB1367 Feb 22 10:57:56 scapa kernel: [26557.293693] scsi host4: uas Feb 22 10:57:56 scapa kernel: [26557.293707] kworker/0:0: page allocation failure: order:7, mode:0x2204020 Feb 22 10:57:56 scapa kernel: [26557.293711] CPU: 0 PID: 11015 Comm: kworker/0:0 Tainted: GW 4.4.0-1-amd64 #1 Debian 4.4.2-3~a.test Feb 22 10:57:56 scapa kernel: [26557.293713] Hardware name: LENOVO 20CMCTO1WW/20CMCTO1WW, BIOS N10ET41W (1.20 ) 01/19/2016 Feb 22 10:57:56 scapa kernel: [26557.293724] Workqueue: usb_hub_wq hub_event [usbcore] Feb 22 10:57:56 scapa kernel: [26557.293727] c0207f69 812e7679 02204020 Feb 22 10:57:56 scapa kernel: [26557.293730] 8116b23a 0001c0207f69 88024dffbb20 Feb 22 10:57:56 scapa kernel: [26557.293733] 810b475e 0001020c8220 c0207f69 0046 Feb 22 10:57:56 scapa kernel: [26557.293736] Call Trace: Feb 22 10:57:56 scapa kernel: [26557.293741] [] ? dump_stack+0x40/0x57 Feb 22 10:57:56 scapa kernel: [26557.293745] [] ? warn_alloc_failed+0xfa/0x150 Feb 22 10:57:56 scapa kernel: [26557.293749] [] ? __wake_up_common+0x4e/0x90 Feb 22 10:57:56 scapa kernel: [26557.293752] [] ? __alloc_pages_nodemask+0x306/0xb70 Feb 22 10:57:56 scapa kernel: [26557.293757] [] ? kmem_getpages+0x51/0xf0 Feb 22 10:57:56 scapa kernel: [26557.293759] [] ? fallback_alloc+0x145/0x1f0 Feb 22 10:57:56 scapa kernel: [26557.293765] [] ? init_tag_map+0x38/0xb0 Feb 22 10:57:56 scapa kernel: [26557.293768] [] ? __kmalloc+0x17f/0x1c0 Feb 22 10:57:56 scapa kernel: [26557.293771] [] ? init_tag_map+0x38/0xb0 Feb 22 10:57:56 scapa kernel: [26557.293774] [] ? __blk_queue_init_tags+0x40/0x80 Feb 22 10:57:56 scapa kernel: [26557.293781] [] ? scsi_add_host_with_dma+0x7b/0x2f0 [scsi_mod] Feb 22 10:57:56 scapa kernel: [26557.293785] [] ? uas_probe+0x41a/0x560 [uas] Feb 22 10:57:56 scapa kernel: [26557.293796] [] ? usb_probe_interface+0x1b3/0x300 [usbcore] Feb 22 10:57:56 scapa kernel: [26557.293801] [] ? driver_probe_device+0x212/0x480 Feb 22 10:57:56 scapa kernel: [26557.293803] [] ? __driver_attach+0x80/0x80 Feb 22 10:57:56 scapa kernel: [26557.293806] [] ? bus_for_each_drv+0x62/0xb0 Feb 22 10:57:56 scapa kernel: [26557.293809] [] ? __device_attach+0xd8/0x160 Feb 22 10:57:56 scapa kernel: [26557.293811] [] ? bus_probe_device+0x87/0xa0 Feb 22 10:57:56 scapa kernel: [26557.293814] [] ? device_add+0x3f5/0x660 Feb 22 10:57:56 scapa kernel: [26557.293823] [] ? usb_set_configuration+0x51b/0x8f0 [usbcore] Feb 22 10:57:56 scapa kernel: [26557.293835] [] ? generic_probe+0x28/0x80 [usbcore] Feb 22 10:57:56 scapa kernel: [26557.293838] [] ? driver_probe_device+0x212/0x480 Feb 22 10:57:56 scapa kernel: [26557.293840] [] ? __driver_attach+0x80/0x80 Feb 22 10:57:56 scapa kernel: [26557.293842] [] ? bus_for_each_drv+0x62/0xb0 Feb 22 10:57:56 scapa kernel: [26557.293845] [] ? __device_attach+0xd8/0x160 Feb 22 10:57:56 scapa kernel: [26557.293847] [] ? bus_probe_device+0x87/0xa0 Feb 22 10:57:56 scapa kernel: [26557.293850] [] ? device_add+0x3f5/0x660 Feb 22 10:57:56 scapa kernel: [26557.293857] [] ? usb_new_device+0x265/0x490 [usbcore] Feb 22 10:57:56 scapa kernel: [26557.293864] [] ? hub_event+0xfb3/0x14f0 [usbcore] Feb 22 10:57:56 scapa kernel: [26557.293868] [] ? process_one_work+0x19f/0x3d0 Feb 22 10:57:56 scapa kernel: [26557.293871] [] ? worker_thread+0x4d/0x450 Feb 22 10:57:56 scapa kernel: [26557.293873] [] ? process_one_work+0x3d0/0x3d0 Feb 22 10:57:56 scapa kernel: [26557.293876] [] ? kthread+0xcd/0xf0 Feb 22 10:57:56 scapa kernel: [26557.293879] [] ? kthread_create_on_node+0x190/0x190 Feb 22 10:57:56 scapa kernel: [26557.293883] [] ? ret_from_fork+0x3f/0x70 Feb 22 10:57:56 scapa kernel: [26557.293886] [] ? kthread_create_on_node+0x190/0x190 Feb 22 10:57:56 scapa kernel: [26557.293888] Mem-Info: Feb 22 10:57:56 scapa kernel: [26557.293892] active_anon:1
