Bug 4240

Summary: smp kernel hangs when serial port is used with modem
Product: [Retired] Red Hat Linux Reporter: peterce
Component: kernelAssignee: Cristian Gafton <gafton>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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.