I have two systems, When I turn the system next to me on the machine thats
currently powered on spews out this each time, why is the magic key
(alt+sysrq h) being dumped?
They are both connected via serial.
SysRq : HELP : loglevel0-8 reBoot Dumpmsgs tErm kIll saK showMem powerOff
showPc unRaw Sync showTasks Unmount
SysRq : HELP : loglevel0-8 reBoot Dumpmsgs tErm kIll saK showMem powerOff
showPc unRaw Sync showTasks Unmount
SysRq : HELP : loglevel0-8 reBoot Dumpmsgs tErm kIll saK showMem powerOff
showPc unRaw Sync showTasks Unmount
SysRq : HELP : loglevel0-8 reBoot Dumpmsgs tErm kIll saK showMem powerOff
showPc unRaw Sync showTasks Unmount
SysRq : HELP : loglevel0-8 reBoot Dumpmsgs tErm kIll saK showMem powerOff
showPc unRaw Sync showTasks Unmount
SysRq : HELP : loglevel0-8 reBoot Dumpmsgs tErm kIll saK showMem powerOff
showPc unRaw Sync showTasks Unmount
SysRq : HELP : loglevel0-8 reBoot Dumpmsgs tErm kIll saK showMem powerOff
showPc unRaw Sync showTasks Unmount
I have run into race conditions with the two machines and serial
connectivity in the past (see previous emails on that).
What would be the best way to determine why my systems cause so much
problems wrt to serial connectivity?
Also, what is the best way to debug a kernel over serial when the system
on the other end is completely locked?
The other issue is:
Dec 8 17:56:45 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0xb8, on isa0060/serio0) pressed.
Dec 8 17:56:45 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
Feb 12 23:25:29 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0xae, on isa0060/serio0) pressed.
Feb 17 02:09:26 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0xb8, on isa0060/serio0) pressed.
Feb 20 23:06:04 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.Feb 22 01:45:55 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
Feb 24 18:33:37 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0xa0, on isa0060/serio0) pressed.
Feb 27 00:09:52 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
Mar 5 00:49:59 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0xb8, on isa0060/serio0) pressed.
Mar 5 00:49:59 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
..........................
Sep 1 23:38:58 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0xc0, on isa0060/serio0) pressed.
Sep 1 23:38:59 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
Sep 1 23:39:04 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0xc0, on isa0060/serio0) pressed.
Sep 1 23:39:35 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
Sep 10 20:25:57 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0xa0, on isa0060/serio0) pressed.
Sep 10 21:50:22 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
Sep 11 22:57:07 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
Sep 13 16:16:24 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0x9c, on isa0060/serio0) pressed.
I have a small 4 port KVM switch from Startech, Is this KVM causing
keyboard issues that the keyboard driver cannot interpret properly?
Why is this occuring so often? I can usually trigger this if I start using
certain key combinations.
What also happens is a key will get 'stuck' and then repeat itself until I
stop it from repeating the letter.
The keyboard is a Microsoft Internet keyboard PS/2 style plugged into the
KVM.
If you want me to catch any debug output let me know and I will do this.
Thanks,
Shawn S.
On Mon, Sep 15, 2003 at 02:12:21AM -0400, Shawn Starr wrote:
> I have two systems, When I turn the system next to me on the machine thats
> currently powered on spews out this each time, why is the magic key
> (alt+sysrq h) being dumped?
No doubt because that is what comes from your keyboard controller.
I do not think this is a Linux matter.
If you want to check, try 2.4 and see that the same happens.
> The other issue is:
>
> Dec 8 17:56:45: atkbd.c: Unknown key (set 2, scancode 0xb8, on isa0060/serio0) pressed.
> Dec 8 17:56:45: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> Feb 12 23:25:29: atkbd.c: Unknown key (set 2, scancode 0xae, on isa0060/serio0) pressed.
> Feb 17 02:09:26: atkbd.c: Unknown key (set 2, scancode 0xb8, on isa0060/serio0) pressed.
> Feb 20 23:06:04: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> Feb 22 01:45:55: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> Feb 24 18:33:37: atkbd.c: Unknown key (set 2, scancode 0xa0, on isa0060/serio0) pressed.
> Feb 27 00:09:52: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> Mar 5 00:49:59: atkbd.c: Unknown key (set 2, scancode 0xb8, on isa0060/serio0) pressed.
> Mar 5 00:49:59: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> ..........................
>
> Sep 1 23:38:58: atkbd.c: Unknown key (set 2, scancode 0xc0, on isa0060/serio0) pressed.
> Sep 1 23:38:59: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> Sep 1 23:39:04: atkbd.c: Unknown key (set 2, scancode 0xc0, on isa0060/serio0) pressed.
> Sep 1 23:39:35: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> Sep 10 20:25:57: atkbd.c: Unknown key (set 2, scancode 0xa0, on isa0060/serio0) pressed.
> Sep 10 21:50:22: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> Sep 11 22:57:07: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> Sep 13 16:16:24: atkbd.c: Unknown key (set 2, scancode 0x9c, on isa0060/serio0) pressed.
These are key up sequences for keys that the kernel did not think were down.
0xb8: LAlt up
0x9d: LCtrl up
0xae: C up
0xa0: D up
0xc0: F6 up
0x9c: Enter up
> I have a small 4 port KVM switch from Startech, Is this KVM causing
> keyboard issues that the keyboard driver cannot interpret properly?
Most KVMs emit some garbage at the moment of switching.
> Why is this occuring so often? I can usually trigger this if I start using
> certain key combinations.
>
> What also happens is a key will get 'stuck' and then repeat itself until I
> stop it from repeating the letter.
That is the opposite phenomenon: the kernel sees a key down but no key up.
> The keyboard is a Microsoft Internet keyboard PS/2 style plugged into the
> KVM.
I imagine that your problems, apart from the key repeat, are not Linux problems
but hardware problems.
Andries
Issue 1: magic key + h noise
I have determined that LILO on the remote box is feeding noise back to the
other machine while it's booted. When I commented the serial port in
inittab and init q'd. Shut the other machine down and brought it up. I saw
no such noise spewed out.
This is not a kernel issue.
As for the keyboard sticky issue other users are reporting this as well.
Shawn S.
On Wed, 17 Sep 2003, Michael Frank wrote:
> On powerup the ports may see breaks.
>
> Disable magic sysrq on the ports by which both machines connect ;)
>
> So, either use seperate ports or turn of magic sysrq - can alos do
> in proc fs.
>
> Regards
> Michael
>
> On Monday 15 September 2003 14:12, Shawn Starr wrote:
> > I have two systems, When I turn the system next to me on the machine thats
> > currently powered on spews out this each time, why is the magic key
> > (alt+sysrq h) being dumped?
> >
> > Also, what is the best way to debug a kernel over serial when the system
> > on the other end is completely locked?
>
> KGDB
>
> Alternatives KDB via keyboard or KGDB via ethernet
>
> >
> > The other issue is:
>
> Also interface problem but sorry, don't know how to fix
>
> Regards
> Michael
>
>
>
On Mon, Sep 15, 2003 at 02:12:21AM -0400, Shawn Starr wrote:
> I have two systems, When I turn the system next to me on the machine thats
> currently powered on spews out this each time, why is the magic key
> (alt+sysrq h) being dumped?
>
> They are both connected via serial.
on a serial line, a break is ALT-SYSRQ, maybe
some process is restarted and then outputs
some characters, including a 'h' ...
HTH,
Herbert
> SysRq : HELP : loglevel0-8 reBoot Dumpmsgs tErm kIll saK showMem powerOff
> showPc unRaw Sync showTasks Unmount
> SysRq : HELP : loglevel0-8 reBoot Dumpmsgs tErm kIll saK showMem powerOff
> showPc unRaw Sync showTasks Unmount
> SysRq : HELP : loglevel0-8 reBoot Dumpmsgs tErm kIll saK showMem powerOff
> showPc unRaw Sync showTasks Unmount
> SysRq : HELP : loglevel0-8 reBoot Dumpmsgs tErm kIll saK showMem powerOff
> showPc unRaw Sync showTasks Unmount
> SysRq : HELP : loglevel0-8 reBoot Dumpmsgs tErm kIll saK showMem powerOff
> showPc unRaw Sync showTasks Unmount
> SysRq : HELP : loglevel0-8 reBoot Dumpmsgs tErm kIll saK showMem powerOff
> showPc unRaw Sync showTasks Unmount
> SysRq : HELP : loglevel0-8 reBoot Dumpmsgs tErm kIll saK showMem powerOff
> showPc unRaw Sync showTasks Unmount
>
> I have run into race conditions with the two machines and serial
> connectivity in the past (see previous emails on that).
>
> What would be the best way to determine why my systems cause so much
> problems wrt to serial connectivity?
>
> Also, what is the best way to debug a kernel over serial when the system
> on the other end is completely locked?
>
> The other issue is:
>
> Dec 8 17:56:45 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0xb8, on isa0060/serio0) pressed.
> Dec 8 17:56:45 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> Feb 12 23:25:29 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0xae, on isa0060/serio0) pressed.
> Feb 17 02:09:26 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0xb8, on isa0060/serio0) pressed.
> Feb 20 23:06:04 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.Feb 22 01:45:55 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> Feb 24 18:33:37 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0xa0, on isa0060/serio0) pressed.
> Feb 27 00:09:52 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> Mar 5 00:49:59 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0xb8, on isa0060/serio0) pressed.
> Mar 5 00:49:59 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> ..........................
>
> Sep 1 23:38:58 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0xc0, on isa0060/serio0) pressed.
> Sep 1 23:38:59 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> Sep 1 23:39:04 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0xc0, on isa0060/serio0) pressed.
> Sep 1 23:39:35 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> Sep 10 20:25:57 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0xa0, on isa0060/serio0) pressed.
> Sep 10 21:50:22 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> Sep 11 22:57:07 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0x9d, on isa0060/serio0) pressed.
> Sep 13 16:16:24 coredump kernel: atkbd.c: Unknown key (set 2, scancode 0x9c, on isa0060/serio0) pressed.
>
> I have a small 4 port KVM switch from Startech, Is this KVM causing
> keyboard issues that the keyboard driver cannot interpret properly?
>
> Why is this occuring so often? I can usually trigger this if I start using
> certain key combinations.
>
> What also happens is a key will get 'stuck' and then repeat itself until I
> stop it from repeating the letter.
>
> The keyboard is a Microsoft Internet keyboard PS/2 style plugged into the
> KVM.
>
> If you want me to catch any debug output let me know and I will do this.
>
> Thanks,
>
> Shawn S.
>
> -
> 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/