Red Hat Bugzilla – Bug 90018
modem irrevocably lost during update to 9.0
Last modified: 2007-04-18 12:53:24 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.10 (X11; Linux i686; U;) Gecko/20030314 Description of problem: This really bugs me: updated 7.2 to 9. Now the modem is lost. I used setserial and it does display the correct values. But minicom remains dead blank. I tried to re-setup hylafax (for which the modem is required): doesn't find it ('wedged') Now the clue: I have a 'ghosted' harddisk of that old 7.2 and it works! I really don't touch anything on the machine but swapping the power-connector between the two harddisks; the original 7.2 and the updated 9; and reboot, makes the difference between modem dead and modem alive. Hylafax goes along the lines of minicom here: as soon as I plug 7.2 it works, receives, etc. As soon as I plug 9, it's dead and whines. Minicom the same: 7.2 is great, 9 is dead blank. Since I use *exactly* the same hardware (now both harddisks are built-in) that I don't touch except the cable to the harddisk(s), something else must be funny. I hesitated to put 'kernel' as category. If not: where else? Version-Release number of selected component (if applicable): How reproducible: Didn't try Steps to Reproduce: 1. upgrade to 9 2. 3. Actual Results: modem 'wedged' Expected Results: modem alive Additional info: It should be added that the modem sits on COM3, IRQ5. Of course, in both versions: 7.2 and 9 I didn't touch it at all. It's one of those old, jumpered, ones
More likely to be kernel than setserial.
Okay, this problem is solved after a day's work: The kernel is too authoritative. During upgrade it has found some usb-uhci device. In the BIOS this device had deliberately been disabled, plus the IRQ for the modem (5) been allocated to ISA. The kernel cannot bother less and allocates usb-uhci to that IRQ. Therefore, commenting out that extra line in modules.conf works around this problem. I decline to call it 'solved', though. Let's better stick to 'workaround'. If the kernel doesn't bother about BIOS: fine, okay, well; but then it must somehow replicate some of its functions.
the bios apparently doesn't REALLY disable USB :(
Seems we hit something more general now. Maybe someone can point out the correct component, since setserial isn't. It rather has a more general nature. I tried to modprobe that usb-uhci *after* boot. It does the wrong trick again and loads it to IRQ 5. Even though, /proc/interrupts clearly show this one as taken *before* the modprobe is issued: CPU0 0: 1189106 XT-PIC timer 1: 893 XT-PIC keyboard 2: 0 XT-PIC cascade 5: 561 XT-PIC serial 8: 1 XT-PIC rtc 10: 14196 XT-PIC NE2000 12: 17606 XT-PIC eth1 14: 4970 XT-PIC ide0 NMI: 0 ERR: 0 What happens then? The newly loaded usb-uhci sends an IRQ 5, hylafax gets it, queries the modem, modem doesn't answer, hylafax considers it dead and starts filling my mail-box with repetitive modem error mails. We should add, even though usb-uhci is disabled, usb-uhci is marked as 'not allocate IRQ' plus IRQ is reserved for ISA, all in the BIOS. But even - as Arjan pointed out - the USB might not be disabled *really*, another operating system - name forgotten, also something with Red .... - had always respected these settings sufficiently. Let's increase our 'if's: Even if the fault was completely with the BIOS in the first instance: /proc/interrupts talks a clear language: IRQ 5 is taken. Together with that 'Serial' not showing up neither as ISAPNP nor PCI: 00:00.0 Host bridge: Intel Corp. 430TX - 82439TX MTXC (rev 01) 00:01.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 01) 00:01.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) 00:01.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01) 00:01.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 01) 00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 00:0b.0 VGA compatible controller: S3 Inc. 86c775/86c785 [Trio 64V2/DX or /GX] (rev 16) should give a clear indication that usb-uhci better uses another, an unallocated IRQ. And there must be quite a few, despite the VGA-controller. Which sits on IRQ 11, as lspci -v tells us. Dumping an incoming module to 5 because PCI-wise this is fine, does not witness an intelligence sufficient to discard everything else: BIOS settings, /proc/interrupts.
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/