With 2.6.4 I'm getting the following messages very early in the boot
long before XFree86 is started:
Mar 18 16:05:31 mudlark kernel: atkbd.c: Unknown key released
(translated set 2, code 0x7a on isa0060/serio0).
Mar 18 16:05:31 mudlark kernel: atkbd.c: This is an XFree86 bug. It
shouldn't access hardware directly.
They are repeated 6 times and are NOT the result of any keys being
pressed or released.
Peter
--
Dr Peter Williams, Chief Scientist [email protected]
Aurema Pty Limited Tel:+61 2 9698 2322
PO Box 305, Strawberry Hills NSW 2012, Australia Fax:+61 2 9699 9174
79 Myrtle Street, Chippendale NSW 2008, Australia http://www.aurema.com
Wrongly ? I don't think so, as it has presumably been fixed in
XFree86 after 4.4.0.
http://www.xfree86.org/cvs/changes.html:
6. Do the Linux KDKBDREP ioctl on the correct fd. This
prevents the fallback that tries to directly program the
keyboard repeat rate, and the related warning messages that
recent Linux kernels generate (David Dawes).
I'm attaching the patch I extracted from CVS.
Vojtech, what about adding such information to your HOWTO ? And
better, adding the URL to atkbd.c, so people stop reporting it.
On Thu, 18 Mar 2004, Peter Williams wrote:
> With 2.6.4 I'm getting the following messages very early in the boot
> long before XFree86 is started:
>
> Mar 18 16:05:31 mudlark kernel: atkbd.c: Unknown key released
> (translated set 2, code 0x7a on isa0060/serio0).
> Mar 18 16:05:31 mudlark kernel: atkbd.c: This is an XFree86 bug. It
> shouldn't access hardware directly.
>
> They are repeated 6 times and are NOT the result of any keys being
> pressed or released.
--
http://www.pervalidus.net/contact.html
>With 2.6.4 I'm getting the following messages very early in the boot
>long before XFree86 is started:
>
>Mar 18 16:05:31 mudlark kernel: atkbd.c: Unknown key released
>(translated set 2, code 0x7a on isa0060/serio0).
>Mar 18 16:05:31 mudlark kernel: atkbd.c: This is an XFree86 bug. It
>shouldn't access hardware directly.
>
>They are repeated 6 times and are NOT the result of any keys being
>pressed or released.
this has been fixed in XFree86 HEAD (4.4.99.1)
see changelog entry nr. 6 - the changes can easily be backported to 4.3.0, and work as expected on my box.
(no noise anymore)
Christian
Fr?d?ric L. W. Meunier wrote:
> Wrongly ?
Yes, wrongly. XFree86 wasn't even running when the messages appeared so
there's no way that it could be to blame. Also no keys had been pressed
or released.
Peter
--
Dr Peter Williams, Chief Scientist [email protected]
Aurema Pty Limited Tel:+61 2 9698 2322
PO Box 305, Strawberry Hills NSW 2012, Australia Fax:+61 2 9699 9174
79 Myrtle Street, Chippendale NSW 2008, Australia http://www.aurema.com
Christian Guggenberger wrote:
>>With 2.6.4 I'm getting the following messages very early in the boot
>>long before XFree86 is started:
>>
>>Mar 18 16:05:31 mudlark kernel: atkbd.c: Unknown key released
>>(translated set 2, code 0x7a on isa0060/serio0).
>>Mar 18 16:05:31 mudlark kernel: atkbd.c: This is an XFree86 bug. It
>>shouldn't access hardware directly.
>>
>>They are repeated 6 times and are NOT the result of any keys being
>>pressed or released.
>
>
> this has been fixed in XFree86 HEAD (4.4.99.1)
> see changelog entry nr. 6 - the changes can easily be backported to 4.3.0, and work as expected on my box.
> (no noise anymore)
I repeat. These messages are appearing when XFree86 is NOT running so
there is no way that it can be the cause of them.
Peter
--
Dr Peter Williams, Chief Scientist [email protected]
Aurema Pty Limited Tel:+61 2 9698 2322
PO Box 305, Strawberry Hills NSW 2012, Australia Fax:+61 2 9699 9174
79 Myrtle Street, Chippendale NSW 2008, Australia http://www.aurema.com
On Thu, 2004-03-18 at 08:02, Christian Guggenberger wrote:
> >With 2.6.4 I'm getting the following messages very early in the boot
> >long before XFree86 is started:
> >
oops, must have overlook this sentence before - should get a coffee
first. Well in that case, XFree86 should not have been blamed.
sorry for the noise.
> >Mar 18 16:05:31 mudlark kernel: atkbd.c: Unknown key released
> >(translated set 2, code 0x7a on isa0060/serio0).
> >Mar 18 16:05:31 mudlark kernel: atkbd.c: This is an XFree86 bug. It
> >shouldn't access hardware directly.
> >
> >They are repeated 6 times and are NOT the result of any keys being
> >pressed or released.
>
> this has been fixed in XFree86 HEAD (4.4.99.1)
> see changelog entry nr. 6 - the changes can easily be backported to 4.3.0, and work as expected on my box.
> (no noise anymore)
>
On Thu, Mar 18, 2004 at 03:56:35AM -0300, Fr?d?ric L. W. Meunier wrote:
> Wrongly ? I don't think so, as it has presumably been fixed in
> XFree86 after 4.4.0.
>
> http://www.xfree86.org/cvs/changes.html:
>
> 6. Do the Linux KDKBDREP ioctl on the correct fd. This
> prevents the fallback that tries to directly program the
> keyboard repeat rate, and the related warning messages that
> recent Linux kernels generate (David Dawes).
>
> I'm attaching the patch I extracted from CVS.
>
> Vojtech, what about adding such information to your HOWTO ? And
> better, adding the URL to atkbd.c, so people stop reporting it.
I'll add the info and the URL into the HOWTO and kill the message.
> On Thu, 18 Mar 2004, Peter Williams wrote:
>
> > With 2.6.4 I'm getting the following messages very early in the boot
> > long before XFree86 is started:
> >
> > Mar 18 16:05:31 mudlark kernel: atkbd.c: Unknown key released
> > (translated set 2, code 0x7a on isa0060/serio0).
> > Mar 18 16:05:31 mudlark kernel: atkbd.c: This is an XFree86 bug. It
> > shouldn't access hardware directly.
> >
> > They are repeated 6 times and are NOT the result of any keys being
> > pressed or released.
>
> --
> http://www.pervalidus.net/contact.html
> Index: xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_io.c
> diff -u xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_io.c:3.26 xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_io.c:3.27
> --- xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_io.c:3.26 Mon Nov 17 22:20:41 2003
> +++ xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_io.c Wed Mar 3 18:53:41 2004
> @@ -1,4 +1,4 @@
> -/* $XFree86: xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_io.c,v 3.26 2003/11/17 22:20:41 dawes Exp $ */
> +/* $XFree86: xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_io.c,v 3.27 2004/03/03 18:53:41 dawes Exp $ */
> /*
> * Copyright 1992 by Orest Zborowski <[email protected]>
> * Copyright 1993 by David Dawes <[email protected]>
> @@ -81,7 +81,7 @@
> #endif
>
> static int
> -KDKBDREP_ioctl_ok(int rate, int delay) {
> +KDKBDREP_ioctl_ok(int fd, int rate, int delay) {
> #if defined(KDKBDREP) && !defined(__sparc__)
> /* This ioctl is defined in <linux/kd.h> but is not
> implemented anywhere - must be in some m68k patches. */
> @@ -90,7 +90,7 @@
> /* don't change, just test */
> kbdrep_s.rate = -1;
> kbdrep_s.delay = -1;
> - if (ioctl( 0, KDKBDREP, &kbdrep_s )) {
> + if (ioctl( fd, KDKBDREP, &kbdrep_s )) {
> return 0;
> }
>
> @@ -105,7 +105,7 @@
> if (kbdrep_s.delay < 1)
> kbdrep_s.delay = 1;
>
> - if (ioctl( 0, KDKBDREP, &kbdrep_s )) {
> + if (ioctl( fd, KDKBDREP, &kbdrep_s )) {
> return 0;
> }
>
> @@ -174,7 +174,7 @@
> delay = xf86Info.kbdDelay;
>
>
> - if(KDKBDREP_ioctl_ok(rate, delay)) /* m68k? */
> + if(KDKBDREP_ioctl_ok(xf86Info.consoleFd, rate, delay)) /* m68k? */
> return;
>
> if(KIOCSRATE_ioctl_ok(rate, delay)) /* sparc? */
> Index: xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_kbd.c
> diff -u xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_kbd.c:1.5 xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_kbd.c:1.6
> --- xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_kbd.c:1.5 Tue Nov 4 03:14:39 2003
> +++ xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_kbd.c Wed Mar 3 18:53:41 2004
> @@ -1,4 +1,4 @@
> -/* $XFree86: xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_kbd.c,v 1.5 2003/11/04 03:14:39 tsi Exp $ */
> +/* $XFree86: xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_kbd.c,v 1.6 2004/03/03 18:53:41 dawes Exp $ */
>
> /*
> * Copyright (c) 2002 by The XFree86 Project, Inc.
> @@ -108,7 +108,7 @@
> #endif
>
> static int
> -KDKBDREP_ioctl_ok(int rate, int delay) {
> +KDKBDREP_ioctl_ok(int fd, int rate, int delay) {
> #if defined(KDKBDREP) && !defined(__sparc__)
> /* This ioctl is defined in <linux/kd.h> but is not
> implemented anywhere - must be in some m68k patches. */
> @@ -117,7 +117,7 @@
> /* don't change, just test */
> kbdrep_s.rate = -1;
> kbdrep_s.delay = -1;
> - if (ioctl( 0, KDKBDREP, &kbdrep_s )) {
> + if (ioctl( fd, KDKBDREP, &kbdrep_s )) {
> return 0;
> }
>
> @@ -132,7 +132,7 @@
> if (kbdrep_s.delay < 1)
> kbdrep_s.delay = 1;
>
> - if (ioctl( 0, KDKBDREP, &kbdrep_s )) {
> + if (ioctl( fd, KDKBDREP, &kbdrep_s )) {
> return 0;
> }
>
> @@ -200,7 +200,7 @@
> if (pKbd->delay >= 0)
> delay = pKbd->delay;
>
> - if(KDKBDREP_ioctl_ok(rate, delay)) /* m68k? */
> + if(KDKBDREP_ioctl_ok(pInfo->fd, rate, delay)) /* m68k? */
> return;
>
> if(KIOCSRATE_ioctl_ok(rate, delay)) /* sparc? */
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Thu, Mar 18, 2004 at 06:02:28PM +1100, Peter Williams wrote:
> Fr?d?ric L. W. Meunier wrote:
> >Wrongly ?
>
> Yes, wrongly. XFree86 wasn't even running when the messages appeared so
> there's no way that it could be to blame. Also no keys had been pressed
> or released.
XFree86 wasn't the only one doing that. Old versions of 'kbdrate' have
did direct HW accesses, too.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Thu, 18 Mar 2004, Vojtech Pavlik wrote:
> On Thu, Mar 18, 2004 at 03:56:35AM -0300, Fr?d?ric L. W. Meunier wrote:
>
> > Wrongly ? I don't think so, as it has presumably been fixed in
> > XFree86 after 4.4.0.
> >
> > http://www.xfree86.org/cvs/changes.html:
> >
> > 6. Do the Linux KDKBDREP ioctl on the correct fd. This
> > prevents the fallback that tries to directly program the
> > keyboard repeat rate, and the related warning messages that
> > recent Linux kernels generate (David Dawes).
> >
> > I'm attaching the patch I extracted from CVS.
> >
> > Vojtech, what about adding such information to your HOWTO ? And
> > better, adding the URL to atkbd.c, so people stop reporting it.
>
> I'll add the info and the URL into the HOWTO and kill the message.
Here are the URLs directly from CVS (just in case someone
doesn't trust the diff I sent):
http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_io.c.diff?r1=3.26&r2=3.27
http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_kbd.c.diff?r1=1.5&r2=1.6
--
http://www.pervalidus.net/contact.html
On 18.03.2004 08:57 Peter Williams wrote:
> Christian Guggenberger wrote:
>> On Thu, 2004-03-18 at 08:08, Peter Williams wrote:
>>
>>> Christian Guggenberger wrote:
>>>
>>>>> With 2.6.4 I'm getting the following messages very early in the boot
>>>>> long before XFree86 is started:
>>>>>
>>>>> Mar 18 16:05:31 mudlark kernel: atkbd.c: Unknown key released
>>>>> (translated set 2, code 0x7a on isa0060/serio0).
>>>>> Mar 18 16:05:31 mudlark kernel: atkbd.c: This is an XFree86 bug. It
>>>>> shouldn't access hardware directly.
>>>>>
>>>>> They are repeated 6 times and are NOT the result of any keys being
>>>>> pressed or released.
>>>>
>>>>
>>>> this has been fixed in XFree86 HEAD (4.4.99.1)
>>>> see changelog entry nr. 6 - the changes can easily be backported to
>>>> 4.3.0, and work as expected on my box.
>>>> (no noise anymore)
>>>
>>> I repeat. These messages are appearing when XFree86 is NOT running so
>>> there is no way that it can be the cause of them.
>>
>>
>> yeah, sorry. After reading your previous mail I realized it, too.
>> If you have some spare time, you could boot with init=/bin/bash and then
>> start every boot script step by step to see which one is causing these
>> kernel messages.
>
> OK. As requested, I just did a boot with init=/bin/bash and the bad news is
> that the messages appeared before bash started. So I think that confirms my
> suspicion that they occur before any of the start scripts are invoked?
>
[cc'ed linux-kernel again]
Yeah, I do think so.
On Thu, 2004-03-18 at 08:08, Peter Williams wrote:
> Christian Guggenberger wrote:
> >>With 2.6.4 I'm getting the following messages very early in the boot
> >>long before XFree86 is started:
> >>
> >>Mar 18 16:05:31 mudlark kernel: atkbd.c: Unknown key released
> >>(translated set 2, code 0x7a on isa0060/serio0).
> >>Mar 18 16:05:31 mudlark kernel: atkbd.c: This is an XFree86 bug. It
> >>shouldn't access hardware directly.
> >>
> >>They are repeated 6 times and are NOT the result of any keys being
> >>pressed or released.
> >
> >
> > this has been fixed in XFree86 HEAD (4.4.99.1)
> > see changelog entry nr. 6 - the changes can easily be backported to 4.3.0, and work as expected on my box.
> > (no noise anymore)
>
> I repeat. These messages are appearing when XFree86 is NOT running so
> there is no way that it can be the cause of them.
I have the exact same behaviour on my machine.
(my 2 cents)
Regards
--
Emmanuel Fleury
Computer Science Department, | Office: B1-201
Aalborg University, | Phone: +45 96 35 72 23
Fredriks Bajersvej 7E, | Fax: +45 98 15 98 89
9220 Aalborg East, Denmark | Email: [email protected]
On Thu, Mar 18, 2004 at 09:16:30AM +0100, Christian Guggenberger wrote:
> >>>I repeat. These messages are appearing when XFree86 is NOT running so
> >>>there is no way that it can be the cause of them.
> >>yeah, sorry. After reading your previous mail I realized it, too.
> >>If you have some spare time, you could boot with init=/bin/bash and then
> >>start every boot script step by step to see which one is causing these
> >>kernel messages.
> >OK. As requested, I just did a boot with init=/bin/bash and the bad news
> >is that the messages appeared before bash started. So I think that
> >confirms my suspicion that they occur before any of the start scripts are
> >invoked?
> [cc'ed linux-kernel again]
> Yeah, I do think so.
Ok. If it appeats with init=/bin/bash and you're not running kbdrate in
your bashrc or profile, then this is likely a kernel or hardware
problem.
Can you please #define DEBUG in drivers/input/serio/i8042.c, recompile,
boot with init=/bin/bash, and then send me the resulting 'dmesg'?
Thanks.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
i8042 (interrupt, aux, 12) [610]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [610]
drivers/input/serio/i8042.c: 00 -> i8042 (parameter) [610]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12) [618]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [618]
drivers/input/serio/i8042.c: e8 -> i8042 (parameter) [618]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12) [626]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [626]
drivers/input/serio/i8042.c: 00 -> i8042 (parameter) [626]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12) [638]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [638]
drivers/input/serio/i8042.c: e8 -> i8042 (parameter) [638]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12) [646]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [646]
drivers/input/serio/i8042.c: 00 -> i8042 (parameter) [646]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12) [654]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [654]
drivers/input/serio/i8042.c: e8 -> i8042 (parameter) [654]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12) [666]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [666]
drivers/input/serio/i8042.c: 00 -> i8042 (parameter) [666]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12) [674]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [674]
drivers/input/serio/i8042.c: e9 -> i8042 (parameter) [674]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12) [683]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux, 12) [686]
drivers/input/serio/i8042.c: 00 <- i8042 (interrupt, aux, 12) [690]
drivers/input/serio/i8042.c: 64 <- i8042 (interrupt, aux, 12) [694]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [694]
drivers/input/serio/i8042.c: f3 -> i8042 (parameter) [694]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12) [702]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [702]
drivers/input/serio/i8042.c: c8 -> i8042 (parameter) [702]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12) [710]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [710]
drivers/input/serio/i8042.c: f3 -> i8042 (parameter) [710]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12) [718]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [718]
drivers/input/serio/i8042.c: 64 -> i8042 (parameter) [718]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12) [726]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [726]
drivers/input/serio/i8042.c: f3 -> i8042 (parameter) [726]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12) [738]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [738]
drivers/input/serio/i8042.c: 50 -> i8042 (parameter) [738]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12) [746]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [746]
drivers/input/serio/i8042.c: f2 -> i8042 (parameter) [746]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12) [754]
drivers/input/serio/i8042.c: 03 <- i8042 (interrupt, aux, 12) [758]
input: ImPS/2 Generic Wheel Mouse on isa0060/serio1
drivers/input/serio/i8042.c: d4 -> i8042 (command) [758]
drivers/input/serio/i8042.c: f3 -> i8042 (parameter) [758]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12) [766]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [766]
drivers/input/serio/i8042.c: 64 -> i8042 (parameter) [766]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12) [778]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [778]
drivers/input/serio/i8042.c: e8 -> i8042 (parameter) [778]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12) [786]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [786]
drivers/input/serio/i8042.c: 03 -> i8042 (parameter) [786]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12) [794]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [794]
drivers/input/serio/i8042.c: e6 -> i8042 (parameter) [794]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12) [806]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [806]
drivers/input/serio/i8042.c: ea -> i8042 (parameter) [806]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12) [814]
drivers/input/serio/i8042.c: d4 -> i8042 (command) [814]
drivers/input/serio/i8042.c: f4 -> i8042 (parameter) [814]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, aux, 12) [818]
drivers/input/serio/i8042.c: 60 -> i8042 (command) [818]
drivers/input/serio/i8042.c: 46 -> i8042 (parameter) [818]
serio: i8042 KBD port at 0x60,0x64 irq 1
drivers/input/serio/i8042.c: 60 -> i8042 (command) [819]
drivers/input/serio/i8042.c: 47 -> i8042 (parameter) [819]
drivers/input/serio/i8042.c: f2 -> i8042 (kbd-data) [820]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [822]
drivers/input/serio/i8042.c: ab <- i8042 (interrupt, kbd, 1) [826]
drivers/input/serio/i8042.c: 41 <- i8042 (interrupt, kbd, 1) [830]
drivers/input/serio/i8042.c: ed -> i8042 (kbd-data) [830]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [837]
drivers/input/serio/i8042.c: 00 -> i8042 (kbd-data) [837]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [844]
drivers/input/serio/i8042.c: f3 -> i8042 (kbd-data) [844]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [850]
drivers/input/serio/i8042.c: 00 -> i8042 (kbd-data) [850]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [857]
drivers/input/serio/i8042.c: f4 -> i8042 (kbd-data) [857]
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [863]
input: AT Translated Set 2 keyboard on isa0060/serio0
Advanced Linux Sound Architecture Driver Version 1.0.2c (Thu Feb 05 15:41:49 2004 UTC).
ALSA device list:
No soundcards found.
oprofile: using timer interrupt.
NET: Registered protocol family 2
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [866]
atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly.
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [870]
atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly.
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [874]
atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly.
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [878]
atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly.
IP: routing cache hash table of 8192 buckets, 64Kbytes
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [882]
atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly.
TCP: Hash tables configured (established 262144 bind 65536)
ip_conntrack version 2.1 (8191 buckets, 65528 max) - 296 bytes per conntrack
drivers/input/serio/i8042.c: fa <- i8042 (interrupt, kbd, 1) [886]
atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly.
ip_tables: (C) 2000-2002 Netfilter core team
ipt_recent v0.3.1: Stephen Frost <[email protected]>. http://snowman.net/projects/ipt_recent/
arp_tables: (C) 2002 David S. Miller
NET: Registered protocol family 1
NET: Registered protocol family 17
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 144k freed
drivers/input/serio/i8042.c: 32 <- i8042 (interrupt, kbd, 1) [3394]
drivers/input/serio/i8042.c: b2 <- i8042 (interrupt, kbd, 1) [3500]
drivers/input/serio/i8042.c: 18 <- i8042 (interrupt, kbd, 1) [3713]
drivers/input/serio/i8042.c: 98 <- i8042 (interrupt, kbd, 1) [3805]
drivers/input/serio/i8042.c: 16 <- i8042 (interrupt, kbd, 1) [3993]
drivers/input/serio/i8042.c: 96 <- i8042 (interrupt, kbd, 1) [4093]
drivers/input/serio/i8042.c: 31 <- i8042 (interrupt, kbd, 1) [4260]
drivers/input/serio/i8042.c: b1 <- i8042 (interrupt, kbd, 1) [4371]
drivers/input/serio/i8042.c: 14 <- i8042 (interrupt, kbd, 1) [4707]
drivers/input/serio/i8042.c: 94 <- i8042 (interrupt, kbd, 1) [4854]
drivers/input/serio/i8042.c: 39 <- i8042 (interrupt, kbd, 1) [5170]
drivers/input/serio/i8042.c: b9 <- i8042 (interrupt, kbd, 1) [5291]
drivers/input/serio/i8042.c: 35 <- i8042 (interrupt, kbd, 1) [6902]
drivers/input/serio/i8042.c: b5 <- i8042 (interrupt, kbd, 1) [7044]
drivers/input/serio/i8042.c: 32 <- i8042 (interrupt, kbd, 1) [8740]
drivers/input/serio/i8042.c: b2 <- i8042 (interrupt, kbd, 1) [8846]
drivers/input/serio/i8042.c: 31 <- i8042 (interrupt, kbd, 1) [8996]
drivers/input/serio/i8042.c: b1 <- i8042 (interrupt, kbd, 1) [9103]
drivers/input/serio/i8042.c: 14 <- i8042 (interrupt, kbd, 1) [9474]
drivers/input/serio/i8042.c: 94 <- i8042 (interrupt, kbd, 1) [9572]
drivers/input/serio/i8042.c: 35 <- i8042 (interrupt, kbd, 1) [10453]
drivers/input/serio/i8042.c: b5 <- i8042 (interrupt, kbd, 1) [10551]
drivers/input/serio/i8042.c: 2c <- i8042 (interrupt, kbd, 1) [11048]
drivers/input/serio/i8042.c: ac <- i8042 (interrupt, kbd, 1) [11227]
drivers/input/serio/i8042.c: 17 <- i8042 (interrupt, kbd, 1) [11359]
drivers/input/serio/i8042.c: 97 <- i8042 (interrupt, kbd, 1) [11443]
drivers/input/serio/i8042.c: 19 <- i8042 (interrupt, kbd, 1) [11926]
drivers/input/serio/i8042.c: 99 <- i8042 (interrupt, kbd, 1) [12044]
drivers/input/serio/i8042.c: 1c <- i8042 (interrupt, kbd, 1) [13278]
drivers/input/serio/i8042.c: 9c <- i8042 (interrupt, kbd, 1) [13428]
drivers/input/serio/i8042.c: 20 <- i8042 (interrupt, kbd, 1) [17283]
drivers/input/serio/i8042.c: a0 <- i8042 (interrupt, kbd, 1) [17398]
drivers/input/serio/i8042.c: 32 <- i8042 (interrupt, kbd, 1) [17539]
drivers/input/serio/i8042.c: b2 <- i8042 (interrupt, kbd, 1) [17653]
drivers/input/serio/i8042.c: 12 <- i8042 (interrupt, kbd, 1) [17730]
drivers/input/serio/i8042.c: 92 <- i8042 (interrupt, kbd, 1) [17837]
drivers/input/serio/i8042.c: 1f <- i8042 (interrupt, kbd, 1) [18098]
drivers/input/serio/i8042.c: 9f <- i8042 (interrupt, kbd, 1) [18273]
drivers/input/serio/i8042.c: 22 <- i8042 (interrupt, kbd, 1) [18560]
drivers/input/serio/i8042.c: a2 <- i8042 (interrupt, kbd, 1) [18693]
drivers/input/serio/i8042.c: 39 <- i8042 (interrupt, kbd, 1) [19279]
drivers/input/serio/i8042.c: b9 <- i8042 (interrupt, kbd, 1) [19387]
drivers/input/serio/i8042.c: 2a <- i8042 (interrupt, kbd, 1) [19810]
drivers/input/serio/i8042.c: 2a <- i8042 (interrupt, kbd, 1) [20063]
drivers/input/serio/i8042.c: 2a <- i8042 (interrupt, kbd, 1) [20095]
drivers/input/serio/i8042.c: 2a <- i8042 (interrupt, kbd, 1) [20128]
drivers/input/serio/i8042.c: 2a <- i8042 (interrupt, kbd, 1) [20160]
drivers/input/serio/i8042.c: 2a <- i8042 (interrupt, kbd, 1) [20193]
drivers/input/serio/i8042.c: 2a <- i8042 (interrupt, kbd, 1) [20225]
drivers/input/serio/i8042.c: 2a <- i8042 (interrupt, kbd, 1) [20257]
drivers/input/serio/i8042.c: 2a <- i8042 (interrupt, kbd, 1) [20289]
drivers/input/serio/i8042.c: 2a <- i8042 (interrupt, kbd, 1) [20322]
drivers/input/serio/i8042.c: 2a <- i8042 (interrupt, kbd, 1) [20354]
drivers/input/serio/i8042.c: 2a <- i8042 (interrupt, kbd, 1) [20386]
drivers/input/serio/i8042.c: 2a <- i8042 (interrupt, kbd, 1) [20419]
drivers/input/serio/i8042.c: 2a <- i8042 (interrupt, kbd, 1) [20451]
drivers/input/serio/i8042.c: 2a <- i8042 (interrupt, kbd, 1) [20483]
drivers/input/serio/i8042.c: 2a <- i8042 (interrupt, kbd, 1) [20515]
drivers/input/serio/i8042.c: 2a <- i8042 (interrupt, kbd, 1) [20548]
drivers/input/serio/i8042.c: 2a <- i8042 (interrupt, kbd, 1) [20580]
drivers/input/serio/i8042.c: 2a <- i8042 (interrupt, kbd, 1) [20612]
drivers/input/serio/i8042.c: 34 <- i8042 (interrupt, kbd, 1) [20634]
drivers/input/serio/i8042.c: b4 <- i8042 (interrupt, kbd, 1) [20726]
drivers/input/serio/i8042.c: aa <- i8042 (interrupt, kbd, 1) [20893]
drivers/input/serio/i8042.c: 39 <- i8042 (interrupt, kbd, 1) [22266]
drivers/input/serio/i8042.c: b9 <- i8042 (interrupt, kbd, 1) [22410]
drivers/input/serio/i8042.c: 35 <- i8042 (interrupt, kbd, 1) [23358]
drivers/input/serio/i8042.c: b5 <- i8042 (interrupt, kbd, 1) [23469]
drivers/input/serio/i8042.c: 32 <- i8042 (interrupt, kbd, 1) [23835]
drivers/input/serio/i8042.c: b2 <- i8042 (interrupt, kbd, 1) [23935]
drivers/input/serio/i8042.c: 31 <- i8042 (interrupt, kbd, 1) [24063]
drivers/input/serio/i8042.c: b1 <- i8042 (interrupt, kbd, 1) [24169]
drivers/input/serio/i8042.c: 14 <- i8042 (interrupt, kbd, 1) [24483]
drivers/input/serio/i8042.c: 94 <- i8042 (interrupt, kbd, 1) [24579]
drivers/input/serio/i8042.c: 35 <- i8042 (interrupt, kbd, 1) [25509]
drivers/input/serio/i8042.c: b5 <- i8042 (interrupt, kbd, 1) [25618]
drivers/input/serio/i8042.c: 2c <- i8042 (interrupt, kbd, 1) [26047]
drivers/input/serio/i8042.c: ac <- i8042 (interrupt, kbd, 1) [26221]
drivers/input/serio/i8042.c: 17 <- i8042 (interrupt, kbd, 1) [26388]
drivers/input/serio/i8042.c: 97 <- i8042 (interrupt, kbd, 1) [26483]
drivers/input/serio/i8042.c: 19 <- i8042 (interrupt, kbd, 1) [26884]
drivers/input/serio/i8042.c: 99 <- i8042 (interrupt, kbd, 1) [27011]
drivers/input/serio/i8042.c: 35 <- i8042 (interrupt, kbd, 1) [27885]
drivers/input/serio/i8042.c: b5 <- i8042 (interrupt, kbd, 1) [27988]
drivers/input/serio/i8042.c: 20 <- i8042 (interrupt, kbd, 1) [28525]
drivers/input/serio/i8042.c: a0 <- i8042 (interrupt, kbd, 1) [28648]
drivers/input/serio/i8042.c: 32 <- i8042 (interrupt, kbd, 1) [28842]
drivers/input/serio/i8042.c: b2 <- i8042 (interrupt, kbd, 1) [28941]
drivers/input/serio/i8042.c: 12 <- i8042 (interrupt, kbd, 1) [29003]
drivers/input/serio/i8042.c: 92 <- i8042 (interrupt, kbd, 1) [29094]
drivers/input/serio/i8042.c: 1f <- i8042 (interrupt, kbd, 1) [29258]
drivers/input/serio/i8042.c: 9f <- i8042 (interrupt, kbd, 1) [29449]
drivers/input/serio/i8042.c: 22 <- i8042 (interrupt, kbd, 1) [29582]
drivers/input/serio/i8042.c: a2 <- i8042 (interrupt, kbd, 1) [29670]
drivers/input/serio/i8042.c: 34 <- i8042 (interrupt, kbd, 1) [30268]
drivers/input/serio/i8042.c: b4 <- i8042 (interrupt, kbd, 1) [30371]
drivers/input/serio/i8042.c: 14 <- i8042 (interrupt, kbd, 1) [30900]
drivers/input/serio/i8042.c: 94 <- i8042 (interrupt, kbd, 1) [30995]
drivers/input/serio/i8042.c: 12 <- i8042 (interrupt, kbd, 1) [31167]
drivers/input/serio/i8042.c: 92 <- i8042 (interrupt, kbd, 1) [31291]
drivers/input/serio/i8042.c: 2d <- i8042 (interrupt, kbd, 1) [31510]
drivers/input/serio/i8042.c: ad <- i8042 (interrupt, kbd, 1) [31719]
drivers/input/serio/i8042.c: 14 <- i8042 (interrupt, kbd, 1) [31760]
drivers/input/serio/i8042.c: 94 <- i8042 (interrupt, kbd, 1) [31823]
drivers/input/serio/i8042.c: 0e <- i8042 (interrupt, kbd, 1) [33690]
drivers/input/serio/i8042.c: 8e <- i8042 (interrupt, kbd, 1) [33795]
drivers/input/serio/i8042.c: 0e <- i8042 (interrupt, kbd, 1) [33887]
drivers/input/serio/i8042.c: 8e <- i8042 (interrupt, kbd, 1) [33952]
drivers/input/serio/i8042.c: 0e <- i8042 (interrupt, kbd, 1) [34042]
drivers/input/serio/i8042.c: 8e <- i8042 (interrupt, kbd, 1) [34086]
drivers/input/serio/i8042.c: 2d <- i8042 (interrupt, kbd, 1) [35022]
drivers/input/serio/i8042.c: ad <- i8042 (interrupt, kbd, 1) [35246]
drivers/input/serio/i8042.c: 14 <- i8042 (interrupt, kbd, 1) [35286]
drivers/input/serio/i8042.c: 94 <- i8042 (interrupt, kbd, 1) [35351]
drivers/input/serio/i8042.c: 1c <- i8042 (interrupt, kbd, 1) [35995]
On Thu, 18 Mar 2004, Peter Williams wrote:
> Fr?d?ric L. W. Meunier wrote:
> > Wrongly ?
>
> Yes, wrongly. XFree86 wasn't even running when the messages appeared so
> there's no way that it could be to blame. Also no keys had been pressed
> or released.
I have a machine here I see that message on before the init scripts even
load.
Gerhard
--
Gerhard Mack
[email protected]
<>< As a computer I find your faith in technology amusing.
On Fri, Mar 19, 2004 at 12:37:37PM -0500, Gerhard Mack wrote:
> On Thu, 18 Mar 2004, Peter Williams wrote:
>
> > Fr?d?ric L. W. Meunier wrote:
> > > Wrongly ?
> >
> > Yes, wrongly. XFree86 wasn't even running when the messages appeared so
> > there's no way that it could be to blame. Also no keys had been pressed
> > or released.
>
> I have a machine here I see that message on before the init scripts even
> load.
Quick question: Does it go away if you compile USB support into the
kernel statically?
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Fri, 19 Mar 2004, Vojtech Pavlik wrote:
> Date: Fri, 19 Mar 2004 20:03:55 +0100
> From: Vojtech Pavlik <[email protected]>
> To: Gerhard Mack <[email protected]>
> Cc: Peter Williams <[email protected]>,
> "[iso-8859-1] \"Fr?d?ric L. W. Meunier\"" <[email protected]>,
> [email protected]
> Subject: Re: XFree86 seems to be being wrongly accused of doing the wrong
> thing
>
> On Fri, Mar 19, 2004 at 12:37:37PM -0500, Gerhard Mack wrote:
> > On Thu, 18 Mar 2004, Peter Williams wrote:
> >
> > > Fr?d?ric L. W. Meunier wrote:
> > > > Wrongly ?
> > >
> > > Yes, wrongly. XFree86 wasn't even running when the messages appeared so
> > > there's no way that it could be to blame. Also no keys had been pressed
> > > or released.
> >
> > I have a machine here I see that message on before the init scripts even
> > load.
>
> Quick question: Does it go away if you compile USB support into the
> kernel statically?
>
I have USB compiled in and it's still there. I should also note that the
keyboard is plugged into the ps/2 port.
The mouse on the other hand is plugged into the USB port.
Gerhard
--
Gerhard Mack
[email protected]
<>< As a computer I find your faith in technology amusing.
On Fri, Mar 19, 2004 at 02:26:05PM -0500, Gerhard Mack wrote:
> On Fri, 19 Mar 2004, Vojtech Pavlik wrote:
>
> > Date: Fri, 19 Mar 2004 20:03:55 +0100
> > From: Vojtech Pavlik <[email protected]>
> > To: Gerhard Mack <[email protected]>
> > Cc: Peter Williams <[email protected]>,
> > "[iso-8859-1] \"Fr?d?ric L. W. Meunier\"" <[email protected]>,
> > [email protected]
> > Subject: Re: XFree86 seems to be being wrongly accused of doing the wrong
> > thing
> >
> > On Fri, Mar 19, 2004 at 12:37:37PM -0500, Gerhard Mack wrote:
> > > On Thu, 18 Mar 2004, Peter Williams wrote:
> > >
> > > > Fr?d?ric L. W. Meunier wrote:
> > > > > Wrongly ?
> > > >
> > > > Yes, wrongly. XFree86 wasn't even running when the messages appeared so
> > > > there's no way that it could be to blame. Also no keys had been pressed
> > > > or released.
> > >
> > > I have a machine here I see that message on before the init scripts even
> > > load.
> >
> > Quick question: Does it go away if you compile USB support into the
> > kernel statically?
> >
>
> I have USB compiled in and it's still there. I should also note that the
> keyboard is plugged into the ps/2 port.
Yes, if you had the keyboard in USB, then i8042 wouldn't need to be used
at all.
> The mouse on the other hand is plugged into the USB port.
--
Vojtech Pavlik
SuSE Labs, SuSE CR