Re: 2.6.10: e100 network broken after swsusp/resume

Barry K. Nathan
2005-01-03T05:10:53Z

On Sun, Jan 02, 2005 at 09:09:16PM +0100, Håkan Lindqvist wrote:
> On sön, 2005-01-02 at 13:42 -0500, John M Flinchbaugh wrote:
> > pci=routeirq worked for me to get my e100 working again after resume.
>
> For the record: It works around my problems with e100 and snd-intel8x0,
> too.

I previously mentioned that "pci=routeirq" works to fix my 8139too
problems. However, I just figured out that if I use "acpi=noirq" or
"pci=noacpi" instead of "pci=routeirq", that works too. (This is with
2.6.10-bk4.)

[snip]
> The Documentation/kernel-parameters.txt says this about pci=routeirq:
> "Do IRQ routing for all PCI devices. This is normally done in
> pci_enable_device(), so this option is a temporary workaround for broken
> drivers that don't call it."
>
> Ie, it doesn't sound too bad to use it until the problem is solved.
> And I don't know if this particular issue is a case of broken drivers,
> but that was what the parameter was added to work around.

I don't think this is a case of broken drivers. So far in this thread, it's
been seen with e100, 8139too, snd-intel8x0, and probably one of the USB
drivers too. And the problem happens even if the module is unloaded and
reloaded -- unless I'm seriously missing something, this probably means
pci_enable_device() is unable to do its job properly for some reason --
but only after a swsusp resume.

It would also be informative to examine the kernel command line options
that are making the problem go away:

pci=routeirq
acpi=off
acpi=noirq
pci=noacpi

What do they all have in common? ACPI. (AFAICT from my reading of the
source code, on i386 pci=routeirq only has an effect if ACPI is being
used for IRQ routing.)

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...

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