Description of problem: On some of the U20 from the customer he get from time to time the following messages: Feb 23 09:46:07 evebe622 kernel: drivers/usb/input/hid-core.c: control queue full Feb 23 09:51:54 evebe622 kernel: drivers/usb/input/hid-core.c: control queue full When the customer tries to run the command "lsusb -v" when this issue is happen, the command takes more the 2 minutes and brakes than with the message: kernel: usb 2-5: control timeout on ep0in This issue seems to happen only when the customer is running VMware player: - VMware Player version=1.0.3 build=build-34682 - Guest is Windows XP - Vmwaretools are installed We try to reproduce this in our labs but unfortunately aren't able. Any suggestion for the cause of this issue? Version-Release number of selected component (if applicable): kernel 2.6.9-42.40.ELsmp and 2.6.9-68.3 reproduces How reproducible: This issue has happened from the beginning, on RHEL4u4 systems with vmplayer. They didn't use any extra USB devices, just running Windows XP as guest. The only USB devices they are using are mice and keyboards, which are provided as legacy device (non usb) to the guest system. Steps to Reproduce: Run vmware. Actual results: * messages printed * run the command "lsusb -v" when this issue is happen, the command takes more the 2 minutes and brakes then with the message: kernel: usb 2-5: control timeout on ep0in He checks the messages of all his systems and also find the same happen on a W2100z. This makes us believe that this is not a Hardware or BIOS issue as both systems uses completely different USB implementations (ck804 vs. AMD8111/NEC). Customer has confirmed that he do not see any ill effect from these messages and he didn't bring up this issue with VMware. Expected results: No messages/errors printed and lsusb runs fine. Additional info: from vmware.log: 342 May 21 15:02:26: mks| MKS lost grab 343 May 21 15:04:08: mks| MKS lost grab 344 May 21 15:07:51: mks| MKS lost grab 345 May 21 15:07:53: mks| MKS lost grab 346 May 21 15:07:54: mks| MKS lost grab 347 May 21 17:11:30: vmx| DISKLIB-LIB :numIOs = 100000 numMergedIOs = 20084 numSplitIOs = 2471 348 May 21 17:34:41: mks| MKS lost grab 349 May 21 17:34:42: mks| MKS lost grab 350 May 21 17:34:47: vcpu-0| Guest: toolbox: Got a logoff event. 351 May 21 17:34:47: vcpu-0| GuestRpc: Channel 2 reinitialized. 352 May 21 17:34:52: vcpu-0| Guest: toolbox: Got a logoff event. 353 May 21 17:34:54: vcpu-0| Guest: toolbox: VMware Tools Service Shutdown. 354 May 21 17:34:54: vcpu-0| Guest: toolbox: VMware Tools Service Stopping. 355 May 21 17:34:54: vcpu-0| GuestRpc: Channel 1 reinitialized. 356 May 21 17:34:58: vcpu-0| VNET: Notification enabled for Ethernet0 357 May 21 17:34:59: vcpu-0| VMMouse: CMD Disable 358 May 21 17:34:59: vcpu-0| VMMouse: Disabling VMMouse mode 359 May 21 17:34:59: vcpu-0| MKS switching absolute mouse on 360 May 21 17:34:59: vcpu-0| UHCI: HCReset 361 May 21 17:34:59: vcpu-0| CPU reset: soft 362 May 21 17:34:59: mks| Ignoring update request in VGA_Expose (mode change pending). 363 May 21 17:34:59: vcpu-0| SVGA: Unregistering IOSpace at 0x1440 (0x1440) 364 May 21 17:34:59: vcpu-0| SVGA: Unregistering MemSpace at 0xf0000000(0xf0000000) and 0xfe000000(0xfe000000) 365 May 21 17:34:59: vcpu-0| SVGA: Registering MemSpace at 0xf0000000(0xf0000000) and 0xe8000000(0xfe000000) 366 May 21 17:34:59: vcpu-0| PCI OPROM: Asked to map the VBIOS OPROM at 0xfe800000 (size 32768 bytes) During this times he frequently get the USB error message, but there seems nothing related. New packages didn't help: libusb-devel-0.1.8-3 usbutils-0.11-7.RHEL4.1 libusb-0.1.8-3 libusb-0.1.8-3 Debug were enabled in VM's vmx file adding the following: debug = "TRUE" usb.generic.skipsetconfig = "TRUE" usb.analyxer.enable = "TRUE" The files should be attached in the next comments.
Created attachment 291877 [details] vmware log with debug enabled Attaching the vmware log using the following options: debug = "TRUE" usb.generic.skipsetconfig = "TRUE" usb.analyxer.enable = "TRUE"
This is not going to be resolved in the RHEL 4.7 timeframe, we are past code submission, moving out to R4.8.
Flavio or Jeremy: Please ask the customer to run my kernel 2.6.9-68.32.EL.bz429009.3 from this URL: http://people.redhat.com/zaitcev/ftp/429009/ This kernel is NOT supposed to fix the issue, just collect the data for me. Also, I'm quite certain it's not going to be the last iteration. Once I see what usbmon taps, I'll know better what special instrumentation to add. Special instructions (they are in Documentation/usb/usbmon.txt too): mkdir /dbg mount -t debugfs none /dbg Now it gets tricky, they have to look at /proc/bus/usb/devices and find the bus number. The sysreport says it's #2, but that can change randomly as they plug the mouse in... Suppose it's 2, then: cat /dbg/usbmon/2t > 00.mon.t & Next step, run VMware and see if it reproduces the issue Once they see the message, kill the cat. Save the 00.mon.t and pass it over to us. It can be big, but usually not more than a megabyte. Let me know if anything does not connects: e.g. bug fails to appear while under usbmon, for example, or they usbmon itself does not work, or they cannot find the bus number, or anything.
Updating PM score.
Since RHEL 4.8 External Beta has begun, and this bugzilla remains unresolved, it has been rejected as it is not proposed as exception or blocker.