Messages in this thread | | | Subject | Re: Regression caused by commit 7bb05b85bc2d ("r8169: don't use MSI-X on RTL8106e") | From | Kai-Heng Feng <> | Date | Wed, 12 Sep 2018 16:19:39 +0800 |
| |
at 14:32, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Wed, 12 Sep 2018, Kai-Heng Feng wrote: > >> There's a Dell machine with RTL8106e stops to work after S3 since the >> commit introduced. So I am wondering if it's possible to revert the >> commit and use DMI/subsystem id based quirk table? > > Probably.
Hopefully Jian-Hong can cook up a quirk table for the issue.
> >> It's because of commit bc976233a872 ("genirq/msi, x86/vector: Prevent >> reservation mode for non maskable MSI") cleared the reservation mode, >> and I >> can see this after S3: >> >> [ 94.872838] do_IRQ: 3.33 No irq handler for vector > > It's not because of that commit, really. There is a interrupt sent after > resume to the wrong vector for whatever reason. The MSI vector cannot be > masked it seems in the device, but the driver should quiescen the device to > a point where it does not send interrupts.
Understood.
> >> If the device uses MSI-X instead of MSI, the issue doesn't happen >> because of >> reservation mode. > > Reservation mode has absolutely nothing to do with that. What prevents the > issue is the fact that MSI-X can be masked by the IRQ core.
So in this case I think keep the device using MSI-X is a better route, it's MSI-X capable anyway.
> >> Is it something should be handled by x86 BIOS? Because I don't see this >> issue >> when I use Suspend-to-Idle, which doesn't use BIOS to do suspend. > > Suspend to idle works completely different and I don't see the BIOS at > fault here. it's more an issue of MSI not being maskable on that device, > which can't be fixed in BIOS or it's some half quiescened state which is > used when suspending and that's a pure driver issue.
Understood. Thanks for all the info!
Kai-Heng
> > Thanks, > > tglx
| |