Hi,
my AT keyboard is dead on 2.6 series. Tests on other machines proves
that this is my-hardware-specyfic problem (exacly the same binnary works
on different mainboards with PS/2 keyboard and another AT keyboard). 2.4
series works correctly. On 2.6 kernel seems to not hear what keyboard
wants to tell him (eg. atkbd.reset preforms keyboard reset but reports
error). Were any hadrware-handling changes made since 2.4? If so, how to
undo them and make keyboard alive? I'm grateful for any help.
---
May the Source be with you.
Wiktor
On Fri, 21 Jan 2005 16:27:53 +0100, Wiktor <[email protected]> wrote:
> Hi,
>
> my AT keyboard is dead on 2.6 series. Tests on other machines proves
> that this is my-hardware-specyfic problem (exacly the same binnary works
> on different mainboards with PS/2 keyboard and another AT keyboard). 2.4
> series works correctly. On 2.6 kernel seems to not hear what keyboard
> wants to tell him (eg. atkbd.reset preforms keyboard reset but reports
> error). Were any hadrware-handling changes made since 2.4? If so, how to
> undo them and make keyboard alive? I'm grateful for any help.
>
Hi,
What kernel version are you using? Have you tried 2.6.8.1? - it looks
like changes in 2.6.9-rc2-bk3 caused problems on some hardware.
--
Dmitry
Dmitry Torokhov wrote:
> Hi,
>
> What kernel version are you using? Have you tried 2.6.8.1? - it looks
> like changes in 2.6.9-rc2-bk3 caused problems on some hardware.
>
Hi,
it looks like 2.6.10 (which I was using) - serio ports are detected ok
(both on 0x60,0x64, keyboard irq 1, aux irq 12), keyboard also (AT
Keyboard Translated Set 2 on isa0060/serio) and nothing - while
detection NumLock (set by BIOS) is turned off and keyboard is dead.
Maybe someone would be so kind and compare keyboard driver
hadrware-level parts and (possibly) post patch reversing any changes
since 2.4? Any other ideas?
(I use the newest gcc-3.3 if it matters.)
On Fri, 21 Jan 2005 20:07:51 +0100, Wiktor <[email protected]> wrote:
> Dmitry Torokhov wrote:
> > Hi,
> >
> > What kernel version are you using? Have you tried 2.6.8.1? - it looks
> > like changes in 2.6.9-rc2-bk3 caused problems on some hardware.
> >
>
> Hi,
>
> it looks like 2.6.10 (which I was using) - serio ports are detected ok
> (both on 0x60,0x64, keyboard irq 1, aux irq 12), keyboard also (AT
> Keyboard Translated Set 2 on isa0060/serio) and nothing - while
> detection NumLock (set by BIOS) is turned off and keyboard is dead.
> Maybe someone would be so kind and compare keyboard driver
> hadrware-level parts and (possibly) post patch reversing any changes
> since 2.4?
Ahem, that would be the one wiping out entire input system...
> Any other ideas?
1. Try compiling psmouse as a module and not load it until keyboard
driver (atkbd) is loaded.
2. Try kernel 2.6.8.1 - it looks like changes in 2.6.9-rc2-bk3 are
causing trouble on some systems but I can't figure out the reason.
Also, if you change undef DEBUG to #define DEBUG in
drivers/input/serio/i8042.c, reboot with log_buf_size=131072 and send
me the full dmesg or kernel log I'd appreciate it.
Thanks!
--
Dmitry
Hi,
here you are gzip-ed dmesg from booting 2.6.8.1 - i've been playing
keyboard while booting, maybe interrupt reports will help you. also my
.config part follows:
CONFIG_INPUT=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
no modules or other built-ins. maybe it is some simple way to fall back
to old handling mechanism? in my system most of programs (i mean
x-server) uses hardware directly (what means uses /dev/ttyS0 as mouse
device). i'm grateful for any help.
---
May the Source be with you.
Witkor
On Fri, Jan 21, 2005 at 04:27:53PM +0100, Wiktor wrote:
> Hi,
>
> my AT keyboard is dead on 2.6 series. Tests on other machines proves
> that this is my-hardware-specyfic problem (exacly the same binnary works
> on different mainboards with PS/2 keyboard and another AT keyboard). 2.4
> series works correctly. On 2.6 kernel seems to not hear what keyboard
> wants to tell him (eg. atkbd.reset preforms keyboard reset but reports
> error). Were any hadrware-handling changes made since 2.4? If so, how to
> undo them and make keyboard alive? I'm grateful for any help.
Please try i8042.noaux=1. You say you're using a serial mouse in your
other e-mail, so the system may not have an AUX port yet the kernel
thinks it does. This may cause the keyboard to stop responding.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Tue, Jan 25, 2005 at 08:37:34PM +0100, Wiktor wrote:
> Hi,
>
> here you are gzip-ed dmesg from booting 2.6.8.1 - i've been playing
> keyboard while booting, maybe interrupt reports will help you. also my
> .config part follows:
> CONFIG_INPUT=y
> CONFIG_INPUT_MOUSEDEV=y
> CONFIG_SOUND_GAMEPORT=y
> CONFIG_SERIO=y
> CONFIG_SERIO_I8042=y
> CONFIG_INPUT_KEYBOARD=y
> CONFIG_KEYBOARD_ATKBD=y
> no modules or other built-ins. maybe it is some simple way to fall back
> to old handling mechanism? in my system most of programs (i mean
> x-server) uses hardware directly (what means uses /dev/ttyS0 as mouse
> device). i'm grateful for any help.
This dmesg looks like the keyboard works perfectly OK. Do new lines
appear in dmesg when you press keys while the system is running?
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Fri, 28 Jan 2005 15:31:21 +0100, Vojtech Pavlik <[email protected]> wrote:
> On Tue, Jan 25, 2005 at 08:37:34PM +0100, Wiktor wrote:
> > Hi,
> >
> > here you are gzip-ed dmesg from booting 2.6.8.1 - i've been playing
> > keyboard while booting, maybe interrupt reports will help you. also my
> > .config part follows:
> > CONFIG_INPUT=y
> > CONFIG_INPUT_MOUSEDEV=y
> > CONFIG_SOUND_GAMEPORT=y
> > CONFIG_SERIO=y
> > CONFIG_SERIO_I8042=y
> > CONFIG_INPUT_KEYBOARD=y
> > CONFIG_KEYBOARD_ATKBD=y
> > no modules or other built-ins. maybe it is some simple way to fall back
> > to old handling mechanism? in my system most of programs (i mean
> > x-server) uses hardware directly (what means uses /dev/ttyS0 as mouse
> > device). i'm grateful for any help.
>
> This dmesg looks like the keyboard works perfectly OK. Do new lines
> appear in dmesg when you press keys while the system is running?
>
It does no report any IDs but ACKs GETID command. Not very nice...
--
Dmitry
Vojtech Pavlik wrote:
> On Fri, Jan 21, 2005 at 04:27:53PM +0100, Wiktor wrote:
>
>>Hi,
>>
>>my AT keyboard is dead on 2.6 series. Tests on other machines proves
>>that this is my-hardware-specyfic problem (exacly the same binnary works
>>on different mainboards with PS/2 keyboard and another AT keyboard). 2.4
>>series works correctly. On 2.6 kernel seems to not hear what keyboard
>>wants to tell him (eg. atkbd.reset preforms keyboard reset but reports
>>error). Were any hadrware-handling changes made since 2.4? If so, how to
>>undo them and make keyboard alive? I'm grateful for any help.
>
> Please try i8042.noaux=1. You say you're using a serial mouse in your
> other e-mail, so the system may not have an AUX port yet the kernel
> thinks it does. This may cause the keyboard to stop responding.
fyi, there is a thread going on on linuxppc-dev regarding a similiar
looking issue:
http://ozlabs.org/pipermail/linuxppc-dev/2005-January/018321.html
someone suggested booting with atkbd.reset=0, maybe the problems are
somehow related? what exact kernel version are you using, Wiktor?
Christian.
--
BOFH excuse #20:
divide-by-zero error
Hi,
>This dmesg looks like the keyboard works perfectly OK. Do new lines
>appear in dmesg when you press keys while the system is running?
eeeeeeee.....no? no, they don't. i've new dmesg for you - it reports
timeouts while trying to perform keyboard reset (by atkbd.reset=1).
after detection pressing any keys has absolutley no effect. maybe it's
some timeout-violation?
---
May the Source be with you.
wixor (it's my nick)
On Fri, 28 Jan 2005 20:22:32 +0100, Wiktor <[email protected]> wrote:
> Hi,
>
> >This dmesg looks like the keyboard works perfectly OK. Do new lines
> >appear in dmesg when you press keys while the system is running?
>
> eeeeeeee.....no? no, they don't. i've new dmesg for you - it reports
> timeouts while trying to perform keyboard reset (by atkbd.reset=1).
> after detection pressing any keys has absolutley no effect. maybe it's
> some timeout-violation?
>
Could you please try editing drivers/input/serio/i8042.c and add
udelay(20) before and after calls to i8042_write_data() in
i8042_kbd_write() and i8042_command().
--
Dmitry
Hi, IT WORKED!
> Please try i8042.noaux=1. You say you're using a serial mouse in your
> other e-mail, so the system may not have an AUX port yet the kernel
> thinks it does. This may cause the keyboard to stop responding.
command line "linux-new init=/bin/bash i8042.noaux=1 atkbd.reset=1"
booted 2.6.8.1 kernel with working keyboard. reset succeded. If AUX port
is what not-keen-on-hardware people call PS/2 port, the problem is
solved. my mainboard has damaged PS/2 port - it is detected but it does
NOT work. Thanks for paying attention.
---
May the Source be with you.
wixor (it's my nick)
Hi,
> Could you please try editing drivers/input/serio/i8042.c and add
> udelay(20) before and after calls to i8042_write_data() in
> i8042_kbd_write() and i8042_command().
of course i could, will it make kernel not detect smoked AUX port?
(problem is solved by i8042.noaux=1 cause my hardware has smoked PS/2
port) i would rather think about testing devices before assuming thet
work and trying to use them (maybe not as standard kernel feature, but
it would be nice stuff for people with self-built machines where not
everything works). Thanks for your help
---
May the Source be with you.
wixor
On Fri, 28 Jan 2005 20:49:03 +0100, Wiktor <[email protected]> wrote:
> Hi,
>
> > Could you please try editing drivers/input/serio/i8042.c and add
> > udelay(20) before and after calls to i8042_write_data() in
> > i8042_kbd_write() and i8042_command().
>
> of course i could, will it make kernel not detect smoked AUX port?
> (problem is solved by i8042.noaux=1 cause my hardware has smoked PS/2
> port) i would rather think about testing devices before assuming thet
> work and trying to use them (maybe not as standard kernel feature, but
> it would be nice stuff for people with self-built machines where not
> everything works).
We do test AUX port and your port appears to be perfectly functional
from the kernel point of view - it porperly responds to AUX_LOOP
commands, does not claim to support MUX mode and KBC properly sets
status register when asked to disable interface...
--
Dmitry
Hi,
> We do test AUX port and your port appears to be perfectly functional
> from the kernel point of view - it porperly responds to AUX_LOOP
> commands, does not claim to support MUX mode and KBC properly sets
> status register when asked to disable interface...
ok, but how AUX block KBD port? if procesor-interface works, it
shouldn't disturb communication in any way! how it is possible that
tests do not detect broken down port? if kernel enables it in some way
(when disabling port from command line, KBD works ok), it should be
detected that AUX does not work correctly and lock it somehow? can it be
etermined by analyzing data flow? or maybe tests are not enought good,
maybe some corelations when using both KBD and AUX exist and are not
tested? as my keyboard works now, i'm not keen on solving this, but to
make the world better and dominate it, some "runtime hardware failures
handling" could be added.
--
May the Source be with you.
wixor
On Fri, Jan 28, 2005 at 08:49:03PM +0100, Wiktor wrote:
> Hi,
>
> >Could you please try editing drivers/input/serio/i8042.c and add
> >udelay(20) before and after calls to i8042_write_data() in
> >i8042_kbd_write() and i8042_command().
>
> of course i could, will it make kernel not detect smoked AUX port?
> (problem is solved by i8042.noaux=1 cause my hardware has smoked PS/2
> port) i would rather think about testing devices before assuming thet
> work and trying to use them (maybe not as standard kernel feature, but
> it would be nice stuff for people with self-built machines where not
> everything works). Thanks for your help
Well, the kernel tests the AUX port and it seemed OK, that's the
problem. Unfortunately it's not always possible to detect whether
there's a problem with some device.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Fri, Jan 28, 2005 at 08:22:32PM +0100, Wiktor wrote:
> Hi,
>
> >This dmesg looks like the keyboard works perfectly OK. Do new lines
> >appear in dmesg when you press keys while the system is running?
>
> eeeeeeee.....no? no, they don't. i've new dmesg for you - it reports
> timeouts while trying to perform keyboard reset (by atkbd.reset=1).
> after detection pressing any keys has absolutley no effect. maybe it's
> some timeout-violation?
It still looks OK. It seems to be a very ancient keyboard. Can you try with
a newer one? That'd tell us whether it's the controller or the keyboard
that is giving problems.
What keyboard model is it? What machine?
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Fri, Jan 28, 2005 at 02:27:20PM -0500, Dmitry Torokhov wrote:
> On Fri, 28 Jan 2005 20:22:32 +0100, Wiktor <[email protected]> wrote:
> > Hi,
> >
> > >This dmesg looks like the keyboard works perfectly OK. Do new lines
> > >appear in dmesg when you press keys while the system is running?
> >
> > eeeeeeee.....no? no, they don't. i've new dmesg for you - it reports
> > timeouts while trying to perform keyboard reset (by atkbd.reset=1).
> > after detection pressing any keys has absolutley no effect. maybe it's
> > some timeout-violation?
> >
>
> Could you please try editing drivers/input/serio/i8042.c and add
> udelay(20) before and after calls to i8042_write_data() in
> i8042_kbd_write() and i8042_command().
Uh? What that'd help? All the communication proceeds OK, up to proper
registration of the input device, but the keyboard seems to stay in a
'disabled' state. The keyboard, not the controller, because if it were
the controller, atkbd.c wouldn't get the 'fa' responses back via
functioning interrupts.
Wiktor, can you try atkbd.dumbkbd=1?
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Fri, Jan 28, 2005 at 09:22:20PM +0100, Wiktor wrote:
> Hi,
>
> >We do test AUX port and your port appears to be perfectly functional
> >from the kernel point of view - it porperly responds to AUX_LOOP
> >commands, does not claim to support MUX mode and KBC properly sets
> >status register when asked to disable interface...
>
> ok, but how AUX block KBD port? if procesor-interface works, it
> shouldn't disturb communication in any way!
The AUX and KBD ports share the same processor interface. If the AUX
port is enabled, and somehow keeps the interface for itself, then the
keyboard wouldn't work.
For some reason, however, the keyboard is recognized, which means it
_can_ communicate with the kernel. I don't understand why it doesn't, at
the moment.
> how it is possible that
> tests do not detect broken down port?
The kernel issues the AUX_TEST command, which instructs the port
controller to test whether the port is OK. And the controller returns
with "Yes, it is."
> if kernel enables it in some way
> (when disabling port from command line, KBD works ok), it should be
> detected that AUX does not work correctly and lock it somehow?
Remember, it's the keyboard that doesn't work in that case. How the
kernel should know the AUX port is the cause, and how it should discern
that from the user not typing?
> can it be
> etermined by analyzing data flow?
No.
> or maybe tests are not enought good,
> maybe some corelations when using both KBD and AUX exist and are not
> tested? as my keyboard works now, i'm not keen on solving this, but to
> make the world better and dominate it, some "runtime hardware failures
> handling" could be added.
We're pretty happy when it works on functional hardware at the moment.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Fri, Jan 28, 2005 at 09:46:41AM -0500, Dmitry Torokhov wrote:
> On Fri, 28 Jan 2005 15:31:21 +0100, Vojtech Pavlik <[email protected]> wrote:
> > On Tue, Jan 25, 2005 at 08:37:34PM +0100, Wiktor wrote:
> > > Hi,
> > >
> > > here you are gzip-ed dmesg from booting 2.6.8.1 - i've been playing
> > > keyboard while booting, maybe interrupt reports will help you. also my
> > > .config part follows:
> > > CONFIG_INPUT=y
> > > CONFIG_INPUT_MOUSEDEV=y
> > > CONFIG_SOUND_GAMEPORT=y
> > > CONFIG_SERIO=y
> > > CONFIG_SERIO_I8042=y
> > > CONFIG_INPUT_KEYBOARD=y
> > > CONFIG_KEYBOARD_ATKBD=y
> > > no modules or other built-ins. maybe it is some simple way to fall back
> > > to old handling mechanism? in my system most of programs (i mean
> > > x-server) uses hardware directly (what means uses /dev/ttyS0 as mouse
> > > device). i'm grateful for any help.
> >
> > This dmesg looks like the keyboard works perfectly OK. Do new lines
> > appear in dmesg when you press keys while the system is running?
> >
>
> It does no report any IDs but ACKs GETID command. Not very nice...
Very old AT keyboards can do that.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Fri, Jan 28, 2005 at 08:39:42PM +0100, Wiktor wrote:
> Hi, IT WORKED!
>
> >Please try i8042.noaux=1. You say you're using a serial mouse in your
> >other e-mail, so the system may not have an AUX port yet the kernel
> >thinks it does. This may cause the keyboard to stop responding.
>
> command line "linux-new init=/bin/bash i8042.noaux=1 atkbd.reset=1"
> booted 2.6.8.1 kernel with working keyboard. reset succeded. If AUX port
> is what not-keen-on-hardware people call PS/2 port, the problem is
> solved. my mainboard has damaged PS/2 port - it is detected but it does
> NOT work. Thanks for paying attention.
Yes, the AUX port and PS/2 mouse port are two names for the same thing.
Do you still need atkbd.reset=1?
--
Vojtech Pavlik
SuSE Labs, SuSE CR
> It still looks OK. It seems to be a very ancient keyboard. Can you try with
> a newer one? That'd tell us whether it's the controller or the keyboard
> that is giving problems.
>
> What keyboard model is it? What machine?
>
Machine info attached as a part of /dev/proc. i've tried with another AT
keyboard and PS/2 keyboard attached via connector - results were the
same. keyboard i'm using is: chicony model KB-5911 serial 6A00152705.
what does it mean 'ancient'? mine keyb has about 10 years. is it ancient
or not (it is the first keyboard i've been using)?
--
May the Source be with you.
wixor
>
> Wiktor, can you try atkbd.dumbkbd=1?
>
Here you are full dmesg (see attachment). i've been typing alphabet
after kernel boot.
> Do you still need atkbd.reset=1?
No, i don't. i've just tried it, because when keyboard was not working,
the only error report was produced by this option.