Mailing List Archive

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

Alan Stern napsal(a):
> 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 0000 0002 0004 4 <
d61f5c40 3949386751 C Ci:001:00 0 4 = 01010100
d61f5c40 3949386753 S Co:001:00 s 23 01 0010 0002 0000 0
d61f5c40 3949386756 C Co:001:00 0 0
d61f5c40 3949386763 S Ci:001:00 s a3 00 0000 0002 0004 4 <
d61f5c40 3949386766 C Ci:001:00 0 4 = 01010000
d61f5c40 3949418677 S Ci:001:00 s a3 00 0000 0002 0004 4 <
d61f5c40 3949418683 C Ci:001:00 0 4 = 01010000
d61f5c40 3949450679 S Ci:001:00 s a3 00 0000 0002 0004 4 <
d61f5c40 3949450685 C Ci:001:00 0 4 = 01010000
d61f5c40 3949482684 S Ci:001:00 s a3 00 0000 0002 0004 4 <
d61f5c40 3949482691 C Ci:001:00 0 4 = 01010000
d61f5c40 3949514679 S Ci:001:00 s a3 00 0000 0002 0004 4 <
d61f5c40 3949514684 C Ci:001:00 0 4 = 01010000
d61f5c40 3949514700 S Co:001:00 s 23 03 0004 0002 0000 0
d61f5c40 3949514703 C Co:001:00 0 0
d61f5c40 3949570683 S Ci:001:00 s a3 00 0000 0002 0004 4 <
d61f5c40 3949570704 C Ci:001:00 0 4 = 03010000
d61f5c40 3949626685 S Co:001:00 s 23 01 0014 0002 0000 0
d61f5c40 3949626688 C Co:001:00 0 0
d61f5c40 3949626700 S Ci:000:00 s 80 06 0100 0000 0040 64 <
d61f5c40 3949630848 C Ci:000:00 0 8 = 12011001 09000008
d61f5c40 3949630855 S Co:001:00 s 23 03 0004 0002 0000 0
d61f5c40 3949630859 C Co:001:00 0 0
d61f5c40 3949686687 S Ci:001:00 s a3 00 0000 0002 0004 4 <
d61f5c40 3949686708 C Ci:001:00 0 4 = 03010000
d61f5c40 3949742688 S Co:001:00 s 23 01 0014 0002 0000 0
d61f5c40 3949742691 C Co:001:00 0 0
d61f5c40 3949742695 S Co:000:00 s 00 05 0002 0000 0000 0
d61f5c40 3949744829 C Co:000:00 0 0
d61f5c40 3949762695 S Ci:002:00 s 80 06 0100 0000 0012 18 <
d61f5c40 3949767826 C Ci:002:00 0 18 = 12011001 09000008 b4045020 01000102 0001
d61f5c40 3949767836 S Ci:002:00 s 80 06 0200 0000 0009 9 <
d61f5c40 3949772823 C Ci:002:00 0 9 = 09021900 010100e0 32
d61f5c40 3949772828 S Ci:002:00 s 80 06 0200 0000 0019 25 <
d61f5c40 3949779822 C Ci:002:00 0 25 = 09021900 010100e0 32090400 00010900
00000705 81030100 ff
d61f5c40 3949779831 S Ci:002:00 s 80 06 0300 0000 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 0000 0000 0
d61f5c40 3949808826 C Co:002:00 0 0
d61f5c40 3949808930 S Ci:002:00 s a0 06 2900 0000 000f 15 <
d61f5c40 3949811830 C Ci:002:00 0 9 = 0929030d 00321902 ff
d61f5c40 3949811866 S Ci:002:00 s 80 00 0000 0000 0002 2 <
d61f5c40 3949812824 C Ci:002:00 0 2 = 0000
d61f5c40 3949812849 S Ci:002:00 s a0 00 0000 0000 0004 4 <
d61f5c40 3949813825 C Ci:002:00 0 4 = 00000000
c19df340 3949813854 S Co:002:00 s 23 03 0008 0001 0000 0
c19df340 3949814819 C Co:002:00 0 0
c19df340 3949814828 S Co:002:00 s 23 03 0008 0002 0000 0
c19df340 3949815821 C Co:002:00 0 0
c19df340 3949815836 S Co:002:00 s 23 03 0008 0003 0000 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 0000 0001 0004 4 <
c19df340 3949920805 C Ci:002:00 0 4 = 01010100
c19df340 3949920821 S Co:002:00 s 23 01 0010 0001 0000 0
c19df340 3949921803 C Co:002:00 0 0
c19df340 3949921824 S Ci:002:00 s a3 00 0000 0001 0004 4 <
c19df340 3949922799 C Ci:002:00 0 4 = 01010000
c19df340 3949954701 S Ci:002:00 s a3 00 0000 0001 0004 4 <
c19df340 3949955795 C Ci:002:00 0 4 = 01010000
c19df340 3949986696 S Ci:002:00 s a3 00 0000 0001 0004 4 <
c19df340 3949987785 C Ci:002:00 0 4 = 01010000
c19df340 3950018699 S Ci:002:00 s a3 00 0000 0001 0004 4 <
c19df340 3950019781 C Ci:002:00 0 4 = 01010000
c19df340 3950050704 S Ci:002:00 s a3 00 0000 0001 0004 4 <
c19df340 3950051778 C Ci:002:00 0 4 = 01010000
c19df340 3950051800 S Co:002:00 s 23 03 0004 0001 0000 0
c19df340 3950052775 C Co:002:00 0 0
c19df340 3950066701 S Ci:002:00 s a3 00 0000 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 0000 0
c19df340 3950123761 C Co:002:00 0 0
c19df340 3950123774 S Ci:000:00 s 80 06 0100 0000 0040 64 <
c19df340 3950128760 C Ci:000:00 0 8 = 12011001 00000008
c19df340 3950128766 S Co:002:00 s 23 03 0004 0001 0000 0
c19df340 3950129760 C Co:002:00 0 0
c19df340 3950142704 S Ci:002:00 s a3 00 0000 0001 0004 4 <
c19df340 3950143759 C Ci:002:00 0 4 = 03011000
c19df340 3950198708 S Co:002:00 s 23 01 0014 0001 0000 0
c19df340 3950199750 C Co:002:00 0 0
c19df340 3950199757 S Co:000:00 s 00 05 0003 0000 0000 0
c19df340 3950202746 C Co:000:00 0 0
c19df340 3950218712 S Ci:003:00 s 80 06 0100 0000 0012 18 <
c19df340 3950223745 C Ci:003:00 0 18 = 12011001 00000008 58044c00 01010102 0001
c19df340 3950223753 S Ci:003:00 s 80 06 0200 0000 0009 9 <
c19df340 3950228743 C Ci:003:00 0 9 = 09023b00 020100e0 19
c19df340 3950228749 S Ci:003:00 s 80 06 0200 0000 003b 59 <
c19df340 3950239745 C Ci:003:00 0 59 = 09023b00 020100e0 19090400 00010301
01000921 10010001 22410007 05810308
c19df340 3950239765 S Ci:003:00 s 80 06 0300 0000 00ff 255 <
c19df340 3950244739 C Ci:003:00 0 4 = 04030904
c19df340 3950244749 S Ci:003:00 s 80 06 0302 0409 00ff 255 <
c19df340 3950252738 C Ci:003:00 0 26 = 1a035500 53004200 20004b00 65007900
62006f00 61007200 6400
c19df340 3950252744 S Ci:003:00 s 80 06 0301 0409 00ff 255 <
c19df340 3950259737 C Ci:003:00 0 16 = 10034100 42004200 48004f00 4d004500
c19df340 3950259879 S Co:003:00 s 00 09 0001 0000 0000 0
c19df340 3950262742 C Co:003:00 0 0
dc622dc0 3950262842 S Co:003:00 s 21 0a 0000 0000 0000 0
dc622dc0 3950264745 C Co:003:00 0 0
dc622dc0 3950264763 S Ci:003:00 s 81 06 2200 0000 0041 65 <
dc622dc0 3950265753 C Ci:003:00 0 65 = 05010906 a1010507 19e029e7 15002501
95087501 81029508 75018101 05081901
c19df340 3950266246 S Ii:003:01 -115 8 <
f7f9f540 3950266436 S Co:003:00 s 21 0a 0000 0001 0000 0
f7f9f540 3950266742 C Co:003:00 0 0
f7f9f540 3950266786 S Ci:003:00 s 81 06 2200 0001 0068 104 <
f7f9f540 3950268745 C Ci:003:00 0 104 = 05010902 a1018504 0901a100 05091901
29031500 25019503 75018102 95017505
f7b30540 3950269366 S Ii:003:02 -115 5 <
d61f5440 3950269562 S Ci:002:00 s a3 00 0000 0002 0004 4 <
d61f5440 3950269745 C Ci:002:00 0 4 = 00010000
d61f5440 3950269765 S Ci:002:00 s a3 00 0000 0003 0004 4 <
d61f5440 3950270743 C Ci:002:00 0 4 = 00010000
d61f5440 3950270781 S Ci:002:00 s a3 00 0000 0001 0004 4 <
d61f5440 3950271743 C Ci:002:00 0 4 = 03010000
c19df340 3951308554 C Ii:003:01 0 8 = 00005300 00000000
c19df340 3951308575 S Ii:003:01 -115 8 <
f7f9f3c0 3951308594 S Co:003:00 s 21 09 0200 0000 0001 1 = 01
f7f9f3c0 3951310552 C Co:003:00 0 1 >
c19df340 3951364542 C Ii:003:01 0 8 = 00000000 00000000
c19df340 3951364554 S Ii:003:01 -115 8 <

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 0000 0000 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 0000 0001 0004 4 <
-C Ci:001:00 0 4 = 00010000
S Ci:001:00 s a3 00 0000 0002 0004 4 <
C Ci:001:00 0 4 = 01010100
S Co:001:00 s 23 01 0010 0002 0000 0
@@ -28,8 +24,6 @@
C Ci:000:00 0 8 = 12011001 09000008
S Co:001:00 s 23 03 0004 0002 0000 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 0000 0002 0004 4 <
C Ci:001:00 0 4 = 03010000
S Co:001:00 s 23 01 0014 0002 0000 0
@@ -63,8 +57,6 @@
S Co:002:00 s 23 03 0008 0003 0000 0
C Co:002:00 0 0
S Ii:002:01 -115 1 <
-S Ci:001:00 s a3 00 0000 0002 0004 4 <
-C Ci:001:00 0 4 = 03010000
S Ci:002:00 s a3 00 0000 0001 0004 4 <
C Ci:002:00 0 4 = 01010100
S Co:002:00 s 23 01 0010 0001 0000 0
@@ -131,3 +123,5 @@
S Ii:003:01 -115 8 <
S Co:003:00 s 21 09 0200 0000 0001 1 = 01
C Co:003:00 0 1 >
+C Ii:003:01 0 8 = 00000000 00000000
+S Ii:003:01 -115 8 <

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

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

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

On Sun, 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 0000 0000 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 0000 0001 0004 4 <
> -C Ci:001:00 0 4 = 00010000
> S Ci:001:00 s a3 00 0000 0002 0004 4 <
> C Ci:001:00 0 4 = 01010100
> S Co:001:00 s 23 01 0010 0002 0000 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 09000008
> S Co:001:00 s 23 03 0004 0002 0000 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 0000 0002 0004 4 <
> C Ci:001:00 0 4 = 03010000
> S Co:001:00 s 23 01 0014 0002 0000 0
> @@ -63,8 +57,6 @@
> S Co:002:00 s 23 03 0008 0003 0000 0
> C Co:002:00 0 0
> S Ii:002:01 -115 1 <
> -S Ci:001:00 s a3 00 0000 0002 0004 4 <
> -C Ci:001:00 0 4 = 03010000
> S Ci:002:00 s a3 00 0000 0001 0004 4 <
> C Ci:002:00 0 4 = 01010100
> S Co:002:00 s 23 01 0010 0001 0000 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 0000 0001 1 = 01
> C Co:003:00 0 1 >
> +C Ii:003:01 0 8 = 00000000 00000000
> +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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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

On Sun, 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 = link_to_next_qh;

- /* If this is the first FSBQ QH, take special action */
+ /* If this is 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 this QH is also the last one, we must link in
- * the terminating skeleton QH. */
- if (qh == lqh) {
- link_to_next_qh = LINK_TO_QH(uhci->skel_term_qh);
- uhci->skel_term_qh->link = link_to_next_qh;
- wmb();
- qh->link = link_to_next_qh;
-
- /* Otherwise the last QH must point to the new first FSBR QH */
- } else
- lqh->link = link_to_next_qh;
+ /* The terminating skeleton QH must point to the new
+ * first FSBR QH */
+ uhci->skel_term_qh->link = link_to_next_qh;
}

- pqh->link = link_to_next_qh;
mb();
}

@@ -786,9 +765,11 @@ static void uhci_free_urb_priv(struct uh
{
struct uhci_td *td, *tmp;

- if (!list_empty(&urbp->node))
+ if (!list_empty(&urbp->node)) {
dev_warn(uhci_dev(uhci), "urb %p still on QH's list!\n",
urbp->urb);
+ WARN_ON(1);
+ }

list_for_each_entry_safe(td, tmp, &urbp->td_list, list) {
uhci_remove_td_from_urbp(td);

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

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

On Sun, 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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/