Bug 34172 - Slimerald (6350) will not boot to linux 7.1 after installation (fails on USB load)
Slimerald (6350) will not boot to linux 7.1 after installation (fails on USB ...
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.1
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-03-30 16:47 EST by Shane Painter
Modified: 2007-04-18 12:32 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-04-06 17:24:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg output from a "clean" boot (14.45 KB, text/plain)
2001-03-30 20:28 EST, Jonathan Arehart
no flags Details
lspci -v output from a "clean" boot (3.31 KB, text/plain)
2001-03-30 20:30 EST, Jonathan Arehart
no flags Details
serial log of kernel messages and oops(es) (14.83 KB, text/plain)
2001-03-30 20:39 EST, Jonathan Arehart
no flags Details

  None (edit)
Description Shane Painter 2001-03-30 16:47:00 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)


When booting for the first time after installation, the driver fails >to 
load for the USB device that it thinks it has.  Apparently, >Florence 
detects the chipset and thinks that there should be a USB >port, but since 
there is not one on an Emerald it causes this fail.  >Cannot go any 
further.  

This was seen with 7.0, but was fixed. Doug fixed this last time. Doug? 

The BIOS sets the USB interrupt to 0. RH7 made adjustments for USB being 
set to 0 and assumed a non-working USB controller. Please make this the 
case for 7.1 as well.

Reproducible: Always
Steps to Reproduce:
1. Load Emerald (6300)
2. On first boot USB loads, and hangs the system
3.
------- Additional comments from notting@redhat.com 2001-03-22 12:18:53 ---
----
lspci -v output?
------- Additional comments from shane_painter@dell.com 2001-03-26 
09:35:06 -------
This was not reproducable on a production grade machine. NON-ISSUE. Thanks.
-----------------
This has returned with greater visability/reproducability with the qa0328 
build. This seems to affect 6300/6350. Jonathan is in the process of 
gathering information to provide back to you. This should be available 
soon.
** shane_painter@dell.com **

Reproducible: Always
Steps to Reproduce:
1.See copied Description
2.
3.
Comment 1 Jonathan Arehart 2001-03-30 20:26:54 EST
I checked on a PE6300 and couldn't re-create the problem.  However, I do still
have the problem on a PE6350.  When the boot locks up, shift-page-up is still
funciontal so I can see the kernel oops output.

I'll attach output from dmesg and lspci -v on a "clean" boot.  "Clean" being
with the nousb option on the kernel command line.  I'll also attach the oops
output from a failed boot.  (This is the QA0328 build, btw.)

So, the rundown of how the boot proceeds.  The kernel finishes, init starts, the
hostname is set, the USB filesystem is mounted, the usb-ohci module fails to
load saying "usb-uhci.o: init_module: No such device" with the note from insmod
about errors possibly coming from invalid IRQ or IO parameters.  Then the
oops'es happen, and filesystems are checked.  Init eventually enteres runlevel
3, and things lock up after the "Checking for new hardware" message is printed
but before the "[ OK ]" shows up.
Comment 2 Jonathan Arehart 2001-03-30 20:28:21 EST
Created attachment 14323 [details]
dmesg output from a "clean" boot
Comment 3 Jonathan Arehart 2001-03-30 20:30:25 EST
Created attachment 14324 [details]
lspci -v output from a "clean" boot
Comment 4 Jonathan Arehart 2001-03-30 20:39:39 EST
Created attachment 14325 [details]
serial log of kernel messages and oops(es)
Comment 5 Jonathan Arehart 2001-04-02 21:38:37 EDT
Earlier today I installed QA0401 on the PE6350 and the problem persists.  I
remember seeing some usb related kernel output on the log VT during the install
process.  Tomorrow I'll capture that and send it along.
Comment 6 Bill Nottingham 2001-04-03 00:41:43 EDT
What's the entry for the usb controller in /etc/sysconfig/hwconf look like?
Are these all fresh installs, or upgrades?
Comment 7 Jonathan Arehart 2001-04-03 13:04:46 EDT
These are fresh installs.  Here's the USB entry from /etc/sysconfig/hwconf:

-
class: USB
bus: PCI
detached: 0
driver: disabled
desc: "Intel Corporation|82371AB PIIX4 USB"
vendorId: 8086
deviceId: 7112
subVendorId: 0000
subDeviceId: 0000
pciType: 1
Comment 8 Matt Domsch 2001-04-03 13:43:13 EDT
It's dying because the USB controller is being assigned IRQ0 by the BIOS.
Here are a couple patches to fix it like we did with 7.0.

--- linux-2.4/drivers/usb/usb-ohci.c~	Sun Apr  1 12:43:44 2001
+++ linux-2.4/drivers/usb/usb-ohci.c	Tue Apr  3 12:42:15 2001
@@ -2323,6 +2323,11 @@
 
 	if (pci_enable_device(dev) < 0)
 		return -ENODEV;
+
+	if (!dev->irq) {
+		err("found OHCI device with no IRQ assigned. check BIOS 
settings!");
+		return -ENODEV;
+	}
 	
 	/* we read its hardware registers as memory */
 	mem_resource = pci_resource_start(dev, 0);


--- linux-2.4/drivers/usb/usb-uhci.c~	Sun Apr  1 12:43:53 2001
+++ linux-2.4/drivers/usb/usb-uhci.c	Tue Apr  3 12:42:03 2001
@@ -2998,6 +2998,12 @@
 
 	if (pci_enable_device(dev) < 0)
 		return -ENODEV;
+
+	if (!dev->irq) {
+		err("found UHCI device with no IRQ assigned. check BIOS 
settings!");
+		return -ENODEV;
+	}
+
 	
 	/* Search for the IO base address.. */
 	for (i = 0; i < 6; i++) {
Comment 9 Bill Nottingham 2001-04-03 15:07:02 EDT
On a machine that displays this problem, if you look at VT 2/3/4, are there
any messages logged from kudzu.
Comment 10 Bill Nottingham 2001-04-06 14:52:21 EDT
usb-ohci bit will be in 2.4.2-0.1.50.
Comment 11 Matt Domsch 2001-04-06 14:57:16 EDT
The slimerald is using the usb-uhci module.  Can the second part of this patch 
get applied please?
Comment 12 Matt Domsch 2001-04-06 15:00:51 EDT
Shane tested this here and the usb-uhci patch above solves the problem for us.
Comment 13 Arjan van de Ven 2001-04-06 17:24:33 EDT
Apologies for missing the 2nd part; It's kind of busy here in kernelland.
2nd half of the patch is now in the kernel

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