Messages in this thread | | | Date | 27 Aug 1998 13:30:10 +0200 | From | "Henning P. Schmiedehausen" <> | Subject | 2.0.36pre6 - SMP lockup, interrupt related |
| |
Hardware:
- Gigabyte GA-686LX2 board with 2x PII 233, 512 MByte RAM
- 2x Adaptec 2940UW Controller, Controller 1: 4 G Boot Disk, SCSI CDROM, 9 G Stripe Disk Controller 2: 9 G Stripe Disk 9 G Data Disk
running off the 5.0.20 driver from 2.0.36pre6. ;-)
- 1x 100 MBit Ethernet, DEC DC21140 based (some dlink card)
running from the tulip driver in the 2.0.36pre6 kernel.
Board has BIOS Rev 1.14 (without this it was a simple catastrophe), the Adaptecs have BIOS Rev 1.32.
Kernel running is 2.0.35 + Alan's pre-patch 2.0.36pre6 (really, this time I checked... ;-) + the 2.0.33 mtrr patch without which it wouldn't run at all in SMP mode.
Kernel is SMP Mode, machine boots fine, I checked the SCSI and Ethernet boot messages, everything seems to be fine.
The ethernet is connected (100 MBit, full duplex) to a cisco catalyst 2900 switch. The Catalyst is hard coded to 100 MBit, full duplex, the card does auto-negotiation.
The machine is a full feed newsserver + reader machine, normal load is around four and tops out at about 25.
It runs fine for some period of time (between four hours and three days) and then locks up with fast scrolling the following message on the console:
eth0: Re-entering the interrupt handler with proc 0, proc 0 already handling
Don't know whether there are other messages in front as I get no information in any logfile, just on the console. This messages scrolls at max speed until the system is resetted.
No Scroll-Key or CTL-ALT-DEL or anything remote works. Machine presents itself as completely dead.
After reboot it works again for some time.
Is there any sense in switching to the de4x5 driver in the kernel away from tulip? As far as I can see, the driver in the 2.0.36pre6 kernel is the most actual (0.89H). (There seems to bei a .89K as a development version. I will try this one, too).
I also found a message from Donald Becker about similar problems and a small patch to the driver:
--- cut --- Donald Becker --- cut --- I'm not certain how the driver can prevent these errors -- the kernel is supposed to prevent the device driver from being re-entered. I consider this a SMP kernel flaw.
You can mitigate the effect by adding the following around line 1778:
ioaddr = dev->base_addr; lp = (struct tulip_private *)dev->priv; - if (dev->interrupt) + if (test_and_set_bit(dev->interrupt)) { printk(KERN_ERR "%s: Re-entering the interrupt handler.\n", dev->name); + return; + } - dev->interrupt = 1;
Note: This code wasn't intended to be a mutual-exclusion lock (I would have used test_and_set_bit() initially!), but only as a cheap sanity check. --- cut --- Donald Becker --- cut ---
I'm currently considering changing the board as the Gigabyte seems to be known as crappy but as this is the first Linux box in a "sun only" shop and I already had a hard time to convince everyone around here, that Linux is a reliable platform, I really need some sort of solution beyond "run in UP mode". :-)
Kind regards Henning
-- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- hps@tanstaafl.de TANSTAAFL! Consulting - Unix, Internet, Security
Hutweide 15 Fon.: 09131 / 50654-0 "There ain't no such D-91054 Buckenhof Fax.: 09131 / 50654-20 thing as a free Linux"
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
| |