Hi all,
This is a strange one. My laptop, a Dell Inspiron 6400 (UK model
MM061) has a BIOS option to set system password that is required on
boot/reboot/and on waking up from suspend to RAM (sleep).
This works fine, but after I enter my password during resume, I find
my keyboard has gone AWOL (no keys mapped, all keys auto repeat etc.)
and shortly mouse buttons die too... so all I can do now is hit the
power off button!
log/messages spews out lots of this stuff:
Nov 14 11:36:36 palantir kernel: [10330.783152] atkbd.c: Unknown key pressed (raw set 2, code 0x28 on isa0060/serio0).
Nov 14 11:36:36 palantir kernel: [10330.783164] atkbd.c: Use 'setkeycodes 28 <keycode>' to make it known.
Nov 14 11:36:37 palantir kernel: [10330.855664] atkbd.c: Unknown key pressed (raw set 2, code 0x128 on isa0060/serio0).
Nov 14 11:36:37 palantir kernel: [10330.855676] atkbd.c: Use 'setkeycodes 28 <keycode>' to make it known
I have invested this, and one difference I notice in log/messages
during resume activity is this:
WITHOUT system password required:
input: AT Translated Set 2 keyboard
as /devices/platform/i8042/serio0/input/input1
WITH system password required:
input: AT Raw Set 2 keyboard as /devices/platform/i8042/serio16/input/input45
Now, investigating further, I have found that I can replicate this whole issue with this script:
#!/bin/sh
echo -n "i8042" > /sys/bus/platform/drivers/i8042/unbind
sleep 5;
echo -n "i8042" > /sys/bus/platform/drivers/i8042/bind
if I hit a key during the sleep stage, the keyboard et al all goes AWOL again.
So, I am presuming here that when my laptop gets woken up, the BIOS system password screen comes, and the /etc/acpi/resume.d/ scripts are being held in stasis until I enter the password. BUT, I have then used the keyboard before i8042 is echoed to 'bind', and this causes the issue. Without the system password set, the scipts perhaps run fast enough before I can hit the keyboard in this keyboard state.
One reference I found with similar problem:
http://kerneltrap.org/mailarchive/linux-kernel/2008/5/13/1805874
Thanks,
Nick
--
Free Software Foundation Associate Member 5508
On Fri, 14 Nov 2008 12:30:58 +0000
Nick Warne <[email protected]> wrote:
> Hi all,
>
> This is a strange one. My laptop, a Dell Inspiron 6400 (UK model
> MM061) has a BIOS option to set system password that is required on
> boot/reboot/and on waking up from suspend to RAM (sleep).
>
> This works fine, but after I enter my password during resume, I find
> my keyboard has gone AWOL (no keys mapped, all keys auto repeat etc.)
> and shortly mouse buttons die too... so all I can do now is hit the
> power off button!
>
> log/messages spews out lots of this stuff:
> Nov 14 11:36:36 palantir kernel: [10330.783152] atkbd.c: Unknown key
> pressed (raw set 2, code 0x28 on isa0060/serio0). Nov 14 11:36:36
> palantir kernel: [10330.783164] atkbd.c: Use 'setkeycodes 28
> <keycode>' to make it known. Nov 14 11:36:37 palantir kernel:
> [10330.855664] atkbd.c: Unknown key pressed (raw set 2, code 0x128 on
> isa0060/serio0). Nov 14 11:36:37 palantir kernel: [10330.855676]
> atkbd.c: Use 'setkeycodes 28 <keycode>' to make it known
>
> I have invested this, and one difference I notice in log/messages
> during resume activity is this:
>
> WITHOUT system password required:
> input: AT Translated Set 2 keyboard
> as /devices/platform/i8042/serio0/input/input1
>
> WITH system password required:
> input: AT Raw Set 2 keyboard
> as /devices/platform/i8042/serio16/input/input45
>
> Now, investigating further, I have found that I can replicate this
> whole issue with this script:
>
> #!/bin/sh
> echo -n "i8042" > /sys/bus/platform/drivers/i8042/unbind
> sleep 5;
> echo -n "i8042" > /sys/bus/platform/drivers/i8042/bind
>
> if I hit a key during the sleep stage, the keyboard et al all goes
> AWOL again.
>
> So, I am presuming here that when my laptop gets woken up, the BIOS
> system password screen comes, and the /etc/acpi/resume.d/ scripts are
> being held in stasis until I enter the password. BUT, I have then
> used the keyboard before i8042 is echoed to 'bind', and this causes
> the issue. Without the system password set, the scipts perhaps run
> fast enough before I can hit the keyboard in this keyboard state.
>
> One reference I found with similar problem:
>
> http://kerneltrap.org/mailarchive/linux-kernel/2008/5/13/1805874
Forgot!
I am running Ubuntu 8.10 base, with hand built 2.6.27.5 kernel.
BTW, this issue also happens in plain console with no X running.
> Thanks,
>
> Nick
>
--
Free Software Foundation Associate Member 5508
On Fri, 14 Nov 2008 12:38:40 +0000
Nick Warne <[email protected]> wrote:
> On Fri, 14 Nov 2008 12:30:58 +0000
> Nick Warne <[email protected]> wrote:
>
> > Hi all,
> >
> > This is a strange one. My laptop, a Dell Inspiron 6400 (UK model
> > MM061) has a BIOS option to set system password that is required on
> > boot/reboot/and on waking up from suspend to RAM (sleep).
> >
> > This works fine, but after I enter my password during resume, I find
> > my keyboard has gone AWOL (no keys mapped, all keys auto repeat
> > etc.) and shortly mouse buttons die too... so all I can do now is
> > hit the power off button!
> >
> > log/messages spews out lots of this stuff:
> > Nov 14 11:36:36 palantir kernel: [10330.783152] atkbd.c: Unknown key
> > pressed (raw set 2, code 0x28 on isa0060/serio0). Nov 14 11:36:36
> > palantir kernel: [10330.783164] atkbd.c: Use 'setkeycodes 28
> > <keycode>' to make it known. Nov 14 11:36:37 palantir kernel:
> > [10330.855664] atkbd.c: Unknown key pressed (raw set 2, code 0x128
> > on isa0060/serio0). Nov 14 11:36:37 palantir kernel: [10330.855676]
> > atkbd.c: Use 'setkeycodes 28 <keycode>' to make it known
> >
> > I have invested this, and one difference I notice in log/messages
> > during resume activity is this:
> >
> > WITHOUT system password required:
> > input: AT Translated Set 2 keyboard
> > as /devices/platform/i8042/serio0/input/input1
> >
> > WITH system password required:
> > input: AT Raw Set 2 keyboard
> > as /devices/platform/i8042/serio16/input/input45
> >
> > Now, investigating further, I have found that I can replicate this
> > whole issue with this script:
> >
> > #!/bin/sh
> > echo -n "i8042" > /sys/bus/platform/drivers/i8042/unbind
> > sleep 5;
> > echo -n "i8042" > /sys/bus/platform/drivers/i8042/bind
> >
> > if I hit a key during the sleep stage, the keyboard et al all goes
> > AWOL again.
> >
> > So, I am presuming here that when my laptop gets woken up, the BIOS
> > system password screen comes, and the /etc/acpi/resume.d/ scripts
> > are being held in stasis until I enter the password. BUT, I have
> > then used the keyboard before i8042 is echoed to 'bind', and this
> > causes the issue. Without the system password set, the scipts
> > perhaps run fast enough before I can hit the keyboard in this
> > keyboard state.
> >
> > One reference I found with similar problem:
> >
> > http://kerneltrap.org/mailarchive/linux-kernel/2008/5/13/1805874
>
> Forgot!
>
> I am running Ubuntu 8.10 base, with hand built 2.6.27.5 kernel.
>
> BTW, this issue also happens in plain console with no X running.
>
OK, also found this all works great if I remove the
/etc/acpi/suspend.s/20-i8042-input.sh
/etc/acpi/resume.d/40-i8042-input.sh
scripts (i.e. no 'echoes of i8042 to unbind/bind). Keyboard seems to
still be dead when asleep also :-)
Nick
--
Free Software Foundation Associate Member 5508
On Fri, Nov 14, 2008 at 12:30:58PM +0000, Nick Warne wrote:
> Now, investigating further, I have found that I can replicate this whole issue with this script:
>
> #!/bin/sh
> echo -n "i8042" > /sys/bus/platform/drivers/i8042/unbind
> sleep 5;
> echo -n "i8042" > /sys/bus/platform/drivers/i8042/bind
>
> if I hit a key during the sleep stage, the keyboard et al all goes AWOL again.
>
> So, I am presuming here that when my laptop gets woken up, the BIOS system password screen comes, and the /etc/acpi/resume.d/ scripts are being held in stasis until I enter the password. BUT, I have then used the keyboard before i8042 is echoed to 'bind', and this causes the issue. Without the system password set, the scipts perhaps run fast enough before I can hit the keyboard in this keyboard state.
Why are you binding/unbinding the keyboard? That destroys the kernel
state about the mode the keyboard is in, and when the BIOS programs your
keyboard into RAW mode for the BIOS password the kernel will assume that
it should be treating it in raw mode on replug.
--
Matthew Garrett | [email protected]
On Fri, 14 Nov 2008 15:18:49 +0000
Matthew Garrett <[email protected]> wrote:
> On Fri, Nov 14, 2008 at 12:30:58PM +0000, Nick Warne wrote:
> > Now, investigating further, I have found that I can replicate this
> > whole issue with this script:
> >
> > #!/bin/sh
> > echo -n "i8042" > /sys/bus/platform/drivers/i8042/unbind
> > sleep 5;
> > echo -n "i8042" > /sys/bus/platform/drivers/i8042/bind
> >
> > if I hit a key during the sleep stage, the keyboard et al all goes
> > AWOL again.
> >
> > So, I am presuming here that when my laptop gets woken up, the BIOS
> > system password screen comes, and the /etc/acpi/resume.d/ scripts
> > are being held in stasis until I enter the password. BUT, I have
> > then used the keyboard before i8042 is echoed to 'bind', and this
> > causes the issue. Without the system password set, the scipts
> > perhaps run fast enough before I can hit the keyboard in this
> > keyboard state.
>
> Why are you binding/unbinding the keyboard? That destroys the kernel
> state about the mode the keyboard is in, and when the BIOS programs
> your keyboard into RAW mode for the BIOS password the kernel will
> assume that it should be treating it in raw mode on replug.
>
OK, I found out what is going on - this is a Ubuntu hack reference this
bug:
https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/23497
It appears default Ubuntu Gnome/KDE desktop power management render
some peoples keyboard useless after a resume, so the echo i8042 >
unbind/bind fixed it up for them.
As I do not use a desktop environment, just Fluxbox window manager, this
'hack' actually does the opposite and renders my keyboard useless. So,
just removing these scripts fixes it up, and everything all works
perfectly now.
Sorry for the noise.
Nick
--
Free Software Foundation Associate Member 5508