subject:"Re\: Keyboard stops working after \*lock \[Was\: 2.6.21\-rc2\-mm1\]"

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-18 Thread Alan Stern

On Sun, 18 Mar 2007, Jiri Slaby wrote:

> Alan Stern napsal(a):
> > On Sun, 18 Mar 2007, Jiri Slaby wrote:
> > 
> >> Alan Stern napsal(a):
> >>> In drivers/usb/host/uhci-q.c, near the start is a function named
> >>> uhci_fsbr_on().  Put a "return" statement right at its beginning so that
> >>> the function doesn't do anything.  Does that make any difference?
> >> Yes, it works.
> > 
> > Okay.  Take out that extra "return" statement and revert the WARN_ON, and
> > try this patch.  I don't like it because it adds extra PCI bus overhead to
> > the driver, but if some systems need it then there's no choice.
> 
> Yes, I'm proud to let you know, that it solves the problem :).
> 
> thanks a lot,

Okay, I'll run some tests of my own and submit it.

Alan Stern

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

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-18 Thread Jiri Slaby


Alan Stern napsal(a):

On Sun, 18 Mar 2007, Jiri Slaby wrote:


Alan Stern napsal(a):

In drivers/usb/host/uhci-q.c, near the start is a function named
uhci_fsbr_on().  Put a "return" statement right at its beginning so that
the function doesn't do anything.  Does that make any difference?

Yes, it works.


Okay.  Take out that extra "return" statement and revert the WARN_ON, and
try this patch.  I don't like it because it adds extra PCI bus overhead to
the driver, but if some systems need it then there's no choice.


Yes, I'm proud to let you know, that it solves the problem :).

thanks a lot,
--
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 <[EMAIL PROTECTED]> is an alias for /dev/null
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-18 Thread Alan Stern

On Sun, 18 Mar 2007, Jiri Slaby wrote:

> Alan Stern napsal(a):
> > In drivers/usb/host/uhci-q.c, near the start is a function named
> > uhci_fsbr_on().  Put a "return" statement right at its beginning so that
> > the function doesn't do anything.  Does that make any difference?
> 
> Yes, it works.

Okay.  Take out that extra "return" statement and revert the WARN_ON, and
try this patch.  I don't like it because it adds extra PCI bus overhead to
the driver, but if some systems need it then there's no choice.

Warning: I just wrote this and haven't tried to test it.  Consider 
yourself a guinea pig.  :-)

Alan Stern



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
@@ -54,22 +54,17 @@ static void uhci_fsbr_on(struct uhci_hcd
/* Find the first FSBR QH.  Linear search through the list is
 * acceptable because normally FSBR gets turned on as soon as
 * one QH needs it. */
-   fsbr_qh = NULL;
+   fsbr_qh = uhci->skel_term_qh;
list_for_each_entry_reverse(tqh, >skel_async_qh->node, node) {
if (tqh->skel < SKEL_FSBR)
break;
fsbr_qh = tqh;
}
 
-   /* No FSBR QH means we must insert the terminating skeleton QH */
-   if (!fsbr_qh) {
-   uhci->skel_term_qh->link = LINK_TO_QH(uhci->skel_term_qh);
-   wmb();
-   lqh->link = uhci->skel_term_qh->link;
-
-   /* Otherwise loop the last QH to the first FSBR QH */
-   } else
-   lqh->link = LINK_TO_QH(fsbr_qh);
+   /* The terminating skeleton QH points back to the first FSBR QH */
+   uhci->skel_term_qh->link = LINK_TO_QH(fsbr_qh);
+   wmb();
+   lqh->link = LINK_TO_QH(uhci->skel_term_qh);
 }
 
 static void uhci_fsbr_off(struct uhci_hcd *uhci)
@@ -139,10 +134,14 @@ static struct uhci_td *uhci_alloc_td(str
 
 static void uhci_free_td(struct uhci_hcd *uhci, struct uhci_td *td)
 {
-   if (!list_empty(>list))
+   if (!list_empty(>list)) {
dev_warn(uhci_dev(uhci), "td %p still in list!\n", td);
-   if (!list_empty(>fl_list))
+   WARN_ON(1);
+   }
+   if (!list_empty(>fl_list)) {
dev_warn(uhci_dev(uhci), "td %p still in fl_list!\n", td);
+   WARN_ON(1);
+   }
 
dma_pool_free(uhci->td_pool, td, td->dma_handle);
 }
@@ -307,8 +306,10 @@ static struct uhci_qh *uhci_alloc_qh(str
 static void uhci_free_qh(struct uhci_hcd *uhci, struct uhci_qh *qh)
 {
WARN_ON(qh->state != QH_STATE_IDLE && qh->udev);
-   if (!list_empty(>queue))
+   if (!list_empty(>queue)) {
dev_warn(uhci_dev(uhci), "qh %p list not empty!\n", qh);
+   WARN_ON(1);
+   }
 
list_del(>node);
if (qh->udev) {
@@ -464,9 +465,8 @@ static void link_interrupt(struct uhci_h
  */
 static void link_async(struct uhci_hcd *uhci, struct uhci_qh *qh)
 {
-   struct uhci_qh *pqh, *lqh;
+   struct uhci_qh *pqh;
__le32 link_to_new_qh;
-   __le32 *extra_link = _to_new_qh;
 
/* Find the predecessor QH for our new one and insert it in the list.
 * The list of QHs is expected to be short, so linear search won't
@@ -476,31 +476,20 @@ static void link_async(struct uhci_hcd *
break;
}
list_add(>node, >node);
-   qh->link = pqh->link;
 
+   /* Link it into the schedule */
+   qh->link = pqh->link;
+   wmb();
link_to_new_qh = LINK_TO_QH(qh);
+   pqh->link = link_to_new_qh;
 
/* If this is now the first FSBR QH, take special action */
if (uhci->fsbr_is_on && pqh->skel < SKEL_FSBR &&
qh->skel >= SKEL_FSBR) {
-   lqh = list_entry(uhci->skel_async_qh->node.prev,
-   struct uhci_qh, node);
 
-   /* If the new QH is also the last one, we must unlink
-* the terminating skeleton QH and make the new QH point
-* back to itself. */
-   if (qh == lqh) {
-   qh->link = link_to_new_qh;
-   extra_link = >skel_term_qh->link;
-
-   /* Otherwise the last QH must point to the new QH */
-   } else
-   extra_link = >link;
+   /* The terminating skeleton QH must point to the new QH */
+   uhci->skel_term_qh->link = link_to_new_qh;
}
-
-   /* Link it into the schedule */
-   wmb();
-   *extra_link = pqh->link = link_to_new_qh;
 }
 
 /*
@@ -561,31 +550,21 @@ static void unlink_interrupt(struct uhci
  */
 static void unlink_async(struct uhci_hcd *uhci, struct uhci_qh *qh)
 {
-   struct uhci_qh *pqh, *lqh;
+   struct uhci_qh *pqh;
__le32 link_to_next_qh = qh->link;
 
pqh = list_entry(qh->node.prev, struct uhci_qh, node);

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-18 Thread Jiri Slaby


Alan Stern napsal(a):

In drivers/usb/host/uhci-q.c, near the start is a function named
uhci_fsbr_on().  Put a "return" statement right at its beginning so that
the function doesn't do anything.  Does that make any difference?


Yes, it works.

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 <[EMAIL PROTECTED]> is an alias for /dev/null
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-18 Thread Alan Stern

On Sun, 18 Mar 2007, Jiri Slaby wrote:

> Alan Stern napsal(a):
> > Nothing in the log stands out.  Can you collect an equivalent log using a
> > version of uhci-hcd with the "eliminate skeleton QHs" patch reverted?  
> > Perhaps there will be a significant difference.  Although I doubt it...

...

> The diff after trimming address and timestamps is:
> @@ -1,9 +1,5 @@
> -C Ii:001:01 -2 0
> -S Ci:001:00 s 80 00   0002 2 <
> -C Ci:001:00 0 2 = 0300
> +C Ii:001:01 0 1 = 04
>   S Ii:001:01 -115 2 <
> -S Ci:001:00 s a3 00  0001 0004 4 <
> -C Ci:001:00 0 4 = 0001
>   S Ci:001:00 s a3 00  0002 0004 4 <
>   C Ci:001:00 0 4 = 01010100
>   S Co:001:00 s 23 01 0010 0002  0

Those differences were caused by your own action: the amount of time 
between insmod uhci-hcd.ko and plugging in the keyboard.  In the first 
test the time was long enough for the root hub to be autosuspended; in the 
second test it wasn't.  As a result, the first test includes the sequences 
used in waking up the root hub.

> @@ -28,8 +24,6 @@
>   C Ci:000:00 0 8 = 12011001 0908
>   S Co:001:00 s 23 03 0004 0002  0
>   C Co:001:00 0 0
> -C Ii:001:01 0 1 = 04
> -S Ii:001:01 -115 2 <
>   S Ci:001:00 s a3 00  0002 0004 4 <
>   C Ci:001:00 0 4 = 0301
>   S Co:001:00 s 23 01 0014 0002  0
> @@ -63,8 +57,6 @@
>   S Co:002:00 s 23 03 0008 0003  0
>   C Co:002:00 0 0
>   S Ii:002:01 -115 1 <
> -S Ci:001:00 s a3 00  0002 0004 4 <
> -C Ci:001:00 0 4 = 0301
>   S Ci:002:00 s a3 00  0001 0004 4 <
>   C Ci:002:00 0 4 = 01010100
>   S Co:002:00 s 23 01 0010 0001  0

Those differences were just accidents of timing.  The driver has a kernel
timer that fires every 250 ms.  In the first test it happened to fire in
the middle of an update sequence and in the second test it didn't.

> @@ -131,3 +123,5 @@
>   S Ii:003:01 -115 8 <
>   S Co:003:00 s 21 09 0200  0001 1 = 01
>   C Co:003:00 0 1 >
> +C Ii:003:01 0 8 =  
> +S Ii:003:01 -115 8 <

And that difference, of course, is the failure we're trying to fix.  It is 
the NumLock-release message from the keyboard.  So we haven't learned 
anything.

> > I'm running out of ideas.  I tried doing exactly the same thing with a USB
> > keyboard+hub on my system, and it worked perfectly.  This suggests that
> > you might be seeing some weird hardware flaw that is somehow exposed by
> > the patch.
> > 
> > Can you borrow a different USB keyboard and see if it behaves the same 
> > way?  Or can you try using your keyboard on a different computer (one with 
> > UHCI)?
> 
> I'll try my best, but I doubt so, there is neither other linux running around 
> with uhci nor another USB keyboard :(, AFAIK.

I did manage to think of something else for you to try.  It may help pin 
down the source of the problem.

In drivers/usb/host/uhci-q.c, near the start is a function named
uhci_fsbr_on().  Put a "return" statement right at its beginning so that
the function doesn't do anything.  Does that make any difference?

Alan Stern

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

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-18 Thread Jiri Slaby


Alan Stern napsal(a):

Nothing in the log stands out.  Can you collect an equivalent log using a
version of uhci-hcd with the "eliminate skeleton QHs" patch reverted?  
Perhaps there will be a significant difference.  Although I doubt it...


f74d8f40 3949330898 C Ii:001:01 0 1 = 04
f74d8f40 3949330911 S Ii:001:01 -115 2 <
d61f5c40 3949386740 S Ci:001:00 s a3 00  0002 0004 4 <
d61f5c40 3949386751 C Ci:001:00 0 4 = 01010100
d61f5c40 3949386753 S Co:001:00 s 23 01 0010 0002  0
d61f5c40 3949386756 C Co:001:00 0 0
d61f5c40 3949386763 S Ci:001:00 s a3 00  0002 0004 4 <
d61f5c40 3949386766 C Ci:001:00 0 4 = 0101
d61f5c40 3949418677 S Ci:001:00 s a3 00  0002 0004 4 <
d61f5c40 3949418683 C Ci:001:00 0 4 = 0101
d61f5c40 3949450679 S Ci:001:00 s a3 00  0002 0004 4 <
d61f5c40 3949450685 C Ci:001:00 0 4 = 0101
d61f5c40 3949482684 S Ci:001:00 s a3 00  0002 0004 4 <
d61f5c40 3949482691 C Ci:001:00 0 4 = 0101
d61f5c40 3949514679 S Ci:001:00 s a3 00  0002 0004 4 <
d61f5c40 3949514684 C Ci:001:00 0 4 = 0101
d61f5c40 3949514700 S Co:001:00 s 23 03 0004 0002  0
d61f5c40 3949514703 C Co:001:00 0 0
d61f5c40 3949570683 S Ci:001:00 s a3 00  0002 0004 4 <
d61f5c40 3949570704 C Ci:001:00 0 4 = 0301
d61f5c40 3949626685 S Co:001:00 s 23 01 0014 0002  0
d61f5c40 3949626688 C Co:001:00 0 0
d61f5c40 3949626700 S Ci:000:00 s 80 06 0100  0040 64 <
d61f5c40 3949630848 C Ci:000:00 0 8 = 12011001 0908
d61f5c40 3949630855 S Co:001:00 s 23 03 0004 0002  0
d61f5c40 3949630859 C Co:001:00 0 0
d61f5c40 3949686687 S Ci:001:00 s a3 00  0002 0004 4 <
d61f5c40 3949686708 C Ci:001:00 0 4 = 0301
d61f5c40 3949742688 S Co:001:00 s 23 01 0014 0002  0
d61f5c40 3949742691 C Co:001:00 0 0
d61f5c40 3949742695 S Co:000:00 s 00 05 0002   0
d61f5c40 3949744829 C Co:000:00 0 0
d61f5c40 3949762695 S Ci:002:00 s 80 06 0100  0012 18 <
d61f5c40 3949767826 C Ci:002:00 0 18 = 12011001 0908 b4045020 01000102 0001
d61f5c40 3949767836 S Ci:002:00 s 80 06 0200  0009 9 <
d61f5c40 3949772823 C Ci:002:00 0 9 = 09021900 010100e0 32
d61f5c40 3949772828 S Ci:002:00 s 80 06 0200  0019 25 <
d61f5c40 3949779822 C Ci:002:00 0 25 = 09021900 010100e0 32090400 00010900 
0705 81030100 ff

d61f5c40 3949779831 S Ci:002:00 s 80 06 0300  00ff 255 <
d61f5c40 3949784821 C Ci:002:00 0 4 = 04030904
d61f5c40 3949784829 S Ci:002:00 s 80 06 0302 0409 00ff 255 <
d61f5c40 3949796819 C Ci:002:00 0 62 = 3e034700 42006500 6c006c00 61002000 
43006f00 72007000 6f007200 61007400

d61f5c40 3949796825 S Ci:002:00 s 80 06 0301 0409 00ff 255 <
d61f5c40 3949805817 C Ci:002:00 0 36 = 24034200 65006c00 6c006100 20004300 
6f007200 70006f00 72006100 74006900

d61f5c40 3949805967 S Co:002:00 s 00 09 0001   0
d61f5c40 3949808826 C Co:002:00 0 0
d61f5c40 3949808930 S Ci:002:00 s a0 06 2900  000f 15 <
d61f5c40 3949811830 C Ci:002:00 0 9 = 0929030d 00321902 ff
d61f5c40 3949811866 S Ci:002:00 s 80 00   0002 2 <
d61f5c40 3949812824 C Ci:002:00 0 2 = 
d61f5c40 3949812849 S Ci:002:00 s a0 00   0004 4 <
d61f5c40 3949813825 C Ci:002:00 0 4 = 
c19df340 3949813854 S Co:002:00 s 23 03 0008 0001  0
c19df340 3949814819 C Co:002:00 0 0
c19df340 3949814828 S Co:002:00 s 23 03 0008 0002  0
c19df340 3949815821 C Co:002:00 0 0
c19df340 3949815836 S Co:002:00 s 23 03 0008 0003  0
c19df340 3949816821 C Co:002:00 0 0
d61f5c40 3949918710 S Ii:002:01 -115 1 <
c19df340 3949918843 S Ci:002:00 s a3 00  0001 0004 4 <
c19df340 3949920805 C Ci:002:00 0 4 = 01010100
c19df340 3949920821 S Co:002:00 s 23 01 0010 0001  0
c19df340 3949921803 C Co:002:00 0 0
c19df340 3949921824 S Ci:002:00 s a3 00  0001 0004 4 <
c19df340 3949922799 C Ci:002:00 0 4 = 0101
c19df340 3949954701 S Ci:002:00 s a3 00  0001 0004 4 <
c19df340 3949955795 C Ci:002:00 0 4 = 0101
c19df340 3949986696 S Ci:002:00 s a3 00  0001 0004 4 <
c19df340 3949987785 C Ci:002:00 0 4 = 0101
c19df340 3950018699 S Ci:002:00 s a3 00  0001 0004 4 <
c19df340 3950019781 C Ci:002:00 0 4 = 0101
c19df340 3950050704 S Ci:002:00 s a3 00  0001 0004 4 <
c19df340 3950051778 C Ci:002:00 0 4 = 0101
c19df340 3950051800 S Co:002:00 s 23 03 0004 0001  0
c19df340 3950052775 C Co:002:00 0 0
c19df340 3950066701 S Ci:002:00 s a3 00  0001 0004 4 <
c19df340 3950067771 C Ci:002:00 0 4 = 03011000
d61f5c40 3950080768 C Ii:002:01 0 1 = 02
d61f5c40 3950080770 S Ii:002:01 -115 1 <
c19df340 3950122703 S Co:002:00 s 23 01 0014 0001  0
c19df340 3950123761 C Co:002:00 0 0
c19df340 3950123774 S Ci:000:00 s 80 06 0100  0040 64 <
c19df340 3950128760 C Ci:000:00 0 8 = 12011001 0008
c19df340 3950128766 S Co:002:00 s 23 03 0004 0001  0
c19df340 3950129760 C Co:002:00 0 0
c19df340 3950142704 S Ci:002:00 s a3 00  0001 0004 4 <
c19df340 3950143759 C Ci:002:00 0 4 = 03011000
c19df340 3950198708 S Co:002:00 s 23 01 0014 0001  0
c19df340 3950199750 C Co:002:00 0 0
c19df340 3950199757 S

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-18 Thread Jiri Slaby


Alan Stern napsal(a):

Nothing in the log stands out.  Can you collect an equivalent log using a
version of uhci-hcd with the eliminate skeleton QHs patch reverted?  
Perhaps there will be a significant difference.  Although I doubt it...


f74d8f40 3949330898 C Ii:001:01 0 1 = 04
f74d8f40 3949330911 S Ii:001:01 -115 2 
d61f5c40 3949386740 S Ci:001:00 s a3 00  0002 0004 4 
d61f5c40 3949386751 C Ci:001:00 0 4 = 01010100
d61f5c40 3949386753 S Co:001:00 s 23 01 0010 0002  0
d61f5c40 3949386756 C Co:001:00 0 0
d61f5c40 3949386763 S Ci:001:00 s a3 00  0002 0004 4 
d61f5c40 3949386766 C Ci:001:00 0 4 = 0101
d61f5c40 3949418677 S Ci:001:00 s a3 00  0002 0004 4 
d61f5c40 3949418683 C Ci:001:00 0 4 = 0101
d61f5c40 3949450679 S Ci:001:00 s a3 00  0002 0004 4 
d61f5c40 3949450685 C Ci:001:00 0 4 = 0101
d61f5c40 3949482684 S Ci:001:00 s a3 00  0002 0004 4 
d61f5c40 3949482691 C Ci:001:00 0 4 = 0101
d61f5c40 3949514679 S Ci:001:00 s a3 00  0002 0004 4 
d61f5c40 3949514684 C Ci:001:00 0 4 = 0101
d61f5c40 3949514700 S Co:001:00 s 23 03 0004 0002  0
d61f5c40 3949514703 C Co:001:00 0 0
d61f5c40 3949570683 S Ci:001:00 s a3 00  0002 0004 4 
d61f5c40 3949570704 C Ci:001:00 0 4 = 0301
d61f5c40 3949626685 S Co:001:00 s 23 01 0014 0002  0
d61f5c40 3949626688 C Co:001:00 0 0
d61f5c40 3949626700 S Ci:000:00 s 80 06 0100  0040 64 
d61f5c40 3949630848 C Ci:000:00 0 8 = 12011001 0908
d61f5c40 3949630855 S Co:001:00 s 23 03 0004 0002  0
d61f5c40 3949630859 C Co:001:00 0 0
d61f5c40 3949686687 S Ci:001:00 s a3 00  0002 0004 4 
d61f5c40 3949686708 C Ci:001:00 0 4 = 0301
d61f5c40 3949742688 S Co:001:00 s 23 01 0014 0002  0
d61f5c40 3949742691 C Co:001:00 0 0
d61f5c40 3949742695 S Co:000:00 s 00 05 0002   0
d61f5c40 3949744829 C Co:000:00 0 0
d61f5c40 3949762695 S Ci:002:00 s 80 06 0100  0012 18 
d61f5c40 3949767826 C Ci:002:00 0 18 = 12011001 0908 b4045020 01000102 0001
d61f5c40 3949767836 S Ci:002:00 s 80 06 0200  0009 9 
d61f5c40 3949772823 C Ci:002:00 0 9 = 09021900 010100e0 32
d61f5c40 3949772828 S Ci:002:00 s 80 06 0200  0019 25 
d61f5c40 3949779822 C Ci:002:00 0 25 = 09021900 010100e0 32090400 00010900 
0705 81030100 ff

d61f5c40 3949779831 S Ci:002:00 s 80 06 0300  00ff 255 
d61f5c40 3949784821 C Ci:002:00 0 4 = 04030904
d61f5c40 3949784829 S Ci:002:00 s 80 06 0302 0409 00ff 255 
d61f5c40 3949796819 C Ci:002:00 0 62 = 3e034700 42006500 6c006c00 61002000 
43006f00 72007000 6f007200 61007400

d61f5c40 3949796825 S Ci:002:00 s 80 06 0301 0409 00ff 255 
d61f5c40 3949805817 C Ci:002:00 0 36 = 24034200 65006c00 6c006100 20004300 
6f007200 70006f00 72006100 74006900

d61f5c40 3949805967 S Co:002:00 s 00 09 0001   0
d61f5c40 3949808826 C Co:002:00 0 0
d61f5c40 3949808930 S Ci:002:00 s a0 06 2900  000f 15 
d61f5c40 3949811830 C Ci:002:00 0 9 = 0929030d 00321902 ff
d61f5c40 3949811866 S Ci:002:00 s 80 00   0002 2 
d61f5c40 3949812824 C Ci:002:00 0 2 = 
d61f5c40 3949812849 S Ci:002:00 s a0 00   0004 4 
d61f5c40 3949813825 C Ci:002:00 0 4 = 
c19df340 3949813854 S Co:002:00 s 23 03 0008 0001  0
c19df340 3949814819 C Co:002:00 0 0
c19df340 3949814828 S Co:002:00 s 23 03 0008 0002  0
c19df340 3949815821 C Co:002:00 0 0
c19df340 3949815836 S Co:002:00 s 23 03 0008 0003  0
c19df340 3949816821 C Co:002:00 0 0
d61f5c40 3949918710 S Ii:002:01 -115 1 
c19df340 3949918843 S Ci:002:00 s a3 00  0001 0004 4 
c19df340 3949920805 C Ci:002:00 0 4 = 01010100
c19df340 3949920821 S Co:002:00 s 23 01 0010 0001  0
c19df340 3949921803 C Co:002:00 0 0
c19df340 3949921824 S Ci:002:00 s a3 00  0001 0004 4 
c19df340 3949922799 C Ci:002:00 0 4 = 0101
c19df340 3949954701 S Ci:002:00 s a3 00  0001 0004 4 
c19df340 3949955795 C Ci:002:00 0 4 = 0101
c19df340 3949986696 S Ci:002:00 s a3 00  0001 0004 4 
c19df340 3949987785 C Ci:002:00 0 4 = 0101
c19df340 3950018699 S Ci:002:00 s a3 00  0001 0004 4 
c19df340 3950019781 C Ci:002:00 0 4 = 0101
c19df340 3950050704 S Ci:002:00 s a3 00  0001 0004 4 
c19df340 3950051778 C Ci:002:00 0 4 = 0101
c19df340 3950051800 S Co:002:00 s 23 03 0004 0001  0
c19df340 3950052775 C Co:002:00 0 0
c19df340 3950066701 S Ci:002:00 s a3 00  0001 0004 4 
c19df340 3950067771 C Ci:002:00 0 4 = 03011000
d61f5c40 3950080768 C Ii:002:01 0 1 = 02
d61f5c40 3950080770 S Ii:002:01 -115 1 
c19df340 3950122703 S Co:002:00 s 23 01 0014 0001  0
c19df340 3950123761 C Co:002:00 0 0
c19df340 3950123774 S Ci:000:00 s 80 06 0100  0040 64 
c19df340 3950128760 C Ci:000:00 0 8 = 12011001 0008
c19df340 3950128766 S Co:002:00 s 23 03 0004 0001  0
c19df340 3950129760 C Co:002:00 0 0
c19df340 3950142704 S Ci:002:00 s a3 00  0001 0004 4 
c19df340 3950143759 C Ci:002:00 0 4 = 03011000
c19df340 3950198708 S Co:002:00 s 23 01 0014 0001  0
c19df340 3950199750 C Co:002:00 0 0
c19df340 3950199757 S Co:000:00 s 00 05 0003   0

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-18 Thread Alan Stern

On Sun, 18 Mar 2007, Jiri Slaby wrote:

 Alan Stern napsal(a):
  Nothing in the log stands out.  Can you collect an equivalent log using a
  version of uhci-hcd with the eliminate skeleton QHs patch reverted?  
  Perhaps there will be a significant difference.  Although I doubt it...

...

 The diff after trimming address and timestamps is:
 @@ -1,9 +1,5 @@
 -C Ii:001:01 -2 0
 -S Ci:001:00 s 80 00   0002 2 
 -C Ci:001:00 0 2 = 0300
 +C Ii:001:01 0 1 = 04
   S Ii:001:01 -115 2 
 -S Ci:001:00 s a3 00  0001 0004 4 
 -C Ci:001:00 0 4 = 0001
   S Ci:001:00 s a3 00  0002 0004 4 
   C Ci:001:00 0 4 = 01010100
   S Co:001:00 s 23 01 0010 0002  0

Those differences were caused by your own action: the amount of time 
between insmod uhci-hcd.ko and plugging in the keyboard.  In the first 
test the time was long enough for the root hub to be autosuspended; in the 
second test it wasn't.  As a result, the first test includes the sequences 
used in waking up the root hub.

 @@ -28,8 +24,6 @@
   C Ci:000:00 0 8 = 12011001 0908
   S Co:001:00 s 23 03 0004 0002  0
   C Co:001:00 0 0
 -C Ii:001:01 0 1 = 04
 -S Ii:001:01 -115 2 
   S Ci:001:00 s a3 00  0002 0004 4 
   C Ci:001:00 0 4 = 0301
   S Co:001:00 s 23 01 0014 0002  0
 @@ -63,8 +57,6 @@
   S Co:002:00 s 23 03 0008 0003  0
   C Co:002:00 0 0
   S Ii:002:01 -115 1 
 -S Ci:001:00 s a3 00  0002 0004 4 
 -C Ci:001:00 0 4 = 0301
   S Ci:002:00 s a3 00  0001 0004 4 
   C Ci:002:00 0 4 = 01010100
   S Co:002:00 s 23 01 0010 0001  0

Those differences were just accidents of timing.  The driver has a kernel
timer that fires every 250 ms.  In the first test it happened to fire in
the middle of an update sequence and in the second test it didn't.

 @@ -131,3 +123,5 @@
   S Ii:003:01 -115 8 
   S Co:003:00 s 21 09 0200  0001 1 = 01
   C Co:003:00 0 1 
 +C Ii:003:01 0 8 =  
 +S Ii:003:01 -115 8 

And that difference, of course, is the failure we're trying to fix.  It is 
the NumLock-release message from the keyboard.  So we haven't learned 
anything.

  I'm running out of ideas.  I tried doing exactly the same thing with a USB
  keyboard+hub on my system, and it worked perfectly.  This suggests that
  you might be seeing some weird hardware flaw that is somehow exposed by
  the patch.
  
  Can you borrow a different USB keyboard and see if it behaves the same 
  way?  Or can you try using your keyboard on a different computer (one with 
  UHCI)?
 
 I'll try my best, but I doubt so, there is neither other linux running around 
 with uhci nor another USB keyboard :(, AFAIK.

I did manage to think of something else for you to try.  It may help pin 
down the source of the problem.

In drivers/usb/host/uhci-q.c, near the start is a function named
uhci_fsbr_on().  Put a return statement right at its beginning so that
the function doesn't do anything.  Does that make any difference?

Alan Stern

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

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-18 Thread Jiri Slaby


Alan Stern napsal(a):

In drivers/usb/host/uhci-q.c, near the start is a function named
uhci_fsbr_on().  Put a return statement right at its beginning so that
the function doesn't do anything.  Does that make any difference?


Yes, it works.

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 [EMAIL PROTECTED] is an alias for /dev/null
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-18 Thread Alan Stern

On Sun, 18 Mar 2007, Jiri Slaby wrote:

 Alan Stern napsal(a):
  In drivers/usb/host/uhci-q.c, near the start is a function named
  uhci_fsbr_on().  Put a return statement right at its beginning so that
  the function doesn't do anything.  Does that make any difference?
 
 Yes, it works.

Okay.  Take out that extra return statement and revert the WARN_ON, and
try this patch.  I don't like it because it adds extra PCI bus overhead to
the driver, but if some systems need it then there's no choice.

Warning: I just wrote this and haven't tried to test it.  Consider 
yourself a guinea pig.  :-)

Alan Stern



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
@@ -54,22 +54,17 @@ static void uhci_fsbr_on(struct uhci_hcd
/* Find the first FSBR QH.  Linear search through the list is
 * acceptable because normally FSBR gets turned on as soon as
 * one QH needs it. */
-   fsbr_qh = NULL;
+   fsbr_qh = uhci-skel_term_qh;
list_for_each_entry_reverse(tqh, uhci-skel_async_qh-node, node) {
if (tqh-skel  SKEL_FSBR)
break;
fsbr_qh = tqh;
}
 
-   /* No FSBR QH means we must insert the terminating skeleton QH */
-   if (!fsbr_qh) {
-   uhci-skel_term_qh-link = LINK_TO_QH(uhci-skel_term_qh);
-   wmb();
-   lqh-link = uhci-skel_term_qh-link;
-
-   /* Otherwise loop the last QH to the first FSBR QH */
-   } else
-   lqh-link = LINK_TO_QH(fsbr_qh);
+   /* The terminating skeleton QH points back to the first FSBR QH */
+   uhci-skel_term_qh-link = LINK_TO_QH(fsbr_qh);
+   wmb();
+   lqh-link = LINK_TO_QH(uhci-skel_term_qh);
 }
 
 static void uhci_fsbr_off(struct uhci_hcd *uhci)
@@ -139,10 +134,14 @@ 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);
-   if (!list_empty(td-fl_list))
+   WARN_ON(1);
+   }
+   if (!list_empty(td-fl_list)) {
dev_warn(uhci_dev(uhci), td %p still in fl_list!\n, td);
+   WARN_ON(1);
+   }
 
dma_pool_free(uhci-td_pool, td, td-dma_handle);
 }
@@ -307,8 +306,10 @@ static struct uhci_qh *uhci_alloc_qh(str
 static void uhci_free_qh(struct uhci_hcd *uhci, struct uhci_qh *qh)
 {
WARN_ON(qh-state != QH_STATE_IDLE  qh-udev);
-   if (!list_empty(qh-queue))
+   if (!list_empty(qh-queue)) {
dev_warn(uhci_dev(uhci), qh %p list not empty!\n, qh);
+   WARN_ON(1);
+   }
 
list_del(qh-node);
if (qh-udev) {
@@ -464,9 +465,8 @@ static void link_interrupt(struct uhci_h
  */
 static void link_async(struct uhci_hcd *uhci, struct uhci_qh *qh)
 {
-   struct uhci_qh *pqh, *lqh;
+   struct uhci_qh *pqh;
__le32 link_to_new_qh;
-   __le32 *extra_link = link_to_new_qh;
 
/* Find the predecessor QH for our new one and insert it in the list.
 * The list of QHs is expected to be short, so linear search won't
@@ -476,31 +476,20 @@ static void link_async(struct uhci_hcd *
break;
}
list_add(qh-node, pqh-node);
-   qh-link = pqh-link;
 
+   /* Link it into the schedule */
+   qh-link = pqh-link;
+   wmb();
link_to_new_qh = LINK_TO_QH(qh);
+   pqh-link = link_to_new_qh;
 
/* If this is now the first FSBR QH, take special action */
if (uhci-fsbr_is_on  pqh-skel  SKEL_FSBR 
qh-skel = SKEL_FSBR) {
-   lqh = list_entry(uhci-skel_async_qh-node.prev,
-   struct uhci_qh, node);
 
-   /* If the new QH is also the last one, we must unlink
-* the terminating skeleton QH and make the new QH point
-* back to itself. */
-   if (qh == lqh) {
-   qh-link = link_to_new_qh;
-   extra_link = uhci-skel_term_qh-link;
-
-   /* Otherwise the last QH must point to the new QH */
-   } else
-   extra_link = lqh-link;
+   /* The terminating skeleton QH must point to the new QH */
+   uhci-skel_term_qh-link = link_to_new_qh;
}
-
-   /* Link it into the schedule */
-   wmb();
-   *extra_link = pqh-link = link_to_new_qh;
 }
 
 /*
@@ -561,31 +550,21 @@ static void unlink_interrupt(struct uhci
  */
 static void unlink_async(struct uhci_hcd *uhci, struct uhci_qh *qh)
 {
-   struct uhci_qh *pqh, *lqh;
+   struct uhci_qh *pqh;
__le32 link_to_next_qh = qh-link;
 
pqh = list_entry(qh-node.prev, struct uhci_qh, node);
+   pqh-link =

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-18 Thread Jiri Slaby


Alan Stern napsal(a):

On Sun, 18 Mar 2007, Jiri Slaby wrote:


Alan Stern napsal(a):

In drivers/usb/host/uhci-q.c, near the start is a function named
uhci_fsbr_on().  Put a return statement right at its beginning so that
the function doesn't do anything.  Does that make any difference?

Yes, it works.


Okay.  Take out that extra return statement and revert the WARN_ON, and
try this patch.  I don't like it because it adds extra PCI bus overhead to
the driver, but if some systems need it then there's no choice.


Yes, I'm proud to let you know, that it solves the problem :).

thanks a lot,
--
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 [EMAIL PROTECTED] is an alias for /dev/null
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-18 Thread Alan Stern

On Sun, 18 Mar 2007, Jiri Slaby wrote:

 Alan Stern napsal(a):
  On Sun, 18 Mar 2007, Jiri Slaby wrote:
  
  Alan Stern napsal(a):
  In drivers/usb/host/uhci-q.c, near the start is a function named
  uhci_fsbr_on().  Put a return statement right at its beginning so that
  the function doesn't do anything.  Does that make any difference?
  Yes, it works.
  
  Okay.  Take out that extra return statement and revert the WARN_ON, and
  try this patch.  I don't like it because it adds extra PCI bus overhead to
  the driver, but if some systems need it then there's no choice.
 
 Yes, I'm proud to let you know, that it solves the problem :).
 
 thanks a lot,

Okay, I'll run some tests of my own and submit it.

Alan Stern

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

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-17 Thread Alan Stern

On Sat, 17 Mar 2007, Jiri Slaby wrote:

> 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:

...

> (Remind: there is a hub inside the keyboard)

Yes.  It shows up very clearly in the log.

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

Oh well, I didn't really expect there to be.

Nothing in the log stands out.  Can you collect an equivalent log using a
version of uhci-hcd with the "eliminate skeleton QHs" patch reverted?  
Perhaps there will be a significant difference.  Although I doubt it...

I'm running out of ideas.  I tried doing exactly the same thing with a USB
keyboard+hub on my system, and it worked perfectly.  This suggests that
you might be seeing some weird hardware flaw that is somehow exposed by
the patch.

Can you borrow a different USB keyboard and see if it behaves the same 
way?  Or can you try using your keyboard on a different computer (one with 
UHCI)?

Alan Stern

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

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-17 Thread Jiri Slaby


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   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  0001 0004 4 <
f74d7b40 1996271694 C Ci:001:00 0 4 = 0001
f74d7b40 1996271698 S Ci:001:00 s a3 00  0002 0004 4 <
f74d7b40 1996271708 C Ci:001:00 0 4 = 01010100
f74d7b40 1996271710 S Co:001:00 s 23 01 0010 0002  0
f74d7b40 1996271713 C Co:001:00 0 0
f74d7b40 1996271719 S Ci:001:00 s a3 00  0002 0004 4 <
f74d7b40 1996271722 C Ci:001:00 0 4 = 0101
f74d7b40 1996303687 S Ci:001:00 s a3 00  0002 0004 4 <
f74d7b40 1996303693 C Ci:001:00 0 4 = 0101
f74d7b40 1996335682 S Ci:001:00 s a3 00  0002 0004 4 <
f74d7b40 1996335689 C Ci:001:00 0 4 = 0101
f74d7b40 1996367681 S Ci:001:00 s a3 00  0002 0004 4 <
f74d7b40 1996367686 C Ci:001:00 0 4 = 0101
f74d7b40 1996399686 S Ci:001:00 s a3 00  0002 0004 4 <
f74d7b40 1996399692 C Ci:001:00 0 4 = 0101
f74d7b40 1996399709 S Co:001:00 s 23 03 0004 0002  0
f74d7b40 1996399712 C Co:001:00 0 0
f74d7b40 1996455682 S Ci:001:00 s a3 00  0002 0004 4 <
f74d7b40 1996455703 C Ci:001:00 0 4 = 0301
f74d7b40 1996514453 S Co:001:00 s 23 01 0014 0002  0
f74d7b40 1996514456 C Co:001:00 0 0
f74d7b40 1996514468 S Ci:000:00 s 80 06 0100  0040 64 <
f74d7b40 1996518652 C Ci:000:00 0 8 = 12011001 0908
f74d7b40 1996518660 S Co:001:00 s 23 03 0004 0002  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  0002 0004 4 <
f74d7b40 1996571702 C Ci:001:00 0 4 = 0301
f74d7b40 1996627687 S Co:001:00 s 23 01 0014 0002  0
f74d7b40 1996627691 C Co:001:00 0 0
f74d7b40 1996627694 S Co:000:00 s 00 05 0002   0
f74d7b40 1996630633 C Co:000:00 0 0
f74d7b40 1996647688 S Ci:002:00 s 80 06 0100  0012 18 <
f74d7b40 1996653630 C Ci:002:00 0 18 = 12011001 0908 b4045020 01000102 0001
f74d7b40 1996653639 S Ci:002:00 s 80 06 0200  0009 9 <
f74d7b40 1996658627 C Ci:002:00 0 9 = 09021900 010100e0 32
f74d7b40 1996658634 S Ci:002:00 s 80 06 0200  0019 25 <
f74d7b40 1996665626 C Ci:002:00 0 25 = 09021900 010100e0 32090400 00010900 
0705 81030100 ff

f74d7b40 1996665640 S Ci:002:00 s 80 06 0300  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   0
f74d7b40 1996694627 C Co:002:00 0 0
f74d7b40 1996694717 S Ci:002:00 s a0 06 2900  000f 15 <
f74d7b40 1996697629 C Ci:002:00 0 9 = 0929030d 00321902 ff
f74d7b40 1996697664 S Ci:002:00 s 80 00   0002 2 <
f74d7b40 1996698633 C Ci:002:00 0 2 = 
f74d7b40 1996698663 S Ci:002:00 s a0 00   0004 4 <
f74d7b40 1996699629 C Ci:002:00 0 4 = 
f7ab7d40 1996699658 S Co:002:00 s 23 03 0008 0001  0
f7ab7d40 1996700627 C Co:002:00 0 0
f7ab7d40 1996700645 S Co:002:00 s 23 03 0008 0002  0
f7ab7d40 1996701629 C Co:002:00 0 0
f7ab7d40 1996701644 S Co:002:00 s 23 03 0008 0003  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  0002 0004 4 <
f75d02c0 1996806626 C Ci:001:00 0 4 = 0301
f75d02c0 1996806634 S Ci:002:00 s a3 00  0001 0004 4 <
f75d02c0 1996808610 C Ci:002:00 0 4 = 01010100
f75d02c0 1996808628 S Co:002:00 s 23 01 0010 0001  0
f75d02c0 1996809607 C Co:002:00 0 0
f75d02c0 1996809628 S Ci:002:00 s a3 00  0001 0004 4 <
f75d02c0 1996810605 C Ci:002:00 0 4 = 0101
f75d02c0 1996842478 S Ci:002:00 s a3 00  0001 0004 4 <
f75d02c0 1996843599 C Ci:002:00 0 4 = 0101
f75d02c0 1996871682 S Ci:002:00 s a3 00  0001 0004 4 <
f75d02c0 1996873590 C Ci:002:00 0 4 = 0101
f75d02c0 1996903686 S Ci:002:00 s a3 00  0001 0004 4 <
f75d02c0 1996905586 C Ci:002:00 0 4 = 0101
f75d02c0 1996938484 S Ci:002:00 s a3 00  0001 0004 4 <
f75d02c0 1996939582 C Ci:002:00 0 4 = 0101
f75d02c0 1996939601 S Co:002:00 s 23 03 0004 0001  0
f75d02c0 1996940581 C Co:002:00 0 0
f75d02c0 1996955681 S Ci:002:00 s a3 00  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  0
f75d02c0 1997013566 C Co:002:00 0 0
f75d02c0 1997013579 S Ci:000:00 s 80 06 0100  0040 64 <

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-17 Thread Jiri Slaby


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   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  0001 0004 4 
f74d7b40 1996271694 C Ci:001:00 0 4 = 0001
f74d7b40 1996271698 S Ci:001:00 s a3 00  0002 0004 4 
f74d7b40 1996271708 C Ci:001:00 0 4 = 01010100
f74d7b40 1996271710 S Co:001:00 s 23 01 0010 0002  0
f74d7b40 1996271713 C Co:001:00 0 0
f74d7b40 1996271719 S Ci:001:00 s a3 00  0002 0004 4 
f74d7b40 1996271722 C Ci:001:00 0 4 = 0101
f74d7b40 1996303687 S Ci:001:00 s a3 00  0002 0004 4 
f74d7b40 1996303693 C Ci:001:00 0 4 = 0101
f74d7b40 1996335682 S Ci:001:00 s a3 00  0002 0004 4 
f74d7b40 1996335689 C Ci:001:00 0 4 = 0101
f74d7b40 1996367681 S Ci:001:00 s a3 00  0002 0004 4 
f74d7b40 1996367686 C Ci:001:00 0 4 = 0101
f74d7b40 1996399686 S Ci:001:00 s a3 00  0002 0004 4 
f74d7b40 1996399692 C Ci:001:00 0 4 = 0101
f74d7b40 1996399709 S Co:001:00 s 23 03 0004 0002  0
f74d7b40 1996399712 C Co:001:00 0 0
f74d7b40 1996455682 S Ci:001:00 s a3 00  0002 0004 4 
f74d7b40 1996455703 C Ci:001:00 0 4 = 0301
f74d7b40 1996514453 S Co:001:00 s 23 01 0014 0002  0
f74d7b40 1996514456 C Co:001:00 0 0
f74d7b40 1996514468 S Ci:000:00 s 80 06 0100  0040 64 
f74d7b40 1996518652 C Ci:000:00 0 8 = 12011001 0908
f74d7b40 1996518660 S Co:001:00 s 23 03 0004 0002  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  0002 0004 4 
f74d7b40 1996571702 C Ci:001:00 0 4 = 0301
f74d7b40 1996627687 S Co:001:00 s 23 01 0014 0002  0
f74d7b40 1996627691 C Co:001:00 0 0
f74d7b40 1996627694 S Co:000:00 s 00 05 0002   0
f74d7b40 1996630633 C Co:000:00 0 0
f74d7b40 1996647688 S Ci:002:00 s 80 06 0100  0012 18 
f74d7b40 1996653630 C Ci:002:00 0 18 = 12011001 0908 b4045020 01000102 0001
f74d7b40 1996653639 S Ci:002:00 s 80 06 0200  0009 9 
f74d7b40 1996658627 C Ci:002:00 0 9 = 09021900 010100e0 32
f74d7b40 1996658634 S Ci:002:00 s 80 06 0200  0019 25 
f74d7b40 1996665626 C Ci:002:00 0 25 = 09021900 010100e0 32090400 00010900 
0705 81030100 ff

f74d7b40 1996665640 S Ci:002:00 s 80 06 0300  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   0
f74d7b40 1996694627 C Co:002:00 0 0
f74d7b40 1996694717 S Ci:002:00 s a0 06 2900  000f 15 
f74d7b40 1996697629 C Ci:002:00 0 9 = 0929030d 00321902 ff
f74d7b40 1996697664 S Ci:002:00 s 80 00   0002 2 
f74d7b40 1996698633 C Ci:002:00 0 2 = 
f74d7b40 1996698663 S Ci:002:00 s a0 00   0004 4 
f74d7b40 1996699629 C Ci:002:00 0 4 = 
f7ab7d40 1996699658 S Co:002:00 s 23 03 0008 0001  0
f7ab7d40 1996700627 C Co:002:00 0 0
f7ab7d40 1996700645 S Co:002:00 s 23 03 0008 0002  0
f7ab7d40 1996701629 C Co:002:00 0 0
f7ab7d40 1996701644 S Co:002:00 s 23 03 0008 0003  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  0002 0004 4 
f75d02c0 1996806626 C Ci:001:00 0 4 = 0301
f75d02c0 1996806634 S Ci:002:00 s a3 00  0001 0004 4 
f75d02c0 1996808610 C Ci:002:00 0 4 = 01010100
f75d02c0 1996808628 S Co:002:00 s 23 01 0010 0001  0
f75d02c0 1996809607 C Co:002:00 0 0
f75d02c0 1996809628 S Ci:002:00 s a3 00  0001 0004 4 
f75d02c0 1996810605 C Ci:002:00 0 4 = 0101
f75d02c0 1996842478 S Ci:002:00 s a3 00  0001 0004 4 
f75d02c0 1996843599 C Ci:002:00 0 4 = 0101
f75d02c0 1996871682 S Ci:002:00 s a3 00  0001 0004 4 
f75d02c0 1996873590 C Ci:002:00 0 4 = 0101
f75d02c0 1996903686 S Ci:002:00 s a3 00  0001 0004 4 
f75d02c0 1996905586 C Ci:002:00 0 4 = 0101
f75d02c0 1996938484 S Ci:002:00 s a3 00  0001 0004 4 
f75d02c0 1996939582 C Ci:002:00 0 4 = 0101
f75d02c0 1996939601 S Co:002:00 s 23 03 0004 0001  0
f75d02c0 1996940581 C Co:002:00 0 0
f75d02c0 1996955681 S Ci:002:00 s a3 00  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  0
f75d02c0 1997013566 C Co:002:00 0 0
f75d02c0 1997013579 S Ci:000:00 s 80 06 0100  0040 64 
f75d02c0 1997018565 C Ci:000:00 0 8 =

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-17 Thread Alan Stern

On Sat, 17 Mar 2007, Jiri Slaby wrote:

 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:

...

 (Remind: there is a hub inside the keyboard)

Yes.  It shows up very clearly in the log.

   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.

Oh well, I didn't really expect there to be.

Nothing in the log stands out.  Can you collect an equivalent log using a
version of uhci-hcd with the eliminate skeleton QHs patch reverted?  
Perhaps there will be a significant difference.  Although I doubt it...

I'm running out of ideas.  I tried doing exactly the same thing with a USB
keyboard+hub on my system, and it worked perfectly.  This suggests that
you might be seeing some weird hardware flaw that is somehow exposed by
the patch.

Can you borrow a different USB keyboard and see if it behaves the same 
way?  Or can you try using your keyboard on a different computer (one with 
UHCI)?

Alan Stern

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

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-16 Thread Jiri Slaby


On 3/15/07, Alan Stern <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-16 Thread Jiri Slaby


On 3/15/07, Alan Stern [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-15 Thread Alan Stern

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(>list))
+   if (!list_empty(>list)) {
dev_warn(uhci_dev(uhci), "td %p still in list!\n", td);
+   WARN_ON(1);
+   }
if (!list_empty(>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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-15 Thread Alan Stern

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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-13 Thread Alan Stern

On Tue, 13 Mar 2007, Jiri Slaby wrote:

> On 3/13/07, Alan Stern <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-13 Thread Jiri Slaby


On 3/13/07, Alan Stern <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-13 Thread Alan Stern

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 = 5300 
> d28dba40 1882513090 S Ii:008:01 -115 8 <
> f7b31340 1882515363 S Co:008:00 s 21 09 0200  0001 1 = 00
> f7b31340 1882517065 C Co:008:00 0 1 >

> ***
> - GOOD kernel (reverted):
> 
> USBMON output:
> f7b31ec0 2545055172 C Ii:004:01 0 8 = 5300 
> f7b31ec0 2545055198 S Ii:004:01 -115 8 <
> f588aec0 2545055215 S Co:004:00 s 21 09 0200  0001 1 = 01
> f588aec0 2545057168 C Co:004:00 0 1 >
> f7b31ec0 2545135153 C Ii:004:01 0 8 =  
> 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-13 Thread Alan Stern

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 = 5300 
 d28dba40 1882513090 S Ii:008:01 -115 8 
 f7b31340 1882515363 S Co:008:00 s 21 09 0200  0001 1 = 00
 f7b31340 1882517065 C Co:008:00 0 1 

 ***
 - GOOD kernel (reverted):
 
 USBMON output:
 f7b31ec0 2545055172 C Ii:004:01 0 8 = 5300 
 f7b31ec0 2545055198 S Ii:004:01 -115 8 
 f588aec0 2545055215 S Co:004:00 s 21 09 0200  0001 1 = 01
 f588aec0 2545057168 C Co:004:00 0 1 
 f7b31ec0 2545135153 C Ii:004:01 0 8 =  
 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-13 Thread Jiri Slaby


On 3/13/07, Alan Stern [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-13 Thread Alan Stern

On Tue, 13 Mar 2007, Jiri Slaby wrote:

 On 3/13/07, Alan Stern [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-12 Thread Jiri Slaby


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 = 5300 
f7525b40 1832950517 S Ii:004:01 -115 8 <
f7525140 1832950540 S Co:004:00 s 21 09 0200  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 = 5300 
d28dba40 1882513090 S Ii:008:01 -115 8 <
f7b31340 1882515363 S Co:008:00 s 21 09 0200  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   = 
  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 (0001) element (0001)
  queue is empty
- skel_iso_qh
[c3c41060] Skel QH link (0001) element (0001)
  queue is empty
- skel_int128_qh
[c3c410c0] Skel QH link (03c41542) element (0001)
  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=)

- skel_int64_qh
[c3c41120] Skel QH link (03c41362) element (0001)
  queue is empty
- skel_int32_qh
[c3c41180] Skel QH link (03c41362) element (0001)
  queue is empty
- skel_int16_qh
[c3c411e0] Skel QH link (03c41362) element (0001)
  queue is empty
- skel_int8_qh
[c3c41240] Skel QH link (03c41482) element (0001)
  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=)

[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=)

[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=)

- skel_int4_qh
[c3c412a0] Skel QH link (03c41362) element (0001)
  queue is empty
- skel_int2_qh
[c3c41300] Skel QH link (03c41362) element (0001)
  queue is empty
- skel_async_qh
[c3c41360] Skel QH link (0001) element (02c4a000)
  queue is empty
- skel_term_qh
[c3c413c0] Skel QH link (0001) element (02c4a000)
  queue is empty




UHCI snapshot after hang:
Root-hub state: running   FSBR: 0
HC status
  usbcmd= 00c1   Maxp64 CF RS
  usbstat   = 
  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:

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-12 Thread Jiri Kosina

(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 = 5300 
> f7525b40 1832950517 S Ii:004:01 -115 8 <
> f7525140 1832950540 S Co:004:00 s 21 09 0200  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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-12 Thread Alan Stern

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 <[EMAIL PROTECTED]> 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 = 5300 
> f7525b40 1832950517 S Ii:004:01 -115 8 <
> f7525140 1832950540 S Co:004:00 s 21 09 0200  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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-12 Thread Jiri Slaby


Alan Stern napsal(a):

On Mon, 12 Mar 2007, Jiri Slaby wrote:


Bisecting figured out the culprit:
Commit: 17230acdc71137622ca7dfd789b3944c75d39404
Author: Alan Stern <[EMAIL PROTECTED]> 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 = 5300 
f7525b40 1832950517 S Ii:004:01 -115 8 <
f7525140 1832950540 S Co:004:00 s 21 09 0200  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   = 
  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 (0001) element (0001)
  queue is empty
- skel_iso_qh
[f722f060] Skel QH link (0001) element (0001)
  queue is empty
- skel_int128_qh
[f722f0c0] Skel QH link (3722f542) element (0001)
  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=)

- skel_int64_qh
[f722f120] Skel QH link (3722f362) element (0001)
  queue is empty
- skel_int32_qh
[f722f180] Skel QH link (3722f362) element (0001)
  queue is empty
- skel_int16_qh
[f722f1e0] Skel QH link (3722f362) element (0001)
  queue is empty
- skel_int8_qh
[f722f240] Skel QH link (3722f482) element (0001)
  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=)

[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=)

[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=)

- skel_int4_qh
[f722f2a0] Skel QH link (3722f362) element (0001)
  queue is empty
- skel_int2_qh
[f722f300] Skel QH link (3722f362) element (0001)
  queue is empty
- skel_async_qh
[f722f360] Skel QH link (0001) element (36848000)
  queue is empty
- skel_term_qh
[f722f3c0] Skel QH link (0001) 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 <[EMAIL PROTECTED]> is an alias for /dev/null
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-12 Thread Alan Stern

On Mon, 12 Mar 2007, Jiri Slaby wrote:

> Bisecting figured out the culprit:
> Commit: 17230acdc71137622ca7dfd789b3944c75d39404
> Author: Alan Stern <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>  Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
> 
> 
> -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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-12 Thread Jiri Slaby


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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>


-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 <[EMAIL PROTECTED]> is an alias for /dev/null
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-12 Thread Jiri Slaby


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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]


-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 [EMAIL PROTECTED] is an alias for /dev/null
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-12 Thread Alan Stern

On Mon, 12 Mar 2007, Jiri Slaby wrote:

 Bisecting figured out the culprit:
 Commit: 17230acdc71137622ca7dfd789b3944c75d39404
 Author: Alan Stern [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
  Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
 
 
 -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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-12 Thread Jiri Slaby


Alan Stern napsal(a):

On Mon, 12 Mar 2007, Jiri Slaby wrote:


Bisecting figured out the culprit:
Commit: 17230acdc71137622ca7dfd789b3944c75d39404
Author: Alan Stern [EMAIL PROTECTED] 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 = 5300 
f7525b40 1832950517 S Ii:004:01 -115 8 
f7525140 1832950540 S Co:004:00 s 21 09 0200  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   = 
  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 (0001) element (0001)
  queue is empty
- skel_iso_qh
[f722f060] Skel QH link (0001) element (0001)
  queue is empty
- skel_int128_qh
[f722f0c0] Skel QH link (3722f542) element (0001)
  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=)

- skel_int64_qh
[f722f120] Skel QH link (3722f362) element (0001)
  queue is empty
- skel_int32_qh
[f722f180] Skel QH link (3722f362) element (0001)
  queue is empty
- skel_int16_qh
[f722f1e0] Skel QH link (3722f362) element (0001)
  queue is empty
- skel_int8_qh
[f722f240] Skel QH link (3722f482) element (0001)
  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=)

[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=)

[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=)

- skel_int4_qh
[f722f2a0] Skel QH link (3722f362) element (0001)
  queue is empty
- skel_int2_qh
[f722f300] Skel QH link (3722f362) element (0001)
  queue is empty
- skel_async_qh
[f722f360] Skel QH link (0001) element (36848000)
  queue is empty
- skel_term_qh
[f722f3c0] Skel QH link (0001) 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 [EMAIL PROTECTED] is an alias for /dev/null
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-12 Thread Alan Stern

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 [EMAIL PROTECTED] 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 = 5300 
 f7525b40 1832950517 S Ii:004:01 -115 8 
 f7525140 1832950540 S Co:004:00 s 21 09 0200  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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-12 Thread Jiri Kosina

(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 = 5300 
 f7525b40 1832950517 S Ii:004:01 -115 8 
 f7525140 1832950540 S Co:004:00 s 21 09 0200  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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-12 Thread Jiri Slaby


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 = 5300 
f7525b40 1832950517 S Ii:004:01 -115 8 
f7525140 1832950540 S Co:004:00 s 21 09 0200  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 = 5300 
d28dba40 1882513090 S Ii:008:01 -115 8 
f7b31340 1882515363 S Co:008:00 s 21 09 0200  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   = 
  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 (0001) element (0001)
  queue is empty
- skel_iso_qh
[c3c41060] Skel QH link (0001) element (0001)
  queue is empty
- skel_int128_qh
[c3c410c0] Skel QH link (03c41542) element (0001)
  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=)

- skel_int64_qh
[c3c41120] Skel QH link (03c41362) element (0001)
  queue is empty
- skel_int32_qh
[c3c41180] Skel QH link (03c41362) element (0001)
  queue is empty
- skel_int16_qh
[c3c411e0] Skel QH link (03c41362) element (0001)
  queue is empty
- skel_int8_qh
[c3c41240] Skel QH link (03c41482) element (0001)
  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=)

[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=)

[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=)

- skel_int4_qh
[c3c412a0] Skel QH link (03c41362) element (0001)
  queue is empty
- skel_int2_qh
[c3c41300] Skel QH link (03c41362) element (0001)
  queue is empty
- skel_async_qh
[c3c41360] Skel QH link (0001) element (02c4a000)
  queue is empty
- skel_term_qh
[c3c413c0] Skel QH link (0001) element (02c4a000)
  queue is empty




UHCI snapshot after hang:
Root-hub state: running   FSBR: 0
HC status
  usbcmd= 00c1   Maxp64 CF RS
  usbstat   = 
  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,

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-11 Thread Jiri Slaby


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 <[EMAIL PROTECTED]> is an alias for /dev/null
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-11 Thread Jiri Slaby


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:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 8
  idVendor   0x0458 KYE Systems Corp. (Mouse Systems)
  idProduct  0x004c Slimstar Pro Keyboard
  bcdDevice1.01
  iManufacturer   1 ABBHOME
  iProduct2 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
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 3 Human Interface Devices
  bInterfaceSubClass  1 Boot Interface Subclass
  bInterfaceProtocol  1 Keyboard
  iInterface  0
HID Device Descriptor:
  bLength 9
  bDescriptorType33
  bcdHID   1.10
  bCountryCode0 Not supported
  bNumDescriptors 1
  bDescriptorType34 Report
  wDescriptorLength  65
 Report Descriptors:
   ** UNAVAILABLE **
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0008  1x 8 bytes
bInterval  10
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 3 Human Interface Devices
  bInterfaceSubClass  1 Boot Interface Subclass
  bInterfaceProtocol  2 Mouse
  iInterface  0
HID Device Descriptor:
  bLength 9
  bDescriptorType33
  bcdHID   1.10
  bCountryCode0 Not supported
  bNumDescriptors 1
  bDescriptorType34 Report
  wDescriptorLength 104
 Report Descriptors:
   ** UNAVAILABLE **
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes3
  Transfer TypeInterrupt
  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:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 0 Full speed (or root) hub
  bMaxPacketSize0 8
  idVendor   0x04b4 Cypress Semiconductor Corp.
  idProduct  0x2050
  bcdDevice0.01
  iManufacturer   1 Bella Corporation
  iProduct2 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
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 9

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-11 Thread Jiri Kosina

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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-11 Thread Jiri Slaby


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 <[EMAIL PROTECTED]> is an alias for /dev/null
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-11 Thread Jiri Slaby


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 [EMAIL PROTECTED] is an alias for /dev/null
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-11 Thread Jiri Kosina

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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-11 Thread Jiri Slaby


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:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 8
  idVendor   0x0458 KYE Systems Corp. (Mouse Systems)
  idProduct  0x004c Slimstar Pro Keyboard
  bcdDevice1.01
  iManufacturer   1 ABBHOME
  iProduct2 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
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 3 Human Interface Devices
  bInterfaceSubClass  1 Boot Interface Subclass
  bInterfaceProtocol  1 Keyboard
  iInterface  0
HID Device Descriptor:
  bLength 9
  bDescriptorType33
  bcdHID   1.10
  bCountryCode0 Not supported
  bNumDescriptors 1
  bDescriptorType34 Report
  wDescriptorLength  65
 Report Descriptors:
   ** UNAVAILABLE **
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0008  1x 8 bytes
bInterval  10
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 3 Human Interface Devices
  bInterfaceSubClass  1 Boot Interface Subclass
  bInterfaceProtocol  2 Mouse
  iInterface  0
HID Device Descriptor:
  bLength 9
  bDescriptorType33
  bcdHID   1.10
  bCountryCode0 Not supported
  bNumDescriptors 1
  bDescriptorType34 Report
  wDescriptorLength 104
 Report Descriptors:
   ** UNAVAILABLE **
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes3
  Transfer TypeInterrupt
  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:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 0 Full speed (or root) hub
  bMaxPacketSize0 8
  idVendor   0x04b4 Cypress Semiconductor Corp.
  idProduct  0x2050
  bcdDevice0.01
  iManufacturer   1 Bella Corporation
  iProduct2 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
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 9 Hub

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-11 Thread Jiri Slaby


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 [EMAIL PROTECTED] is an alias for /dev/null
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-09 Thread Jiri Slaby


On 3/9/07, Jiri Slaby <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-09 Thread Jiri Slaby


On 3/9/07, Jiri Kosina <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-09 Thread Jiri Kosina

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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-09 Thread Jiri Kosina

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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-09 Thread Dmitry Torokhov


On 3/9/07, Jiri Slaby <[EMAIL PROTECTED]> wrote:

Andrew Morton napsal(a):
> On Sat, 03 Mar 2007 16:54:45 +0100 Jiri Slaby <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-09 Thread Jiri Slaby


Andrew Morton napsal(a):

On Sat, 03 Mar 2007 16:54:45 +0100 Jiri Slaby <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> is an alias for /dev/null
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-09 Thread Jiri Slaby


Andrew Morton napsal(a):

On Sat, 03 Mar 2007 16:54:45 +0100 Jiri Slaby [EMAIL PROTECTED] 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 [EMAIL PROTECTED] is an alias for /dev/null
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-09 Thread Dmitry Torokhov


On 3/9/07, Jiri Slaby [EMAIL PROTECTED] wrote:

Andrew Morton napsal(a):
 On Sat, 03 Mar 2007 16:54:45 +0100 Jiri Slaby [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-09 Thread Jiri Kosina

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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-09 Thread Jiri Kosina

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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-09 Thread Jiri Slaby


On 3/9/07, Jiri Kosina [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-09 Thread Jiri Slaby


On 3/9/07, Jiri Slaby [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-03 Thread Andrew Morton

On Sat, 03 Mar 2007 16:54:45 +0100 Jiri Slaby <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-03 Thread Jiri Slaby




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 <[EMAIL PROTECTED]> is an alias for /dev/null
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-03 Thread Jiri Slaby




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 [EMAIL PROTECTED] is an alias for /dev/null
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]

2007-03-03 Thread Andrew Morton

On Sat, 03 Mar 2007 16:54:45 +0100 Jiri Slaby [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

62 matches

Mail list logo