Vojtech,
On October 17, I wrote to LKML:
>Dell Latitude CPi laptop. Boot 2.5.42 or .43, then reboot.
>Shortly after the screen is blanked and the BIOS starts, it
>prints a "keyboard error" message and requests an F1 or F2
>response (continue or go into SETUP). Never happened with any
>other kernel on that machine.
(see http://marc.theaimsgroup.com/?t=103484432100001&r=1&w=2
for the full thread)
This problem is still present in 2.5.58. Any ideas what might
be causing it? I've tried a few obvious tweaks (forcing
atkbd_reset=1, making atkbd_cleanup() do nothing), but none
has helped.
Kernel 2.5.41 and older, and current 2.4/2.2 kernels, don't
cause this problem, so obviously the input driver must be doing
_something_ the HW or BIOS doesn't like.
I have CONFIG_{SERIO_I8042,KEYBOARD_ATKBD,INPUT_MOUSEDEV_PSAUX,
MOUSE_PS2,INPUT_PCSKR} enabled.
/Mikael
Possibly related:
Dell Inspiron 8000s won't warm reboot either. They just freeze with a
blinking cursor at the point where the bootloader would ordinarily load.
Have to power off or reset.
Consistent in various versions from 2.5.44 to .55. Have not tested
earlier, nor yet later.
Andrew
--On Wednesday, January 15, 2003 11:22:05 +0100 Mikael Pettersson
<[email protected]> wrote:
> Vojtech,
>
> On October 17, I wrote to LKML:
>> Dell Latitude CPi laptop. Boot 2.5.42 or .43, then reboot.
>> Shortly after the screen is blanked and the BIOS starts, it
>> prints a "keyboard error" message and requests an F1 or F2
>> response (continue or go into SETUP). Never happened with any
>> other kernel on that machine.
>
> (see http://marc.theaimsgroup.com/?t=103484432100001&r=1&w=2
> for the full thread)
>
> This problem is still present in 2.5.58. Any ideas what might
> be causing it? I've tried a few obvious tweaks (forcing
> atkbd_reset=1, making atkbd_cleanup() do nothing), but none
> has helped.
>
> Kernel 2.5.41 and older, and current 2.4/2.2 kernels, don't
> cause this problem, so obviously the input driver must be doing
> _something_ the HW or BIOS doesn't like.
>
> I have CONFIG_{SERIO_I8042,KEYBOARD_ATKBD,INPUT_MOUSEDEV_PSAUX,
> MOUSE_PS2,INPUT_PCSKR} enabled.
>
> /Mikael
> -
> 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/
>
>
On Wed, 15 Jan 2003 23:43:58 +1300, Andrew McGregor said:
> Possibly related:
>
> Dell Inspiron 8000s won't warm reboot either. They just freeze with a
> blinking cursor at the point where the bootloader would ordinarily load.
> Have to power off or reset.
>
> Consistent in various versions from 2.5.44 to .55. Have not tested
> earlier, nor yet later.
Dell Latitude C840s will power off. Oddly enough, it doesn't do it when
LILO itself loads - it does it when LILO starts loading the actual kernel
image. True from 2.5.46 through 2.5.58.
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
The i8k will power off with APM but not ACPI, but it won't reboot with
either.
I'm using grub, so it may hit the problem before outputting anything where
lilo may not.
Andrew
--On Wednesday, January 15, 2003 14:21:57 -0500 [email protected]
wrote:
> On Wed, 15 Jan 2003 23:43:58 +1300, Andrew McGregor said:
>> Possibly related:
>>
>> Dell Inspiron 8000s won't warm reboot either. They just freeze with a
>> blinking cursor at the point where the bootloader would ordinarily load.
>> Have to power off or reset.
>>
>> Consistent in various versions from 2.5.44 to .55. Have not tested
>> earlier, nor yet later.
>
> Dell Latitude C840s will power off. Oddly enough, it doesn't do it when
> LILO itself loads - it does it when LILO starts loading the actual kernel
> image. True from 2.5.46 through 2.5.58.
> --
> Valdis Kletnieks
> Computer Systems Senior Engineer
> Virginia Tech
>
Andrew McGregor wrote:
> The i8k will power off with APM but not ACPI, but it won't reboot with
> either.
>
> I'm using grub, so it may hit the problem before outputting anything
> where lilo may not.
[Fixed CC: to Vojtech]
CPx750J powers off with grub/APM
C640 powers off with grub/ACPI - much earlier than the CPx
Most likely the same interval of kernel that Valdis mentions. For
sure both behave like this in 2.5.58.
> --On Wednesday, January 15, 2003 14:21:57 -0500 [email protected]
> wrote:
>
>> On Wed, 15 Jan 2003 23:43:58 +1300, Andrew McGregor said:
>>
>>> Possibly related:
>>>
>>> Dell Inspiron 8000s won't warm reboot either. They just freeze with a
>>> blinking cursor at the point where the bootloader would ordinarily load.
>>> Have to power off or reset.
>>>
>>> Consistent in various versions from 2.5.44 to .55. Have not tested
>>> earlier, nor yet later.
>>
>>
>> Dell Latitude C840s will power off. Oddly enough, it doesn't do it when
>> LILO itself loads - it does it when LILO starts loading the actual kernel
>> image. True from 2.5.46 through 2.5.58.
--alessandro
"And though it don't seem fair, for every smile that plays
a tear must fall somewhere"
(Bruce Springsteen, "The Price You Pay", live 31/12/1980)
On Thu, Jan 16, 2003 at 02:33:11PM +0100, Alessandro Suardi wrote:
> Andrew McGregor wrote:
> > The i8k will power off with APM but not ACPI, but it won't reboot with
> > either.
> >
> > I'm using grub, so it may hit the problem before outputting anything
> > where lilo may not.
>
> [Fixed CC: to Vojtech]
>
> CPx750J powers off with grub/APM
> C640 powers off with grub/ACPI - much earlier than the CPx
>
> Most likely the same interval of kernel that Valdis mentions. For
> sure both behave like this in 2.5.58.
Do the symptoms persist when you disable AT keyboard support completely?
(You'll need a different way to control the machine - USB or Ethernet
for the test.)
> > --On Wednesday, January 15, 2003 14:21:57 -0500 [email protected]
> > wrote:
> >
> >> On Wed, 15 Jan 2003 23:43:58 +1300, Andrew McGregor said:
> >>
> >>> Possibly related:
> >>>
> >>> Dell Inspiron 8000s won't warm reboot either. They just freeze with a
> >>> blinking cursor at the point where the bootloader would ordinarily load.
> >>> Have to power off or reset.
> >>>
> >>> Consistent in various versions from 2.5.44 to .55. Have not tested
> >>> earlier, nor yet later.
> >>
> >>
> >> Dell Latitude C840s will power off. Oddly enough, it doesn't do it when
> >> LILO itself loads - it does it when LILO starts loading the actual kernel
> >> image. True from 2.5.46 through 2.5.58.
>
> --alessandro
>
> "And though it don't seem fair, for every smile that plays
> a tear must fall somewhere"
> (Bruce Springsteen, "The Price You Pay", live 31/12/1980)
--
Vojtech Pavlik
SuSE Labs
On Sat, 25 Jan 2003 15:02:16 +0100, Vojtech Pavlik wrote:
>Do the symptoms persist when you disable AT keyboard support completely?
>(You'll need a different way to control the machine - USB or Ethernet
>for the test.)
Disabling CONFIG_KEYBOARD_ATKBD (but keeping SERIO_I8042 and
MOUSE_PS2 enabled) eliminates the BIOS keyboard error on my
Latitude when rebooting after running 2.5.59.
/Mikael
On Sun, Jan 26, 2003 at 03:39:44PM +0100, Mikael Pettersson wrote:
> On Sat, 25 Jan 2003 15:02:16 +0100, Vojtech Pavlik wrote:
> >Do the symptoms persist when you disable AT keyboard support completely?
> >(You'll need a different way to control the machine - USB or Ethernet
> >for the test.)
>
> Disabling CONFIG_KEYBOARD_ATKBD (but keeping SERIO_I8042 and
> MOUSE_PS2 enabled) eliminates the BIOS keyboard error on my
> Latitude when rebooting after running 2.5.59.
Hmm, interesting. Can you try disabling some of the probes for extended
keyboards in atkbd.c to see if some of them could confuse your keyboard
so that the BIOS doesn't like it after boot? Also you may want to kill
the keyboard reset on reboot ... (atkbd_cleanup) ...
--
Vojtech Pavlik
SuSE Labs
On 26 Jan 2003 21:19:52 -0500, Tom Sightler wrote:
>> Hmm, interesting. Can you try disabling some of the probes for
>> extended keyboards in atkbd.c to see if some of them could confuse
>> your keyboard so that the BIOS doesn't like it after boot? Also you
>> may want to kill the keyboard reset on reboot ... (atkbd_cleanup) ...
>
>I've been following this because my Dell Latitude C810 has the
>"keyboard/mouse doesn't work after reboot" with all of the recent 2.5.x
>kernel that I have tried.
>
>When I saw the suggestion above to try removing the keyboard reset I
>thought that was just too easy to pass up giving it a try. Sure enough,
>removing just the one line that preforms the keyboard reset from
>atkbd_cleanup solves the problem for me.
I tried that too and it eliminated the keyboard error problem on my CPi.
(Strangely enough, when I tried the same hack with the 2.5.42 kernel
some time ago it did not help. Oh well.)
I added some logging to atkbd_command(), and found that GSCANSET
always returns 22 (decimal), but SSCANSET with 22 fails and
triggers the BIOS keyboard error. So what happens is that atkbd_set_3()
does GSCANSET and stores 22 in atkbd->oldset. Then it issues
SSCANSET with 2, checks the result with GSCANSET, gets 22, and
assumes 2 since 22 != 3. Just before reboot, atkbd_cleanup() does
SSCANSET with 22 (from atkb->oldset), which fails (though atkbd
doesn't check this) and later triggers the BIOS keyboard error.
Either removing the SSCANSET from atkbd_cleanup(), or changing
atkbd->oldset from 22 to 2, solves my CPi's keyboard problems.
/Mikael
On Mon, Jan 27, 2003 at 01:26:54PM +0100, Mikael Pettersson wrote:
> On 26 Jan 2003 21:19:52 -0500, Tom Sightler wrote:
> >> Hmm, interesting. Can you try disabling some of the probes for
> >> extended keyboards in atkbd.c to see if some of them could confuse
> >> your keyboard so that the BIOS doesn't like it after boot? Also you
> >> may want to kill the keyboard reset on reboot ... (atkbd_cleanup) ...
> >
> >I've been following this because my Dell Latitude C810 has the
> >"keyboard/mouse doesn't work after reboot" with all of the recent 2.5.x
> >kernel that I have tried.
> >
> >When I saw the suggestion above to try removing the keyboard reset I
> >thought that was just too easy to pass up giving it a try. Sure enough,
> >removing just the one line that preforms the keyboard reset from
> >atkbd_cleanup solves the problem for me.
>
> I tried that too and it eliminated the keyboard error problem on my CPi.
> (Strangely enough, when I tried the same hack with the 2.5.42 kernel
> some time ago it did not help. Oh well.)
>
> I added some logging to atkbd_command(), and found that GSCANSET
> always returns 22 (decimal), but SSCANSET with 22 fails and
> triggers the BIOS keyboard error. So what happens is that atkbd_set_3()
> does GSCANSET and stores 22 in atkbd->oldset. Then it issues
> SSCANSET with 2, checks the result with GSCANSET, gets 22, and
> assumes 2 since 22 != 3. Just before reboot, atkbd_cleanup() does
> SSCANSET with 22 (from atkb->oldset), which fails (though atkbd
> doesn't check this) and later triggers the BIOS keyboard error.
>
> Either removing the SSCANSET from atkbd_cleanup(), or changing
> atkbd->oldset from 22 to 2, solves my CPi's keyboard problems.
Can you try with the attached atkbd.c? It uses RESET_BAT instead of
SSCANSET, which will slow down the reboot a bit, but should be very safe
to bring the keyboard to its power-on state, which the BIOS should be
able to handle.
--
Vojtech Pavlik
SuSE Labs
On Mon, 27 Jan 2003 13:34:32 +0100, Vojtech Pavlik wrote:
>> Either removing the SSCANSET from atkbd_cleanup(), or changing
>> atkbd->oldset from 22 to 2, solves my CPi's keyboard problems.
>
>Can you try with the attached atkbd.c? It uses RESET_BAT instead of
>SSCANSET, which will slow down the reboot a bit, but should be very safe
>to bring the keyboard to its power-on state, which the BIOS should be
>able to handle.
I tried it, and the change to use RESET_BAT in atkbd_cleanup()
works fine. Tested on my Dell Latitiude CPi and four desktop
boxes of various vintages. No new problems. A reboot takes maybe
1/10 of a second longer, but I don't care.
However, your version of atkbd.c caused a linkage error due to a
reference to input_regs() in atkbd_interrupt(). I extracted
just the changes to atkbd_cleanup() and atkbd_command(), but that
left me with a dead keyboard on the first test box. In the end
I kept only the atkbd_cleanup() change and the increased timeout
for RESET_BAT in atkbd_command() [see below].
/Mikael
--- linux-2.5.59/drivers/input/keyboard/atkbd.c.~1~ 2002-11-23 17:59:41.000000000 +0100
+++ linux-2.5.59/drivers/input/keyboard/atkbd.c 2003-01-27 19:54:30.000000000 +0100
@@ -233,6 +233,9 @@
int i;
atkbd->cmdcnt = receive;
+
+ if (command == ATKBD_CMD_RESET_BAT)
+ timeout = 200000; /* 2 sec */
if (command & 0xff)
if (atkbd_sendbyte(atkbd, command & 0xff))
@@ -442,7 +445,7 @@
static void atkbd_cleanup(struct serio *serio)
{
struct atkbd *atkbd = serio->private;
- atkbd_command(atkbd, &atkbd->oldset, ATKBD_CMD_SSCANSET);
+ atkbd_command(atkbd, NULL, ATKBD_CMD_RESET_BAT);
}
/*
On Mon, Jan 27, 2003 at 09:57:43PM +0100, Mikael Pettersson wrote:
> On Mon, 27 Jan 2003 13:34:32 +0100, Vojtech Pavlik wrote:
> >> Either removing the SSCANSET from atkbd_cleanup(), or changing
> >> atkbd->oldset from 22 to 2, solves my CPi's keyboard problems.
> >
> >Can you try with the attached atkbd.c? It uses RESET_BAT instead of
> >SSCANSET, which will slow down the reboot a bit, but should be very safe
> >to bring the keyboard to its power-on state, which the BIOS should be
> >able to handle.
>
> I tried it, and the change to use RESET_BAT in atkbd_cleanup()
> works fine. Tested on my Dell Latitiude CPi and four desktop
> boxes of various vintages. No new problems. A reboot takes maybe
> 1/10 of a second longer, but I don't care.
>
> However, your version of atkbd.c caused a linkage error due to a
> reference to input_regs() in atkbd_interrupt(). I extracted
> just the changes to atkbd_cleanup() and atkbd_command(), but that
> left me with a dead keyboard on the first test box. In the end
> I kept only the atkbd_cleanup() change and the increased timeout
> for RESET_BAT in atkbd_command() [see below].
Good. I'll do more tests here and find the problem which left you
without the keyboard - the current atkbd.c I sent you is fairly
untested.
>
> /Mikael
>
> --- linux-2.5.59/drivers/input/keyboard/atkbd.c.~1~ 2002-11-23 17:59:41.000000000 +0100
> +++ linux-2.5.59/drivers/input/keyboard/atkbd.c 2003-01-27 19:54:30.000000000 +0100
> @@ -233,6 +233,9 @@
> int i;
>
> atkbd->cmdcnt = receive;
> +
> + if (command == ATKBD_CMD_RESET_BAT)
> + timeout = 200000; /* 2 sec */
>
> if (command & 0xff)
> if (atkbd_sendbyte(atkbd, command & 0xff))
> @@ -442,7 +445,7 @@
> static void atkbd_cleanup(struct serio *serio)
> {
> struct atkbd *atkbd = serio->private;
> - atkbd_command(atkbd, &atkbd->oldset, ATKBD_CMD_SSCANSET);
> + atkbd_command(atkbd, NULL, ATKBD_CMD_RESET_BAT);
> }
>
> /*
--
Vojtech Pavlik
SuSE Labs
On Mon, 2003-01-27 at 15:57, Mikael Pettersson wrote:
> However, your version of atkbd.c caused a linkage error due to a
> reference to input_regs() in atkbd_interrupt(). I extracted
> just the changes to atkbd_cleanup() and atkbd_command(), but that
> left me with a dead keyboard on the first test box. In the end
> I kept only the atkbd_cleanup() change and the increased timeout
> for RESET_BAT in atkbd_command() [see below].
Just as another point of reference, I tested your patch with only the
RESET_BAT changes and it worked on my machine as well.
Later,
Tom
On Mon, Jan 27, 2003 at 08:56:07PM -0500, Tom Sightler wrote:
> On Mon, 2003-01-27 at 15:57, Mikael Pettersson wrote:
> > However, your version of atkbd.c caused a linkage error due to a
> > reference to input_regs() in atkbd_interrupt(). I extracted
> > just the changes to atkbd_cleanup() and atkbd_command(), but that
> > left me with a dead keyboard on the first test box. In the end
> > I kept only the atkbd_cleanup() change and the increased timeout
> > for RESET_BAT in atkbd_command() [see below].
>
> Just as another point of reference, I tested your patch with only the
> RESET_BAT changes and it worked on my machine as well.
Great.
--
Vojtech Pavlik
SuSE Labs