Bug 1077 - Inoperative CompUSA USB optical notebook mouse
Inoperative CompUSA USB optical notebook mouse
Status: REJECTED WILL_NOT_FIX
Product: Drivers
Classification: Unclassified
Component: USB
i386 Linux
: P2 normal
Assigned To: Greg Kroah-Hartman
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-08-10 23:30 UTC by Warren Togami
Modified: 2003-10-06 20:52 UTC (History)
0 users

See Also:
Kernel Version: 2.6.0-0.test3.1.31
Tree: Mainline
Regression: ---


Attachments

Description Warren Togami 2003-08-10 23:30:11 UTC
Distribution:
Red Hat Linux Beta 9.0.93 "Severn"
Hardware Environment:
Sony Vaio FXA36
Athlon XP 1GHz
VIA KT133A chipset
Problem Description:
I normally use Logitech optical USB mice in Linux.  I bought a "CompUSA Optical
USB Notebook Mouse" for $14 and the following happens in dmesg in
kernel-2.6.0-test3.  The mouse seems to be completely inoperative.  Please let
me know what additional information you may need in order to make the kernel
recognize this device.

hub 1-1:0: debounce: port 2: delay 100ms stable 4 status 0x301
hub 1-1:0: new USB device on port 2, assigned address 8
drivers/usb/core/message.c: selecting invalid configuration 0
usb 1-1.2: failed to set device 8 default configuration (error=-22)
hub 1-1:0: new USB device on port 2, assigned address 9
drivers/usb/core/message.c: selecting invalid configuration 0
usb 1-1.2: failed to set device 9 default configuration (error=-22)
Debug: sleeping function called from invalid context at
include/asm/uaccess.h:473
Call Trace:
 [<c011ab9b>] __might_sleep+0x5b/0x80
 [<c010cc66>] save_v86_state+0x66/0x1f0
 [<c010d737>] handle_vm86_fault+0xa7/0x8c0
 [<c01519fb>] do_sync_write+0x8b/0xc0
 [<c01a1e15>] inode_has_perm+0x65/0xa0
 [<c010b820>] do_general_protection+0x0/0xa0
 [<c010aae5>] error_code+0x2d/0x38
 [<c010a93b>] syscall_call+0x7/0xb

Regarding this traceback, Andrew Morton said:

This is probably due to userspace performing a system call while the CPU
has interrupts disabled.  Privileged apps can do this - the X server and
hwclock are two examples.

Longer-term we probably need to remove the irqs_disabled() test from
__might_sleep().
Comment 1 Warren Togami 2003-08-13 01:14:39 UTC
I have determined that the traceback above was an unrelated coincidence, not
triggered by the mouse.

===== drivers/usb/core/message.c 1.34 vs edited =====
--- 1.34/drivers/usb/core/message.c     Mon Aug 11 07:56:25 2003
+++ edited/drivers/usb/core/message.c   Tue Aug 12 07:54:19 2003
@@ -1055,6 +1055,7 @@
        }
        if ((!cp && configuration != 0) || (cp && configuration == 0)) {
                warn("selecting invalid configuration %d", configuration);
+               usb_show_device(dev);
                return -EINVAL;
        }

After applying this patch suggested by David Brownell, this message appears in
dmesg.

  Length              = 18
  DescriptorType      = 01
  USB version         = 1.10
  Vendor:Product      = 062a:0000
  MaxPacketSize0      = 8
  NumConfigurations   = 1
  Device version      = 2.04
  Device Class:SubClass:Protocol = 00:00:00
    Per-interface classes
Configuration:
  bLength             =    9
  bDescriptorType     =   02
  wTotalLength        = 0022
  bNumInterfaces      =   01
  bConfigurationValue =   00
  iConfiguration      =   00
  bmAttributes        =   a0
  bMaxPower            =  100mA
 
  Interface: 0
  Alternate Setting:  0
    bLength             =    9
    bDescriptorType     =   04
    bInterfaceNumber    =   00
    bAlternateSetting   =   00
    bNumEndpoints       =   01
    bInterface Class:SubClass:Protocol =   03:01:02
    iInterface          =   00
    Endpoint:
      bLength             =    7
      bDescriptorType     =   05
      bEndpointAddress    =   81 (in)
      bmAttributes        =   03 (Interrupt)
      wMaxPacketSize      = 0004
      bInterval           =   0a
Comment 2 Warren Togami 2003-08-13 21:09:39 UTC
On Wed, 2003-08-13 at 05:30, David Brownell wrote:
> Thanks for that info.  It confirms what I expected:  this
> device violates the USB specification.  That's interesting
> to know.  This particular violation doesn't seem common,
> since yours is the first report of this error.  And it
> should be one we can turn into a "don't care".
> 
> 
> > Please instruct me about what to do next.
> 
> Let us know if you can use the device after applying
> this patch!  If it does, I'll ask Greg to merge it.
> 
> - Dave
> 
> 
> 
> --- 1.34/drivers/usb/core/message.c	Mon Aug 11 07:56:25 2003
> +++ edited/drivers/usb/core/message.c	Wed Aug 13 08:26:45 2003
> @@ -1053,10 +1053,18 @@
>  			break;
>  		}
>  	}
> -	if ((!cp && configuration != 0) || (cp && configuration == 0)) {
> -		warn("selecting invalid configuration %d", configuration);
> +	if (!cp && configuration != 0) {
> +		dev_dbg(&dev->dev, "selecting invalid configuration %d\n",
> +				configuration);
>  		return -EINVAL;
>  	}
> +
> +	/* the usb spec defines config zero as meaning the device is in
> +	 * ADDRESS state; otherwise it's CONFIGURED.  but at least one
> +	 * usb 1.1 mouse (062a:0000 v2.4) won't even try to fake it.
> +	 */
> +	if (cp && configuration == 0)
> +		dev_warn(&dev->dev, "illegal descriptors, for config #0\n");
>  
>  	/* if it's already configured, clear out old state first. */
>  	if (dev->state != USB_STATE_ADDRESS)

After applying this patch, these messages appear when the CompUSA mouse is
plugged in, immediately after all USB devices on my system including my Logitech
USB keyboard seize to function.  If I am in X it locks up completely, if I am in
a VT I am able to use my laptop's PS/2 internal keyboard to poweroff.

hub 1-0:0: debounce: port 2: delay 100ms stable 4 status 0x301
hub 1-0:0: new USB device on port 2, assigned address 5
usb 1-2: illegal descriptors, for config #0
drivers/usb/core/message.c: error getting string descriptor 0 (error=-75)
Comment 3 Greg Kroah-Hartman 2003-08-14 09:26:42 UTC
Just return this device.  It is broken very badly, and violates the USB spec

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