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, kernel-2.4.18-19.8.0.i586.rpm. 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 errata kernel. 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 is 'initializing'. 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 8.1 box. 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): How reproducible: Always 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. Additional info: 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 usb-uhci.o module.
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".