[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87d00gltb9.fsf@nanos.tec.linutronix.de>
Date: Sat, 14 Nov 2020 00:40:10 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Bjorn Helgaas <helgaas@...nel.org>,
"Guilherme G. Piccoli" <gpiccoli@...onical.com>
Cc: linux-pci@...r.kernel.org, kexec@...ts.infradead.org,
x86@...nel.org, linux-kernel@...r.kernel.org, bhelgaas@...gle.com,
dyoung@...hat.com, bhe@...hat.com, vgoyal@...hat.com,
mingo@...hat.com, bp@...en8.de, hpa@...or.com, andi@...stfloor.org,
lukas@...ner.de, okaya@...nel.org, kernelfans@...il.com,
ddstreet@...onical.com, gavin.guo@...onical.com,
jay.vosburgh@...onical.com, kernel@...ccoli.net,
shan.gavin@...ux.alibaba.com,
Eric Biederman <ebiederm@...ssion.com>
Subject: Re: [PATCH 1/3] x86/quirks: Scan all busses for early PCI quirks
Bjorn,
On Sat, Nov 14 2020 at 00:31, Thomas Gleixner wrote:
> On Fri, Nov 13 2020 at 10:46, Bjorn Helgaas wrote:
>> pci_device_shutdown() still clears the Bus Master Enable bit if we're
>> doing a kexec and the device is in D0-D3hot, which should also disable
>> MSI/MSI-X. Why doesn't this solve the problem? Is this because the
>> device causing the storm was in PCI_UNKNOWN state?
>
> That's indeed a really good question.
So we do that on kexec, but is that true when starting a kdump kernel
from a kernel crash? I doubt it.
Thanks,
tglx
Powered by blists - more mailing lists