On Mon, 15 Jul 2019 21:09:44 +0200 (CEST) Thomas Gleixner <[email protected]> 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.
