Bug 7159 - Networking on older machine with stock Debian kernel requires "acpi=off"
Summary: Networking on older machine with stock Debian kernel requires "acpi=off"
Status: REJECTED INSUFFICIENT_DATA
Alias: None
Product: Drivers
Classification: Unclassified
Component: Network (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Jeff Garzik
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-09-14 10:54 UTC by Adam Powell
Modified: 2008-09-22 17:03 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.16, 2.6.17, 2.6.18-rc6
Subsystem:
Regression: ---
Bisected commit-id:


Attachments

Description Adam Powell 2006-09-14 10:54:55 UTC
Most recent kernel where this bug did not occur: 2.6.8
Distribution: Debian
Hardware Environment: Dual-PIII, Ethernet Pro 100 and Realtek 8139 PCI interfaces
Software Environment: Debian Etch (Testing)
Problem Description: The network is not reachable, though the kernel does seem
to sense line presence on both interfaces.

On boot, udev/discover loads e100, 8139cp and 8139too.  /etc/modules does not
have any network modules (needs eepro100 for 2.6.8, but I removed it, no
change).  The relevant lspci listings
are:

00:09.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 05)
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)

Both interfaces work fine under 2.6.8 as long as eepro100 is loaded.

More information (lspci -v, /proc/interrupts, /proc/ioports) can be found at the
Debian bug: http://bugs.debian.org/386972

Steps to reproduce: Boot, try to use network.
Comment 1 Andrew Morton 2006-09-14 11:44:28 UTC
(Switching from bugzilla to email - please retain all Cc's)

On Thu, 14 Sep 2006 11:04:03 -0700
bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=7159
> 
>            Summary: No networking on a machine with Ethernet Pro 100 and
>                     Realtek 8139
>     Kernel Version: 2.6.16, 2.6.17, 2.6.18-rc6
>             Status: NEW
>           Severity: normal
>              Owner: jgarzik@pobox.com
>          Submitter: hazelsct@debian.org
> 
> 
> Most recent kernel where this bug did not occur: 2.6.8
> Distribution: Debian
> Hardware Environment: Dual-PIII, Ethernet Pro 100 and Realtek 8139 PCI interfaces
> Software Environment: Debian Etch (Testing)
> Problem Description: The network is not reachable, though the kernel does seem
> to sense line presence on both interfaces.
> 
> On boot, udev/discover loads e100, 8139cp and 8139too.  /etc/modules does not
> have any network modules (needs eepro100 for 2.6.8, but I removed it, no
> change).  The relevant lspci listings
> are:
> 
> 00:09.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 05)
> 00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL-8139/8139C/8139C+ (rev 10)
> 
> Both interfaces work fine under 2.6.8 as long as eepro100 is loaded.
> 
> More information (lspci -v, /proc/interrupts, /proc/ioports) can be found at the
> Debian bug: http://bugs.debian.org/386972
> 
> Steps to reproduce: Boot, try to use network.
> 

This is all a bit peculiar.  I'd be assuming that you're not getting
any interrupts through for those NICs.

Could you please check /proc/interrupts, see if the interrupt counts
related to the NICs can be made to increase?

Also, the full `dmesg -s 1000000' output might help.

We might also get some interesting info if you can compile your own kernel,
build thsoe net drivers into vmlinux, capture the dmesg output.

If it _is_ an IRQ problem then you might find that fiddling with ACPI
helps: disable it in config or boot with `acpi=off', see if that helps.  Also
try booting with the `pci=routeirq' option.

There are various options described under acpi= and pci= in
Documentation/kernel-parameters.txt which it would be useful for you to
experiment with.

Comment 2 Adam Powell 2006-09-19 11:11:17 UTC
Hello again,

It seems nobody received the message below; likely because the SMTP
server at work refused to forward a message from hazelsct@debian.org .
Sorry about the delay.

On Sun, 2006-09-17 at 15:12 -0400, Adam C Powell IV wrote:
> Hello, and apologies for the reply delay.  (This is a production
> machine, and I haven't been able to experiment until today, though I
> should have time Tuesday morning to try some things if needed.)
> 
> On Thu, 2006-09-14 at 11:53 -0700, Andrew Morton wrote:
> > (Switching from bugzilla to email - please retain all Cc's)
> > 
> > On Thu, 14 Sep 2006 11:04:03 -0700
> > bugme-daemon@bugzilla.kernel.org wrote:
> > 
> > > http://bugzilla.kernel.org/show_bug.cgi?id=7159
> > > 
> > >            Summary: No networking on a machine with Ethernet Pro 100 and
> > >                     Realtek 8139
> > >     Kernel Version: 2.6.16, 2.6.17, 2.6.18-rc6
> > >             Status: NEW
> > >           Severity: normal
> > >              Owner: jgarzik@pobox.com
> > >          Submitter: hazelsct@debian.org
> > > 
> > > 
> > > Most recent kernel where this bug did not occur: 2.6.8
> > > Distribution: Debian
> > > Hardware Environment: Dual-PIII, Ethernet Pro 100 and Realtek 8139 PCI interfaces
> > > Software Environment: Debian Etch (Testing)
> > > Problem Description: The network is not reachable, though the kernel does seem
> > > to sense line presence on both interfaces.
> > > 
> > > On boot, udev/discover loads e100, 8139cp and 8139too.  /etc/modules does not
> > > have any network modules (needs eepro100 for 2.6.8, but I removed it, no
> > > change).  The relevant lspci listings
> > > are:
> > > 
> > > 00:09.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 05)
> > > 00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> > > RTL-8139/8139C/8139C+ (rev 10)
> > > 
> > > Both interfaces work fine under 2.6.8 as long as eepro100 is loaded.
> > > 
> > > More information (lspci -v, /proc/interrupts, /proc/ioports) can be found at the
> > > Debian bug: http://bugs.debian.org/386972
> > > 
> > > Steps to reproduce: Boot, try to use network.
> > > 
> > 
> > This is all a bit peculiar.  I'd be assuming that you're not getting
> > any interrupts through for those NICs.
> > 
> > Could you please check /proc/interrupts, see if the interrupt counts
> > related to the NICs can be made to increase?
> 
> Can't do it.  Connecting/disconnecting, ping from inside and out,
> nothing increments the interrupt counts.
> 
> > Also, the full `dmesg -s 1000000' output might help.
> > 
> > We might also get some interesting info if you can compile your own kernel,
> > build thsoe net drivers into vmlinux, capture the dmesg output.
> > 
> > If it _is_ an IRQ problem then you might find that fiddling with ACPI
> > helps: disable it in config or boot with `acpi=off', see if that helps.
> 
> Yes!  The network works just fine now.
> 
> > Also
> > try booting with the `pci=routeirq' option.
> 
> By itself, this does not cure the network problem.  But all of my GNOME
> applets work with this; without it, the panel hangs after opening a few
> of them.  Different few every time, so it's hard to peg which one is the
> problem.
> 
> With both acpi=off and pci=routeirq, the network works and GNOME applets
> work.  Hooray!
> 
> Not so fast.  The machine hung completely once, then the next two boots,
> everything in X hung except the cursor.  I was able to ssh in, and grab
> interrupts and dmesg.
> 
> Output of "dmesg -s 1000000" and "cat /proc/interrupts" is at
> http://lyre.mit.edu/~powell/temp/ (oops, I had done "ifdown eth0; ifdown
> eth1" before catching interrupts-acpi=off; that's why those are absent.)
> 
> > There are various options described under acpi= and pci= in
> > Documentation/kernel-parameters.txt which it would be useful for you to
> > experiment with.
> 
> I think the acpi=off boot option did the trick.  The config is Debian
> stock 2.6.17-2-686 with 'enter' at all new questions in make oldconfig.
> This problem is also in the Debian stock 2.6.17 and 2.6.16 kernels, so I
> suspect a different .config might clear it up.
> 
> Any suggestions there for a .config which will work with ACPI and
> non-ACPI machines?  Debian stock 2.6.8 seems fine (but of course is
> missing the fancy new features).
> 
> The X apps hang is a separate problem.  I'll pursue it with the Debian
> people before opening a separate bug.  Feel free to close this one.
> 
> Thank you again.
> 
> -Adam
Comment 3 Adam Powell 2006-10-05 09:00:55 UTC
On Tue, 2006-09-19 at 14:19 -0400, Adam C Powell IV wrote:
> On Sun, 2006-09-17 at 15:12 -0400, Adam C Powell IV wrote:
> > Hello, and apologies for the reply delay.  (This is a production
> > machine, and I haven't been able to experiment until today, though I
> > should have time Tuesday morning to try some things if needed.)
> > 
> > On Thu, 2006-09-14 at 11:53 -0700, Andrew Morton wrote:
> > > (Switching from bugzilla to email - please retain all Cc's)
> > > 
> > > On Thu, 14 Sep 2006 11:04:03 -0700
> > > bugme-daemon@bugzilla.kernel.org wrote:
> > > 
> > > > http://bugzilla.kernel.org/show_bug.cgi?id=7159
> > > > 
> > > >            Summary: No networking on a machine with Ethernet Pro 100 and
> > > >                     Realtek 8139
> > > >     Kernel Version: 2.6.16, 2.6.17, 2.6.18-rc6
> > > >             Status: NEW
> > > >           Severity: normal
> > > >              Owner: jgarzik@pobox.com
> > > >          Submitter: hazelsct@debian.org
> > > > 
> > > > 
> > > > Most recent kernel where this bug did not occur: 2.6.8
> > > > Distribution: Debian
> > > > Hardware Environment: Dual-PIII, Ethernet Pro 100 and Realtek 8139 PCI interfaces
> > > > Software Environment: Debian Etch (Testing)
> > > > Problem Description: The network is not reachable, though the kernel does seem
> > > > to sense line presence on both interfaces.
> > > > 
> > > > On boot, udev/discover loads e100, 8139cp and 8139too.  /etc/modules does not
> > > > have any network modules (needs eepro100 for 2.6.8, but I removed it, no
> > > > change).  The relevant lspci listings
> > > > are:
> > > > 
> > > > 00:09.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 05)
> > > > 00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> > > > RTL-8139/8139C/8139C+ (rev 10)
> > > > 
> > > > Both interfaces work fine under 2.6.8 as long as eepro100 is loaded.
> > > > 
> > > > More information (lspci -v, /proc/interrupts, /proc/ioports) can be found at the
> > > > Debian bug: http://bugs.debian.org/386972
> > > > 
> > > > Steps to reproduce: Boot, try to use network.
> > > > 
> > > 
> > > This is all a bit peculiar.  I'd be assuming that you're not getting
> > > any interrupts through for those NICs.
> > > 
> > > Could you please check /proc/interrupts, see if the interrupt counts
> > > related to the NICs can be made to increase?
> > 
> > Can't do it.  Connecting/disconnecting, ping from inside and out,
> > nothing increments the interrupt counts.
> > 
> > > Also, the full `dmesg -s 1000000' output might help.
> > > 
> > > We might also get some interesting info if you can compile your own kernel,
> > > build thsoe net drivers into vmlinux, capture the dmesg output.
> > > 
> > > If it _is_ an IRQ problem then you might find that fiddling with ACPI
> > > helps: disable it in config or boot with `acpi=off', see if that helps.
> > 
> > Yes!  The network works just fine now.
> > 
> > > Also
> > > try booting with the `pci=routeirq' option.
> > 
> > By itself, this does not cure the network problem.  But all of my GNOME
> > applets work with this; without it, the panel hangs after opening a few
> > of them.  Different few every time, so it's hard to peg which one is the
> > problem.
> > 
> > With both acpi=off and pci=routeirq, the network works and GNOME applets
> > work.  Hooray!
> > 
> > Not so fast.  The machine hung completely once, then the next two boots,
> > everything in X hung except the cursor.  I was able to ssh in, and grab
> > interrupts and dmesg.
> > 
> > Output of "dmesg -s 1000000" and "cat /proc/interrupts" is at
> > http://lyre.mit.edu/~powell/temp/ (oops, I had done "ifdown eth0; ifdown
> > eth1" before catching interrupts-acpi=off; that's why those are absent.)
> > 
> > > There are various options described under acpi= and pci= in
> > > Documentation/kernel-parameters.txt which it would be useful for you to
> > > experiment with.
> > 
> > I think the acpi=off boot option did the trick.  The config is Debian
> > stock 2.6.17-2-686 with 'enter' at all new questions in make oldconfig.
> > This problem is also in the Debian stock 2.6.17 and 2.6.16 kernels, so I
> > suspect a different .config might clear it up.
> > 
> > Any suggestions there for a .config which will work with ACPI and
> > non-ACPI machines?  Debian stock 2.6.8 seems fine (but of course is
> > missing the fancy new features).
> > 
> > The X apps hang is a separate problem.  I'll pursue it with the Debian
> > people before opening a separate bug.  Feel free to close this one.

For the record: GNOME applets all open just fine after purging acpid
from the system, without pci=routeirq.  But the machine hangs about 2-4
times in an 8-hour workday, under 2.6.18 final as well.  Again, a
separate problem, for which I'll open a separate bug.

I'm attaching the dmesg and /proc/interrupts outputs for those not
interested in browsing to lyre.mit.edu.

Again, any help on config options which will work on both ACPI and
non-ACPI machines would be much appreciated.

-Adam
Comment 4 Dave Jones 2007-05-31 11:26:31 UTC
this sounds like the original bug got fixed, and this can be closed ?
Comment 5 Adam Powell 2007-06-13 06:39:42 UTC
The original bug was not fixed.  Getting networking to work still requires acpi=off and preventing GNOME crashes requires pci=routeirq.  Furthermore, if I don't killall hald, the whole system hangs within about 10 minutes of booting.

Then again, the most recent kernel I've tried on this machine is 2.6.18.  In the next week or so I'll try 2.6.21 and see how it fares.
Comment 6 Natalie Protasevich 2008-03-29 23:51:47 UTC
Adam, is it still the same with latest kernel?
The acpi=off interrupts snapshot doesn't show any ethX devices configured.  

Note You need to log in before you can comment on or make changes to this bug.