Bug 4240 - smp kernel hangs when serial port is used with modem
smp kernel hangs when serial port is used with modem
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
6.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Cristian Gafton
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-07-28 12:50 EDT by peterce
Modified: 2008-08-01 12:22 EDT (History)
0 users

See Also:
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: ---


Attachments (Terms of Use)

  None (edit)
Description peterce 1999-07-28 12:50:13 EDT
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.