From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021214
Description of problem:
I am currently running Red Hat Linux 8.0 with the recently released errata,
There seems to be a compatibility issue with usb-uhci.o and the USB controller
on my mainboard (Shuttle SS24). Although the majority of devices work with this
module installed, I have a Philips PCVC680K USB camera which is supported via
the pwc.o module.
This issue was present with the original kernel (2.4.18-14) that ships with
Psyche. Do NOT take this bug report as being specific to the recently released
With usb-uhci.o loaded, I can connect the camera and get the usual 'device not
claimed by any active driver' message. Modprobe'ing pwc.o causes the current
terminal session to hang and the output from 'lsmod' indicates that the module
The same behaviour occurs even if you load the pwc.o module first and then
connect the camera. My suspicions originally fell on pwc.o but this camera
works fine on an ALi OHCI-based chipset with Linux 2.4.12 on an elderly Mandrake
After a bit of investigation, this problem seems to go away if I use uhci.o
instead of usb-uhci.o to drive my USB controller. This doesn't seem to have any
detrimental effect on any of my other USB devices (Microsoft Internet Keyboard
USB, Microsoft IntelliMouse USB or Corega USB-TXS Ethernet Controller).
I have attached various outputs from lspci in case you need to 'special case' my
USB controller during the installation process (i.e. replace 'alias
usb-controller usb-uhci' with 'alias usb-controller uhci' in /etc/modules.conf).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Load usb-uhci.o.
2. Connect Philips PCVC680K USB camera.
3. Load pwc.o.
Actual Results: Module initialization hangs.
Expected Results: Driver module should have registered with USB stack and
initialized the camera.
The information supplied should be enough to write a workaround for
anaconda/kudzu and inform the maintainer of the usb-uhci.o module of any
problem. You are welcome to pass on my e-mail address to the maintainer of the
usb-uhci.o module if you think it will help to expedite a permanent fix to the
Created attachment 89008 [details]
verbose output from lspci (referred to in bug description)
See also bug 80622 - there uhci also works better than usb-uhci.
Alexey, thanks for finding this bug for me, I'm taking it.
But don't you dare to dup it :)
Terry, I need some help from you on this issue.
First, please make sure it happens with something more recent. There was
a 2.4.20 based errata recently, with some significant updates. I am mainly
talking about the interrup transfer fixes (some webcams use that, I do not
remember how pwc works though). There were some more, too.
Once there, I'd need the following:
- Edit /etc/inittab and set default runlevel to 3, reboot
(this is done to reduce the number of processes in Sysrq trace).
- Log to a text console (Alt-F1), but don't run startx
- Kill everything unnecessary (again, to reduce the trace).
- Before running the test, do (as root)
echo 1 > /proc/sys/kernel/sysrq
echo 8 > /proc/sys/kernel/printk
- Run the test from a textual console. Well, just stay in the
console a plug the camera - hotplug does the rest.
Verify that a problem happened, e.g. insmod hung. Don't try to
kill it with ^C.
Now, you'll either see a blind lockup, or a so-called "oops".
If there was an "oops", switch to other console with Alt-F2,
log in as root, and run "dmesg > /tmp/dmesg.fail".
If it was just a lockup, hit a chord <Alt-SysRq-T>
This will print gobs of stack info. Swith as before
and do the same dmesg trick.
Once done, sync and reboot. Then, attache the dmesg.fail to the bug,
but please do not drop it into the comments box (just like you did
with the lspci output).
One last thing... On the whole, usb-uhci was consistently less troublesome
than the uhci. I understand that sometimes we hit a driver which works
with uhci better, but it is to be expected.
No reply, needinfo-ing.
Sorry for the late reply - I have been extremely busy and needed to ensure that
I was guaranteed a spare two hours when I updated the kernel just in case I
killed the box (sadly, it is a production machine).
Anyway, I upgraded the kernel to the latest Red Hat errata,
kernel-2.4.20-19.8.i586.rpm, with no problems. The good news is that I can no
longer reproduce the issue described in my initial bug report.
Perhaps pwc was doing something with non-timeouted isochronous transfers...
I am closing as "ERRATA".