Date:   Sun, 19 Mar 2017 18:29:32 -0300
From:   Diego Viola <diego.viola@...il.com>
To:     mathias.nyman@...el.com, Roger <rogerable@...ltek.com>
Cc:     Ulf Hansson <ulf.hansson@...aro.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Wei WANG <wei_wang@...lsil.com.cn>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linux USB List <linux-usb@...r.kernel.org>,
        Alan Stern <stern@...land.harvard.edu>
Subject: Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3
 is enabled

On Fri, Mar 17, 2017 at 5:18 PM, Diego Viola <diego.viola@...il.com> wrote:
> On Fri, Mar 17, 2017 at 1:57 PM, Diego Viola <diego.viola@...il.com> wrote:
>> On Fri, Mar 17, 2017 at 1:24 PM, Alan Stern <stern@...land.harvard.edu> wrote:
>>> On Fri, 17 Mar 2017, Diego Viola wrote:
>>>
>>>> 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
>>>
>>> I'm not an expert on xHCI.  This should be CC'ed to the xhci-hcd
>>> maintainer.
>>>
>>> Alan Stern
>>>
>>>>
>>>> Please let me know if I should provide something else.
>>>>
>>>> Thanks,
>>>> Diego
>>>>
>>>
>>
>> I've forwarded my email to Mathias Nyman.
>>
>> Diego
>
> Still a problem with 4.11.0-rc2-ARCH+
>
> commit d528ae0d3dfedea553812c957a6ed1e87feeed8a

I have had a conversation with oiaohm over IRC about this, some
interesting things he had said about this issue:

2017-03-18 18:08:02     oiaohm  That driver that was going dead
because because it was physical port less was usb stack.   So maybe it
that bit of hardware still doing stupid.

2017-03-18 18:21:44     oiaohm  I guess this current log of yours is
with the realtek memstick black listed.
2017-03-18 18:21:55     oiaohm  because it does not exist.
2017-03-18 18:22:09     oiaohm  physically.

2017-03-18 18:23:04     oiaohm  Maybe.   If the hardware is not inited
the usb stack might not try to suspend it.

2017-03-18 18:26:30     oiaohm  No matter how you look at it the thing
is broken hardware.   I don't know if that realtek is USB 3.0
2017-03-18 18:27:02     oiaohm  Or it sitting on a USB 3.0 hub inside
the machine.

2017-03-18 18:27:39     oiaohm  You cannot expect a driver to work
when the hardware is portless.
2017-03-18 18:27:51     oiaohm  and it should have a port.
2017-03-18 18:27:52     oiaohm  either.

2017-03-18 18:29:03     oiaohm  rtsx_usb_ms this is a memstick driver
there should be  memstick port on you system or a header for a
memstick port both mean the pull down and pull up circiuts are present
so the hardware cannot function right.
2017-03-18 18:29:38     oiaohm  You gone over the machine and there is
no memstick port exposed being a laptop the odds of internal header is
basically never happens.
2017-03-18 18:30:27     oiaohm  so it broken hardware.
2017-03-18 18:31:18     oiaohm  the correct answer with broken
hardware is don't init the part blacklist the driver.

2017-03-18 18:40:36     oiaohm  You can think of it this way the
hardware gets lost because it cannot tell if something is connected so
is sending messages and waiting for responses that will never come.
But when hardware is there due to different speeds of cards it has no
clear clue what the time frame is.
2017-03-18 18:41:27     oiaohm  So the hardware being lost and kinda
jammed is purely to be excepted if it does not have all it required
circuits to function.

2017-03-18 18:48:42     oiaohm  You have the realtek controller for a
memstick port and it cannot tell if the proper hardware is present or
not that is what is triggering the driver to load.
2017-03-18 18:49:18     oiaohm  There is a difference when you have
the USB 3.0 controller active.
2017-03-18 18:49:49     oiaohm  You will see a lot of windows users
noting they need to disable the USB 3.0 controller to hibernate.
2017-03-18 18:50:19     oiaohm  In usb 2.0 the operating system polls
the USB ports and does a lot of the messaging.   In USB 3.0 controller
it does that polling.
2017-03-18 18:50:40     oiaohm  USB 3.0 controllers normally presume
all the hardware that is inited is functional.
2017-03-18 18:51:07     oiaohm  Linux kernel doing USB 2.0 polling
itself presumes the hardware could be busted.
2017-03-18 18:56:37     oiaohm  USB 3.0 controller is interpret driven
to the OS so it does a lot of heavy lifting of USB by itself.     USB
2.0 and before controllers are like win modems basically brainless and
depending on the OS todo everything thing.

2017-03-18 18:58:27     oiaohm  So usb 2.0 controller not showing the
issue and the usb 3.0 showing the issue is kind of expected.   If you
did not init the hardware and usb 3.0 controller still showed a issue
then there would be a problem.
2017-03-18 19:02:59     oiaohm  dviola I guess the only thing you were
missing is that the USB 3.0 controller had proper controller so can
think for itself and USB 2.0 and before is like a brainless winmoden
so the OS can work around a few USB hardware issues in USB 2.0
controller mode.

2017-03-18 19:09:58     oiaohm  do remember the difference between usb
2.0 and usb 3.0 at times you have no choice but to force back to usb
2.0
2017-03-18 19:10:12     oiaohm  With broken bits of hardware.

2017-03-18 22:30:38     oiaohm  I think everyone is being confused by
a basic hardware construciton cost cutting move.
2017-03-18 22:31:18     oiaohm  Now maybe they will be able to come up
with some solution to allow memmory stick part of the realtek where it
not a port to be sanely not inited.

Powered by blists - more mailing lists