usb power output issues

[Mark Felder-4]

Hi all,

I have a Dell OptiPlex 390. There are several in the office, but mine is  
the only one that runs FreeBSD. I'm currently running FreeBSD 9.0-STABLE  
#4 r234571, but this has happened on several previous builds as well. I've  
never run an 8.x branch on this hardware.

Sometimes when I come into the office -- perhaps once a week -- I'll find  
that my nice keyboard has stopped functioning. My mouse always works, but  
the keyboard does not. I can plug in any USB keyboard and I see it  
recognized by reading the console messages, but they just don't work. The  
CapsLock, ScrollLock, Numlock, etc lights don't even turn on. I usually  
just reboot the computer and move on, but today this happened when I was  
on the phone with a customer so I knew I couldn't blame it on a  
screensaver or anything whacky like that. I ended up digging out a powered  
USB hub and plugging my keyboard into that. It started working as expected  
at this time.

I am wondering if this is a known issue or if there is anything in the USB  
stack that could cause this behavior? My PC is currently in this state and  
I don't ever power it off, so if someone needs some USB diagnostics output  
I can provide that. This is not a debugging kernel so I can't get you any  
output from DDB at this time.


tech304# usbconfig show_ifdrv
ugen0.1: <EHCI root HUB Intel> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps)  
pwr=SAVE
ugen0.1.0: uhub0: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1>
ugen1.1: <EHCI root HUB Intel> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps)  
pwr=SAVE
ugen1.1.0: uhub1: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1>
ugen0.2: <product 0x0024 vendor 0x8087> at usbus0, cfg=0 md=HOST spd=HIGH  
(480Mbps) pwr=SAVE
ugen0.2.0: uhub2: <vendor 0x8087 product 0x0024, class 9/0, rev 2.00/0.00,  
addr 2>
ugen1.2: <product 0x0024 vendor 0x8087> at usbus1, cfg=0 md=HOST spd=HIGH  
(480Mbps) pwr=SAVE
ugen1.2.0: uhub3: <vendor 0x8087 product 0x0024, class 9/0, rev 2.00/0.00,  
addr 2>
ugen1.3: <USB 2.0 Hub MTT vendor 0x1a40> at usbus1, cfg=0 md=HOST spd=HIGH  
(480Mbps) pwr=SAVE
ugen1.3.0: uhub5: <vendor 0x1a40 USB 2.0 Hub MTT, class 9/0, rev  
2.00/1.00, addr 3>
ugen1.4: <Cypress USB Keyboard  PS2 Mouse Cypress> at usbus1, cfg=0  
md=HOST spd=LOW (1.5Mbps) pwr=ON
ugen1.4.0: ukbd0: <EndPoint1 Interrupt>
ugen1.4.1: ums0: <EP2 Interrupt>
ugen1.5: <USB 2.0 Hub MTT vendor 0x1a40> at usbus1, cfg=0 md=HOST spd=HIGH  
(480Mbps) pwr=SAVE
ugen1.5.0: uhub4: <vendor 0x1a40 USB 2.0 Hub MTT, class 9/0, rev  
2.00/1.00, addr 5>
ugen1.6: <USB Receiver Logitech> at usbus1, cfg=0 md=HOST spd=FULL  
(12Mbps) pwr=ON
ugen1.6.0: ukbd1: <Logitech USB Receiver, class 0/0, rev 2.00/12.01, addr  
6>
ugen1.6.1: ums1: <Logitech USB Receiver, class 0/0, rev 2.00/12.01, addr 6>
ugen1.6.2: uhid0: <Logitech USB Receiver, class 0/0, rev 2.00/12.01, addr  
6>
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"

[Hans Petter Selasky]

On Wednesday 06 June 2012 17:38:44 Mark Felder wrote:

> Hi all,
>
> I have a Dell OptiPlex 390. There are several in the office, but mine is
> the only one that runs FreeBSD. I'm currently running FreeBSD 9.0-STABLE
> #4 r234571, but this has happened on several previous builds as well. I've
> never run an 8.x branch on this hardware.
>
> Sometimes when I come into the office -- perhaps once a week -- I'll find
> that my nice keyboard has stopped functioning. My mouse always works, but
> the keyboard does not. I can plug in any USB keyboard and I see it
> recognized by reading the console messages, but they just don't work. The
> CapsLock, ScrollLock, Numlock, etc lights don't even turn on. I usually
> just reboot the computer and move on, but today this happened when I was
> on the phone with a customer so I knew I couldn't blame it on a
> screensaver or anything whacky like that. I ended up digging out a powered
> USB hub and plugging my keyboard into that. It started working as expected
> at this time.

Hi,

Can you try pressing CTRL+ALT+F1, then CTRL+ALT+F9. Sometimes I see something
similar, and switching back and forth between the console helps.

>
> I am wondering if this is a known issue or if there is anything in the USB
> stack that could cause this behavior? My PC is currently in this state and
> I don't ever power it off, so if someone needs some USB diagnostics output
> I can provide that. This is not a debugging kernel so I can't get you any
> output from DDB at this time.

You can try to get dmesg, and also run:

usbconfig dump_device_desc dump_curr_config_desc

If your device times out on the command above, something is wrong in USB. Else
it is a problem in the interaction with X11.

FYI: CAPS-LOCK-LED and NUM-LOCK-LED are software controlled by the USB stack.

>
>
> tech304# usbconfig show_ifdrv
> ugen0.1: <EHCI root HUB Intel> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps)
> pwr=SAVE
> ugen0.1.0: uhub0: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1>
> ugen1.1: <EHCI root HUB Intel> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps)
> pwr=SAVE
> ugen1.1.0: uhub1: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1>
> ugen0.2: <product 0x0024 vendor 0x8087> at usbus0, cfg=0 md=HOST spd=HIGH
> (480Mbps) pwr=SAVE
> ugen0.2.0: uhub2: <vendor 0x8087 product 0x0024, class 9/0, rev 2.00/0.00,
> addr 2>
> ugen1.2: <product 0x0024 vendor 0x8087> at usbus1, cfg=0 md=HOST spd=HIGH
> (480Mbps) pwr=SAVE
> ugen1.2.0: uhub3: <vendor 0x8087 product 0x0024, class 9/0, rev 2.00/0.00,
> addr 2>
> ugen1.3: <USB 2.0 Hub MTT vendor 0x1a40> at usbus1, cfg=0 md=HOST spd=HIGH
> (480Mbps) pwr=SAVE
> ugen1.3.0: uhub5: <vendor 0x1a40 USB 2.0 Hub MTT, class 9/0, rev
> 2.00/1.00, addr 3>
> ugen1.4: <Cypress USB Keyboard  PS2 Mouse Cypress> at usbus1, cfg=0
> md=HOST spd=LOW (1.5Mbps) pwr=ON
> ugen1.4.0: ukbd0: <EndPoint1 Interrupt>
> ugen1.4.1: ums0: <EP2 Interrupt>
> ugen1.5: <USB 2.0 Hub MTT vendor 0x1a40> at usbus1, cfg=0 md=HOST spd=HIGH
> (480Mbps) pwr=SAVE
> ugen1.5.0: uhub4: <vendor 0x1a40 USB 2.0 Hub MTT, class 9/0, rev
> 2.00/1.00, addr 5>
> ugen1.6: <USB Receiver Logitech> at usbus1, cfg=0 md=HOST spd=FULL
> (12Mbps) pwr=ON
> ugen1.6.0: ukbd1: <Logitech USB Receiver, class 0/0, rev 2.00/12.01, addr
> 6>
> ugen1.6.1: ums1: <Logitech USB Receiver, class 0/0, rev 2.00/12.01, addr 6>
> ugen1.6.2: uhid0: <Logitech USB Receiver, class 0/0, rev 2.00/12.01, addr
> 6>

--HPS
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"

[Mark Felder-4]

On Wed, 06 Jun 2012 10:58:32 -0500, Hans Petter Selasky <[hidden email]>  
wrote:
>
> Hi,
>
> Can you try pressing CTRL+ALT+F1, then CTRL+ALT+F9. Sometimes I see  
> something
> similar, and switching back and forth between the console helps.
>

The keyboard goes *completely* dead, so even switching VTs like that isn't  
possible.

I worked around the issue by plugging in a powered USB hub. So currently  
if I plug in my keyboard directly, it won't work.

>
> You can try to get dmesg, and also run:
>
> usbconfig dump_device_desc dump_curr_config_desc
>
> If your device times out on the command above, something is wrong in  
> USB. Else
> it is a problem in the interaction with X11.

It doesn't appear to time out when I collect that info, and it can't be an  
X11 issue because I can kill X11 completely and the problem persists.

>
> FYI: CAPS-LOCK-LED and NUM-LOCK-LED are software controlled by the USB  
> stack.
>

I suspected as much.


See attached.

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"

[Hans Petter Selasky]

On Wednesday 06 June 2012 18:05:56 Mark Felder wrote:

> On Wed, 06 Jun 2012 10:58:32 -0500, Hans Petter Selasky <[hidden email]>
>
> wrote:
> > Hi,
> >
> > Can you try pressing CTRL+ALT+F1, then CTRL+ALT+F9. Sometimes I see
> > something
> > similar, and switching back and forth between the console helps.
>
> The keyboard goes *completely* dead, so even switching VTs like that isn't
> possible.
>
> I worked around the issue by plugging in a powered USB hub. So currently
> if I plug in my keyboard directly, it won't work.
>
> > You can try to get dmesg, and also run:
> >
> > usbconfig dump_device_desc dump_curr_config_desc
> >
> > If your device times out on the command above, something is wrong in
> > USB. Else
> > it is a problem in the interaction with X11.
>
> It doesn't appear to time out when I collect that info, and it can't be an
> X11 issue because I can kill X11 completely and the problem persists.
>
> > FYI: CAPS-LOCK-LED and NUM-LOCK-LED are software controlled by the USB
> > stack.
>
> I suspected as much.
>
>
> See attached.

Attachments look OK.

Are any other USB devices being used at the time this failure happens?

--HPS
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"

[Mark Felder-4]

On Wed, 06 Jun 2012 11:21:04 -0500, Hans Petter Selasky <[hidden email]>  
wrote:

> Attachments look OK.
> Are any other USB devices being used at the time this failure happens?

No, the only things plugged in via USB are the keyboard, the mouse, and a  
cable for the USB keyboard's built-in hub. No other devices are present.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"

[Hans Petter Selasky]

On Wednesday 06 June 2012 18:37:15 Mark Felder wrote:
> On Wed, 06 Jun 2012 11:21:04 -0500, Hans Petter Selasky <[hidden email]>
>
> wrote:
> > Attachments look OK.
> > Are any other USB devices being used at the time this failure happens?
>
> No, the only things plugged in via USB are the keyboard, the mouse, and a
> cable for the USB keyboard's built-in hub. No other devices are present.

Then I see no reason for a software fault. You could dump all threads when
this happen and see if some threads are stuck in xxx_drain() functions. It is
very unlikely though.

--HPS
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"

[Mark Felder-4]

On Wed, 06 Jun 2012 11:47:52 -0500, Hans Petter Selasky <[hidden email]>  
wrote:

> Then I see no reason for a software fault. You could dump all threads  
> when
> this happen and see if some threads are stuck in xxx_drain() functions.  
> It is
> very unlikely though.

I'll assume this is a hardware bug for now. Thanks for looking into it for  
me!
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"