e100 problems in .23rc8 ?

DISCUSSION Dave Jones 7 participants 27 messages Sep 26, 2007 – Oct 22, 2007

Subsystems (2)

Networking Network drivers

lore

Share & tools

lore

Dave Jones

author

2007-09-26 15:04 UTC #0 lore raw

Last night, I hit this bug during boot up..
http://www.codemonkey.org.uk/junk/e100-2.jpg

This morning, I got a mail from a Fedora user of the same .23-rc8 based kernel that has seen a different trace also implicating e100..

http://www.codemonkey.org.uk/junk/e100.jpg

It may be that the two problems are unrelated, and it's just coincidence that both reports happen to be on an e100, but the timing is odd. Have there been other reports of similar problems recently ?

Dave

Signature · 1 line

http://www.codemonkey.org.uk

Kok, Auke

2007-09-26 18:10 UTC #1 lore raw

Quoted 7 lines · Dave Jones

Last night, I hit this bug during boot up..
http://www.codemonkey.org.uk/junk/e100-2.jpg
This morning, I got a mail from a Fedora user of the same .23-rc8 based kernel that has seen a different trace also implicating e100..

Quoted 6 lines

http://www.codemonkey.org.uk/junk/e100.jpg
It may be that the two problems are unrelated, and it's just coincidence that both reports happen to be on an e100, but the timing is odd. Have there been other reports of similar problems recently ?

there hasn't been a change to e100 in two months now - perhaps something slipped into the stack that broke it? If this reproduces, could you bisect?

Auke

Dave Jones

author

2007-09-26 18:18 UTC #2 lore raw

Quoted 10 lines · Auke

Quoted 9 lines · Dave Jones
Last night, I hit this bug during boot up..
http://www.codemonkey.org.uk/junk/e100-2.jpg
This morning, I got a mail from a Fedora user of the same .23-rc8 based kernel that has seen a different trace also implicating e100..
http://www.codemonkey.org.uk/junk/e100.jpg

Quoted 7 lines

Quoted 4 lines
It may be that the two problems are unrelated, and it's just coincidence that both reports happen to be on an e100, but the timing is odd. Have there been other reports of similar problems recently ?
there hasn't been a change to e100 in two months now - perhaps something slipped into the stack that broke it? If this reproduces, could you bisect?

Yeah, I notice only 3 changes to e100 since .22 I'll see if I can reproduce the first one and bisect.

Dave

Signature · 1 line

http://www.codemonkey.org.uk

Herbert Xu

2007-09-27 06:58 UTC #3 lore raw

In reply to Kok, Auke

Quoted 10 lines · Auke

Quoted 9 lines · Dave Jones
Last night, I hit this bug during boot up..
http://www.codemonkey.org.uk/junk/e100-2.jpg
This morning, I got a mail from a Fedora user of the same .23-rc8 based kernel that has seen a different trace also implicating e100..
http://www.codemonkey.org.uk/junk/e100.jpg

Quoted 7 lines

Quoted 4 lines
It may be that the two problems are unrelated, and it's just coincidence that both reports happen to be on an e100, but the timing is odd. Have there been other reports of similar problems recently ?
there hasn't been a change to e100 in two months now - perhaps something slipped into the stack that broke it? If this reproduces, could you bisect?

Well this looks exactly like the e1000 race that we fixed around the time of the last kernel release. That fix never made it into e100 so it's no surprise that we get a similar crash here.

The problem is that if a spurious interrupt comes in between request_irq and netif_poll_enable then you'll get a crash at the next netif_rx_complete.

It'd be good if this were reproducible as it would allow us to identify the source of the spurious interrupt, which may well be caused by an unrelated bug somewhere else.

In any case, e100 should be prepared to deal with spurious interrupts as e1000 has been fixed to do.

Cheers,

Signature · 4 lines

Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Dave Jones

author

2007-10-11 00:36 UTC #4 lore raw

Quoted 11 lines · Herbert Xu

Quoted 10 lines · Auke
Quoted 9 lines · Dave Jones
Last night, I hit this bug during boot up..
http://www.codemonkey.org.uk/junk/e100-2.jpg
This morning, I got a mail from a Fedora user of the same .23-rc8 based kernel that has seen a different trace also implicating e100..
http://www.codemonkey.org.uk/junk/e100.jpg

Quoted 7 lines

Quoted 7 lines
Quoted 4 lines
It may be that the two problems are unrelated, and it's just coincidence that both reports happen to be on an e100, but the timing is odd. Have there been other reports of similar problems recently ?
there hasn't been a change to e100 in two months now - perhaps something slipped into the stack that broke it? If this reproduces, could you bisect?

So I looked into this some more, after it reared its head again. The problem with bisecting it is that it doesn't happen on every boot, so it's difficult to determine the good/bad state. I've never managed to reproduce it on 2.6.22 however.

Quoted 3 lines

Well this looks exactly like the e1000 race that we fixed around the time of the last kernel release. That fix never made it into e100 so it's no surprise that we get a similar crash here.

We're starting to see more reports of this from Fedora users now that 2.6.23 is final. Once we push that as an update for Fedora 7 users, it's likely we'll see even more. (likewise for the soon-to-be released F8, based on 2.6.23)

The e1000 changes you reference above, is this the changeset you mean?

commit 416b5d10afdc797c21c457ade3714e8f2f75edd9

Author: Auke Kok <[email protected]>
Date:   Fri Jun 1 10:22:39 2007 -0700

e1000: disable polling before registering netdevice

Quoted 10 lines

The problem is that if a spurious interrupt comes in between request_irq and netif_poll_enable then you'll get a crash at the next netif_rx_complete.
It'd be good if this were reproducible as it would allow us to identify the source of the spurious interrupt, which may well be caused by an unrelated bug somewhere else.
In any case, e100 should be prepared to deal with spurious interrupts as e1000 has been fixed to do.

Adding some of the other reporters of this bug to Cc, in case they've found this more reproducable than myself (maybe they'll have more luck bisecting).

Dave

Signature · 1 line

http://www.codemonkey.org.uk

Herbert Xu

2007-10-11 01:25 UTC #5 lore raw

Quoted 8 lines · Dave Jones

The e1000 changes you reference above, is this the changeset you mean?
commit 416b5d10afdc797c21c457ade3714e8f2f75edd9
Author: Auke Kok <[email protected]>
Date:   Fri Jun 1 10:22:39 2007 -0700
e1000: disable polling before registering netdevice

Yep.

Cheers,

Signature · 4 lines

Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Kok, Auke

2007-10-11 16:10 UTC #6 lore raw

Quoted 10 lines · Herbert Xu

Quoted 7 lines · Dave Jones
The e1000 changes you reference above, is this the changeset you mean?
commit 416b5d10afdc797c21c457ade3714e8f2f75edd9
Author: Auke Kok <[email protected]>
Date:   Fri Jun 1 10:22:39 2007 -0700
e1000: disable polling before registering netdevice
Yep.

this patch actually called napi_disable() in the probe routine which was wrong, but e100 does not do that. Nonetheless e100 doesn't call netif_carrier_off() and netif_stop_queue(), so to make e100 the same as e1000 we should probably do this, see below.

Dave, can you see if this resolves the issue for you? If so then we might want to push this to -stable.

Auke

---
e100: disable netdevice explicitly to avoid rx irq oops

Several reported OOPS messages suggest that e100 has a race that was fixed in e1000 before where incoming interrupts trigger an OOPS immediately after probe() finishes.

Signed-off-by Auke Kok <[email protected]>

drivers/net/e100.c +4 -0

index 280313b..ded5f68 100644
@@ -2682,6 +2682,10 @@ static int __devinit e100_probe(struct pci_dev *pdev,
 	if (err)
 		DPRINTK(PROBE, ERR, "Error clearing wake event\n");
 
+	/* tell the stack to leave us alone until e100_open() is called */
+	netif_carrier_off(netdev);
+	netif_stop_queue(netdev);
+
 	strcpy(netdev->name, "eth%d");
 	if((err = register_netdev(netdev))) {
 		DPRINTK(PROBE, ERR, "Cannot register net device, aborting.\n");

Dave Jones

author

2007-10-11 17:26 UTC #7 lore raw

Quoted 12 lines · Auke

Quoted 10 lines · Herbert Xu
Quoted 7 lines · Dave Jones
The e1000 changes you reference above, is this the changeset you mean?
commit 416b5d10afdc797c21c457ade3714e8f2f75edd9
Author: Auke Kok <[email protected]>
Date:   Fri Jun 1 10:22:39 2007 -0700
e1000: disable polling before registering netdevice
Yep.

Quoted 7 lines

this patch actually called napi_disable() in the probe routine which was wrong, but e100 does not do that. Nonetheless e100 doesn't call netif_carrier_off() and netif_stop_queue(), so to make e100 the same as e1000 we should probably do this, see below.
Dave, can you see if this resolves the issue for you? If so then we might want to push this to -stable.

Will do, thanks Auke.

Eric/David, the Fedora 8 RPM version 2.6.23-6.fc8 will have this if you want to give it a shot too. It'll be at
http://people.redhat.com/davej/kernels/Fedora/f7.92/ when it's done building in an hour or so.

Dave

Signature · 1 line

http://www.codemonkey.org.uk

Eric Sandeen

2007-10-11 18:56 UTC #8 lore raw

Quoted 7 lines

Eric/David, the Fedora 8 RPM version 2.6.23-6.fc8 will have this if you want to give it a shot too. It'll be at
http://people.redhat.com/davej/kernels/Fedora/f7.92/ when it's done building in an hour or so.
Dave

Thanks, I'll give it a whirl this evening. I put a new net card in that box 'cause I got tired of resetting it :)

-Eric

David Mack

2007-10-12 16:15 UTC #9 lore raw

In reply to Dave Jones

Still no joy here. See attached capture. What's really weird is that it shows *two* kernel panics, one in e100_poll and one in _list_add.

Dave

Quoted 36 lines

-----Original Message-----
From: Dave Jones [mailto:[email protected]]
Sent: Thursday, October 11, 2007 10:26 AM
To: Kok, Auke
Cc: Herbert Xu; [email protected]; [email protected]; David Mack
Subject: Re: e100 problems in .23rc8 ?
Quoted 3 lines · Auke
Quoted 2 lines · Herbert Xu
Quoted 1 line · Dave Jones
The e1000 changes you reference above, is this the
changeset you mean?
Quoted 10 lines
Quoted 8 lines
Quoted 6 lines
commit 416b5d10afdc797c21c457ade3714e8f2f75edd9
Author: Auke Kok <[email protected]>
Date:   Fri Jun 1 10:22:39 2007 -0700
e1000: disable polling before registering netdevice
Yep.
this patch actually called napi_disable() in the probe
routine which was wrong,
Quoted 1 line
but e100 does not do that. Nonetheless e100 doesn't call
netif_carrier_off() and
Quoted 1 line
netif_stop_queue(), so to make e100 the same as e1000 we
should probably do this,
Quoted 3 lines
see below.
Dave, can you see if this resolves the issue for you? If
so then we might want to
Quoted 1 line
push this to -stable.
Will do, thanks Auke.

Quoted 11 lines

Eric/David, the Fedora 8 RPM version 2.6.23-6.fc8 will have this if you
want to give it a shot too. It'll be at
http://people.redhat.com/davej/kernels/Fedora/f7.92/ when it's done building in an hour or so.
Dave
Signature · 1 line
http://www.codemonkey.org.uk

Linux version 2.6.23-6.fc8 (kojibuilder@) (gcc version 4.1.2 20070925 (Red Hat 4.1.2-31)) #1 SMP Thu Oct 11 14:54:16 EDT 2007 BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000ec000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000003fff0000 (usable)
BIOS-e820: 000000003fff0000 - 000000003fff8000 (ACPI data)
BIOS-e820: 000000003fff8000 - 0000000040000000 (ACPI NVS)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
127MB HIGHMEM available.
896MB LOWMEM available.
Using x86 segment limits to approximate NX protection
Zone PFN ranges:
DMA 0 -> 4096
Normal 4096 -> 229376
HighMem 229376 -> 262128
Movable zone start PFN for each node
early_node_map[1] active PFN ranges

    0:        0 ->   262128

DMI 2.3 present.
Using APIC driver default
ACPI: RSDP 000FA8D0, 0014 (r0 AMI )
ACPI: RSDT 3FFF0000, 0028 (r1 AMIINT 10 MSFT 97)
ACPI: FACP 3FFF0030, 0074 (r1 AMIINT 10 MSFT 97)
ACPI: DSDT 3FFF00B0, 2AE4 (r1 VIA VT8371 1000 MSFT 100000B)
ACPI: FACS 3FFF8000, 0040
ACPI: PM-Timer IO Port: 0x808
Allocating PCI resources starting at 50000000 (gap: 40000000:bfff0000)
swsusp: Registered nosave memory region: 000000000009f000 - 00000000000a0000
swsusp: Registered nosave memory region: 00000000000a0000 - 00000000000ec000
swsusp: Registered nosave memory region: 00000000000ec000 - 0000000000100000 Built 1 zonelists in Zone order. Total pages: 258545
Kernel command line: ro root=LABEL=/1 console=ttyS0,9600n8
Local APIC disabled by BIOS -- you can enable it with "lapic" Enabling fast FPU save and restore... done.
Initializing CPU#0
CPU 0 irqstacks, hard=c0814000 soft=c07f4000
PID hash table entries: 4096 (order: 12, 16384 bytes)
Detected 952.200 MHz processor.
Console: colour VGA+ 80x25
console [ttyS0] enabled
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES: 8
... MAX_LOCK_DEPTH: 30
... MAX_LOCKDEP_KEYS: 2048
... CLASSHASH_SIZE: 1024

... MAX_LOCKDEP_ENTRIES:     8192
... MAX_LOCKDEP_CHAINS:      16384
... CHAINHASH_SIZE:          8192

memory used by lock dependency info: 1024 kB
per task-struct memory footprint: 1680 bytes
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1022396k/1048512k available (2271k kernel code, 25372k reserved, 1174k data, 568k init, 131008k highmem) virtual kernel memory layout:

    fixmap  : 0xffc53000 - 0xfffff000   (3760 kB)
    pkmap   : 0xff800000 - 0xffc00000   (4096 kB)
    vmalloc : 0xf8800000 - 0xff7fe000   ( 111 MB)
    lowmem  : 0xc0000000 - 0xf8000000   ( 896 MB)
      .init : 0xc0763000 - 0xc07f1000   ( 568 kB)
      .data : 0xc0637e5f - 0xc075da44   (1174 kB)
      .text : 0xc0400000 - 0xc0637e5f   (2271 kB)

Checking if this processor honours the WP bit even in supervisor mode... Ok.
SLUB: Genslabs=22, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1 Calibrating delay using timer specific routine.. 1907.59 BogoMIPS (lpj=953797) Security Framework v1.0.0 initialized

SELinux:  Initializing.
selinux_register_security:  Registering secondary module capability

Capability LSM initialized as secondary
Mount-cache hash table entries: 512
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 64K (64 bytes/line)
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Compat vDSO mapped to ffffe000.
Checking 'hlt' instruction... OK.
SMP alternatives: switching to UP code
Freeing SMP alternatives: 12k freed
ACPI: Core revision 20070126
ACPI: setting ELCR to 0800 (from 0e00)
CPU0: AMD Athlon(tm) Processor stepping 01
SMP motherboard not detected.
Local APIC not detected. Using dummy APIC emulation.
Brought up 1 CPUs
khelper used greatest stack depth: 3160 bytes left
Booting paravirtualized kernel on bare hardware
Time: 7:47:03 Date: 10/12/07
NET: Registered protocol family 16
khelper used greatest stack depth: 3084 bytes left
No dock devices found.
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfdb71, last bus=1
PCI: Using configuration type 1
Setting up standard PCI resources
ACPI: Interpreter enabled
ACPI: (supports S0 S1 S4 S5)
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
Disabling VIA memory write queue (PCI ID 0305, rev 03): [55] 89 & 1f -> 09 PCI quirk: region 0800-08ff claimed by vt82c586 ACPI
PCI quirk: region 0c00-0c7f claimed by vt82c686 HW-mon
PCI quirk: region 0400-040f claimed by vt82c686 SMB
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: Power Resource [URP1] (off)
ACPI: Power Resource [URP2] (off)
ACPI: Power Resource [FDDP] (off)
ACPI: Power Resource [LPTP] (off)
Linux Plug and Play Support v0.97 (c) Adam Belay

pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 11 devices
ACPI: ACPI bus type pnp unregistered
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
NetLabel: Initializing
NetLabel:  domain hash size = 128
NetLabel:  protocols = UNLABELED CIPSOv4
NetLabel:  unlabeled traffic allowed by default
Time: tsc clocksource has been installed.
PCI: Bridge: 0000:00:01.0

IO window: 8000-8fff
MEM window: dde00000-dfefffff
PREFETCH window: cdc00000-ddcfffff
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes) TCP established hash table entries: 65536 (order: 9, 2621440 bytes) TCP bind hash table entries: 65536 (order: 9, 2359296 bytes)
TCP: Hash tables configured (established 65536 bind 65536) TCP reno registered
checking if image is initramfs... it is
Switched to high resolution mode on CPU 0
Freeing initrd memory: 2921k freed
khelper used greatest stack depth: 2956 bytes left
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac)
apm: overridden by ACPI.
audit: initializing netlink socket (disabled) audit(1192175220.146:1): initialized
highmem bounce pool size: 64 pages
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
ksign: Installing public key data
Loading keyring
- Added public key BA5046002C6A482A
- User ID: Red Hat, Inc. (Kernel Module GPG key)
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
PCI: VIA PCI bridge detected. Disabling DAC.
PCI: Disabling Via external APIC routing
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
ACPI: Thermal Zone [THRM] (30 C)
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Real Time Clock Driver v1.12ac
Non-volatile memory driver v1.2
Linux agpgart interface v0.102
agpgart: Detected VIA Twister-K/KT133x/KM133 chipset
agpgart: AGP aperture is 64M @ 0xe0000000
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled �serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
00:08: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:09: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 16384K size 4096 blocksize
input: Macintosh mouse button emulation as /class/input/input0
PNP: PS/2 Controller [PNP0303:PS2K,PNP0f03:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard as /class/input/input1
cpuidle: using governor menu
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
powernow-k8: Processor cpuid 631 not supported
Using IPI No-Shortcut mode
Magic number: 11:900:773
Freeing unused kernel memory: 568k freed
Write protecting the kernel read-only data: 877k
Red Hat nash version 6.0.19 starting
Mounting proc filesystem
Mounting sysfs filesystem
Creating /dev
Creating initial device nodes
Setting up hotplug.
Creating block device nodes.
Loinsmod used greatest stack depth: 2696 bytes left
ading ehci-hcd.ko module
Loading ohci-hcd.ko module
Loading uhUSB Universal Host Controller Interface driver v3.0 ci-hcd.ko moduleACPI: PCI Interrupt Link [LNKD] enabled at IRQ 9

ACPI: PCI Interrupt 0000:00:07.2[D] -> Link [LNKD] -> GSI 9 (level, low) -> IRQ 9 uhci_hcd 0000:00:07.2: UHCI Host Controller
uhci_hcd 0000:00:07.2: new USB bus registered, assigned bus number 1 uhci_hcd 0000:00:07.2: irq 9, io base 0x0000b800
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:07.3[D] -> Link [LNKD] -> GSI 9 (level, low) -> IRQ 9 uhci_hcd 0000:00:07.3: UHCI Host Controller
uhci_hcd 0000:00:07.3: new USB bus registered, assigned bus number 2 uhci_hcd 0000:00:07.3: irq 9, io base 0x0000bc00
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
insmod used greatest stack depth: 1892 bytes left
Loading mbcache.ko module
Loading jbd.ko minput: ImPS/2 Generic Wheel Mouse as /class/input/input2 odule
Loading ext3.ko module
Loading scsi_mod.ko module
SCSI subsystem initialized
Loading sd_mod.ko module
Loading libata.ko module
Loading ata_generic.ko module
Loading pata_via.ko module
scsi0 : pata_via
scsi1 : pata_via
ata1: PATA max UDMA/66 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001ffa0 irq 14
ata2: PATA max UDMA/66 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001ffa8 irq 15 ata1.00: ATA-5: IC35L060AVER07-0, ER6OA41A, max UDMA/100
ata1.00: 120103200 sectors, multi 16: LBA
ata1.01: ATA-7: Maxtor 6Y250P0, YAR41BW0, max UDMA/133
ata1.01: 490234752 sectors, multi 16: LBA48
ata1.00: configured for UDMA/66
ata1.01: configured for UDMA/66
ata2.00: ATAPI: PIONEER DVD-RW DVR-106D, 1.05, max UDMA/33
ata2.00: configured for UDMA/33
scsi 0:0:0:0: Direct-Access ATA IC35L060AVER07-0 ER6O PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 120103200 512-byte hardware sectors (61493 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 120103200 512-byte hardware sectors (61493 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sda: sda1 sda2 sda3
sd 0:0:0:0: [sda] Attached SCSI disk
scsi 0:0:1:0: Direct-Access ATA Maxtor 6Y250P0 YAR4 PQ: 0 ANSI: 5
sd 0:0:1:0: [sdb] 490234752 512-byte hardware sectors (251000 MB)
sd 0:0:1:0: [sdb] Write Protect is off
sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:1:0: [sdb] 490234752 512-byte hardware sectors (251000 MB)
sd 0:0:1:0: [sdb] Write Protect is off
sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sdb: sdb1
sd 0:0:1:0: [sdb] Attached SCSI disk
scsi 1:0:0:0: CD-ROM PIONEER DVD-RW DVR-106D 1.05 PQ: 0 ANSI: 5
insmod used greatest stack depth: 820 bytes left
Waiting for driver initialization.
Trying to resume from LABEL=SWAP-sda2
No suspend signature on swap, not resuming.
Creating root device.
Mounting root filesystem.
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
kjournald starting. Commit interval 5 seconds
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
Setting up other filesystems.
Setting up new root fs
no fstab.sys, mounting internal defaults
Switching to new root and running init.
unmounting old /dev
unmounting old /proc
unmounting old /sys
SELinux: Disabled at runtime.
audit(1192175231.628:2): selinux=0 auid=4294967295
INIT: version 2.86 booting
Welcome to Fedora
Press 'I' to enter interactive startup.
Setting clock (localtime): Fri Oct 12 07:47:21 PDT 2007 [ OK ] Starting udev: [ OK ]
Loading default keymap (us): [ OK ]
Setting hostname garnet.leviatron.com: [ OK ]
No devices found
Setting up Logical Volume Management: No volume groups found
[ OK ]
Checking filesystems
Checking all file systems.
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/sda3
/1: clean, 269209/14731200 files, 2239016/14725580 blocks [/sbin/fsck.ext3 (1) -- /boot] fsck.ext3 -a /dev/sda1
/boot: recovering journal
/boot: clean, 50/26104 files, 42169/104388 blocks
[ OK ]
Remounting root filesystem in read-write mode: [ OK ]

Mounting local filesystems:  [  OK  ]
Enabling local filesystem quotas:  [  OK  ]
Enabling /etc/fstab swaps:  [  OK  ]

INIT: Entering runlevel: 3
Entering non-interactive startup
Checking for hardware changes [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface eth0:
Determining IP information for eth0...------------[ cut here ]------------ kernel BUG at include/linux/netdevice.h:1008!
invalid opcode: 0000 [#1] SMP

Modules linked in: ipv6 dm_mirror dm_multipath dm_mod floppy snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_via82xx gameport snd_via82xx_modem snd_seq_dummy snd_emu10k1 snd_hwdep snd_ac97_codec ac97_bus snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss snd_pcm snd_mpu401_uart via686a hwmon snd_rawmidi i2c_viapro snd_timer e100 snd_util_mem snd_seq_device mii button parport_pc snd snd_page_alloc i2c_core soundcore parport sr_mod sg cdrom pata_via ata_generic libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd
CPU:    0
EIP:    0060:[<f8936cff>]    Not tainted VLI
EFLAGS: 00210046   (2.6.23-6.fc8 #1)

EIP is at e100_poll+0x24e/0x2ba [e100]
eax: 00000016 ebx: 00200246 ecx: 00000234 edx: f7b26000
esi: f7b26600 edi: 00000000 ebp: c07f4fc0 esp: c07f4f84
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process ip (pid: 1487, ti=c07f4000 task=f73fed60 task.ti=f6c3b000)

Stack: c07f4f9c c0449484 00000001 f73fed60 c07f4fd0 f7b26000 00000010 00000000 
       00000000 00000046 f6c1e000 007f4fbc f7b26000 00000000 c1e588b0 c07f4fe0 
       c05d05fb c1e58880 fffbf2ec 0000012c 00000001 c0751b18 0000000a c07f4ff8 
Call Trace:
 [<c0406463>] show_trace_log_lvl+0x1a/0x2f
 [<c0406513>] show_stack_log_lvl+0x9b/0xa3
 [<c04066d3>] show_registers+0x1b8/0x289
 [<c04068af>] die+0x10b/0x23e
 [<c0634ce8>] do_trap+0x8a/0xa3
 [<c0406ca1>] do_invalid_op+0x88/0x92
 [<c0634ab2>] error_code+0x72/0x78
 [<c05d05fb>] net_rx_action+0xa4/0x1bc
 [<c0432a39>] __do_softirq+0x78/0xff
 [<c04075d4>] do_softirq+0x74/0xf7
 =======================
Code: 42 2c a8 02 75 73 9c 58 8d 04 05 00 00 00 00 90 89 c3 fa 8d 04 05 00 00 00 00 90 90 e8 7d 0a b1 c7 8b 55 d8 8b 42 2c a8 20 75 04 <0f> 0b eb fe 8b 45 d8 05 80 01 00 00 e8 b4 de bc c7 8b 45 d8 90 
EIP: [<f8936cff>] e100_poll+0x24e/0x2ba [e100] SS:ESP 0068:c07f4f84
Kernel panic - not syncing: Fatal exception in interrupt
list_add corruption. prev->next should be next (c1e588b0), but was 00100100. (prev=f7b26180).
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:33!
invalid opcode: 0000 [#2] SMP 
Modules linked in: ipv6 dm_mirror dm_multipath dm_mod floppy snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_via82xx gameport snd_via82xx_modem snd_seq_dummy snd_emu10k1 snd_hwdep snd_ac97_codec ac97_bus snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss snd_pcm snd_mpu401_uart via686a hwmon snd_rawmidi i2c_viapro snd_timer e100 snd_util_mem snd_seq_device mii button parport_pc snd snd_page_alloc i2c_core soundcore parport sr_mod sg cdrom pata_via ata_generic libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd
CPU:    0
EIP:    0060:[<c0504c70>]    Tainted: G      D VLI
EFLAGS: 00210082   (2.6.23-6.fc8 #1)

EIP is at __list_add+0x4b/0x60
eax: 00000061 ebx: f7b26180 ecx: c042e1f4 edx: f73fed60
esi: 00100100 edi: f7b26600 ebp: c0814f94 esp: c0814f7c
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process ip (pid: 1487, ti=c0814000 task=f73fed60 task.ti=f6c3b000)

Stack: c06dab51 c1e588b0 00100100 f7b26180 f7b26000 00200046 c0814fa4 c05cd3a7 
       00000000 f7b26000 c0814fc8 f89355c4 00000000 c0814fc0 c052b9d1 f7ffd870 
       f70c6d70 00000000 00000000 c0814fe0 c046214e 0000000b c0752380 0000000b 
Call Trace:
 [<c0406463>] show_trace_log_lvl+0x1a/0x2f
 [<c0406513>] show_stack_log_lvl+0x9b/0xa3
 [<c04066d3>] show_registers+0x1b8/0x289
 [<c04068af>] die+0x10b/0x23e
 [<c0634ce8>] do_trap+0x8a/0xa3
 [<c0406ca1>] do_invalid_op+0x88/0x92
 [<c0634ab2>] error_code+0x72/0x78
 [<c05cd3a7>] __netif_rx_schedule+0x47/0xab
 [<f89355c4>] e100_intr+0x96/0xa5 [e100]
 [<c046214e>] handle_IRQ_event+0x1a/0x4f
 [<c0463696>] handle_level_irq+0x7f/0xc9
 [<c04076e8>] do_IRQ+0x91/0xbd
 =======================
Code: 01 ab 6d c0 e8 88 9a f2 ff 0f 0b eb fe 8b 32 39 ce 74 1c 89 54 24 0c 89 74 24 08 89 4c 24 04 c7 04 24 51 ab 6d c0 e8 66 9a f2 ff <0f> 0b eb fe 89 59 04 89 0b 89 43 04 89 18 83 c4 10 5b 5e 5d c3 
EIP: [<c0504c70>] __list_add+0x4b/0x60 SS:ESP 0068:c0814f7c
Kernel panic - not syncing: Fatal exception in interrupt

Herbert Xu

2007-10-12 15:38 UTC #10 lore raw

Quoted 2 lines · David Mack

Still no joy here. See attached capture. What's really weird is that it shows *two* kernel panics, one in e100_poll and one in _list_add.

Yes that's the symptom one would expect from that bug. We really need to apply the same fix that was done for e1000.

Cheers,

Signature · 4 lines

Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

David Mack

2007-10-12 15:52 UTC #11 lore raw

If I understand the message Dave Jones sent yesterday, the patch you mention *was* applied to the e100 driver in 2.6.23-6.fc8?

Dave

Quoted 22 lines

-----Original Message-----
From: Herbert Xu [mailto:[email protected]]
Sent: Friday, October 12, 2007 8:36 AM
To: David Mack
Cc: Dave Jones; Kok, Auke; [email protected]; [email protected]
Subject: Re: e100 problems in .23rc8 ?
Quoted 1 line · David Mack
Still no joy here. See attached capture. What's really
weird is that it
Quoted 1 line
shows *two* kernel panics, one in e100_poll and one in _list_add.
Yes that's the symptom one would expect from that bug. We really need to apply the same fix that was done for e1000.
Cheers,
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Herbert Xu

2007-10-13 02:36 UTC #12 lore raw

Quoted 2 lines · David Mack

If I understand the message Dave Jones sent yesterday, the patch you mention *was* applied to the e100 driver in 2.6.23-6.fc8?

Nope, he applied a different one which doesn't have the crucial part to disable NAPI polls before registration.

Cheers,

Signature · 4 lines

Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Eric Sandeen

2007-10-16 14:33 UTC #13 lore raw

Quoted 8 lines · Herbert Xu

Quoted 2 lines · David Mack
If I understand the message Dave Jones sent yesterday, the patch you mention *was* applied to the e100 driver in 2.6.23-6.fc8?
Nope, he applied a different one which doesn't have the crucial part to disable NAPI polls before registration.
Cheers,

Hm... running 2.6.23-6.fc8, I've been through 30+ reboot cycles without a problem. Before, I'd oops every 5 or so times I booted...

I now have another NIC in the box, disabled; I don't think that should be affecting anything?

-Eric

Herbert Xu

2007-10-16 14:53 UTC #14 lore raw

Quoted 6 lines · Eric Sandeen

Hm... running 2.6.23-6.fc8, I've been through 30+ reboot cycles without a problem. Before, I'd oops every 5 or so times I booted...
I now have another NIC in the box, disabled; I don't think that should be affecting anything?

Well the original problem was caused by spurious interrupts on the IRQ line where your e100 is so it could well be sporadic.

Cheers,

Signature · 4 lines

Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Eric Sandeen

2007-10-16 15:47 UTC #15 lore raw

Quoted 9 lines · Herbert Xu

Quoted 5 lines · Eric Sandeen
Hm... running 2.6.23-6.fc8, I've been through 30+ reboot cycles without a problem. Before, I'd oops every 5 or so times I booted...
I now have another NIC in the box, disabled; I don't think that should be affecting anything?
Well the original problem was caused by spurious interrupts on the IRQ line where your e100 is so it could well be sporadic.

Hah, well, I took the other NIC out and it didn't survive more than a couple reboots on that kernel.

Now that I know I can still hit it, I'll do any testing that's needed.

Thanks,

-Eric

David Mack

2007-10-16 16:40 UTC #16 lore raw

In reply to Herbert Xu

My problem is anything but sporadic. I have succeeded in booting a 2.6.23-based kernel exactly once since the roll toward F8 started early last summer.

Dave

Quoted 29 lines

-----Original Message-----
From: Herbert Xu [mailto:[email protected]] On Behalf Of Herbert Xu
Sent: Tuesday, October 16, 2007 7:35 AM
To: Eric Sandeen
Cc: David Mack; [email protected]; [email protected]; [email protected]
Subject: Re: e100 problems in .23rc8 ?
Quoted 2 lines · Eric Sandeen
Hm... running 2.6.23-6.fc8, I've been through 30+ reboot
cycles without
Quoted 3 lines
a problem. Before, I'd oops every 5 or so times I booted...
I now have another NIC in the box, disabled; I don't think
that should
Quoted 1 line
be affecting anything?
Well the original problem was caused by spurious interrupts on the IRQ line where your e100 is so it could well be sporadic.
Cheers,
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Kok, Auke

2007-10-12 17:08 UTC #17 lore raw

In reply to Herbert Xu

Quoted 6 lines · Herbert Xu

Quoted 2 lines · David Mack
Still no joy here. See attached capture. What's really weird is that it shows *two* kernel panics, one in e100_poll and one in _list_add.
Yes that's the symptom one would expect from that bug. We really need to apply the same fix that was done for e1000.

I feared that. its not the same as that commit that floated around in this thread and involves some reorganization in the init/probe code, so it's a bit more involved than just a few lines. I'll need a little bit of time to generate this fix.

Auke

David Mack

2007-10-18 17:55 UTC #18 lore raw

It appears that the needed e100 fix made it into the Fedora 2.6.23.1-23.fc8 kernel. Boots reliably now.

Huge thanks and great work, guys.

Dave

Quoted 26 lines

-----Original Message-----
From: Kok, Auke [mailto:[email protected]]
Sent: Friday, October 12, 2007 10:05 AM
To: Herbert Xu
Cc: David Mack; Dave Jones; [email protected]; [email protected]
Subject: Re: e100 problems in .23rc8 ?
Quoted 2 lines · Herbert Xu
Quoted 1 line · David Mack
Still no joy here. See attached capture. What's really
weird is that it
Quoted 4 lines
Quoted 1 line
shows *two* kernel panics, one in e100_poll and one in _list_add.
Yes that's the symptom one would expect from that bug. We really need to apply the same fix that was done for e1000.
I feared that. its not the same as that commit that floated around in this thread
and involves some reorganization in the init/probe code, so it's a bit more
involved than just a few lines. I'll need a little bit of time to generate this fix.
Auke

Kok, Auke

2007-10-18 18:00 UTC #19 lore raw

Quoted 4 lines · David Mack

It appears that the needed e100 fix made it into the Fedora 2.6.23.1-23.fc8 kernel. Boots reliably now.
Huge thanks and great work, guys.

DaveJ, I didn't push anything upstream. Can you verify this now works?

Auke

Quoted 27 lines

Dave
Quoted 24 lines
-----Original Message-----
From: Kok, Auke [mailto:[email protected]]
Sent: Friday, October 12, 2007 10:05 AM
To: Herbert Xu
Cc: David Mack; Dave Jones; [email protected]; [email protected]
Subject: Re: e100 problems in .23rc8 ?
Quoted 2 lines · Herbert Xu
Quoted 1 line · David Mack
Still no joy here. See attached capture. What's really
weird is that it
Quoted 3 lines
Quoted 1 line
shows *two* kernel panics, one in e100_poll and one in _list_add.
Yes that's the symptom one would expect from that bug. We really need to apply the same fix that was done for e1000.
I feared that. its not the same as that commit that floated around in this thread
and involves some reorganization in the init/probe code, so it's a bit more
involved than just a few lines. I'll need a little bit of time to generate this fix.
Auke

Chuck Ebbert

2007-10-18 18:17 UTC #20 lore raw

Quoted 9 lines · Auke

Quoted 4 lines · David Mack
It appears that the needed e100 fix made it into the Fedora 2.6.23.1-23.fc8 kernel. Boots reliably now.
Huge thanks and great work, guys.
DaveJ, I didn't push anything upstream. Can you verify this now works?

We didn't put anything in Fedora recently...

Dave Jones

author

2007-10-22 01:04 UTC #21 lore raw

In reply to Kok, Auke

Quoted 7 lines · Auke

Quoted 4 lines · David Mack
It appears that the needed e100 fix made it into the Fedora 2.6.23.1-23.fc8 kernel. Boots reliably now.
Huge thanks and great work, guys.
DaveJ, I didn't push anything upstream. Can you verify this now works?

There was no e100 changes in the kernel above, so David just got lucky. (The race doesn't always occur, so it sometimes appears something got fixed.).

I included the patch below in the latest build, but I've not had chance to try it on an e100 box yet..

Dave

drivers/net/e100.c renamed from drivers/net/e100.c~ +2 -0

@@ -2682,6 +2682,8 @@ static int __devinit e100_probe(struct p
 	if (err)
 		DPRINTK(PROBE, ERR, "Error clearing wake event\n");
 
+	netif_poll_disable(netdev);
+
 	strcpy(netdev->name, "eth%d");
 	if((err = register_netdev(netdev))) {
 		DPRINTK(PROBE, ERR, "Cannot register net device, aborting.\n");

Signature · 1 line

http://www.codemonkey.org.uk

Herbert Xu

2007-10-22 03:15 UTC #22 lore raw

Quoted 3 lines · Dave Jones

I included the patch below in the latest build, but I've not had chance to try it on an e100 box yet..

Looks good to me. Thanks Dave!

Signature · 4 lines

Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

David Mack

2007-10-22 14:06 UTC #23 lore raw

In reply to Dave Jones

Then I got very, very lucky, since I have successfully rebooted 2.6.23.1-23.fc8 four times (zero panics) and this is the first time a 2.6.23 kernel has not panicked on me in months.

This does not fill me with confidence in the theory that the panics I've been seeing are due to a race condition.

Dave

Quoted 45 lines

-----Original Message-----
From: Dave Jones [mailto:[email protected]]
Sent: Sunday, October 21, 2007 6:05 PM
To: Kok, Auke
Cc: David Mack; Herbert Xu; [email protected]; [email protected]
Subject: Re: e100 problems in .23rc8 ?
Quoted 7 lines · Auke
Quoted 4 lines · David Mack
It appears that the needed e100 fix made it into the Fedora 2.6.23.1-23.fc8 kernel. Boots reliably now.
Huge thanks and great work, guys.
DaveJ, I didn't push anything upstream. Can you verify
this now works?
There was no e100 changes in the kernel above, so David just got lucky. (The race doesn't always occur, so it sometimes appears something got fixed.).
I included the patch below in the latest build, but I've not had chance to try it on an e100 box yet..
Dave
--- linux-2.6.23.noarch/drivers/net/e100.c~ 2007-10-18
16:10:40.000000000 -0400
+++ linux-2.6.23.noarch/drivers/net/e100.c 2007-10-18
16:16:02.000000000 -0400
drivers/net/e100.c renamed from drivers/net/e100.c~ +2 -0
@@ -2682,6 +2682,8 @@ static int __devinit e100_probe(struct p
 	if (err)
 		DPRINTK(PROBE, ERR, "Error clearing wake event\n");
 
+	netif_poll_disable(netdev);
+
 	strcpy(netdev->name, "eth%d");
 	if((err = register_netdev(netdev))) {
 		DPRINTK(PROBE, ERR, "Cannot register net 
device, aborting.\n");
Signature · 1 line
http://www.codemonkey.org.uk

Eric Sandeen

2007-10-22 15:00 UTC #24 lore raw

Quoted 6 lines · David Mack

Then I got very, very lucky, since I have successfully rebooted 2.6.23.1-23.fc8 four times (zero panics) and this is the first time a 2.6.23 kernel has not panicked on me in months.
This does not fill me with confidence in the theory that the panics I've been seeing are due to a race condition.

I'll agree with the testing results, at least. I booted successfully *60* times with 2.6.23.1-23.fc8, booting the stock F8test3 kernel would oops every 5 or 6 boots.

It may well be a race, but if so something is apparently opening/closing the window on us! :)

-Eric

Chuck Ebbert

2007-10-22 14:44 UTC #25 lore raw

In reply to Kok, Auke

Quoted 9 lines · Auke

Quoted 4 lines · David Mack
It appears that the needed e100 fix made it into the Fedora 2.6.23.1-23.fc8 kernel. Boots reliably now.
Huge thanks and great work, guys.
DaveJ, I didn't push anything upstream. Can you verify this now works?

One of our users just posted this:

We observed the same panic on a Dell Dimension 5150 (E510), although not
limited to warm boots. We noticed that the following trace is possible:

- when starting the interface, e100_up() gets called
- it calls e100_hw_init(), which disables e100 IRQ generation (e100_disable_irq())
- it registers the interrupt handler
- the interrupt handler (e100_intr()) gets called - this happens because the IRQ line is shared with another device (in this case, the SATA controller)
- the interrupt handler examines the stat_ack register of the interface: even though interrupts are disabled, an event is indicated and the interrupt handler proceeds
- the interrupt handler calls netif_rx_schedule_prep(), which sets the __LINK_STATE_RX_SCHED bit, and __netif_rx_schedule(), which adds the interface to the poll list
- when the interrupt handler returns, e100_up() calls netif_poll_enable(), thus clearing the __LINK_STATE_RX_SCHED bit
- now the NET RX softirq (net_rx_action) calls e100_poll(), which in turn calls netif_rx_complete()
- netif_rx_complete() checks whether the __LINK_STATE_RX_SCHED bit is set and triggers the panic

To avoid this situation, where the interrupt handler executes although e100 interrupts are disabled, we suggest the attached patch. It lets the interrupt handler check the interrupt mask bit before proceeding with the interrupt handling.

Authors: Christof Efkemann <[email protected]>, Kai Thomsen <[email protected]> Description:
Avoid interrupt handler execution if e100 interrupts are disabled. Checks the interrupt mask bit before proceeding with the interrupt handling.

net/e100.c renamed from net/e100.c.old +3 -1

@@ -1960,11 +1960,13 @@
 	struct net_device *netdev = dev_id;
 	struct nic *nic = netdev_priv(netdev);
 	u8 stat_ack = ioread8(&nic->csr->scb.stat_ack);
+	u8 cmd_hi = ioread8(&nic->csr->scb.cmd_hi);
 
 	DPRINTK(INTR, DEBUG, "stat_ack = 0x%02X\n", stat_ack);
 
 	if(stat_ack == stat_ack_not_ours ||	/* Not our interrupt */
-	   stat_ack == stat_ack_not_present)	/* Hardware is ejected */
+	   stat_ack == stat_ack_not_present ||	/* Hardware is ejected */
+	   cmd_hi & irq_mask_all)		/* Interrupts masked */
 		return IRQ_NONE;
 
 	/* Ack interrupt(s) */

Herbert Xu

2007-10-11 23:24 UTC #26 lore raw

In reply to Kok, Auke

Quoted 11 lines · Auke

Quoted 6 lines
Quoted 6 lines
commit 416b5d10afdc797c21c457ade3714e8f2f75edd9
Author: Auke Kok <[email protected]>
Date:   Fri Jun 1 10:22:39 2007 -0700
e1000: disable polling before registering netdevice
this patch actually called napi_disable() in the probe routine which was wrong, but e100 does not do that. Nonetheless e100 doesn't call netif_carrier_off() and netif_stop_queue(), so to make e100 the same as e1000 we should probably do this, see below.

Back then we didn't have napi_disable at all. That patch calls netif_poll_disable which has different semantics.

Quoted 2 lines

Dave, can you see if this resolves the issue for you? If so then we might want to push this to -stable.

The problem is with netif_poll so this patch probably won't help.

Cheers,

Signature · 4 lines

Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt