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?
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.
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.
(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?)
(Adding myself to Cc list)
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.
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?
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).
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.
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.
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.
Indeed that does seem to work. Thanks.
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?
[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.
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.
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.