Bug 80805 - usb-uhci vs. uhci ?
Summary: usb-uhci vs. uhci ?
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 8.0
Hardware: i586
OS: Linux
Target Milestone: ---
Assignee: Pete Zaitcev
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2002-12-31 16:33 UTC by Terry Froy
Modified: 2007-04-18 16:49 UTC (History)
1 user (show)

Fixed In Version: 2.4.20-19
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-07-27 23:03:20 UTC

Attachments (Terms of Use)
verbose output from lspci (referred to in bug description) (13.12 KB, text/plain)
2002-12-31 16:34 UTC, Terry Froy
no flags Details

Description Terry Froy 2002-12-31 16:33:11 UTC
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
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:

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.

Comment 1 Terry Froy 2002-12-31 16:34:49 UTC
Created attachment 89008 [details]
verbose output from lspci (referred to in bug description)

Comment 2 Aleksey Nogin 2003-01-06 11:35:46 UTC
See also bug 80622 - there uhci also works better than usb-uhci.

Comment 3 Pete Zaitcev 2003-01-06 19:09:01 UTC
Alexey, thanks for finding this bug for me, I'm taking it.
But don't you dare to dup it :)

Comment 4 Pete Zaitcev 2003-06-03 02:14:38 UTC
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.

Comment 5 Pete Zaitcev 2003-07-27 06:26:00 UTC
No reply, needinfo-ing.

Comment 6 Terry Froy 2003-07-27 21:38:33 UTC
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.

Comment 7 Pete Zaitcev 2003-07-27 23:03:20 UTC
Perhaps pwc was doing something with non-timeouted isochronous transfers...

I am closing as "ERRATA".

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