On Thu, Mar 16, 2017 at 2:14 PM, Diego Viola <diego.viola@xxxxxxxxx> wrote: > On Thu, Mar 16, 2017 at 12:07 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: >> On Thu, 16 Mar 2017, Ulf Hansson wrote: >> >>> +Alan >>> >>> On 15 March 2017 at 15:00, Diego Viola <diego.viola@xxxxxxxxx> wrote: >>> > On Tue, Mar 14, 2017 at 4:15 PM, Diego Viola <diego.viola@xxxxxxxxx> wrote: >>> >> On Tue, Mar 14, 2017 at 2:20 PM, Diego Viola <diego.viola@xxxxxxxxx> wrote: >>> >>> On Thu, Mar 9, 2017 at 2:15 PM, Diego Viola <diego.viola@xxxxxxxxx> wrote: >>> >>>> On Thu, Mar 9, 2017 at 11:11 AM, Diego Viola <diego.viola@xxxxxxxxx> wrote: >>> >>>>> On Wed, Mar 8, 2017 at 5:40 PM, Diego Viola <diego.viola@xxxxxxxxx> wrote: >>> >>>>>> Hi Greg, >>> >>>>>> >>> >>>>>> On Wed, Mar 8, 2017 at 5:15 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: >>> >>>>>>> On Wed, Mar 08, 2017 at 03:49:19PM -0300, Diego Viola wrote: >>> >>>>>>>> It hangs on resume from suspend if I have USB 3.0 enabled on the BIOS, >>> >>>>>>>> it works fine with ehci_hcd or USB 2.0. >>> >>>>>>>> >>> >>>>>>>> The way I reproduce the problem is with this command: >>> >>>>>>>> >>> >>>>>>>> $ i3lock && systemctl suspend >>> >>>>>>>> >>> >>>>>>>> This is what I see on the screen when it hangs: >>> >>>>>>>> >>> >>>>>>>> https://dl.dropboxusercontent.com/u/6005119/dell/IMG_20170308_095000.jpg >>> >>>>>>>> https://dl.dropboxusercontent.com/u/6005119/dell/IMG_20170307_133928.jpg >>> >>>>>>>> >>> >>>>>>>> Some logs: >>> >>>>>>>> >>> >>>>>>>> https://dl.dropboxusercontent.com/u/6005119/dell/dmesg1.txt >>> >>>>>>>> https://dl.dropboxusercontent.com/u/6005119/dell/dmesg2.txt >>> >>>>>>>> >>> >>>>>>>> I'm on Arch Linux x86_64, kernel 4.9.11-1-ARCH. >>> >>>>>>>> >>> >>>>>>>> I also tried Linux 4.10.1 and I could reproduce this problem there as well. >>> >>>>>>>> >>> >>>>>>>> Please let me know if I could provide more info. >>> >>>>>>> >>> >>>>>>> Has any previous kernel ever worked properly before? If so, any chance >>> >>>>>>> you can use 'git bisect' to find the offending commit? >>> >>>>>> >>> >>>>>> I'm not sure, this is my work machine and I've only started using it >>> >>>>>> recently (since about a month ago or so). >>> >>>>>> >>> >>>>>> I will try older kernels and see if I get any different results, I >>> >>>>>> will report back in any case. >>> >>>>>> >>> >>>>>>> >>> >>>>>>> And are you sure you have updated your bios to the latest version? >>> >>>>>> >>> >>>>>> Yes. >>> >>>>>> >>> >>>>>>> >>> >>>>>>> thanks, >>> >>>>>>> >>> >>>>>>> greg k-h >>> >>>>>> >>> >>>>>> Thanks, >>> >>>>>> Diego >>> >>>>> >>> >>>>> I found another workaround, I can suspend/resume fine with `i3lock && >>> >>>>> systemctl suspend` if I disconnect/unplug all my USB devices >>> >>>>> (keyboard, mouse, etc). This with the default settings in the BIOS >>> >>>>> (both USB 2.0 and 3.0 enabled). >>> >>>>> >>> >>>>> I'm also seeing some messages like this in dmesg: >>> >>>>> >>> >>>>> [ 16.172190] usb 2-6: device descriptor read/64, error -110 >>> >>>>> >>> >>>>> Would this indicate a hardware/firmware/power issue? >>> >>>>> >>> >>>>> Thanks, >>> >>>>> Diego >>> >>>> >>> >>>> OK, I've built Linux 4.4.52 (I did a localmodconfig) and rebooted into >>> >>>> it, I did a suspend/resume and it hanged the first time I tried to >>> >>>> resume, which isn't much different than using the latest kernel. >>> >>>> >>> >>>> My dmesg is still being spammed with these messages: >>> >>>> >>> >>>> [ 260.043673] usb 2-1: Device not responding to setup address. >>> >>>> [ 260.246918] usb 2-1: device not accepting address 15, error -71 >>> >>>> [ 260.633662] usb 2-1: new high-speed USB device number 17 using xhci_hcd >>> >>>> [ 261.341340] usb 2-1: USB disconnect, device number 17 >>> >>>> >>> >>>> I guess it's safe to assume at this point that this is a hardware problem? >>> >>>> >>> >>>> Thanks, >>> >>>> Diego >>> >>> >>> >>> Hello, >>> >>> >>> >>> I've found something interesting and what it seems to be the cause of >>> >>> my problem. >>> >>> >>> >>> As soon as I boot my system I can see this process being in the D-state: >>> >>> >>> >>> [root@myhost ~]# ps aux | grep " D" >>> >>> root 269 0.0 0.0 0 0 ? D 14:11 0:00 [rtsx_usb_ms_2] >>> >>> root 1424 0.0 0.0 10788 2172 pts/2 S+ 14:19 0:00 grep D >>> >>> [root@myhost ~]# >>> >>> >>> >>> I'm not exactly sure why that is, but if I do a 'rmmod rtsx_usb_ms' >>> >>> the problem is gone. I already tried suspending/resuming ~40 times >>> >>> after I disabled the module and the suspend/resume problem is gone. >>> >>> That's a good observation! >>> >>> It suspect the drivers/memstick/host/rtsx_usb_ms.c isn't behaving >>> properly from PM point of view. Perhaps it tries to access its device >>> while it from a runtime PM point view still is in a runtime suspended >>> state. Exactly why I don't know yet. >>> >>> Moreover we have had issues with this driver before and its >>> corresponding SD card driver in drivers/mmc/host/rtsx_usb_sdmmc.c. On >>> top of that, both their corresponding devices shares the same usb mfd >>> device as parent, which is managed by drivers/mfd/rtsx_usb.c. >>> >>> Unfortunate my knowledge about USB is still in the learning phase, >>> however I know well about runtime PM ans system suspend, so perhaps I >>> still might be able to help. >>> >>> Anyway, I have looped in Alan, let's see if he has some input to this. >> >> Is the rtsx_usb_ms device attached to an xHCI controller? >> >> How is the hang during resume related to the actions of the xhci-hcd >> driver? (You'll probably need to enable dynamic debugging for xhci-hcd >> and use a network console to get the answer.) >> >> If this problem really is related to xhci-hcd, have you tried bringing >> it to the attention of the xhci-hcd maintainer? >> >> Are you using the most up-to-date version of the kernel? xhci-hcd is >> still getting fixes at a very high rate. >> >> Alan Stern >> >>> >>> >>> >>> Diego >>> >> >>> >> Adding Roger Tseng to the CC also. >>> >> >>> >> Diego >>> > >>> > According to this document: >>> > >>> > http://downloads.dell.com/manuals/all-products/esuprt_laptop/esuprt_inspiron_laptop/inspiron-15-5558-laptop_reference%20guide_en-us.pdf >>> > >>> > My computer only has a SD card slot and no MEMSTICK slot. >>> > >>> > lsusb says this though: >>> > >>> > Bus 001 Device 005: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 >>> > Card Reader Controller >>> > >>> > Maybe the driver gets locked up looking for the MEMSTICK slot? >>> >>> Yes correct! >>> >>> > >>> > Diego >>> >>> Kind regards >>> Uffe >>> >> > > Alan, > > I'm not sure if you saw or if it's useful, but I already got a trace > with netconsole a while ago while trying to reproduce the hang: > > https://bugzilla.kernel.org/attachment.cgi?id=255227 > > Could you point me to some instructions about enabling dynamic > debugging for xhci-hcd? > > Thanks, > Diego Already explained here. https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/dynamic-debug-howto.rst -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
