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, i
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.
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 39493
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:
...
> (Re
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
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, sendin
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 run
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:
>
> USB
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 00
(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
> f75
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
> >>
> >> UH
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) attempt
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 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/~xsla
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 w
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?
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 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 t
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 eve
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/
>>> Weird
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 n
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
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
31 matches
Mail list logo