Re: 2.6.10: e100 network broken after swsusp/resume

Barry K. Nathan
2005-01-03T08:32:10Z

On Sun, Jan 02, 2005 at 09:10:18PM -0800, Barry K. Nathan wrote:
> So, I think this bug probably lies in ACPI or swsusp. I highly *highly*
> doubt it's driver bugs. Hopefully I'll have time later tonight or
> tomorrow morning to see if I can figure anything else out...

The following patch is a ridiculously dirty kludge which (very arguably)
improves the situation somewhat:

--- linux-2.6.10-bk4/arch/i386/kernel/mpparse.c 2004-12-14 03:17:21.723010806 -0800
+++ linux-2.6.10-bk4-bkn1/arch/i386/kernel/mpparse.c 2005-01-02 23:43:13.647613575 -0800
@@ -1091,9 +1091,10 @@
return gsi;
}
if ((1<<bit) & mp_ioapic_routing[ioapic].pin_programmed[idx]) {
- Dprintk(KERN_DEBUG "Pin %d-%d already programmed\n",
+ printk(KERN_DEBUG "Pin %d-%d already programmed\n",
mp_ioapic_routing[ioapic].apic_id, ioapic_pin);
- return gsi;
+ /* return gsi; */
+ printk(KERN_DEBUG "However, I will reprogram it anyway.\n");
}

mp_ioapic_routing[ioapic].pin_programmed[idx] |= (1<<bit);

With this patch, unloading and reloading 8139too will make it work again
after a resume -- as long as I boot *without* "noapic". This doesn't fix
the actual problem (it's still broken after resume, and reloading the
module still doesn't work for "noapic") but it might provide clues.

More specifically, this shows that the
mp_ioapic_routing[ioapic].pin_programmed[] array is inconsistent with
the IO-APIC's real configuration after the resume.

I think the reason that "pci=routeirq" works is that, with that option,
the kernel sets up everything on the IO-APIC early in bootup and leaves
nothing to be done later on -- that way, the IO-APIC ends up having the
same setup after the resume that it did at suspend time. At leas, that's
what I suspect; I don't think I've proven it yet. I wouldn't be
surprised if a similar phenomenon is happening with acpi=off.

Anyway, I'm going to keep working on this and see if I can figure it out
some more...

-Barry K. Nathan <barryn@pobox.com>