Mailing List Archive

Jiri Slaby napsal(a):
> Andrew Morton napsal(a):
>> Temporarily at
>>
>> http://userweb.kernel.org/~akpm/2.6.21-rc2-mm1/
>
> Weird behaviour of numlock and capslock on USB keyboard in X. After

Hmm, it's not X related. Console behaves similarly.

> pressing

Or actually if some script tries to change LEDs (logout).

> those keys, keyboard "hangs" -- no sysrq, no lock leds are flashing.
>
> After plug; unplug of the keyboard, it works unless I press the keys
> again.
>
> There is nothing in dmesg. X log says
> (II) evdev brain: Rescanning devices (3).
> (II) evdev brain: Rescanning devices (4).
> (II) evdev brain: Rescanning devices (5).
> (II) evdev brain: Rescanning devices (6).
> (II) evdev brain: Rescanning devices (7).
> (II) evdev brain: Rescanning devices (8).
> (II) evdev brain: Rescanning devices (9).
> (II) evdev brain: Rescanning devices (10).
> (II) evdev brain: Rescanning devices (11).
> (II) evdev brain: Rescanning devices (12).
> (II) evdev brain: Rescanning devices (13).
> (II) evdev brain: Rescanning devices (14).
> in this kernel, but I don't know if this is relevant.
>
> After booting back to .20-mm2 everything is OK.

regards,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E

Hnus <hnus@fi.muni.cz> is an alias for /dev/null
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Sat, 03 Mar 2007 16:54:45 +0100 Jiri Slaby <jirislaby@gmail.com> wrote:

>
>
> Jiri Slaby napsal(a):
> > Andrew Morton napsal(a):
> >> Temporarily at
> >>
> >> http://userweb.kernel.org/~akpm/2.6.21-rc2-mm1/
> >
> > Weird behaviour of numlock and capslock on USB keyboard in X. After
>
> Hmm, it's not X related. Console behaves similarly.
>
> > pressing
>
> Or actually if some script tries to change LEDs (logout).
>
> > those keys, keyboard "hangs" -- no sysrq, no lock leds are flashing.
> >
> > After plug; unplug of the keyboard, it works unless I press the keys
> > again.
> >
> > There is nothing in dmesg. X log says
> > (II) evdev brain: Rescanning devices (3).
> > (II) evdev brain: Rescanning devices (4).
> > (II) evdev brain: Rescanning devices (5).
> > (II) evdev brain: Rescanning devices (6).
> > (II) evdev brain: Rescanning devices (7).
> > (II) evdev brain: Rescanning devices (8).
> > (II) evdev brain: Rescanning devices (9).
> > (II) evdev brain: Rescanning devices (10).
> > (II) evdev brain: Rescanning devices (11).
> > (II) evdev brain: Rescanning devices (12).
> > (II) evdev brain: Rescanning devices (13).
> > (II) evdev brain: Rescanning devices (14).
> > in this kernel, but I don't know if this is relevant.
> >
> > After booting back to .20-mm2 everything is OK.
>

Thanks. Cc's added.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Andrew Morton napsal(a):
> On Sat, 03 Mar 2007 16:54:45 +0100 Jiri Slaby <jirislaby@gmail.com> wrote:
>
>>
>> Jiri Slaby napsal(a):
>>> Andrew Morton napsal(a):
>>>> Temporarily at
>>>>
>>>> http://userweb.kernel.org/~akpm/2.6.21-rc2-mm1/
>>> Weird behaviour of numlock and capslock on USB keyboard in X. After
>> Hmm, it's not X related. Console behaves similarly.
>>
>>> pressing
>> Or actually if some script tries to change LEDs (logout).
>>
>>> those keys, keyboard "hangs" -- no sysrq, no lock leds are flashing.
>>>
>>> After plug; unplug of the keyboard, it works unless I press the keys
>>> again.
>>>
>>> There is nothing in dmesg. X log says
>>> (II) evdev brain: Rescanning devices (3).
>>> (II) evdev brain: Rescanning devices (4).
>>> (II) evdev brain: Rescanning devices (5).
>>> (II) evdev brain: Rescanning devices (6).
>>> (II) evdev brain: Rescanning devices (7).
>>> (II) evdev brain: Rescanning devices (8).
>>> (II) evdev brain: Rescanning devices (9).
>>> (II) evdev brain: Rescanning devices (10).
>>> (II) evdev brain: Rescanning devices (11).
>>> (II) evdev brain: Rescanning devices (12).
>>> (II) evdev brain: Rescanning devices (13).
>>> (II) evdev brain: Rescanning devices (14).
>>> in this kernel, but I don't know if this is relevant.
>>>
>>> After booting back to .20-mm2 everything is OK.
>
> Thanks. Cc's added.

Remains unsolved in 2.6.21-rc3-mm2.

regards,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E

Hnus <hnus@fi.muni.cz> is an alias for /dev/null
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On 3/9/07, Jiri Slaby <jirislaby@gmail.com> wrote:
> Andrew Morton napsal(a):
> > On Sat, 03 Mar 2007 16:54:45 +0100 Jiri Slaby <jirislaby@gmail.com> wrote:
> >
> >>
> >> Jiri Slaby napsal(a):
> >>> Andrew Morton napsal(a):
> >>>> Temporarily at
> >>>>
> >>>> http://userweb.kernel.org/~akpm/2.6.21-rc2-mm1/
> >>> Weird behaviour of numlock and capslock on USB keyboard in X. After
> >> Hmm, it's not X related. Console behaves similarly.
> >>
> >>> pressing
> >> Or actually if some script tries to change LEDs (logout).
> >>
> >>> those keys, keyboard "hangs" -- no sysrq, no lock leds are flashing.
> >>>
> >>> After plug; unplug of the keyboard, it works unless I press the keys
> >>> again.
> >>>
> >>> There is nothing in dmesg. X log says
> >>> (II) evdev brain: Rescanning devices (3).
> >>> (II) evdev brain: Rescanning devices (4).
> >>> (II) evdev brain: Rescanning devices (5).
> >>> (II) evdev brain: Rescanning devices (6).
> >>> (II) evdev brain: Rescanning devices (7).
> >>> (II) evdev brain: Rescanning devices (8).
> >>> (II) evdev brain: Rescanning devices (9).
> >>> (II) evdev brain: Rescanning devices (10).
> >>> (II) evdev brain: Rescanning devices (11).
> >>> (II) evdev brain: Rescanning devices (12).
> >>> (II) evdev brain: Rescanning devices (13).
> >>> (II) evdev brain: Rescanning devices (14).
> >>> in this kernel, but I don't know if this is relevant.
> >>>
> >>> After booting back to .20-mm2 everything is OK.
> >
> > Thanks. Cc's added.
>
> Remains unsolved in 2.6.21-rc3-mm2.
>

Does a PS/2 keyboard behave for you?

Nowadays I forward all USB HID related issues to Jiri Kosina ;) (CCed).

--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Fri, 9 Mar 2007, Dmitry Torokhov wrote:

> > > > > (II) evdev brain: Rescanning devices (12).
> > > > > (II) evdev brain: Rescanning devices (13).
> > > > > (II) evdev brain: Rescanning devices (14).
> > > > > in this kernel, but I don't know if this is relevant.
> > > > > After booting back to .20-mm2 everything is OK.
> > > Thanks. Cc's added.
> > Remains unsolved in 2.6.21-rc3-mm2.
> Does a PS/2 keyboard behave for you?
> Nowadays I forward all USB HID related issues to Jiri Kosina ;) (CCed).

Hi,

more importantly, does 2.6.21-rc3 work for you? There are not that many
USB HID/hidinput specific patches in -mm, so it would show clearly whether
it's problem in USB HID/hidinput, or somewhere else.

What keyboard is that please? (vedor/product ids)

Also, if it turns out to be HID problem - could you please send output of
both working and non-working kernels with hid/usbhid debugging enabled?

If this is present also in vanilla and not only in -mm, could you please
try reverting commits 4237081e573b99a48991aa71364b0682c444651c and
d4ae650a904612ffb7edd3f28b69b022988d2466 and let me know if the situation
gets any better?

Thanks,

--
Jiri Kosina
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Fri, 9 Mar 2007, Jiri Kosina wrote:

> If this is present also in vanilla and not only in -mm, could you please
> try reverting commits 4237081e573b99a48991aa71364b0682c444651c and
> d4ae650a904612ffb7edd3f28b69b022988d2466 and let me know if the
> situation gets any better?

Hi Jiri,

or even better, does the patch below (against 2.6.21-rc3) fix the problem
with your keyboard? I can see possibilities of report fields unaligned to
the byte boundary, which this might be causing problems.

(the original patch author added to cc)

Thanks.

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index f4ee1af..f571513 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -873,10 +873,6 @@ static void hid_output_field(struct hid_field *field, __u8 *data)
unsigned size = field->report_size;
unsigned n;

- /* make sure the unused bits in the last byte are zeros */
- if (count > 0 && size > 0)
- data[(offset+count*size-1)/8] = 0;
-
for (n = 0; n < count; n++) {
if (field->logical_minimum < 0) /* signed values */
implement(data, offset + n * size, size, s32ton(field->value[n], size));
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On 3/9/07, Jiri Kosina <jikos@jikos.cz> wrote:
> On Fri, 9 Mar 2007, Jiri Kosina wrote:
>
> > If this is present also in vanilla and not only in -mm, could you please
> > try reverting commits 4237081e573b99a48991aa71364b0682c444651c and
> > d4ae650a904612ffb7edd3f28b69b022988d2466 and let me know if the
> > situation gets any better?
>
> Hi Jiri,

Hi.

> or even better, does the patch below (against 2.6.21-rc3) fix the problem
> with your keyboard? I can see possibilities of report fields unaligned to
> the byte boundary, which this might be causing problems.

I'll try it all.

I don't know if this is related, but my notebook keyboard doesn't emit
numbers with numlock (not even directly Fn+blue number) anymore with
-rc3 (note that LED is flashing when numlock is on). I think -rc2
worked fine (I'm going to check this too). It's Asus M6R, similar
(except wi-fi) to for example yenya's model here:
http://www.fi.muni.cz/~kas/m6r/

thanks,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On 3/9/07, Jiri Slaby <jirislaby@gmail.com> wrote:
> I don't know if this is related, but my notebook keyboard doesn't emit
> numbers with numlock (not even directly Fn+blue number) anymore with
> -rc3 (note that LED is flashing when numlock is on). I think -rc2
> worked fine (I'm going to check this too). It's Asus M6R, similar
> (except wi-fi) to for example yenya's model here:
> http://www.fi.muni.cz/~kas/m6r/

Ignore this, it's deux ex machina, it works now.

regards,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Jiri Kosina napsal(a):
> On Fri, 9 Mar 2007, Jiri Kosina wrote:
>
>> If this is present also in vanilla and not only in -mm, could you please
>> try reverting commits 4237081e573b99a48991aa71364b0682c444651c and
>> d4ae650a904612ffb7edd3f28b69b022988d2466 and let me know if the
>> situation gets any better?
>
> Hi Jiri,
>
> or even better, does the patch below (against 2.6.21-rc3) fix the problem
> with your keyboard? I can see possibilities of report fields unaligned to
> the byte boundary, which this might be causing problems.
>
> (the original patch author added to cc)
>
> Thanks.
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index f4ee1af..f571513 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -873,10 +873,6 @@ static void hid_output_field(struct hid_field *field, __u8 *data)
> unsigned size = field->report_size;
> unsigned n;
>
> - /* make sure the unused bits in the last byte are zeros */
> - if (count > 0 && size > 0)
> - data[(offset+count*size-1)/8] = 0;
> -
> for (n = 0; n < count; n++) {
> if (field->logical_minimum < 0) /* signed values */
> implement(data, offset + n * size, size, s32ton(field->value[n], size));
>

No, this doesn't help -- -rc3-mm2 minus this behaves exactly the same. -rc3
without this patch too.

Going to try to revert the commits mentioned above.

regards,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E

Hnus <hnus@fi.muni.cz> is an alias for /dev/null
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Sun, 11 Mar 2007, Jiri Slaby wrote:

> > - /* make sure the unused bits in the last byte are zeros */
> > - if (count > 0 && size > 0)
> > - data[(offset+count*size-1)/8] = 0;
> > -
> No, this doesn't help -- -rc3-mm2 minus this behaves exactly the same.
> -rc3 without this patch too.
> Going to try to revert the commits mentioned above.

Hmm, strange, I did bet that this would have solved the problem, as the
code is for sure bogus and could be causing these kinds of problems (I
have already scheduled it for removal in the HID tree as an upstream fix)
- it could zero out even the bits which are used and have been previously
set.

I would think that reverting the two commits I have mentioned is not going
to help, if this did not help, but it's always worth trying.

Otherwise, would you care to bisect?

What is the keyboard in question, please? (vendor/product ids).

Thanks,

--
Jiri Kosina
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Jiri Kosina napsal(a):
> On Sun, 11 Mar 2007, Jiri Slaby wrote:
>
>>> - /* make sure the unused bits in the last byte are zeros */
>>> - if (count > 0 && size > 0)
>>> - data[(offset+count*size-1)/8] = 0;
>>> -
>> No, this doesn't help -- -rc3-mm2 minus this behaves exactly the same.
>> -rc3 without this patch too.
>> Going to try to revert the commits mentioned above.
>
> Hmm, strange, I did bet that this would have solved the problem, as the
> code is for sure bogus and could be causing these kinds of problems (I

Hmm, so I'll check this out again to eliminate human factor.

> Otherwise, would you care to bisect?

Yup.

> What is the keyboard in question, please? (vendor/product ids).
Bus 002 Device 013: ID 0458:004c KYE Systems Corp. (Mouse Systems) Slimstar Pro
Keyboard
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0458 KYE Systems Corp. (Mouse Systems)
idProduct 0x004c Slimstar Pro Keyboard
bcdDevice 1.01
iManufacturer 1 ABBHOME
iProduct 2 USB Keyboard
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 59
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 50mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Devices
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 1 Keyboard
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 65
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 10
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Devices
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 2 Mouse
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 104
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 10





It has a hub inside, I think it's connected behind
Bus 002 Device 012: ID 04b4:2050 Cypress Semiconductor Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 8
idVendor 0x04b4 Cypress Semiconductor Corp.
idProduct 0x2050
bcdDevice 0.01
iManufacturer 1 Bella Corporation
iProduct 2 GBella Corporation DV Keyboard
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 255
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 3
wHubCharacteristic 0x000d
Per-port power switching
Compound device
Per-port overcurrent protection
bPwrOn2PwrGood 50 * 2 milli seconds
bHubContrCurrent 25 milli Ampere
DeviceRemovable 0xc0
PortPwrCtrlMask 0xe6
Hub Port Status:
Port 1: 0000.0103 power enable connect
Port 2: 0000.0100 power
Port 3: 0000.0100 power

regards,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E

Hnus <hnus@fi.muni.cz> is an alias for /dev/null
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Jiri Slaby napsal(a):
> Jiri Kosina napsal(a):
>> Hmm, strange, I did bet that this would have solved the problem, as
>> the code is for sure bogus and could be causing these kinds of
>> problems (I
>
> Hmm, so I'll check this out again to eliminate human factor.

verified.

--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E

Hnus <hnus@fi.muni.cz> is an alias for /dev/null
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Jiri Kosina napsal(a):
> On Sun, 11 Mar 2007, Jiri Slaby wrote:
>
>>> - /* make sure the unused bits in the last byte are zeros */
>>> - if (count > 0 && size > 0)
>>> - data[(offset+count*size-1)/8] = 0;
>>> -
>> No, this doesn't help -- -rc3-mm2 minus this behaves exactly the same.
[...]
> Otherwise, would you care to bisect?

Bisecting figured out the culprit:
Commit: 17230acdc71137622ca7dfd789b3944c75d39404
Author: Alan Stern <stern@rowland.harvard.edu> Mon, 19 Feb 2007 15:52:45 -0500

UHCI: Eliminate asynchronous skeleton Queue Headers

This patch (as856) attempts to improve the performance of uhci-hcd by
removing the asynchronous skeleton Queue Headers. They don't contain
any useful information but the controller has to read through them at
least once every millisecond, incurring a non-zero DMA overhead.

Now all the asynchronous queues are combined, along with the period-1
interrupt queue, into a single list with a single skeleton QH. The
start of the low-speed control, full-speed control, and bulk sublists
is determined by linear search. Since there should rarely be more
than a couple of QHs in the list, the searches should incur a much
smaller total load than keeping the skeleton QHs.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>


-mm minus (only) this one is OK.

regards,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E

Hnus <hnus@fi.muni.cz> is an alias for /dev/null
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Mon, 12 Mar 2007, Jiri Slaby wrote:

> Bisecting figured out the culprit:
> Commit: 17230acdc71137622ca7dfd789b3944c75d39404
> Author: Alan Stern <stern@rowland.harvard.edu> Mon, 19 Feb 2007 15:52:45 -0500
>
> UHCI: Eliminate asynchronous skeleton Queue Headers
>
> This patch (as856) attempts to improve the performance of uhci-hcd by
> removing the asynchronous skeleton Queue Headers. They don't contain
> any useful information but the controller has to read through them at
> least once every millisecond, incurring a non-zero DMA overhead.
>
> Now all the asynchronous queues are combined, along with the period-1
> interrupt queue, into a single list with a single skeleton QH. The
> start of the low-speed control, full-speed control, and bulk sublists
> is determined by linear search. Since there should rarely be more
> than a couple of QHs in the list, the searches should incur a much
> smaller total load than keeping the skeleton QHs.
>
> Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
>
>
> -mm minus (only) this one is OK.

Okay, here's how to track this down. I assume that even after the
keyboard stops working you can access the machine via a network
connection.

So turn on CONFIG_USB_DEBUG, CONFIG_USB_MON, and CONFIG_DEBUG_FS. Then
modprobe uhci-hcd with debug=2, and mount a debugfs filesystem. Before
using the keyboard, start a cat process to capture the usbmon output for
the keyboard's bus (see the instructions for usbmon in
Documentation/usb/usbmon.txt).

After hanging the keyboard, get a copy of the appropriate controller's
file in the uhci/ subdirectory of the debugfs filesystem. Post it along
with the usbmon log, and I'll try to figure out what happened.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Alan Stern napsal(a):
> On Mon, 12 Mar 2007, Jiri Slaby wrote:
>
>> Bisecting figured out the culprit:
>> Commit: 17230acdc71137622ca7dfd789b3944c75d39404
>> Author: Alan Stern <stern@rowland.harvard.edu> Mon, 19 Feb 2007 15:52:45 -0500
>>
>> UHCI: Eliminate asynchronous skeleton Queue Headers
[...]
> Post it along
> with the usbmon log, and I'll try to figure out what happened.

Here it comes:
USBMON:
f7525b40 1832950485 C Ii:004:01 0 8 = 00005300 00000000
f7525b40 1832950517 S Ii:004:01 -115 8 <
f7525140 1832950540 S Co:004:00 s 21 09 0200 0000 0001 1 = 01
f7525140 1832952485 C Co:004:00 0 1 >

Corresponds to numlock; 7; numlock; 7.

UHCI snapshot:
Root-hub state: running FSBR: 0
HC status
usbcmd = 00c1 Maxp64 CF RS
usbstat = 0000
usbint = 000f
usbfrnum = (0)6d4
flbaseadd = 36a526d4
sof = 40
stat1 = 01a5 LowSpeed Enabled Connected
stat2 = 0095 Enabled Connected
Most recent frame: 101131 (305) Last ISO frame: 101131 (305)
Periodic load table
12 0 0 0 127 0 0 0
0 0 0 0 127 0 0 0
0 0 0 0 127 0 0 0
0 0 0 0 127 0 0 0
Total: 520, #INT: 4, #ISO: 0
Frame List
Skeleton QHs
- skel_unlink_qh
[f722f000] Skel QH link (00000001) element (00000001)
queue is empty
- skel_iso_qh
[f722f060] Skel QH link (00000001) element (00000001)
queue is empty
- skel_int128_qh
[f722f0c0] Skel QH link (3722f542) element (00000001)
queue is empty
[f722f540] INT QH link (3722f362) element (36848090)
period 128 phase 0 load 12 us
urb_priv [f767ecd0] urb [f7418b40] qh [f722f540] Dev=7 EP=1(IN) INT Actlen=0
1: [f6848090] link (36848030) e3 IOC Active NAK Length=7ff MaxLen=0 DT0
EndPt=1 Dev=7, PID=69(IN) (buf=3722b040)
Dummy TD
[f6848030] link (368480c0) e0 Length=0 MaxLen=7ff DT0 EndPt=0 Dev=0, PID=e1(OUT)
(buf=00000000)
- skel_int64_qh
[f722f120] Skel QH link (3722f362) element (00000001)
queue is empty
- skel_int32_qh
[f722f180] Skel QH link (3722f362) element (00000001)
queue is empty
- skel_int16_qh
[f722f1e0] Skel QH link (3722f362) element (00000001)
queue is empty
- skel_int8_qh
[f722f240] Skel QH link (3722f482) element (00000001)
queue is empty
[f722f480] INT QH link (3722f602) element (36848060)
period 8 phase 4 load 93 us
urb_priv [f767ef70] urb [f74481c0] qh [f722f480] Dev=2 EP=1(IN) INT Actlen=0
1: [f6848060] link (368481e0) e3 LS IOC Active NAK Length=7ff MaxLen=3
DT1 EndPt=1 Dev=2, PID=69(IN) (buf=36a71000)
Dummy TD
[f68481e0] link (36848180) e0 Length=0 MaxLen=7ff DT0 EndPt=0 Dev=0, PID=e1(OUT)
(buf=00000000)
[f722f600] INT QH link (3722f662) element (36848120)
period 8 phase 4 load 17 us
urb_priv [f767ed08] urb [f6566240] qh [f722f600] Dev=8 EP=1(IN) INT Actlen=0
1: [f6848120] link (368480f0) e3 IOC Active NAK Length=7ff MaxLen=7 DT0
EndPt=1 Dev=8, PID=69(IN) (buf=36a71180)
Dummy TD
[f68480f0] link (36848150) e0 Length=0 MaxLen=7ff DT0 EndPt=0 Dev=0, PID=e1(OUT)
(buf=00000000)
[f722f660] INT QH link (3722f362) element (368481b0)
period 8 phase 4 load 17 us
urb_priv [f767e2dc] urb [f7418140] qh [f722f660] Dev=8 EP=2(IN) INT Actlen=0
1: [f68481b0] link (36848210) e3 IOC Active NAK Length=7ff MaxLen=4 DT0
EndPt=2 Dev=8, PID=69(IN) (buf=36a71300)
Dummy TD
[f6848210] link (36848270) e0 Length=0 MaxLen=7ff DT0 EndPt=0 Dev=0, PID=e1(OUT)
(buf=00000000)
- skel_int4_qh
[f722f2a0] Skel QH link (3722f362) element (00000001)
queue is empty
- skel_int2_qh
[f722f300] Skel QH link (3722f362) element (00000001)
queue is empty
- skel_async_qh
[f722f360] Skel QH link (00000001) element (36848000)
queue is empty
- skel_term_qh
[f722f3c0] Skel QH link (00000001) element (36848000)
queue is empty



Side note, it doesn't stop working at all, but there is something like timeout
or whatever, after a while, the keyboard interacts again.

regards,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E

Hnus <hnus@fi.muni.cz> is an alias for /dev/null
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Mon, 12 Mar 2007, Jiri Slaby wrote:

> Alan Stern napsal(a):
> > On Mon, 12 Mar 2007, Jiri Slaby wrote:
> >
> >> Bisecting figured out the culprit:
> >> Commit: 17230acdc71137622ca7dfd789b3944c75d39404
> >> Author: Alan Stern <stern@rowland.harvard.edu> Mon, 19 Feb 2007 15:52:45 -0500
> >>
> >> UHCI: Eliminate asynchronous skeleton Queue Headers
> [...]
> > Post it along
> > with the usbmon log, and I'll try to figure out what happened.
>
> Here it comes:
> USBMON:
> f7525b40 1832950485 C Ii:004:01 0 8 = 00005300 00000000
> f7525b40 1832950517 S Ii:004:01 -115 8 <
> f7525140 1832950540 S Co:004:00 s 21 09 0200 0000 0001 1 = 01
> f7525140 1832952485 C Co:004:00 0 1 >
>
> Corresponds to numlock; 7; numlock; 7.

Actually that little piece corresponds just to pressing Numlock; it
doesn't even include the key release.

> UHCI snapshot:
...

Leaving out the details, one thing is striking. The usbmon trace shows an
interrupt URB submitted for device 4 endpoint 1, but none of the URBs
listed in the UHCI snapshot are for that device. Instead there are
entries for device 7 (which appears to be a hub), device 8, and device 2
(which is low-speed, probably an HID device). Are you certain your UHCI
snapshot was from the correct controller?

It would help to see your /proc/bus/usb/devices. Otherwise it's hard to
know what the various device numbers refer to. Also, it would help to see
UHCI snapshots for both before and after you press Numlock.

> Side note, it doesn't stop working at all, but there is something like timeout
> or whatever, after a while, the keyboard interacts again.

I can't reproduce the problem on 2.6.21-rc3 with the UHCI patch applied.
Can you try the same thing and see what happens?

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

(trimmed CC list a bit)

On Mon, 12 Mar 2007, Jiri Slaby wrote:

> > > UHCI: Eliminate asynchronous skeleton Queue Headers
> > Post it along with the usbmon log, and I'll try to figure out what happened.
> Here it comes:
> USBMON:
> f7525b40 1832950485 C Ii:004:01 0 8 = 00005300 00000000
> f7525b40 1832950517 S Ii:004:01 -115 8 <
> f7525140 1832950540 S Co:004:00 s 21 09 0200 0000 0001 1 = 01
> f7525140 1832952485 C Co:004:00 0 1 >
> Corresponds to numlock; 7; numlock; 7.

Jiri,

thanks. Could you also please redo the test with the offending uhci patch
reverted and send the output of a working situation?

Thanks,

--
Jiri Kosina
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Jiri Kosina napsal(a):
> (trimmed CC list a bit)
>
> On Mon, 12 Mar 2007, Jiri Slaby wrote:
>
>>>> UHCI: Eliminate asynchronous skeleton Queue Headers
>>> Post it along with the usbmon log, and I'll try to figure out what happened.
>> Here it comes:
>> USBMON:
>> f7525b40 1832950485 C Ii:004:01 0 8 = 00005300 00000000
>> f7525b40 1832950517 S Ii:004:01 -115 8 <
>> f7525140 1832950540 S Co:004:00 s 21 09 0200 0000 0001 1 = 01
>> f7525140 1832952485 C Co:004:00 0 1 >
>> Corresponds to numlock; 7; numlock; 7.

Alan, sorry for the previous bad post, I mismatched 2 files. This is
hopefully correct.

> thanks. Could you also please redo the test with the offending uhci patch
> reverted and send the output of a working situation?

- BAD kernel:

USBMON output:
d28dba40 1882513063 C Ii:008:01 0 8 = 00005300 00000000
d28dba40 1882513090 S Ii:008:01 -115 8 <
f7b31340 1882515363 S Co:008:00 s 21 09 0200 0000 0001 1 = 00
f7b31340 1882517065 C Co:008:00 0 1 >




UHCI snapshot before hang:
Root-hub state: running FSBR: 0
HC status
usbcmd = 00c1 Maxp64 CF RS
usbstat = 0000
usbint = 000f
usbfrnum = (1)764
flbaseadd = 0303d764
sof = 40
stat1 = 01a5 LowSpeed Enabled Connected
stat2 = 0095 Enabled Connected
Most recent frame: 75a2 (418) Last ISO frame: 75a2 (418)
Periodic load table
12 0 0 0 127 0 0 0
0 0 0 0 127 0 0 0
0 0 0 0 127 0 0 0
0 0 0 0 127 0 0 0
Total: 520, #INT: 4, #ISO: 0
Frame List
Skeleton QHs
- skel_unlink_qh
[c3c41000] Skel QH link (00000001) element (00000001)
queue is empty
- skel_iso_qh
[c3c41060] Skel QH link (00000001) element (00000001)
queue is empty
- skel_int128_qh
[c3c410c0] Skel QH link (03c41542) element (00000001)
queue is empty
[c3c41540] INT QH link (03c41362) element (02c4a0f0)
period 128 phase 0 load 12 us
urb_priv [f7b2da4c] urb [f7b314c0] qh [c3c41540] Dev=7 EP=1(IN) INT Actlen=0
1: [c2c4a0f0] link (02c4a0c0) e3 IOC Active NAK Length=7ff MaxLen=0
DT1 EndPt=1 Dev=7, PID=69(IN) (buf=36a4a040)
Dummy TD
[c2c4a0c0] link (02c4a120) e0 Length=0 MaxLen=7ff DT0 EndPt=0 Dev=0,
PID=e1(OUT) (buf=00000000)
- skel_int64_qh
[c3c41120] Skel QH link (03c41362) element (00000001)
queue is empty
- skel_int32_qh
[c3c41180] Skel QH link (03c41362) element (00000001)
queue is empty
- skel_int16_qh
[c3c411e0] Skel QH link (03c41362) element (00000001)
queue is empty
- skel_int8_qh
[c3c41240] Skel QH link (03c41482) element (00000001)
queue is empty
[c3c41480] INT QH link (03c41602) element (02c4a030)
period 8 phase 4 load 93 us
urb_priv [f7b2d3bc] urb [d28dbc40] qh [c3c41480] Dev=2 EP=1(IN) INT Actlen=0
1: [c2c4a030] link (02c4a060) e3 LS IOC Active NAK Length=7ff
MaxLen=3 DT0 EndPt=1 Dev=2, PID=69(IN) (buf=037c5000)
Dummy TD
[c2c4a060] link (02c4a0f0) e0 Length=0 MaxLen=7ff DT0 EndPt=0 Dev=0,
PID=e1(OUT) (buf=00000000)
[c3c41600] INT QH link (03c41662) element (02c4a150)
period 8 phase 4 load 17 us
urb_priv [f7b2da30] urb [d28dba40] qh [c3c41600] Dev=8 EP=1(IN) INT Actlen=0
1: [c2c4a150] link (02c4a120) e3 IOC Active NAK Length=7ff MaxLen=7
DT1 EndPt=1 Dev=8, PID=69(IN) (buf=037c5180)
Dummy TD
[c2c4a120] link (02c4a180) e0 Length=0 MaxLen=7ff DT0 EndPt=0 Dev=0,
PID=e1(OUT) (buf=00000000)
[c3c41660] INT QH link (03c41362) element (02c4a1b0)
period 8 phase 4 load 17 us
urb_priv [f7b2d9f8] urb [d1622840] qh [c3c41660] Dev=8 EP=2(IN) INT Actlen=0
1: [c2c4a1b0] link (02c4a1e0) e3 IOC Active NAK Length=7ff MaxLen=4
DT0 EndPt=2 Dev=8, PID=69(IN) (buf=037c5300)
Dummy TD
[c2c4a1e0] link (02c4a210) e0 Length=0 MaxLen=7ff DT0 EndPt=0 Dev=0,
PID=e1(OUT) (buf=00000000)
- skel_int4_qh
[c3c412a0] Skel QH link (03c41362) element (00000001)
queue is empty
- skel_int2_qh
[c3c41300] Skel QH link (03c41362) element (00000001)
queue is empty
- skel_async_qh
[c3c41360] Skel QH link (00000001) element (02c4a000)
queue is empty
- skel_term_qh
[c3c413c0] Skel QH link (00000001) element (02c4a000)
queue is empty




UHCI snapshot after hang:
Root-hub state: running FSBR: 0
HC status
usbcmd = 00c1 Maxp64 CF RS
usbstat = 0000
usbint = 000f
usbfrnum = (1)c2c
flbaseadd = 0303dc2c
sof = 40
stat1 = 01a5 LowSpeed Enabled Connected
stat2 = 0095 Enabled Connected
Most recent frame: 9efc (764) Last ISO frame: 9efc (764)
Periodic load table
12 0 0 0 127 0 0 0
0 0 0 0 127 0 0 0
0 0 0 0 127 0 0 0
0 0 0 0 127 0 0 0
Total: 520, #INT: 4, #ISO: 0
Frame List
Skeleton QHs
- skel_unlink_qh
[c3c41000] Skel QH link (00000001) element (00000001)
queue is empty
- skel_iso_qh
[c3c41060] Skel QH link (00000001) element (00000001)
queue is empty
- skel_int128_qh
[c3c410c0] Skel QH link (03c41542) element (00000001)
queue is empty
[c3c41540] INT QH link (03c41362) element (02c4a0f0)
period 128 phase 0 load 12 us
urb_priv [f7b2da4c] urb [f7b314c0] qh [c3c41540] Dev=7 EP=1(IN) INT Actlen=0
1: [c2c4a0f0] link (02c4a0c0) e3 IOC Active NAK Length=7ff MaxLen=0
DT1 EndPt=1 Dev=7, PID=69(IN) (buf=36a4a040)
Dummy TD
[c2c4a0c0] link (02c4a120) e0 Length=0 MaxLen=7ff DT0 EndPt=0 Dev=0,
PID=e1(OUT) (buf=00000000)
- skel_int64_qh
[c3c41120] Skel QH link (03c41362) element (00000001)
queue is empty
- skel_int32_qh
[c3c41180] Skel QH link (03c41362) element (00000001)
queue is empty
- skel_int16_qh
[c3c411e0] Skel QH link (03c41362) element (00000001)
queue is empty
- skel_int8_qh
[c3c41240] Skel QH link (03c41482) element (00000001)
queue is empty
[c3c41480] INT QH link (03c41602) element (02c4a030)
period 8 phase 4 load 93 us
urb_priv [f7b2d3bc] urb [d28dbc40] qh [c3c41480] Dev=2 EP=1(IN) INT Actlen=0
1: [c2c4a030] link (02c4a060) e3 LS IOC Active NAK Length=7ff
MaxLen=3 DT0 EndPt=1 Dev=2, PID=69(IN) (buf=037c5000)
Dummy TD
[c2c4a060] link (02c4a0f0) e0 Length=0 MaxLen=7ff DT0 EndPt=0 Dev=0,
PID=e1(OUT) (buf=00000000)
[c3c41600] INT QH link (03c41662) element (02c4a120)
period 8 phase 4 load 17 us
urb_priv [f7b2da30] urb [d28dba40] qh [c3c41600] Dev=8 EP=1(IN) INT Actlen=0
1: [c2c4a120] link (02c4a180) e3 IOC Active NAK Length=7ff MaxLen=7
DT0 EndPt=1 Dev=8, PID=69(IN) (buf=037c5180)
Dummy TD
[c2c4a180] link (02c4a150) e0 Length=0 MaxLen=7ff DT0 EndPt=0 Dev=0,
PID=e1(OUT) (buf=00000000)
[c3c41660] INT QH link (03c41362) element (02c4a1b0)
period 8 phase 4 load 17 us
urb_priv [f7b2d9f8] urb [d1622840] qh [c3c41660] Dev=8 EP=2(IN) INT Actlen=0
1: [c2c4a1b0] link (02c4a1e0) e3 IOC Active NAK Length=7ff MaxLen=4
DT0 EndPt=2 Dev=8, PID=69(IN) (buf=037c5300)
Dummy TD
[c2c4a1e0] link (02c4a210) e0 Length=0 MaxLen=7ff DT0 EndPt=0 Dev=0,
PID=e1(OUT) (buf=00000000)
- skel_int4_qh
[c3c412a0] Skel QH link (03c41362) element (00000001)
queue is empty
- skel_int2_qh
[c3c41300] Skel QH link (03c41362) element (00000001)
queue is empty
- skel_async_qh
[c3c41360] Skel QH link (00000001) element (02c4a000)
queue is empty
- skel_term_qh
[c3c413c0] Skel QH link (00000001) element (02c4a000)
queue is empty




*******************************************************************
- GOOD kernel (reverted):

USBMON output:
f7b31ec0 2545055172 C Ii:004:01 0 8 = 00005300 00000000
f7b31ec0 2545055198 S Ii:004:01 -115 8 <
f588aec0 2545055215 S Co:004:00 s 21 09 0200 0000 0001 1 = 01
f588aec0 2545057168 C Co:004:00 0 1 >
f7b31ec0 2545135153 C Ii:004:01 0 8 = 00000000 00000000
f7b31ec0 2545135166 S Ii:004:01 -115 8 <



UHCI snapshot:
Root-hub state: running FSBR: 0
HC status
usbcmd = 00c1 Maxp64 CF RS
usbstat = 0000
usbint = 000f
usbfrnum = (0)988
flbaseadd = 2fce2988
sof = 40
stat1 = 01a5 LowSpeed Enabled Connected
stat2 = 0095 Enabled Connected
Most recent frame: 10a4d (589) Last ISO frame: 10a4d (589)
Periodic load table
12 0 0 0 34 0 0 0
0 0 0 0 34 0 0 0
0 0 0 0 34 0 0 0
0 0 0 0 34 0 0 0
Total: 148, #INT: 3, #ISO: 0
Frame List
Skeleton QHs
- skel_unlink_qh
[e2d00000] Skel QH link (00000001) element (00000001)
queue is empty
- skel_iso_qh
[e2d00060] Skel QH link (00000001) element (00000001)
queue is empty
- skel_int128_qh
[e2d000c0] Skel QH link (22d00602) element (00000001)
queue is empty
[e2d00600] INT QH link (22d00362) element (31db7030)
period 128 phase 0 load 12 us
urb_priv [e2cc63bc] urb [f7427bc0] qh [e2d00600] Dev=3 EP=1(IN) INT Actlen=0
1: [f1db7030] link (31db7090) e3 IOC Active NAK Length=7ff MaxLen=0
DT0 EndPt=1 Dev=3, PID=69(IN) (buf=32f3f040)
Dummy TD
[f1db7090] link (31db70c0) e0 Length=0 MaxLen=7ff DT0 EndPt=0 Dev=0,
PID=e1(OUT) (buf=00000000)
- skel_int64_qh
[e2d00120] Skel QH link (22d00362) element (00000001)
queue is empty
- skel_int32_qh
[e2d00180] Skel QH link (22d00362) element (00000001)
queue is empty
- skel_int16_qh
[e2d001e0] Skel QH link (22d00362) element (00000001)
queue is empty
- skel_int8_qh
[e2d00240] Skel QH link (22d006c2) element (00000001)
queue is empty
[e2d006c0] INT QH link (22d00722) element (31db7060)
period 8 phase 4 load 17 us
urb_priv [e2cc63a0] urb [f7b31ec0] qh [e2d006c0] Dev=4 EP=1(IN) INT Actlen=0
1: [f1db7060] link (31db70f0) e3 IOC Active NAK Length=7ff MaxLen=7
DT0 EndPt=1 Dev=4, PID=69(IN) (buf=2fce3180)
Dummy TD
[f1db70f0] link (31db7180) e0 Length=0 MaxLen=7ff DT0 EndPt=0 Dev=0,
PID=e1(OUT) (buf=00000000)
[e2d00720] INT QH link (22d00362) element (31db7120)
period 8 phase 4 load 17 us
urb_priv [e2cc6384] urb [f72a52c0] qh [e2d00720] Dev=4 EP=2(IN) INT Actlen=0
1: [f1db7120] link (31db7150) e3 IOC Active NAK Length=7ff MaxLen=4
DT0 EndPt=2 Dev=4, PID=69(IN) (buf=2fce3300)
Dummy TD
[f1db7150] link (31db7180) e0 Length=0 MaxLen=7ff DT0 EndPt=0 Dev=0,
PID=e1(OUT) (buf=00000000)
- skel_int4_qh
[e2d002a0] Skel QH link (22d00362) element (00000001)
queue is empty
- skel_int2_qh
[e2d00300] Skel QH link (22d00362) element (00000001)
queue is empty
- skel_int1_qh
[e2d00360] Skel QH link (22d003c2) element (00000001)
queue is empty
- skel_ls_control_qh
[e2d003c0] Skel QH link (22d00422) element (00000001)
queue is empty
- skel_fs_control_qh
[e2d00420] Skel QH link (22d00482) element (00000001)
queue is empty
- skel_bulk_qh
[e2d00480] Skel QH link (22d004e2) element (00000001)
queue is empty
- skel_term_qh
[e2d004e0] Skel QH link (00000001) element (31db7000)
queue is empty




regards,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Mon, 12 Mar 2007, Jiri Slaby wrote:

> Alan, sorry for the previous bad post, I mismatched 2 files. This is
> hopefully correct.
>
> > thanks. Could you also please redo the test with the offending uhci patch
> > reverted and send the output of a working situation?
>
> - BAD kernel:
>
> USBMON output:
> d28dba40 1882513063 C Ii:008:01 0 8 = 00005300 00000000
> d28dba40 1882513090 S Ii:008:01 -115 8 <
> f7b31340 1882515363 S Co:008:00 s 21 09 0200 0000 0001 1 = 00
> f7b31340 1882517065 C Co:008:00 0 1 >

> *******************************************************************
> - GOOD kernel (reverted):
>
> USBMON output:
> f7b31ec0 2545055172 C Ii:004:01 0 8 = 00005300 00000000
> f7b31ec0 2545055198 S Ii:004:01 -115 8 <
> f588aec0 2545055215 S Co:004:00 s 21 09 0200 0000 0001 1 = 01
> f588aec0 2545057168 C Co:004:00 0 1 >
> f7b31ec0 2545135153 C Ii:004:01 0 8 = 00000000 00000000
> f7b31ec0 2545135166 S Ii:004:01 -115 8 <

I don't see anything in the UHCI snapshots to explain the difference in
behavior. One thing that stands out is the other, low-speed device (a
mouse?) -- in the bad kernel dump its driver was running and in the good
kernel dump its driver wasn't.

But that shouldn't have affected the result. In fact, nothing in your
data was significant. It could be that the problem occurs earlier, at the
time when the keyboard is first plugged in.

Can you get another pair of usbmon logs, starting from before you plug in
the keyboard? Don't bother with the UHCI snapshots for now.

Alan Stern


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On 3/13/07, Alan Stern <stern@rowland.harvard.edu> wrote:
> I don't see anything in the UHCI snapshots to explain the difference in
> behavior. One thing that stands out is the other, low-speed device (a
> mouse?) -- in the bad kernel dump its driver was running and in the good
> kernel dump its driver wasn't.

There weren't any changes neither in HW config nor in modules, just
reverted, compiled, installed, rebooted. Mouse is HID user too, so I
don't know what was wrong with that.

> Can you get another pair of usbmon logs, starting from before you plug in
> the keyboard? Don't bother with the UHCI snapshots for now.

So, do you mean rmmod uhci_hcd, unplug the keyboard, modprobe
uhci_hcd, start usbmon, plug the keyboard, press numlock, stop usbmon,
post it?

I'm away from the box till Sat, anyway.

regards,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Tue, 13 Mar 2007, Jiri Slaby wrote:

> On 3/13/07, Alan Stern <stern@rowland.harvard.edu> wrote:
> > I don't see anything in the UHCI snapshots to explain the difference in
> > behavior. One thing that stands out is the other, low-speed device (a
> > mouse?) -- in the bad kernel dump its driver was running and in the good
> > kernel dump its driver wasn't.
>
> There weren't any changes neither in HW config nor in modules, just
> reverted, compiled, installed, rebooted. Mouse is HID user too, so I
> don't know what was wrong with that.

Odd...

> > Can you get another pair of usbmon logs, starting from before you plug in
> > the keyboard? Don't bother with the UHCI snapshots for now.
>
> So, do you mean rmmod uhci_hcd, unplug the keyboard, modprobe
> uhci_hcd, start usbmon, plug the keyboard, press numlock, stop usbmon,
> post it?

Yes. In fact, let's be safe and unplug _both_ the mouse and the keyboard.
Then after starting usbmon, plug in only the keyboard.

> I'm away from the box till Sat, anyway.

Okay, no rush.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Tue, 13 Mar 2007, Jiri Slaby wrote:

> So, do you mean rmmod uhci_hcd, unplug the keyboard, modprobe
> uhci_hcd, start usbmon, plug the keyboard, press numlock, stop usbmon,
> post it?

By the way, what happens if you press CapsLock rather than NumLock? It
should behave pretty the same, sending a command to the keyboard to change
an LED setting. Does the keyboard then stop working in the same way?

Alan Stern

P.S.: When you do your testing, please apply the patch below. I don't
know if it's related to your problem, but I did see this error show up in
someone else's system log.


Index: usb-2.6/drivers/usb/host/uhci-q.c
===================================================================
--- usb-2.6.orig/drivers/usb/host/uhci-q.c
+++ usb-2.6/drivers/usb/host/uhci-q.c
@@ -139,8 +139,10 @@ static struct uhci_td *uhci_alloc_td(str

static void uhci_free_td(struct uhci_hcd *uhci, struct uhci_td *td)
{
- if (!list_empty(&td->list))
+ if (!list_empty(&td->list)) {
dev_warn(uhci_dev(uhci), "td %p still in list!\n", td);
+ WARN_ON(1);
+ }
if (!list_empty(&td->fl_list))
dev_warn(uhci_dev(uhci), "td %p still in fl_list!\n", td);


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On 3/15/07, Alan Stern <stern@rowland.harvard.edu> wrote:
> By the way, what happens if you press CapsLock rather than NumLock? It
> should behave pretty the same, sending a command to the keyboard to change
> an LED setting. Does the keyboard then stop working in the same way?

Yes, and hence the *lock in the subject of the message, i.e. Capslock
behaves exactly the same.

I'll test the attached patch today or tomorrow.

thanks,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Alan Stern napsal(a):
> On Tue, 13 Mar 2007, Jiri Slaby wrote:
>
>> So, do you mean rmmod uhci_hcd, unplug the keyboard, modprobe
>> uhci_hcd, start usbmon, plug the keyboard, press numlock, stop usbmon,
>> post it?

Here you are:
f78666c0 1992239699 C Ii:001:01 -2 0
f74d7b40 1996231756 S Ci:001:00 s 80 00 0000 0000 0002 2 <
f74d7b40 1996231762 C Ci:001:00 0 2 = 0300
f78666c0 1996271682 S Ii:001:01 -115 2 <
f74d7b40 1996271689 S Ci:001:00 s a3 00 0000 0001 0004 4 <
f74d7b40 1996271694 C Ci:001:00 0 4 = 00010000
f74d7b40 1996271698 S Ci:001:00 s a3 00 0000 0002 0004 4 <
f74d7b40 1996271708 C Ci:001:00 0 4 = 01010100
f74d7b40 1996271710 S Co:001:00 s 23 01 0010 0002 0000 0
f74d7b40 1996271713 C Co:001:00 0 0
f74d7b40 1996271719 S Ci:001:00 s a3 00 0000 0002 0004 4 <
f74d7b40 1996271722 C Ci:001:00 0 4 = 01010000
f74d7b40 1996303687 S Ci:001:00 s a3 00 0000 0002 0004 4 <
f74d7b40 1996303693 C Ci:001:00 0 4 = 01010000
f74d7b40 1996335682 S Ci:001:00 s a3 00 0000 0002 0004 4 <
f74d7b40 1996335689 C Ci:001:00 0 4 = 01010000
f74d7b40 1996367681 S Ci:001:00 s a3 00 0000 0002 0004 4 <
f74d7b40 1996367686 C Ci:001:00 0 4 = 01010000
f74d7b40 1996399686 S Ci:001:00 s a3 00 0000 0002 0004 4 <
f74d7b40 1996399692 C Ci:001:00 0 4 = 01010000
f74d7b40 1996399709 S Co:001:00 s 23 03 0004 0002 0000 0
f74d7b40 1996399712 C Co:001:00 0 0
f74d7b40 1996455682 S Ci:001:00 s a3 00 0000 0002 0004 4 <
f74d7b40 1996455703 C Ci:001:00 0 4 = 03010000
f74d7b40 1996514453 S Co:001:00 s 23 01 0014 0002 0000 0
f74d7b40 1996514456 C Co:001:00 0 0
f74d7b40 1996514468 S Ci:000:00 s 80 06 0100 0000 0040 64 <
f74d7b40 1996518652 C Ci:000:00 0 8 = 12011001 09000008
f74d7b40 1996518660 S Co:001:00 s 23 03 0004 0002 0000 0
f74d7b40 1996518663 C Co:001:00 0 0
f78666c0 1996527684 C Ii:001:01 0 1 = 04
f78666c0 1996527687 S Ii:001:01 -115 2 <
f74d7b40 1996571683 S Ci:001:00 s a3 00 0000 0002 0004 4 <
f74d7b40 1996571702 C Ci:001:00 0 4 = 03010000
f74d7b40 1996627687 S Co:001:00 s 23 01 0014 0002 0000 0
f74d7b40 1996627691 C Co:001:00 0 0
f74d7b40 1996627694 S Co:000:00 s 00 05 0002 0000 0000 0
f74d7b40 1996630633 C Co:000:00 0 0
f74d7b40 1996647688 S Ci:002:00 s 80 06 0100 0000 0012 18 <
f74d7b40 1996653630 C Ci:002:00 0 18 = 12011001 09000008 b4045020 01000102 0001
f74d7b40 1996653639 S Ci:002:00 s 80 06 0200 0000 0009 9 <
f74d7b40 1996658627 C Ci:002:00 0 9 = 09021900 010100e0 32
f74d7b40 1996658634 S Ci:002:00 s 80 06 0200 0000 0019 25 <
f74d7b40 1996665626 C Ci:002:00 0 25 = 09021900 010100e0 32090400 00010900
00000705 81030100 ff
f74d7b40 1996665640 S Ci:002:00 s 80 06 0300 0000 00ff 255 <
f74d7b40 1996670625 C Ci:002:00 0 4 = 04030904
f74d7b40 1996670635 S Ci:002:00 s 80 06 0302 0409 00ff 255 <
f74d7b40 1996682623 C Ci:002:00 0 62 = 3e034700 42006500 6c006c00 61002000
43006f00 72007000 6f007200 61007400
f74d7b40 1996682631 S Ci:002:00 s 80 06 0301 0409 00ff 255 <
f74d7b40 1996691621 C Ci:002:00 0 36 = 24034200 65006c00 6c006100 20004300
6f007200 70006f00 72006100 74006900
f74d7b40 1996691781 S Co:002:00 s 00 09 0001 0000 0000 0
f74d7b40 1996694627 C Co:002:00 0 0
f74d7b40 1996694717 S Ci:002:00 s a0 06 2900 0000 000f 15 <
f74d7b40 1996697629 C Ci:002:00 0 9 = 0929030d 00321902 ff
f74d7b40 1996697664 S Ci:002:00 s 80 00 0000 0000 0002 2 <
f74d7b40 1996698633 C Ci:002:00 0 2 = 0000
f74d7b40 1996698663 S Ci:002:00 s a0 00 0000 0000 0004 4 <
f74d7b40 1996699629 C Ci:002:00 0 4 = 00000000
f7ab7d40 1996699658 S Co:002:00 s 23 03 0008 0001 0000 0
f7ab7d40 1996700627 C Co:002:00 0 0
f7ab7d40 1996700645 S Co:002:00 s 23 03 0008 0002 0000 0
f7ab7d40 1996701629 C Co:002:00 0 0
f7ab7d40 1996701644 S Co:002:00 s 23 03 0008 0003 0000 0
f7ab7d40 1996702624 C Co:002:00 0 0
f74d7b40 1996806484 S Ii:002:01 -115 1 <
f75d02c0 1996806621 S Ci:001:00 s a3 00 0000 0002 0004 4 <
f75d02c0 1996806626 C Ci:001:00 0 4 = 03010000
f75d02c0 1996806634 S Ci:002:00 s a3 00 0000 0001 0004 4 <
f75d02c0 1996808610 C Ci:002:00 0 4 = 01010100
f75d02c0 1996808628 S Co:002:00 s 23 01 0010 0001 0000 0
f75d02c0 1996809607 C Co:002:00 0 0
f75d02c0 1996809628 S Ci:002:00 s a3 00 0000 0001 0004 4 <
f75d02c0 1996810605 C Ci:002:00 0 4 = 01010000
f75d02c0 1996842478 S Ci:002:00 s a3 00 0000 0001 0004 4 <
f75d02c0 1996843599 C Ci:002:00 0 4 = 01010000
f75d02c0 1996871682 S Ci:002:00 s a3 00 0000 0001 0004 4 <
f75d02c0 1996873590 C Ci:002:00 0 4 = 01010000
f75d02c0 1996903686 S Ci:002:00 s a3 00 0000 0001 0004 4 <
f75d02c0 1996905586 C Ci:002:00 0 4 = 01010000
f75d02c0 1996938484 S Ci:002:00 s a3 00 0000 0001 0004 4 <
f75d02c0 1996939582 C Ci:002:00 0 4 = 01010000
f75d02c0 1996939601 S Co:002:00 s 23 03 0004 0001 0000 0
f75d02c0 1996940581 C Co:002:00 0 0
f75d02c0 1996955681 S Ci:002:00 s a3 00 0000 0001 0004 4 <
f75d02c0 1996957576 C Ci:002:00 0 4 = 03011000
f74d7b40 1997003567 C Ii:002:01 0 1 = 02
f74d7b40 1997003570 S Ii:002:01 -115 1 <
f75d02c0 1997011687 S Co:002:00 s 23 01 0014 0001 0000 0
f75d02c0 1997013566 C Co:002:00 0 0
f75d02c0 1997013579 S Ci:000:00 s 80 06 0100 0000 0040 64 <
f75d02c0 1997018565 C Ci:000:00 0 8 = 12011001 00000008
f75d02c0 1997018572 S Co:002:00 s 23 03 0004 0001 0000 0
f75d02c0 1997019565 C Co:002:00 0 0
f75d02c0 1997034490 S Ci:002:00 s a3 00 0000 0001 0004 4 <
f75d02c0 1997035562 C Ci:002:00 0 4 = 03011000
f75d02c0 1997087683 S Co:002:00 s 23 01 0014 0001 0000 0
f75d02c0 1997089554 C Co:002:00 0 0
f75d02c0 1997089561 S Co:000:00 s 00 05 0003 0000 0000 0
f75d02c0 1997092552 C Co:000:00 0 0
f75d02c0 1997107692 S Ci:003:00 s 80 06 0100 0000 0012 18 <
f75d02c0 1997113550 C Ci:003:00 0 18 = 12011001 00000008 58044c00 01010102 0001
f75d02c0 1997113560 S Ci:003:00 s 80 06 0200 0000 0009 9 <
f75d02c0 1997118547 C Ci:003:00 0 9 = 09023b00 020100e0 19
f75d02c0 1997118554 S Ci:003:00 s 80 06 0200 0000 003b 59 <
f75d02c0 1997129547 C Ci:003:00 0 59 = 09023b00 020100e0 19090400 00010301
01000921 10010001 22410007 05810308
f75d02c0 1997129567 S Ci:003:00 s 80 06 0300 0000 00ff 255 <
f75d02c0 1997134543 C Ci:003:00 0 4 = 04030904
f75d02c0 1997134553 S Ci:003:00 s 80 06 0302 0409 00ff 255 <
f75d02c0 1997142542 C Ci:003:00 0 26 = 1a035500 53004200 20004b00 65007900
62006f00 61007200 6400
f75d02c0 1997142549 S Ci:003:00 s 80 06 0301 0409 00ff 255 <
f75d02c0 1997149542 C Ci:003:00 0 16 = 10034100 42004200 48004f00 4d004500
f75d02c0 1997149690 S Co:003:00 s 00 09 0001 0000 0000 0
f75d02c0 1997152547 C Co:003:00 0 0
d6228840 1997152648 S Co:003:00 s 21 0a 0000 0000 0000 0
d6228840 1997154552 C Co:003:00 0 0
d6228840 1997154570 S Ci:003:00 s 81 06 2200 0000 0041 65 <
d6228840 1997155558 C Ci:003:00 0 65 = 05010906 a1010507 19e029e7 15002501
95087501 81029508 75018101 05081901
f75d02c0 1997156057 S Ii:003:01 -115 8 <
f75d0540 1997156246 S Co:003:00 s 21 0a 0000 0001 0000 0
f75d0540 1997156551 C Co:003:00 0 0
f75d0540 1997156587 S Ci:003:00 s 81 06 2200 0001 0068 104 <
f75d0540 1997158547 C Ci:003:00 0 104 = 05010902 a1018504 0901a100 05091901
29031500 25019503 75018102 95017505
d62287c0 1997159188 S Ii:003:02 -115 5 <
f75d0f40 1997159379 S Ci:002:00 s a3 00 0000 0002 0004 4 <
f75d0f40 1997159547 C Ci:002:00 0 4 = 00010000
f75d0f40 1997159562 S Ci:002:00 s a3 00 0000 0003 0004 4 <
f75d0f40 1997160546 C Ci:002:00 0 4 = 00010000
f75d0f40 1997160572 S Ci:002:00 s a3 00 0000 0001 0004 4 <
f75d0f40 1997161546 C Ci:002:00 0 4 = 03010000
f75d02c0 1999351157 C Ii:003:01 0 8 = 00005300 00000000
f75d02c0 1999351176 S Ii:003:01 -115 8 <
f7ab7d40 1999351194 S Co:003:00 s 21 09 0200 0000 0001 1 = 01
f7ab7d40 1999353157 C Co:003:00 0 1 >

(Remind: there is a hub inside the keyboard)

> static void uhci_free_td(struct uhci_hcd *uhci, struct uhci_td *td)
> {
> - if (!list_empty(&td->list))
> + if (!list_empty(&td->list)) {
> dev_warn(uhci_dev(uhci), "td %p still in list!\n", td);
> + WARN_ON(1);

Nothing new in dmesg.

regards,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E

Hnus <hnus@fi.muni.cz> is an alias for /dev/null
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/