Re: [xhci-hcd][linux 4.20.13] autosuspend on causes a single cpu core to stay in kernel mode using 100% of said cpu core.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ups I just realised I didn't sent the message to the mailing list, but
instead send it to greg only;
Basically the problem was happening a month ago on version 4.20.7 ,I
have reported it to my distros bug report but I didn't got any
response about it.
It was consistent on every reboot and shutdown.
Even installing a kernel package which previously didn't had any
issues didn't fixed the issue so kernels 4.20 - 4.20.7 were also
eating one of my cpu cores.
(I didn't had any other older version at the time because I did a
clean install of windows and then of linux).
I run linux with 1 less cpu core for about a week until I found out
that I can disable autosuspend.

I tried to trigger the error this time around on versions 4.20-4.20.13
even on 4.20.7 where it first occured. And it refuses to happen again,
the only thing I really have from this occurrence is perf data, which
I used to find out which kernel module was eating my cpu core.
This issue was happening regardless of connected usb devices and
regardless of whether I was putting the machine to sleep or not.

pon., 4 mar 2019 o 13:28 Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx>
napisał(a):
>
> On 3.3.2019 16.30, Greg KH wrote:
> > On Sun, Mar 03, 2019 at 03:15:27PM +0100, Farelka kek wrote:
> >> usbcore.autosuspend higher than -1, causes 1 cpu core to never step
> >> down from kernel mode.
> >
> > Some hardware does not aupport autosuspend, so leaving it at -1 is good.
> >
> >> It happens on a core i5-7200U laptop, an acer f5-573g-50ec
> >> Disabling usb autosuspend causes the cpu not to idle at, minimum of
> >> 25% cpu usage.
> >
> > Is this a regression from earlier kernel versions?  If so, any chance
> > you can run 'git bisect' to find the offending commit?
> >
>
> It could be the following patch:
>
> 2f31a67 usb: xhci: Prevent bus suspend if a port connect change or polling state is detected
>
> It caused similar issues on MacBookPro because of broken usb card reader stuck
> in polling state.
>
> Farelka kek, If that's the case for you, could you try a fix I wrote?
> I added the fix on top of 4.20.13 in a suspend_fix branch:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git suspend_fix
> https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/commit/?h=suspend_fix
>
> -Mathias




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux