[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1907152055430.1767@nanos.tec.linutronix.de>
Date: Mon, 15 Jul 2019 21:09:44 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Octavio Alvarez <octallk1@...arezp.org>
cc: Linus Torvalds <torvalds@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>,
Marc Zyngier <marc.zyngier@....com>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
"Steven Rostedt (VMware)" <rostedt@...dmis.org>,
Jiang Biao <jiang.biao2@....com.cn>,
Yi Wang <wang.yi59@....com.cn>,
Dou Liyang <douly.fnst@...fujitsu.com>,
Nicolai Stange <nstange@...e.de>,
Mirko Lindner <mlindner@...vell.com>,
Stephen Hemminger <stephen@...workplumber.org>
Subject: Re: PROBLEM: Marvell 88E8040 (sky2) fails after hibernation
Octavio,
On Mon, 15 Jul 2019, Octavio Alvarez wrote:
> If I reboot with sky2.disable_msi=1, then I get IO-APIC and the bug does not
> occur:
>
> 19: 0 0 0 0 IO-APIC 19-fasteoi eth0
>
> However, if I reboot without sky2.disable_msi=1 it properly starts as PCI-MSI
> and then, after re-modprobing it it goes to IO-APIC, but the bug occurs
> anyway:
>
> $ cat /proc/interrupts | grep eth
> 27: 0 1 0 0 PCI-MSI 3145728-edge
> eth0
>
> $ sudo modprobe -r sky2
> [sudo] password for alvarezp:
>
> $ sudo modprobe sky2 disable_msi=1
>
> $ # hibernating and coming back hibernation
>
> $ cat /proc/interrupts | grep eth
> 19: 0 0 0 0 IO-APIC 19-fasteoi eth0
>
>
> > Also please check Linus suspicion about the module being reloaded after
> > hibernation through some distro magic.
>
> This is not happening. Each time the driver is loaded the message "sky2:
> driver version 1.30" is shown.
>
> I confirm only 1 line for the sky2.disable_msi=1 from kernel boot and only 2
> lines for re-modprobing.
Odd. I still fail to make a connection to that commit you identified
which merily restores the behaviour before the big changes.
As we cannot revert that commit by any means and as the hardware is known
to have issues with MSI, the only option we have is to avoid MSI on that
particular machine. I suspect that the fact that it is 'working' on some
older kernel version does not necessarily mean that it works by design. It
might as well be a works by chance thing.
Thanks for all the detective work you put into that and sorry that I can't
come up with the magic cure for this.
Thanks,
tglx
Powered by blists - more mailing lists