Bug 90018 - modem irrevocably lost during update to 9.0
modem irrevocably lost during update to 9.0
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
9
i586 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-05-01 01:12 EDT by udippel
Modified: 2007-04-18 12:53 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:40:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description udippel 2003-05-01 01:12:36 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
Comment 1 Tim Waugh 2003-05-01 05:23:32 EDT
More likely to be kernel than setserial.
Comment 2 udippel 2003-05-01 05:24:57 EDT
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.
Comment 3 Arjan van de Ven 2003-05-01 05:27:50 EDT
the bios apparently doesn't REALLY disable USB :(
Comment 4 udippel 2003-05-01 12:48:03 EDT
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.
Comment 5 Bugzilla owner 2004-09-30 11:40:51 EDT
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/

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