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
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,
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
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/
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...
...
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
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
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
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/
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.
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
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
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:
...
>
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
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
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
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
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
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,
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
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
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.
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:
>
>
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
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.
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
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
(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
>
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
> >>
> >>
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
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)
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.
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.
[...]
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
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
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
(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
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
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.
--
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
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
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?
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?
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
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
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.
--
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
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
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
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
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/
>>>
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
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
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
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
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
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
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).
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
>
>
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
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 pressing
those keys, keyboard "hangs" -- no sysrq, no lock leds are flashing.
After plug; unplug of the keyboard, it works unless I
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 pressing
those keys, keyboard hangs -- no sysrq, no lock leds are flashing.
After plug; unplug of the keyboard, it works unless I
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
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.
64 matches
Mail list logo
