lkml.org 
[lkml]   [1998]   [Oct]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectKeyboard lockup with SMP 1.2.123.
Good day to everyone on the linux kernel list.  I hope that this note
finds the day starting well for you.

I experienced a keyboard lockup this afternoon with the 1.2.123 kernel
compiled SMP. The machine configuration is as follows:

Dual PII-300 with 256Mbyte: Intel 440LX
Diamond/Permedia II AGP video card.
SMC Etherpower II
Ensoniq AudioPCI
Buslogic BT-958 SCSI

I can forward the kernel .config if anyone needs that level of
detail. The kernel was a stock 1.2.123 with the exception of the
driver for the Etherpower II which had been replaced with the v1.04
driver from Donald's website.

The kernel had been compiled with support for the Ensoniq AudioPCI
card. The card was not in use at the time and as a side note I was
not able to record or play audio although I could cat to and from
/dev/dsp without an error.

X was running but I had switched back to the VGA virtual consoles.
The lockup occurred as I was switching back and for between two
consoles. The machine was pretty quiet, I was composing e-mail on one
virtual console and had switched to another and was rlogin'ed to
another machine. Just before the lockup the network traffic became
jerky and paused for several seconds. I switched to another console
to ping the target machine to see if it had gone down and when I
switched back to the rlogin screen the keyboard locked.

There was no kernel panic, oops or anything else amiss but the console
was completely dead. The screen blanker blanked the screen after the
inactivity interval expired and I could not revive it. I telnet'ed
from one of the other machines in the office to reboot.

I am growing somewhat suspicious of the SMC Etherpower II cards in the
SMP environment. I have communicated these concerns with Donald. I
have a production SMP server running 2.0.35 with a pair of SMC
Etherpower II cards and have experienced one complete kernel deadlock
and 3 incidents of having the network cards hang.

That machine is an Intel 440FX Dual PII-300 with 256Mbyte of RAM. Two
Etherpower II cards sharing IRQ 10 and a DPT-3334UW on IRQ 11 are the
only other things in the machine. The 2.0.35 kernel in use had been
upgraded to v1.03 of the epic driver BTW.

The only diagnostic from the panic was the following printk from the
allow_interrupts function in sched/kernel.c:

FORWARDED INTERRUPT TIMEOUT (AKP = %d, Saved AKP = %d)

The machine in question is the IMAP server for our university
messaging system. There was moderate 10Mbit/sec traffic on one NIC
and what I would refer to as low traffic on the second. There were
probably 100-110 IMAP connections open, no swapping with only about 45
megabyte of the 256Megabyte of memory actually used.

The networking hangs occurred under somewhat similar load conditions.
In 2 of the 3 situations there would appear to be a somewhat causal
relationship between an increase in traffic on the second NIC (backups
started on the secondary network) and the networking hangs.

The networking hangs were recovered by downing the interfaces for
several minutes and then re-enabling them. Interestingly downing the
hung interface without downing the second interface as well would fail
to recover the hung interface.

My intentions were to upgrade the production server to 1.2.123 if that
seemed stable on my personal workstation. Since I experienced the
keyboard lockup I am going to delay that move until I get a little
more feedback on 1.2.123.

The IMAP server which is currently hosting around 3000 accounts has
been otherwise flawless. Since the server is such a simple
configuration with minimal load except for network traffic/connections
the deadlock would seem to implicate either the DPT card or the SMC
cards as no one would have been banging on the keybard at the time.
The fact that the machine is dual-homed with the cards sharing an
interrupt and recovery required downing both interfaces offers another
interesting ingredient to the analysis.

My suspicion of the SMC cards in the SMP environment has increased
since the keyboard lockup coincided with virtual console switching at
the same time as the machine got hit with a burst of network traffic
from the rlogin session.

All of this of course could be circumstantial but I wanted to get a
review of the problem out in case someone else is seeing similar
coincidences. Donald has a personal review of this problem as well as
a description of problem that we have seen with the SMC cards
negotiating connections with a switch and a 100Mbit shared hub that we
have.

I would entertain any suggestions, comments or further questions.
Have a pleasant end of the week.

Greg

As always,
Dr. G.W. Wettstein Enjellic Systems Development - Specialists in
4206 N. 19th Ave. intranet based enterprise information solutions.
Fargo, ND 58102 WWW: http://www.enjellic.com
Phone: 701-281-1686 EMAIL: greg@wind.enjellic.com
------------------------------------------------------------------------------
"It means your NE2000 clone wet itself. Some of them do this when they
get collisions. The driver response is basically to bang the card on
the head repeatedly until it talks sense."
-- Alan Cox
Linux-Net

-
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.tux.org/lkml/

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