Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 3687

Summary: Upgraded to Kernel 2.2.5-22, Network Configurator ppp fails to dial external /dev/modem or serial port
Product: [Retired] Red Hat Linux Reporter: jimomura
Component: kernelAssignee: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 1999-06-28 15:57:35 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description jimomura 1999-06-24 00:55:33 UTC
Kernel 2.2.5-22 And PPP

Last week I upgraded from RH Linux 5.1 to RH Linux 6.0.
There were
no apparent problems.  Specifically, tests of Netscape
through Network Configurator PPP through /dev/modem, all
Gnome over X Windows, worked without problems where all the
were from the distribution CD-ROM.  I then began upgrading
to the
latest files.

The first few upgrades worked without problems.  Then I got
to the Kernel upgrade from 2.2.5-15 to 2.2.5-22.  At this
Network Configurator failed to dial out through /dev/modem.
When the connection is "activated" the modem's DTR light
one momentarily and then goes down without dialing.  I've
seen this problem before trying to up grade RHL 5.1 from
kernel 2.0.35-x to 2.0.36-x and I never did resolve it.  I
"dmesg" to see what I could and this is the result:

"Linux version 2.2.5-15 (
 (gcc version egcs-2.91.66 19990314/Linux
 (egcs-1.1.2 release)) #1 Mon Apr 19 21:39:28 EDT 1999"

[Note:  The above does not match the Kernel which had
been upgraded to 2.2.5-22]

. . . [Removed stuff that's unlikely to be relevant]

"Linux NET4.0 for Linux 2.2
Based upon Swansea University Computer Society NET3.039
NET4: Unix domain sockets 1.0 for Linux NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
Initializing RT netlink socket
Starting kswapd v 1.5
Serial driver version 4.27 with MANY_PORTS MULTIPORT
SHARE_IRQ enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
pty: 256 Unix98 ptys configured
apm: BIOS version 1.1 Flags 0x07 (Driver version 1.9)"

. . . [More stuff removed]

"tty_io.c: process 649 (pppd) used obsolete /dev/cua1
 - update software to use /dev/ttyS1
tty_io.c: process 695 (pppd) used obsolete /dev/cua1
 - update software to use /dev/ttyS1
tty_io.c: process 703 (pppd) used obsolete /dev/cua1
 - update software to use /dev/ttyS1
tty_io.c: process 779 (pppd) used obsolete /dev/cua1
 - update software to use /dev/ttyS1
tty_io.c: process 787 (pppd) used obsolete /dev/cua1
 - update software to use /dev/ttyS1"

I then continued to upgrade according to the later errata.
Upgrading "dev.2.7.7-2.i386.rpm" got rid of the
"tty_io.c: . . ." reported by "dmesg" listed above, but the
serial ports still don't work with the "2.2.5-22" kernel.

From the last few lines it seemed that I could probably
point "Network Configurator" directly to "/dev/ttyS1",
bypassing "/dev/modem".  But I tried this and it didn't

I'm now in the process of upgrading XFree86 as per the
last errata note I have, dated June 17, 1999.  However,
this is unlikely to help this problem.

------- Additional Comments From   06/27/99 20:27 -------
     I went over the Errata page and the referred URL
and realized that I'd failed to complete the installation process.
I wondered why my earlier upgrades worked, then I remembered that
I had in fact done the complete upgrade procedure before.  But
I didn't keep my previous upgrade notes.  Since I don't work
with Linux often (yet), I simply forgot the issues of checking
linux.conf and running lilo -v.

As far as I'm concerned, this issue is resolved, though the
matter of the obsolete "/dev/cua1" etc. might be worth
looking into.