Bug 90018
| Summary: | modem irrevocably lost during update to 9.0 | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | udippel |
| Component: | kernel | Assignee: | Arjan van de Ven <arjanv> |
| Status: | CLOSED WONTFIX | QA Contact: | David Lawrence <dkl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9 | CC: | twaugh |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i586 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-09-30 15:40:51 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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/ |
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