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):
Steps to Reproduce:
1. upgrade to 9
Actual Results: modem 'wedged'
Expected Results: modem alive
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:
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
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
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]
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,
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
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/