lkml.org 
[lkml]   [1998]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subject2.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

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.021 / U:0.544 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site