Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1600732 > unrolled thread

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

Started byDiego Viola <diego.viola@gmail.com>
First post2017-03-14 18:30 +0100
Last post2017-03-17 17:30 +0100
Articles 12 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3  is enabled Diego Viola <diego.viola@gmail.com> - 2017-03-14 18:30 +0100
    Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3  is enabled Diego Viola <diego.viola@gmail.com> - 2017-03-14 20:20 +0100
      Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3  is enabled Diego Viola <diego.viola@gmail.com> - 2017-03-15 15:10 +0100
        Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3  is enabled Ulf Hansson <ulf.hansson@linaro.org> - 2017-03-16 15:10 +0100
          Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB  3 is enabled Alan Stern <stern@rowland.harvard.edu> - 2017-03-16 16:10 +0100
            Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3  is enabled Diego Viola <diego.viola@gmail.com> - 2017-03-16 17:00 +0100
              Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3  is enabled Diego Viola <diego.viola@gmail.com> - 2017-03-16 17:10 +0100
                Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3  is enabled Diego Viola <diego.viola@gmail.com> - 2017-03-16 17:20 +0100
            Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3  is enabled Diego Viola <diego.viola@gmail.com> - 2017-03-16 17:00 +0100
            Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3  is enabled Diego Viola <diego.viola@gmail.com> - 2017-03-16 18:20 +0100
              Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3  is enabled Diego Viola <diego.viola@gmail.com> - 2017-03-16 19:50 +0100
            Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3  is enabled Diego Viola <diego.viola@gmail.com> - 2017-03-17 17:30 +0100

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

FromDiego Viola <diego.viola@gmail.com>
Date2017-03-14 18:30 +0100
SubjectRe: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled
Message-ID<tkYqJ-3pv-1@gated-at.bofh.it>
On Thu, Mar 9, 2017 at 2:15 PM, Diego Viola <diego.viola@gmail.com> wrote:
> On Thu, Mar 9, 2017 at 11:11 AM, Diego Viola <diego.viola@gmail.com> wrote:
>> On Wed, Mar 8, 2017 at 5:40 PM, Diego Viola <diego.viola@gmail.com> wrote:
>>> Hi Greg,
>>>
>>> On Wed, Mar 8, 2017 at 5:15 PM, Greg KH <gregkh@linuxfoundation.org> 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.

Diego

[toc] | [next] | [standalone]

#1600839

FromDiego Viola <diego.viola@gmail.com>
Date2017-03-14 20:20 +0100
Message-ID<tl09c-4Iz-23@gated-at.bofh.it>
In reply to#1600732
On Tue, Mar 14, 2017 at 2:20 PM, Diego Viola <diego.viola@gmail.com> wrote:
> On Thu, Mar 9, 2017 at 2:15 PM, Diego Viola <diego.viola@gmail.com> wrote:
>> On Thu, Mar 9, 2017 at 11:11 AM, Diego Viola <diego.viola@gmail.com> wrote:
>>> On Wed, Mar 8, 2017 at 5:40 PM, Diego Viola <diego.viola@gmail.com> wrote:
>>>> Hi Greg,
>>>>
>>>> On Wed, Mar 8, 2017 at 5:15 PM, Greg KH <gregkh@linuxfoundation.org> 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.
>
> Diego

Adding Roger Tseng to the CC also.

Diego

[toc] | [prev] | [next] | [standalone]

#1601430

FromDiego Viola <diego.viola@gmail.com>
Date2017-03-15 15:10 +0100
Message-ID<tlhMK-gZ-35@gated-at.bofh.it>
In reply to#1600839
On Tue, Mar 14, 2017 at 4:15 PM, Diego Viola <diego.viola@gmail.com> wrote:
> On Tue, Mar 14, 2017 at 2:20 PM, Diego Viola <diego.viola@gmail.com> wrote:
>> On Thu, Mar 9, 2017 at 2:15 PM, Diego Viola <diego.viola@gmail.com> wrote:
>>> On Thu, Mar 9, 2017 at 11:11 AM, Diego Viola <diego.viola@gmail.com> wrote:
>>>> On Wed, Mar 8, 2017 at 5:40 PM, Diego Viola <diego.viola@gmail.com> wrote:
>>>>> Hi Greg,
>>>>>
>>>>> On Wed, Mar 8, 2017 at 5:15 PM, Greg KH <gregkh@linuxfoundation.org> 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.
>>
>> 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?

Diego

[toc] | [prev] | [next] | [standalone]

#1602316

FromUlf Hansson <ulf.hansson@linaro.org>
Date2017-03-16 15:10 +0100
Message-ID<tlEgj-7RT-43@gated-at.bofh.it>
In reply to#1601430
+Alan

On 15 March 2017 at 15:00, Diego Viola <diego.viola@gmail.com> wrote:
> On Tue, Mar 14, 2017 at 4:15 PM, Diego Viola <diego.viola@gmail.com> wrote:
>> On Tue, Mar 14, 2017 at 2:20 PM, Diego Viola <diego.viola@gmail.com> wrote:
>>> On Thu, Mar 9, 2017 at 2:15 PM, Diego Viola <diego.viola@gmail.com> wrote:
>>>> On Thu, Mar 9, 2017 at 11:11 AM, Diego Viola <diego.viola@gmail.com> wrote:
>>>>> On Wed, Mar 8, 2017 at 5:40 PM, Diego Viola <diego.viola@gmail.com> wrote:
>>>>>> Hi Greg,
>>>>>>
>>>>>> On Wed, Mar 8, 2017 at 5:15 PM, Greg KH <gregkh@linuxfoundation.org> 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.

>>>
>>> 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

[toc] | [prev] | [next] | [standalone]

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

FromAlan Stern <stern@rowland.harvard.edu>
Date2017-03-16 16:10 +0100
SubjectRe: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled
Message-ID<tlFco-97-57@gated-at.bofh.it>
In reply to#1602316
On Thu, 16 Mar 2017, Ulf Hansson wrote:

> +Alan
> 
> On 15 March 2017 at 15:00, Diego Viola <diego.viola@gmail.com> wrote:
> > On Tue, Mar 14, 2017 at 4:15 PM, Diego Viola <diego.viola@gmail.com> wrote:
> >> On Tue, Mar 14, 2017 at 2:20 PM, Diego Viola <diego.viola@gmail.com> wrote:
> >>> On Thu, Mar 9, 2017 at 2:15 PM, Diego Viola <diego.viola@gmail.com> wrote:
> >>>> On Thu, Mar 9, 2017 at 11:11 AM, Diego Viola <diego.viola@gmail.com> wrote:
> >>>>> On Wed, Mar 8, 2017 at 5:40 PM, Diego Viola <diego.viola@gmail.com> wrote:
> >>>>>> Hi Greg,
> >>>>>>
> >>>>>> On Wed, Mar 8, 2017 at 5:15 PM, Greg KH <gregkh@linuxfoundation.org> 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
>

[toc] | [prev] | [next] | [standalone]

#1602588

FromDiego Viola <diego.viola@gmail.com>
Date2017-03-16 17:00 +0100
Message-ID<tlFYJ-td-7@gated-at.bofh.it>
In reply to#1602475
On Thu, Mar 16, 2017 at 12:45 PM, Diego Viola <diego.viola@gmail.com> wrote:
> On Thu, Mar 16, 2017 at 12:07 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
>> On Thu, 16 Mar 2017, Ulf Hansson wrote:
>>
>>> +Alan
>>>
>>> On 15 March 2017 at 15:00, Diego Viola <diego.viola@gmail.com> wrote:
>>> > On Tue, Mar 14, 2017 at 4:15 PM, Diego Viola <diego.viola@gmail.com> wrote:
>>> >> On Tue, Mar 14, 2017 at 2:20 PM, Diego Viola <diego.viola@gmail.com> wrote:
>>> >>> On Thu, Mar 9, 2017 at 2:15 PM, Diego Viola <diego.viola@gmail.com> wrote:
>>> >>>> On Thu, Mar 9, 2017 at 11:11 AM, Diego Viola <diego.viola@gmail.com> wrote:
>>> >>>>> On Wed, Mar 8, 2017 at 5:40 PM, Diego Viola <diego.viola@gmail.com> wrote:
>>> >>>>>> Hi Greg,
>>> >>>>>>
>>> >>>>>> On Wed, Mar 8, 2017 at 5:15 PM, Greg KH <gregkh@linuxfoundation.org> 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

[toc] | [prev] | [next] | [standalone]

#1602602

FromDiego Viola <diego.viola@gmail.com>
Date2017-03-16 17:10 +0100
Message-ID<tlG8p-LZ-9@gated-at.bofh.it>
In reply to#1602588
On Thu, Mar 16, 2017 at 12:51 PM, Diego Viola <diego.viola@gmail.com> wrote:
> On Thu, Mar 16, 2017 at 12:45 PM, Diego Viola <diego.viola@gmail.com> wrote:
>> On Thu, Mar 16, 2017 at 12:07 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
>>> On Thu, 16 Mar 2017, Ulf Hansson wrote:
>>>
>>>> +Alan
>>>>
>>>> On 15 March 2017 at 15:00, Diego Viola <diego.viola@gmail.com> wrote:
>>>> > On Tue, Mar 14, 2017 at 4:15 PM, Diego Viola <diego.viola@gmail.com> wrote:
>>>> >> On Tue, Mar 14, 2017 at 2:20 PM, Diego Viola <diego.viola@gmail.com> wrote:
>>>> >>> On Thu, Mar 9, 2017 at 2:15 PM, Diego Viola <diego.viola@gmail.com> wrote:
>>>> >>>> On Thu, Mar 9, 2017 at 11:11 AM, Diego Viola <diego.viola@gmail.com> wrote:
>>>> >>>>> On Wed, Mar 8, 2017 at 5:40 PM, Diego Viola <diego.viola@gmail.com> wrote:
>>>> >>>>>> Hi Greg,
>>>> >>>>>>
>>>> >>>>>> On Wed, Mar 8, 2017 at 5:15 PM, Greg KH <gregkh@linuxfoundation.org> 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

[toc] | [prev] | [next] | [standalone]

#1602613

FromDiego Viola <diego.viola@gmail.com>
Date2017-03-16 17:20 +0100
Message-ID<tlGi5-RT-11@gated-at.bofh.it>
In reply to#1602602
On Thu, Mar 16, 2017 at 1:02 PM, Diego Viola <diego.viola@gmail.com> wrote:
> On Thu, Mar 16, 2017 at 12:51 PM, Diego Viola <diego.viola@gmail.com> wrote:
>> On Thu, Mar 16, 2017 at 12:45 PM, Diego Viola <diego.viola@gmail.com> wrote:
>>> On Thu, Mar 16, 2017 at 12:07 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
>>>> On Thu, 16 Mar 2017, Ulf Hansson wrote:
>>>>
>>>>> +Alan
>>>>>
>>>>> On 15 March 2017 at 15:00, Diego Viola <diego.viola@gmail.com> wrote:
>>>>> > On Tue, Mar 14, 2017 at 4:15 PM, Diego Viola <diego.viola@gmail.com> wrote:
>>>>> >> On Tue, Mar 14, 2017 at 2:20 PM, Diego Viola <diego.viola@gmail.com> wrote:
>>>>> >>> On Thu, Mar 9, 2017 at 2:15 PM, Diego Viola <diego.viola@gmail.com> wrote:
>>>>> >>>> On Thu, Mar 9, 2017 at 11:11 AM, Diego Viola <diego.viola@gmail.com> wrote:
>>>>> >>>>> On Wed, Mar 8, 2017 at 5:40 PM, Diego Viola <diego.viola@gmail.com> wrote:
>>>>> >>>>>> Hi Greg,
>>>>> >>>>>>
>>>>> >>>>>> On Wed, Mar 8, 2017 at 5:15 PM, Greg KH <gregkh@linuxfoundation.org> 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

CC Mathias Nyman

[toc] | [prev] | [next] | [standalone]

#1602589

FromDiego Viola <diego.viola@gmail.com>
Date2017-03-16 17:00 +0100
Message-ID<tlFYJ-td-9@gated-at.bofh.it>
In reply to#1602475
On Thu, Mar 16, 2017 at 12:07 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Thu, 16 Mar 2017, Ulf Hansson wrote:
>
>> +Alan
>>
>> On 15 March 2017 at 15:00, Diego Viola <diego.viola@gmail.com> wrote:
>> > On Tue, Mar 14, 2017 at 4:15 PM, Diego Viola <diego.viola@gmail.com> wrote:
>> >> On Tue, Mar 14, 2017 at 2:20 PM, Diego Viola <diego.viola@gmail.com> wrote:
>> >>> On Thu, Mar 9, 2017 at 2:15 PM, Diego Viola <diego.viola@gmail.com> wrote:
>> >>>> On Thu, Mar 9, 2017 at 11:11 AM, Diego Viola <diego.viola@gmail.com> wrote:
>> >>>>> On Wed, Mar 8, 2017 at 5:40 PM, Diego Viola <diego.viola@gmail.com> wrote:
>> >>>>>> Hi Greg,
>> >>>>>>
>> >>>>>> On Wed, Mar 8, 2017 at 5:15 PM, Greg KH <gregkh@linuxfoundation.org> 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

[toc] | [prev] | [next] | [standalone]

#1602676

FromDiego Viola <diego.viola@gmail.com>
Date2017-03-16 18:20 +0100
Message-ID<tlHea-1vE-7@gated-at.bofh.it>
In reply to#1602475
On Thu, Mar 16, 2017 at 12:07 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Thu, 16 Mar 2017, Ulf Hansson wrote:
>
>> +Alan
>>
>> On 15 March 2017 at 15:00, Diego Viola <diego.viola@gmail.com> wrote:
>> > On Tue, Mar 14, 2017 at 4:15 PM, Diego Viola <diego.viola@gmail.com> wrote:
>> >> On Tue, Mar 14, 2017 at 2:20 PM, Diego Viola <diego.viola@gmail.com> wrote:
>> >>> On Thu, Mar 9, 2017 at 2:15 PM, Diego Viola <diego.viola@gmail.com> wrote:
>> >>>> On Thu, Mar 9, 2017 at 11:11 AM, Diego Viola <diego.viola@gmail.com> wrote:
>> >>>>> On Wed, Mar 8, 2017 at 5:40 PM, Diego Viola <diego.viola@gmail.com> wrote:
>> >>>>>> Hi Greg,
>> >>>>>>
>> >>>>>> On Wed, Mar 8, 2017 at 5:15 PM, Greg KH <gregkh@linuxfoundation.org> 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

[toc] | [prev] | [next] | [standalone]

#1602774

FromDiego Viola <diego.viola@gmail.com>
Date2017-03-16 19:50 +0100
Message-ID<tlIDg-2mJ-19@gated-at.bofh.it>
In reply to#1602676
On Thu, Mar 16, 2017 at 2:14 PM, Diego Viola <diego.viola@gmail.com> wrote:
> On Thu, Mar 16, 2017 at 12:07 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
>> On Thu, 16 Mar 2017, Ulf Hansson wrote:
>>
>>> +Alan
>>>
>>> On 15 March 2017 at 15:00, Diego Viola <diego.viola@gmail.com> wrote:
>>> > On Tue, Mar 14, 2017 at 4:15 PM, Diego Viola <diego.viola@gmail.com> wrote:
>>> >> On Tue, Mar 14, 2017 at 2:20 PM, Diego Viola <diego.viola@gmail.com> wrote:
>>> >>> On Thu, Mar 9, 2017 at 2:15 PM, Diego Viola <diego.viola@gmail.com> wrote:
>>> >>>> On Thu, Mar 9, 2017 at 11:11 AM, Diego Viola <diego.viola@gmail.com> wrote:
>>> >>>>> On Wed, Mar 8, 2017 at 5:40 PM, Diego Viola <diego.viola@gmail.com> wrote:
>>> >>>>>> Hi Greg,
>>> >>>>>>
>>> >>>>>> On Wed, Mar 8, 2017 at 5:15 PM, Greg KH <gregkh@linuxfoundation.org> 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

[toc] | [prev] | [next] | [standalone]

#1603442

FromDiego Viola <diego.viola@gmail.com>
Date2017-03-17 17:30 +0100
Message-ID<tm2Vj-Og-3@gated-at.bofh.it>
In reply to#1602475
On Thu, Mar 16, 2017 at 12:07 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Thu, 16 Mar 2017, Ulf Hansson wrote:
>
>> +Alan
>>
>> On 15 March 2017 at 15:00, Diego Viola <diego.viola@gmail.com> wrote:
>> > On Tue, Mar 14, 2017 at 4:15 PM, Diego Viola <diego.viola@gmail.com> wrote:
>> >> On Tue, Mar 14, 2017 at 2:20 PM, Diego Viola <diego.viola@gmail.com> wrote:
>> >>> On Thu, Mar 9, 2017 at 2:15 PM, Diego Viola <diego.viola@gmail.com> wrote:
>> >>>> On Thu, Mar 9, 2017 at 11:11 AM, Diego Viola <diego.viola@gmail.com> wrote:
>> >>>>> On Wed, Mar 8, 2017 at 5:40 PM, Diego Viola <diego.viola@gmail.com> wrote:
>> >>>>>> Hi Greg,
>> >>>>>>
>> >>>>>> On Wed, Mar 8, 2017 at 5:15 PM, Greg KH <gregkh@linuxfoundation.org> 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
>>
>

Hi,

Here's the log to the netconsole dmesg capture, I've used
xhci_hcd.dyndbg no_console_suspend=1 as the kernel parameters.

I did the usual suspend/resume cycle with i3lock, it hung after the
third attempt when trying to resume from suspend.

https://bugzilla.kernel.org/attachment.cgi?id=255309

Please let me know if I should provide something else.

Thanks,
Diego

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web