[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190715134032.5a70782f@hermes.lan>
Date: Mon, 15 Jul 2019 13:40:32 -0700
From: Stephen Hemminger <stephen@...workplumber.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Octavio Alvarez <octallk1@...arezp.org>,
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>
Subject: Re: PROBLEM: Marvell 88E8040 (sky2) fails after hibernation
On Mon, 15 Jul 2019 21:09:44 +0200 (CEST)
Thomas Gleixner <tglx@...utronix.de> wrote:
> 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
In the past, I had one ASUS motherboard with broken MSI and updating the
BIOS did fix it.
Powered by blists - more mailing lists