Bug 4240 - smp kernel hangs when serial port is used with modem
Summary: smp kernel hangs when serial port is used with modem
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 6.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Cristian Gafton
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-07-28 16:50 UTC by peterce
Modified: 2008-08-01 16:22 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description peterce 1999-07-28 16:50:13 UTC
smp kernel 2-2-15 hangs if a serial port (either one)
is actively attached to a modem that is dialed in.  The
hang occurs seemingly randomly, even if there is no keyboard
or mouse activity (though it often seems triggered by
typing or mouse movement.)  INTERESTINGLY, if a compute
intensive task (such as the SETI FFT task) is running,
I have never observed the system to hang.  It will hang
for a second or two, but will recover and go on as normal.
However, if the smp machine is empty, and the serial port
is running a modem, it is a matter of time before a hang
will occur.  X stops, keyboard/mouse stops, ctl-alt-del will
not kill X, reset button will not boot (it will hang too)
and only powerdown will release the lockup.  I have noticed
that while X is stopped, there is often some residual
modem activity, which will eventually also stop.  I wonder
if X was assigned to a CPU which was put to sleep, while
the other CPU handled the modem, and it forgot to reactivate
its partner CPU afterwards??

Machine: dual Intel P-III 450MHz, 384MB ECC memory,
IDE hard disks, two SCSI adapters (not in use at time of
hang).

Problem occurs if the X server is either XFree86 or Metro-X.

The serial port is running a ppp connection.

Once (just once), when the hang occurred, the machine
worked out of it part way.  xosview indicated that the
second CPU was dead in the water, and the behavior of X
was start-stop-start-stop as if CPU-0 were trying to hand
work off to the now-dead CPU-1.  Reboot was necessary.
All other times, the machine hangs and never recovers.


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