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 2001-03-22 12:18:53 --- ---- lspci -v output? ------- Additional comments from shane_painter 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 ** Reproducible: Always Steps to Reproduce: 1.See copied Description 2. 3.
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.
Created attachment 14323 [details] dmesg output from a "clean" boot
Created attachment 14324 [details] lspci -v output from a "clean" boot
Created attachment 14325 [details] serial log of kernel messages and oops(es)
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.
What's the entry for the usb controller in /etc/sysconfig/hwconf look like? Are these all fresh installs, or upgrades?
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
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++) {
On a machine that displays this problem, if you look at VT 2/3/4, are there any messages logged from kudzu.
usb-ohci bit will be in 2.4.2-0.1.50.
The slimerald is using the usb-uhci module. Can the second part of this patch get applied please?
Shane tested this here and the usb-uhci patch above solves the problem for us.
Apologies for missing the 2nd part; It's kind of busy here in kernelland. 2nd half of the patch is now in the kernel