Bug 187335 - kernel 2.6.16-1.2069 breaks internal PCI modem
kernel 2.6.16-1.2069 breaks internal PCI modem
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-30 01:06 EST by Jim Haynes
Modified: 2015-01-04 17:26 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-16 16:49:15 EDT
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 Jim Haynes 2006-03-30 01:06:37 EST
Description of problem:
Desktop machine with internal PCI modem, US Robotics5610b
With the last 2.6.15 kernel the modem shows up as ttyS2.
With the new 2.6.16 kernel it does not appear.

Version-Release number of selected component (if applicable):
2.6.16-1.2069_FC4


How reproducible: always


Steps to Reproduce: 
1.boot up with new kernel
2.try to use modem
3.
  
Actual results:
It ain't there

Expected results:
It should be there

Additional info:
With the last 2.6.15 kernel the modem, US Roboticw 5610b appears as ttyS2
With the new kernel it is not there.

Stuff from dmesg  (2.6.15 kernel <   2.6.16 kernel > )
< Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
---
> Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing enabled
...
< 0000:00:0d.0: ttyS2 at I/O 0xe800 (IRQ = 11) is a 16550A
---
> Couldn't register serial port 0000:00:0d.0: -28

Earlier in the dmesg...
< ACPI: local APIC disabled (-2); pass 'lapic' to re-enable
< LAPIC disabled (-2)
---
> ACPI: local APIC address 0xfee00000
> ACPI: LAPIC (acpi-id [0x00] lapic_id[0x00] enabled)
> (whole bunch of ACPI messages)

Could this be related to bug 187316?
Comment 1 Pavel Rosenboim 2006-04-02 10:13:03 EDT
I have the same problem with internal ISAPNP modem. I diffed config files of
latest 2.6.15 kernel and 2.6.16 kernel and found out that
CONFIG_SERIAL_8250_RUNTIME_UARTS value was changed from 4 to 2. I recompiled
2.6.16 kernel after changing its value back to 4 and this fixed the problem.
Comment 2 Brad Wade 2006-04-05 00:30:56 EDT
I have the same problem with an ISA modem with jumpers.  It worked flawless from
the initial release to version 2.6.15-1.1831_FC4 on ttyS3.  I assume that
Pavel's fix would fix this.
Comment 3 Avi Jacobson 2006-04-06 17:38:15 EDT
(In reply to comment #2)
> I have the same problem with an ISA modem with jumpers.  It worked flawless from
> the initial release to version 2.6.15-1.1831_FC4 on ttyS3.  I assume that
> Pavel's fix would fix this.

I have the same problem using my IR port, which normally appears as /dev/ttyS2.
Under 2.6.15-1.1831_FC4, running 

$ dir /dev/ttyS*

shows 

ttyS0 ttyS1 ttyS2 ttyS3

Under the new kernel, only ttyS0 and ttyS2 appear.

Pavel, for us pathetic newbies who don't know how to recompile the kernel, is
there a way you can provide the recompiled kernel as an rpm? (Or, if the
instructions are reasonably easy to follow, just post instructions?)
Comment 4 Avi Jacobson 2006-04-06 17:42:34 EDT
(Adding myself to Cc list)
Comment 5 Jim Haynes 2006-04-22 17:33:49 EDT
I found some adequate directions for rebuilding the kernel in the
Fedora Forum "Rebuilding Fedora Kernels easy guide"  And verified
that Pavel's fix fixes the problem.  At the place where the guide
tells you to make menuconfig   I instead edited   .config and changed
the number of UARTS from 2 to 4.

Red Hat folks, please make this change in the configuration for those
of use who have internal modems, so we don't have to recompile the kernel
every time you make a new one.  Surely there are more than three of
us who have internal COM devices.
Comment 6 Andre Robatino 2006-05-07 13:47:33 EDT
  My father has the same problem with an internal ISA PnP modem.  Is there any
good reason why the number of UARTS was decreased, other than just a belief that
nobody used them?
Comment 7 Andre Robatino 2006-05-07 14:00:43 EDT
  With the 2096 kernel, "ls -l /dev/ttyS*" shows only ttyS0 and ttyS1 on my
father's machine.  With the original 1369 kernel it shows about 90 entries! (0
to about 90).
Comment 8 Andre Robatino 2006-05-08 19:01:31 EDT
  Also, in FC5 "ls -l /dev/ttyS*" gives 4 entries, /dev/ttyS{0,1,2,3}.  Curious
why the change was only made in the FC4 kernels.
Comment 9 Andre Robatino 2006-05-10 13:02:53 EDT
  I think the title of this bug should be changed to something more general to
reflect the much larger class of hardware it can affect.  For starters, it has
nothing to do with PCI or modems, it can break any device that depends on there
being a reasonably large number of /dev/ttyS* device entries.  This is a trivial
thing to change, and it's being done differently than FC5.  Either FC4 or FC5 is
doing it wrong.  If there's some compelling reason for
CONFIG_SERIAL_8250_RUNTIME_UARTS being 2, then FC5 should make the same change,
otherwise FC4 should change back.
Comment 10 Andre Robatino 2006-05-19 17:19:56 EDT
  According to bug #190279, it should be possible to boot with the kernel argument
8250.nr_uarts=n (where n is the desired number of serial ports), instead of
recompiling the kernel.  Haven't tested this yet.
Comment 11 Jim Haynes 2006-05-20 13:54:58 EDT
Indeed that does seem to work.  Thanks.
Comment 12 Avi Jacobson 2006-05-26 16:47:56 EDT
Yes, it works (I'm on build 8111), but I notice that when I boot with the
aforesaid kernel argument, the whole startup process is slower and takes place
in character mode.

The system displays all of the services starting (in character mode, as it would
normally do if a service failed) -- even though all of the services are [OK]. 

It then displays the release name (I don't recall ever seeing the word "Stentz"
before this) and login prompt (machine_name login:), in character mode, and logs
itself in. The Fedora GUI startup interface never appears (the one with the
progress bar and the names of the services displaying on a single line near the
bottom of the screen as they start up), and the first appearance of the GUI is
the actual GUI login screen. The whole startup process seems to be taking at
least twice as long as before. None of this happened when I compiled my own
kernel from source after manually editing CONFIG_SERIAL_8250_RUNTIME_UARTS.

This is not a kernel build-specific thing: using the same build, when I remove
the uarts kernel argument from grub.conf, it starts up quickly and in GUI mode
as usual.

Any ideas?
Comment 13 Dave Jones 2006-09-16 23:00:20 EDT
[This comment added as part of a mass-update to all open FC4 kernel bugs]

FC4 has now transitioned to the Fedora legacy project, which will continue to
release security related updates for the kernel.  As this bug is not security
related, it is unlikely to be fixed in an update for FC4, and has been migrated
to FC5.

Please retest with Fedora Core 5.

Thank you.
Comment 14 Dave Jones 2006-10-16 15:16:17 EDT
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.
Comment 15 Andre Robatino 2006-10-16 15:26:18 EDT
  Someone should have responded earlier - with FC5, the default number of UARTs
is 4, as it should be, not 2 as in FC4, so the problem doesn't exist.  This bug
should probably be closed.

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