linux-kernel - Re: [PATCH] usbnet: prevent device rpm suspend in usbnet

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAd53p6unhMOPRux+HOB9unLy2Et47gcH5SV6H947-=_gS3DPw@mail.gmail.com>
Date:   Mon, 14 Nov 2016 15:34:29 +0800
From:   Kai-Heng Feng <kai.heng.feng@...onical.com>
To:     Mathias Nyman <mathias.nyman@...ux.intel.com>
Cc:     Oliver Neukum <oneukum@...e.com>,
        Bjørn Mork <bjorn@...k.no>,
        Alan Stern <stern@...land.harvard.edu>,
        linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
        netdev@...r.kernel.org
Subject: Re: [PATCH] usbnet: prevent device rpm suspend in usbnet_probe function

On Fri, Nov 11, 2016 at 10:44 PM, Mathias Nyman
<mathias.nyman@...ux.intel.com> wrote:
> On 10.11.2016 13:22, Oliver Neukum wrote:
>>
>> On Thu, 2016-11-10 at 12:09 +0100, Bjørn Mork wrote:
>>>
>>> Kai-Heng Feng <kai.heng.feng@...onical.com> writes:
>>>>
>>>> On Wed, Nov 9, 2016 at 8:32 PM, Bjørn Mork <bjorn@...k.no> wrote:
>>>>>
>>>>> Oliver Neukum <oneukum@...e.com> writes:
>>>>>
>>>>>> On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote:
>>>>>>
>>>>>>> These problems could very well be caused by running at SuperSpeed
>>>>>>> (USB-3) instead of high speed (USB-2).
>>>>
>>>>
>>>> Yes, it's running at SuperSpeed, on a Kabylake laptop.
>>>>
>>>> It does not have this issue on a Broadwell laptop, also running at
>>>> SuperSpeed.
>>>
>>>
>>> Then I must join Oliver, being very surprised by where in the stack you
>>> attempt to fix the issue.  What you write above indicates a problem in
>>> pci bridge or usb host controller, doesn't it?

Yes, I was totally wrong about that.

>>
>>
>> Indeed. And this means we need an XHCI specialist.
>> Mathias, we have a failure specific to one implementation of XHCI.
>>
>
>
> Could be related to resume singnalling time.
> Does the xhci fix for it in 4.9-rc3 help?
>
> commit 7d3b016a6f5a0fa610dfd02b05654c08fa4ae514
>     xhci: use default USB_RESUME_TIMEOUT when resuming ports.
>
> It doesn't directly explain why it would work on Broadwell but not Kabylake,
> but it resolved very similar cases.
>
> If not, then adding dynamic debug for xhci could show something.

I tried the latest commit, 6005a545cadb2adca64350c7aee17d002563e8c7,
on for-usb-next branch.

Now the cdc_mbim still probe failed at the first time, but somehow it
re-probed again with a success.

I reverted commit 7d3b016a6f5a0fa610dfd02b05654c08fa4ae514 and the
behavior is the same, first time probed failed, second time probed
success.

The attached dmesg is with usbcore and xhci_hcd dynamic debug enabled.

>
> -Mathias
>

Download attachment "dmesg" of type "application/octet-stream" (182402 bytes)