[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1906132229540.1791@nanos.tec.linutronix.de>
Date: Thu, 13 Jun 2019 22:45:20 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Octavio Alvarez <octallk1@...arezp.org>
cc: Linus Torvalds <torvalds@...ux-foundation.org>,
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>
Subject: Re: PROBLEM: Marvell 88E8040 (sky2) fails after hibernation
Octavio,
On Thu, 13 Jun 2019, Octavio Alvarez wrote:
> I reported this to different people but I have not received a response [1]
> [2]. I am following the reporting procedure described in the kernel admin
> guide [3] so now I am escalating to you. What am I missing?
>
> I noticed that Thomas' mailbox is filtering my mail because of some RBL and
> have not figured out why that is yet so maybe he has not gotten any e-mails
> from me. However, I already tried conacting using a different mail provider.
I got your mail from June 1st via LKML and this one directly and via
LKML. It's in the pile of the other ~1000 mails in my backlog as I was out
on vacation and travel. Just because people do not reply immediately does
not mean they ignore you.
> Hibernating the machine and bringing it back does not properly bring back the
> Marvell NIC. Most of the time a module reload does not help.
>
> Problem starts on the following commit, which if I revert over a recent
> master, the problem goes away:
>
> $ PAGER= git show bc976233a872c0f20f018fb1e89264a541584e25
> commit bc976233a872c0f20f018fb1e89264a541584e25
> Author: Thomas Gleixner <tglx@...utronix.de>
> Date: Fri Dec 29 10:47:22 2017 +0100
>
> genirq/msi, x86/vector: Prevent reservation mode for non maskable MSI
That does not make sense. This brings the MSI code back to the state which
it had _BEFORE_ I reworked the vector allocation and MSI code. It rather
looks like this patch unearths some other weird issue in that Marvell NIC
(or the driver) which was not visible before. And looking at the code the
hardware has known problems with MSI interrupts and uses a magic probe
function to verify whether they work at all.
Can you please provide the content of /proc/interrupts with the driver
loaded and working after boot (don't hibernate) for the following kernels:
Linus upstream
Linus upstream + revert
4.14 stable (that's before the big overhaul of the vector/msi code)
Thanks,
tglx
Powered by blists - more mailing lists