Bug 73841

Summary: usbview causes mca
Product: Red Hat Enterprise Linux 3 Reporter: Alex Williamson <alex_williamson>
Component: kernelAssignee: Anil S Keshavamurthy <akeshava>
Status: CLOSED WONTFIX QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: grgustaf, kaccardi, peterm, petrides, zaitcev
Target Milestone: ---   
Target Release: ---   
Hardware: ia64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-10-19 19:36:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Alex Williamson 2002-09-11 22:31:41 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020615
Debian/1.0.0-3

Description of problem:
In trying to test a USB CDRW (Plextor PX-W4012TU) I found that when
a USB keyboard and the CDRW are under the same OHCI hub, you can
generate an MCA by starting/refreshing usbview while the CDRW is
active.  This has been observed on a Wilson Peak.  Note, the specific
CDRW I'm using is USB 2.0 capable, but I'm using it in 1.1 mode to
get it under the same OHCI hub as the keyboard.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. hookup USB keyboard & CDRW
2. use usbview to organize them under the same OHCI hub
3. run "cdrecord -v dev=0,0,0 speed=4 blank=fast" while continually
   hitting the refresh button on usbview
	

Actual Results:  MCA

Expected Results:  just works

Additional info:

The MCA log shows a bus error with target address
0xd0062048.  This often indicates that there was a
timeout accessing this address.  0xd0062000 is the
value of PCI BAR 0 of the OHCI hub used by the 
keyboard and CDRW.

Comment 1 Alex Williamson 2002-09-11 22:46:45 UTC
Changing to kernel... I can reproduce just by cat'ing /proc/bus/usb/devices

Comment 2 Glen A. Foster 2002-09-12 14:12:53 UTC
Last I knew, Trond wasn't a kernel developer.  Re-assigning to Larry Woodman.

Comment 3 Alex Williamson 2002-09-12 18:22:14 UTC
Here's some more data.  If I run the following:

touch devices.save
while (true) do
  cat /proc/bus/usb/devices > devices.save2
  diff -u devices.save devices.save2
  cp devices.save2 devices.save
  sleep 1
done

I seem to reach a steady state of the below output:

--- devices.save        Thu Sep 12 06:14:31 2002
+++ devices.save2       Thu Sep 12 06:14:32 2002
@@ -47,9 +47,9 @@
 D:  Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
 P:  Vendor=047b ProdID=0002 Rev= 1.20
 S:  Manufacturer=SILITEK
-S:  Product=USB Keyboard and Mouse
 C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr= 50mA
 I:  If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=01 Driver=hid
 E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=24ms
 I:  If#= 1 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=hid
 E:  Ad=82(I) Atr=03(Int.) MxPS=   5 Ivl=10ms
+I) Atr=03(Int.) MxPS=   5 Ivl=10ms
--- devices.save        Thu Sep 12 06:14:32 2002
+++ devices.save2       Thu Sep 12 06:14:33 2002
@@ -47,9 +47,9 @@
 D:  Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
 P:  Vendor=047b ProdID=0002 Rev= 1.20
 S:  Manufacturer=SILITEK
+S:  Product=USB Keyboard and Mouse
 C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr= 50mA
 I:  If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=01 Driver=hid
 E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=24ms
 I:  If#= 1 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=hid
 E:  Ad=82(I) Atr=03(Int.) MxPS=   5 Ivl=10ms
-I) Atr=03(Int.) MxPS=   5 Ivl=10ms

The last line "I) Atr=..." looks like a line of the form "E: Ad=...",
but for some reason the head of the line was cut-off.  I've tried
multiple keyboards, and they all will cause an MCA with the original
process.  I haven't verified that they all cycle in /proc/usb/bus/devices
the same as this.

Comment 4 Tim Burke 2002-09-12 19:22:24 UTC
Weekly status meeting: Not a showstopper.  If RH can look at it would be great.
HP isn't pursuing it actively.


Comment 5 Alex Williamson 2002-09-19 17:32:14 UTC
The MCA often seems to be from the reads in rh_send_irq().  roothub_a()
causes the 0x48 offset MCA.  If I remove this call (knowing there are
2 ports on the hub), I then get an MCA from reading offset 0x50.  This
looks to be the call to roothub_status() in the same function.

So, it looks like the device is busy and we're timing out on the PCI read.
I don't know enough about USB to know if there's a locking issue or if
the device has a "go away, I'm busy" register.

If I bump up the PCI latency on the USB device, I can greatly reduce the
likely hood of hitting to problem, but it doesn't go away entirely.

I've also found that the problem is reproducable using a USB NIC.  I have
a 3com 3c460B 10/100 NIC (these are the ones you can pickup for $5 sometimes).
If I hook it up on the same root hub as the keyboard, ssh in trough it, and
run usbview, I get an MCA.

Also, the variability I was seeing from teh keyboard by itself, doesn't
seem to matter.  I have another keyboard that doesn't cycle like that and
the problem is still there.  I've tried to reproduce the problem with
a USB mouse, and can't make it fail.

Comment 6 Alex Williamson 2002-09-20 17:21:36 UTC
FYI, backporting USB updates from 2.4.20-pre7 does _not_ help.

Comment 7 Matt Wilson 2003-04-04 04:00:26 UTC
normalizing Version in Red Hat Linux Beta product

Comment 9 RHEL Program Management 2007-10-19 19:36:30 UTC
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
 
For more information of the RHEL errata support policy, please visit:
http://www.redhat.com/security/updates/errata/
 
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.