On Thu, Mar 16, 2017 at 12:51 PM, Diego Viola <diego.viola@xxxxxxxxx> wrote: > On Thu, Mar 16, 2017 at 12:45 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? >> >> I think so, I'm not sure. >> >> lsusb -t reveals rtsx_usb is under xhci_hcd as seen here: >> >> https://bugzilla.kernel.org/attachment.cgi?id=255301 >> >> Also, I tried disabling USB 3.0 from the BIOS and I'm still able to >> see rtsx_usb_ms is being loaded after that and the [rtsx_usb_ms_2] >> also shows up as a D-state process still, but no hanging occurs when >> USB 3.0 (xhci_hcd) is disabled. >> >>> >>> 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.) >> >> OK, I'll do this and get back with a trace. >> >>> >>> If this problem really is related to xhci-hcd, have you tried bringing >>> it to the attention of the xhci-hcd maintainer? >> >> No, not yet. I'm also not sure who the current maintainer for xhci_hcd is? >> >> modinfo says the author is Sarah Sharp but does she still maintains it? >> >>> >>> Are you using the most up-to-date version of the kernel? xhci-hcd is >>> still getting fixes at a very high rate. >> >> Yes, I'm currently on 4.10.2-ARCH. >> >> I will keep an eye on xhci_hcd changes on the latest git and give them >> a try also. >> >>> >>> 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 >>>> >>> >> >> Thanks, >> Diego > > lsusb -t with USB 3.0 disabled on BIOS: > > https://bugzilla.kernel.org/attachment.cgi?id=255303 > > Diego Hrm, that's rtsx_usb and not rtsx_usb_ms. I'm getting confused here. Diego -- 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
