Bug 429009 - VMware - USB message hid-core.c: control queue full
VMware - USB message hid-core.c: control queue full
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.4
All Linux
medium Severity medium
: rc
: ---
Assigned To: Pete Zaitcev
Martin Jenner
:
Depends On:
Blocks: 461304
  Show dependency treegraph
 
Reported: 2008-01-16 14:17 EST by Flavio Leitner
Modified: 2010-10-22 17:48 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-07 01:34:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
vmware log with debug enabled (48.49 KB, application/octet-stream)
2008-01-16 14:26 EST, Flavio Leitner
no flags Details

  None (edit)
Description Flavio Leitner 2008-01-16 14:17:04 EST
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.
Comment 3 Flavio Leitner 2008-01-16 14:26:44 EST
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"
Comment 7 Peter Martuccelli 2008-03-26 15:08:41 EDT
This is not going to be resolved in the RHEL 4.7 timeframe, we are past code
submission, moving out to R4.8.
Comment 10 Pete Zaitcev 2008-04-08 15:27:43 EDT
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.
Comment 12 RHEL Product and Program Management 2008-09-03 09:12:59 EDT
Updating PM score.
Comment 15 RHEL Product and Program Management 2009-03-12 14:52:53 EDT
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.

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