Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled

[Diego Viola]

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