Dell Latitude CPi keyboard problems since 2.5.42

Dell Latitude CPi keyboard problems since 2.5.42

[Mikael Pettersson]

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

Re: Dell Latitude CPi keyboard problems since 2.5.42

[Andrew McGregor]

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 
<mikpe@csd.uu.se> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>

Re: Dell Latitude CPi keyboard problems since 2.5.42

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 631 bytes --]

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


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Dell Latitude CPi keyboard problems since 2.5.42

[Andrew McGregor]

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 Valdis.Kletnieks@vt.edu 
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
>

Re: Dell Latitude CPi keyboard problems since 2.5.42

[Alessandro Suardi]

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 Valdis.Kletnieks@vt.edu 
> 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)

Re: Dell Latitude CPi keyboard problems since 2.5.42

[Vojtech Pavlik]

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 Valdis.Kletnieks@vt.edu 
> > 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

NFS client locking hangs for period

[Christian Reis]

Hello Neil,

I've been trying to get at this problem for a while now, and had been
concentrating on the client-side of the problem (and consequently
bothering Trond about it) [1,2]. I am now pretty much convinced this is a
server-side problem, and as I've patched 2.4.20 with all the NFS patches
pending (that didn't have to do with the kernel lock breaking) and still
see the issue, I decided to report this bug.

The scenario is: a set of NFS clients with root mounted over nfs from a
single server. Clients run vanilla 2.4.20, server runs 2.4.20 patched
with your server-side patches I mentioned above. The clients run okay
for a period, and then one of them will start to hang for long periods
of time for certain operations (it happens on startup and shutdown, for
instance). Once the client hangs start the server needs to be rebooted
for it to clear up.

It seems to be reproducible by having the client hang or reboot without
shutting down properly. Another tip is that the server gets files left
over in /var/lib/nfs/sm/ for the hanging client(s). 

I've been trying to track this down for a while, but since I'm not very
proficient with debugging at this level, I haven't had much luck. It's
really a problem because I need to reboot and make 20 people stop
working when the problem gets serious. Trond has had a hand trying
to help me, but we still haven't uncovered anything. I wonder if you
have any clue what could be happenning?

The other details are standard: the clients are debian woodys with
nfs-utils 1.0.1 installed, and the server has the same version. The
server runs reiserfs over RAID-1 partitions (using the kernel md
driver). Could it be triggered because of this perhaps unusual
combination?

Some of the messages I point out below have some info about the issue -
including tcpdumps and traces of nlm_debug on the server and client.

Mount options follow for the client filesystems:

anthem:/export/root/    /   nfs defaults,rw,rsize=8192,wsize=8192,nfsvers=2 0 0
anthem:/home    /home   nfs defaults,rw,rsize=8192,wsize=8192,nfsvers=3 0 0

I have checked and, yes, root is mounted using version 2 and the rest as
version 3. Perhaps I should try getting the kernel to mount root using
version 3?

[1] http://groups.google.com/groups?q=trond+christian+nfs&hl=pt&lr=&ie=UTF-8&client=googlet&scoring=d&selm=20030108151424.N2628%40blackjesus.async.com.br.lucky.linux.kernel&rnum=1
[2] http://groups.google.com/groups?hl=pt&lr=&ie=UTF-8&client=googlet&th=3575b3c5f3360eb0&seekm=20030108151424.N2628%40blackjesus.async.com.br.lucky.linux.kernel&frame=off

Thanks for any help you can give.

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL

Re: NFS client locking hangs for period

[Neil Brown]

On Friday January 24, kiko@async.com.br wrote:
> 
> Hello Neil,

Hi.

> 
> I've been trying to get at this problem for a while now, ....

> 
> It seems to be reproducible by having the client hang or reboot without
> shutting down properly. Another tip is that the server gets files left
> over in /var/lib/nfs/sm/ for the hanging client(s). 

> 
> Mount options follow for the client filesystems:
> 
> anthem:/export/root/    /   nfs defaults,rw,rsize=8192,wsize=8192,nfsvers=2 0 0
> anthem:/home    /home   nfs defaults,rw,rsize=8192,wsize=8192,nfsvers=3 0 0
> 

Hmmm.  So you have several clients all mounting the same root
filesystem, and mounting it writable?  That doesn't sound like a plan
for success.  How do you make sure the clients don't tread over each
other when using /etc files?

I suspect that what you really want is to mount root read-only, or
mount separate roots for each client, and then in either case to mount
with the "nolock" flag.

I suspect that your problem is related to the client trying to do
locking, but no having statd running on the client.
You cannot meaningfully do locking on an NFS mounted root filesystem.
Infact, I think it would be good if the default mount options for nfs
root included nolock... and if I read fs/nfs/nfsroot.c:root_nfs_name
correctly, nolock is the default.  Are you overriding that default
be explicitly setting "lock"??

NeilBrown

Re: NFS client locking hangs for period

[Christian Reis]

On Sat, Jan 25, 2003 at 02:54:09PM +1100, Neil Brown wrote:
> Hmmm.  So you have several clients all mounting the same root
> filesystem, and mounting it writable?  That doesn't sound like a plan
> for success.  How do you make sure the clients don't tread over each
> other when using /etc files?

The truth is few (broken wrt the FHS) programs actually write to /etc. I
have set up everything so nothing is written to in /etc, and it actually
works very well (have to use a special init(8) that doesn't write to
/etc/ioctl.save). This setup has been running for almost a year now,
with the locking problem being the only one left to fix.

> I suspect that what you really want is to mount root read-only, or
> mount separate roots for each client, and then in either case to mount
> with the "nolock" flag.

Well, mounting root read-only is a good idea but it sacrifices being
able to administer the system from any station, and it also puts a lot
of burden on me to fix *all* programs to not write to anywhere on it.
This shouldn't be too hard, but we're still just working around the bug,
which I would really like to identify and fix.

> I suspect that your problem is related to the client trying to do
> locking, but no having statd running on the client.

I am 100% positive statd runs on every single client. This problem here
only happens spuriously.  It goes away when I restart nfsd and mountd
(in that order). It really does look like a bug <wink>

> You cannot meaningfully do locking on an NFS mounted root filesystem.
> Infact, I think it would be good if the default mount options for nfs
> root included nolock... and if I read fs/nfs/nfsroot.c:root_nfs_name
> correctly, nolock is the default.  Are you overriding that default
> be explicitly setting "lock"??

Nope. I've just tested and the default (specifying no lock option upon
bootup) really is nolock:

/dev/root on / type nfs (rw,v3,rsize=8192,wsize=8192,hard,udp,nolock,addr=192.168.99.4)

I wonder why you can't do locking on NFS root (if it's a current
limitation of if it doesn't make sense). 

But I also think this problem shouldn't be happening if no locking was
going on. And when I checked using nlm_debug it sure did seem locking
was being used. What do you make of it?

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL

Re: [NFS] Re: NFS client locking hangs for period

[Trond Myklebust]

>>>>> " " == Christian Reis <kiko@async.com.br> writes:

     > I wonder why you can't do locking on NFS root (if it's a
     > current limitation of if it doesn't make sense).

locking supposes that you are already running a statd daemon, which
you clearly cannot be doing on an nfsroot system. If you need locking
on a root partition, then you'll need to set up an initrd from which
to start all the necessary daemons...

BTW: Did I understand you and Neil correctly when you appeared to say
that you were sharing the *same* root partition between several
clients?

If so, then that could easily explain your problem: a directory like
/var/lib/nfs simply cannot be shared among several different
machines. Read the 'statd' manpage, and I'm sure you will understand
why.

Cheers,
  Trond

Re: [NFS] Re: NFS client locking hangs for period

[Christian Reis]

On Sun, Jan 26, 2003 at 10:49:14PM +0100, Trond Myklebust wrote:
> >>>>> " " == Christian Reis <kiko@async.com.br> writes:
> 
>      > I wonder why you can't do locking on NFS root (if it's a
>      > current limitation of if it doesn't make sense).
> 
> locking supposes that you are already running a statd daemon, which
> you clearly cannot be doing on an nfsroot system. If you need locking
> on a root partition, then you'll need to set up an initrd from which
> to start all the necessary daemons...

This makes a lot of sense, I just had never thought about it properly.
I'm not sure I *need* locking, so I'll run with nolock till it bites me.

> BTW: Did I understand you and Neil correctly when you appeared to say
> that you were sharing the *same* root partition between several
> clients?

Yes, you did understand correctly. The same root partition is mounted by
around 20 machines. It works, too. The bug that we have manifests itself
very rarely, and only when one of the machines does an unclean shutdown.
I still haven't been able to reproduce it so I still haven't seen a
solution yet.

> If so, then that could easily explain your problem: a directory like
> /var/lib/nfs simply cannot be shared among several different
> machines. Read the 'statd' manpage, and I'm sure you will understand
> why.

Well, none of the machines by default exports anything through NFS, so
none of them explicitly *need* /var/lib/nfs. I've done some careful
study and separated the directories which are written to on a per-host
basis, and used a lot of tmpfs. It works quite well, to be honest. A
breakdown of "special" directories:

- /var/spool and /var/log need to be separate, for obvious reasons.
- /proc/mounts should be linked to /etc/mtab to avoid the need for
  writing there. 
- /tmp, /var/tmp, /dev/shm, /var/lock, /var/run, /var/lib/nfs,
  /var/yp/binding, /var/lib/sendmail are tmpfs.

None of the users have root access so writing to the partition only is
done as the result of servers running. I used a lot of reboots and ls
-lt to find out what needs to be separate, and there are few issues that
need fixing (/etc/ioctl.save being the latest).

One issue I ran into that I only discovered today (well, we all have to
learn someday) was that a shared /dev is not a good idea, because some
programs write to it. Case in point was syslogd, which creates /dev/log
- all but the last machine had logging broken. Since nobody needs logs
on these boxes anyway, it had gone on unnoticed, but I'm now using
devfs, and it works fine.

Everybody seems to find this setup a bit bizarre. It's not. It keeps
maintenence down to zero for everything, and adding a new box means
running a script once.

statd(8) does indicate that /var/lib/nfs is private, so I just mount it
as tmpfs. Should I make it persistent, or is the fact those files
disappear on an unclean reboot a sign of trouble?

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL

Re: [NFS] Re: NFS client locking hangs for period

[Trond Myklebust]

>>>>> " " == Christian Reis <kiko@async.com.br> writes:

     > statd(8) does indicate that /var/lib/nfs is private, so I just
     > mount it as tmpfs. Should I make it persistent, or is the fact
     > those files disappear on an unclean reboot a sign of trouble?

If you want locking to work, then /var/lib/nfs *MUST* be
persistent and unique for each client.

If not then the server will fail to be notified that it needs to
release any POSIX locks it might think you were holding if/when your
NFS client fails to shutdown cleanly.
That again will typically cause a deadlock the next time you try to
access your mailspool (if the server thinks it is already holding a
lock on your behalf).

Cheers,
  Trond

Re: [NFS] Re: NFS client locking hangs for period

[Christian Reis]

On Mon, Jan 27, 2003 at 12:02:00AM +0100, Trond Myklebust wrote:
> >>>>> " " == Christian Reis <kiko@async.com.br> writes:
> 
>      > statd(8) does indicate that /var/lib/nfs is private, so I just
>      > mount it as tmpfs. Should I make it persistent, or is the fact
>      > those files disappear on an unclean reboot a sign of trouble?
> 
> If you want locking to work, then /var/lib/nfs *MUST* be
> persistent and unique for each client.

I had never realized this; things are symmetric in an odd way with NFS,
and this bit with locking can trick you. I've changed the clients to
mount private nfs directories (the perks of shared root for diskless ;)
and I do hope things will work out from now on.

One thing worth noting is that the private /var/lib/nfs directory has to
be mounted a) with nolock (I assume) and b) *before* statd and lockd
have gone up.

> That again will typically cause a deadlock the next time you try to
> access your mailspool (if the server thinks it is already holding a
> lock on your behalf).

I am now left wondering how it bit us so little here. Is there a way of
finding out exactly *which* files are being locked at a certain time for
a certain client? 

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL

Re: [NFS] Re: NFS client locking hangs for period

[Trond Myklebust]

>>>>> " " == Christian Reis <kiko@async.com.br> writes:

     > Is there a way of finding out exactly *which* files are being
     > locked at a certain time for a certain client?

Not really. 'cat /proc/locks' is about the closest you can get. That
will give you no NFS-specific information though.

Cheers,
  Trond

Re: Dell Latitude CPi keyboard problems since 2.5.42

[Tom Sightler]

> 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.  Now I guess it's time to try
to determine why, and what the real fix should likely be.

Just thought it might be valuable to have another report about the
problem.

Later,
Tom

Re: Dell Latitude CPi keyboard problems since 2.5.42

[Mikael Pettersson]

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

Re: Dell Latitude CPi keyboard problems since 2.5.42

[Vojtech Pavlik]

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

Re: Dell Latitude CPi keyboard problems since 2.5.42

[Mikael Pettersson]

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

Re: Dell Latitude CPi keyboard problems since 2.5.42

[Vojtech Pavlik]

[-- Attachment #1: Type: text/plain, Size: 1964 bytes --]

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

[-- Attachment #2: atkbd.c --]
[-- Type: text/plain, Size: 16112 bytes --]

/*
 * AT and PS/2 keyboard driver
 *
 * Copyright (c) 1999-2002 Vojtech Pavlik
 */

/*
 * This program is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 as published by
 * the Free Software Foundation.
 */

#include <linux/delay.h>
#include <linux/module.h>
#include <linux/slab.h>
#include <linux/interrupt.h>
#include <linux/init.h>
#include <linux/input.h>
#include <linux/serio.h>
#include <linux/workqueue.h>

MODULE_AUTHOR("Vojtech Pavlik <vojtech@suse.cz>");
MODULE_DESCRIPTION("AT and PS/2 keyboard driver");
MODULE_PARM(atkbd_set, "1i");
MODULE_PARM(atkbd_reset, "1i");
MODULE_LICENSE("GPL");

static int atkbd_set = 2;
#if defined(__i386__) || defined (__x86_64__)
static int atkbd_reset;
#else
static int atkbd_reset = 1;
#endif

/*
 * Scancode to keycode tables. These are just the default setting, and
 * are loadable via an userland utility.
 */

static unsigned char atkbd_set2_keycode[512] = {
	  0, 67, 65, 63, 61, 59, 60, 88,  0, 68, 66, 64, 62, 15, 41, 85,
	  0, 56, 42,  0, 29, 16,  2, 89,  0,  0, 44, 31, 30, 17,  3, 90,
	  0, 46, 45, 32, 18,  5,  4, 91,  0, 57, 47, 33, 20, 19,  6,  0,
	  0, 49, 48, 35, 34, 21,  7,  0,  0,  0, 50, 36, 22,  8,  9,  0,
	  0, 51, 37, 23, 24, 11, 10,  0,  0, 52, 53, 38, 39, 25, 12,  0,
	122, 89, 40,120, 26, 13,  0,  0, 58, 54, 28, 27,  0, 43,  0,  0,
	 85, 86, 90, 91, 92, 93, 14, 94, 95, 79,183, 75, 71,121,  0,123,
	 82, 83, 80, 76, 77, 72,  1, 69, 87, 78, 81, 74, 55, 73, 70, 99,
	252,  0,  0, 65, 99,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
	  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
	  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,251,  0,  0,  0,  0,  0,
	  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
	  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
	  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
	252,253,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
	254,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,255,
	  0,  0, 92, 90, 85,  0,137,  0,  0,  0,  0, 91, 89,144,115,  0,
	217,100,255,  0, 97,165,164,  0,156,  0,  0,140,115,  0,  0,125,
	173,114,  0,113,152,163,151,126,128,166,  0,140,  0,147,  0,127,
	159,167,115,160,164,  0,  0,116,158,  0,150,166,  0,  0,  0,142,
	157,  0,114,166,168,  0,  0,  0,155,  0, 98,113,  0,163,  0,138,
	226,  0,  0,  0,  0,  0,153,140,  0,255, 96,  0,  0,  0,143,  0,
	133,  0,116,  0,143,  0,174,133,  0,107,  0,105,102,  0,  0,112,
	110,111,108,112,106,103,  0,119,  0,118,109,  0, 99,104,119
};

static unsigned char atkbd_set3_keycode[512] = {
	  0,  0,  0,  0,  0,  0,  0, 59,  1,138,128,129,130, 15, 41, 60,
	131, 29, 42, 86, 58, 16,  2, 61,133, 56, 44, 31, 30, 17,  3, 62,
	134, 46, 45, 32, 18,  5,  4, 63,135, 57, 47, 33, 20, 19,  6, 64,
	136, 49, 48, 35, 34, 21,  7, 65,137,100, 50, 36, 22,  8,  9, 66,
	125, 51, 37, 23, 24, 11, 10, 67,126, 52, 53, 38, 39, 25, 12, 68,
	113,114, 40, 84, 26, 13, 87, 99,100, 54, 28, 27, 43, 84, 88, 70,
	108,105,119,103,111,107, 14,110,  0, 79,106, 75, 71,109,102,104,
	 82, 83, 80, 76, 77, 72, 69, 98,  0, 96, 81,  0, 78, 73, 55, 85,
	 89, 90, 91, 92, 74,185,184,182,  0,  0,  0,125,126,127,112,  0,
	  0,139,150,163,165,115,152,150,166,140,160,154,113,114,167,168,
	148,149,147,140,  0,  0,  0,  0,  0,  0,251,  0,  0,  0,  0,  0,
	  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
	  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
	  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
	252,253,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
	254,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,255
};

#define ATKBD_CMD_SETLEDS	0x10ed
#define ATKBD_CMD_GSCANSET	0x11f0
#define ATKBD_CMD_SSCANSET	0x10f0
#define ATKBD_CMD_GETID		0x02f2
#define ATKBD_CMD_ENABLE	0x00f4
#define ATKBD_CMD_RESET_DIS	0x00f5
#define ATKBD_CMD_RESET_BAT	0x01ff
#define ATKBD_CMD_SETALL_MB	0x00f8
#define ATKBD_CMD_RESEND	0x00fe
#define ATKBD_CMD_EX_ENABLE	0x10ea
#define ATKBD_CMD_EX_SETLEDS	0x20eb
#define ATKBD_CMD_OK_GETID	0x02e8

#define ATKBD_RET_ACK		0xfa
#define ATKBD_RET_NAK		0xfe

#define ATKBD_KEY_UNKNOWN	  0
#define ATKBD_KEY_BAT		251
#define ATKBD_KEY_EMUL0		252
#define ATKBD_KEY_EMUL1		253
#define ATKBD_KEY_RELEASE	254
#define ATKBD_KEY_NULL		255

/*
 * The atkbd control structure
 */

struct atkbd {
	unsigned char keycode[512];
	struct input_dev dev;
	struct serio *serio;
	char name[64];
	char phys[32];
	unsigned char cmdbuf[4];
	unsigned char cmdcnt;
	unsigned char set;
	unsigned char release;
	volatile signed char ack;
	unsigned char emul;
	unsigned short id;
	unsigned char write;
	unsigned char resend;
};

/*
 * atkbd_interrupt(). Here takes place processing of data received from
 * the keyboard into events.
 */

static void atkbd_interrupt(struct serio *serio, unsigned char data, unsigned int flags, struct pt_regs *regs)
{
	struct atkbd *atkbd = serio->private;
	int code = data;

#ifdef ATKBD_DEBUG
	printk(KERN_DEBUG "atkbd.c: Received %02x flags %02x\n", data, flags);
#endif

	if ((flags & (SERIO_FRAME | SERIO_PARITY)) && (~flags & SERIO_TIMEOUT) && !atkbd->resend && atkbd->write) {
		printk("atkbd.c: frame/parity error: %02x\n", flags);
		serio_write(serio, ATKBD_CMD_RESEND);
		atkbd->resend = 1;
		return;
	}
	
	if (!flags)
		atkbd->resend = 0;

	switch (code) {
		case ATKBD_RET_ACK:
			atkbd->ack = 1;
			return;
		case ATKBD_RET_NAK:
			atkbd->ack = -1;
			return;
	}

	if (atkbd->cmdcnt) {
		atkbd->cmdbuf[--atkbd->cmdcnt] = code;
		return;
	}

	switch (atkbd->keycode[code]) {
		case ATKBD_KEY_BAT:
			serio_rescan(atkbd->serio);
			return;
		case ATKBD_KEY_EMUL0:
			atkbd->emul = 1;
			return;
		case ATKBD_KEY_EMUL1:
			atkbd->emul = 2;
			return;
		case ATKBD_KEY_RELEASE:
			atkbd->release = 1;
			return;
	}

	if (atkbd->emul) {
		if (--atkbd->emul) return;
		code |= 0x100;
	}

	switch (atkbd->keycode[code]) {
		case ATKBD_KEY_NULL:
			break;
		case ATKBD_KEY_UNKNOWN:
			printk(KERN_WARNING "atkbd.c: Unknown key (set %d, scancode %#x, on %s) %s.\n",
				atkbd->set, code, serio->phys, atkbd->release ? "released" : "pressed");
			break;
		default:
			input_regs(&atkbd->dev, regs);
			input_report_key(&atkbd->dev, atkbd->keycode[code], !atkbd->release);
			input_sync(&atkbd->dev);
	}
		
	atkbd->release = 0;
}

/*
 * atkbd_sendbyte() sends a byte to the keyboard, and waits for
 * acknowledge. It doesn't handle resends according to the keyboard
 * protocol specs, because if these are needed, the keyboard needs
 * replacement anyway, and they only make a mess in the protocol.
 */

static int atkbd_sendbyte(struct atkbd *atkbd, unsigned char byte)
{
	int timeout = 10000; /* 100 msec */
	atkbd->ack = 0;

#ifdef ATKBD_DEBUG
	printk(KERN_DEBUG "atkbd.c: Sent: %02x\n", byte);
#endif
	if (serio_write(atkbd->serio, byte))
		return -1;

	while (!atkbd->ack && timeout--) udelay(10);

	return -(atkbd->ack <= 0);
}

/*
 * atkbd_command() sends a command, and its parameters to the keyboard,
 * then waits for the response and puts it in the param array.
 */

static int atkbd_command(struct atkbd *atkbd, unsigned char *param, int command)
{
	int timeout = 500000; /* 500 msec */
	int send = (command >> 12) & 0xf;
	int receive = (command >> 8) & 0xf;
	int i;

	atkbd->cmdcnt = receive;

	if (command == ATKBD_CMD_RESET_BAT)
		timeout = 2000000; /* 2 sec */
	
	if (command & 0xff)
		if (atkbd_sendbyte(atkbd, command & 0xff))
			return (atkbd->cmdcnt = 0) - 1;

	for (i = 0; i < send; i++)
		if (atkbd_sendbyte(atkbd, param[i]))
			return (atkbd->cmdcnt = 0) - 1;

	while (atkbd->cmdcnt && timeout--) {

		if (atkbd->cmdcnt == 1 && command == ATKBD_CMD_RESET_BAT)
			timeout = 100000;

		if (atkbd->cmdcnt == 1 && command == ATKBD_CMD_GETID &&
		    atkbd->cmdbuf[1] != 0xab && atkbd->cmdbuf[1] != 0xac) {
			atkbd->cmdcnt = 0;
			break;
		}
	
		udelay(1);
	}

	if (param)
		for (i = 0; i < receive; i++)
			param[i] = atkbd->cmdbuf[(receive - 1) - i];

	if (atkbd->cmdcnt) {
		atkbd->cmdcnt = 0;
		return -1;
	}

	return 0;
}

/*
 * Event callback from the input module. Events that change the state of
 * the hardware are processed here.
 */

static int atkbd_event(struct input_dev *dev, unsigned int type, unsigned int code, int value)
{
	struct atkbd *atkbd = dev->private;
	char param[2];

	if (!atkbd->write)
		return -1;

	switch (type) {

		case EV_LED:

			*param = (test_bit(LED_SCROLLL, dev->led) ? 1 : 0)
			       | (test_bit(LED_NUML,    dev->led) ? 2 : 0)
			       | (test_bit(LED_CAPSL,   dev->led) ? 4 : 0);
		        atkbd_command(atkbd, param, ATKBD_CMD_SETLEDS);

			if (atkbd->set == 4) {
				param[0] = 0;
				param[1] = (test_bit(LED_COMPOSE, dev->led) ? 0x01 : 0)
					 | (test_bit(LED_SLEEP,   dev->led) ? 0x02 : 0)
					 | (test_bit(LED_SUSPEND, dev->led) ? 0x04 : 0)
				         | (test_bit(LED_MISC,    dev->led) ? 0x10 : 0)
				         | (test_bit(LED_MUTE,    dev->led) ? 0x20 : 0);
				atkbd_command(atkbd, param, ATKBD_CMD_EX_SETLEDS);
			}

			return 0;
	}

	return -1;
}

/*
 * atkbd_set_3 checks if a keyboard has a working Set 3 support, and
 * sets it into that. Unfortunately there are keyboards that can be switched
 * to Set 3, but don't work well in that (BTC Multimedia ...)
 */

static int atkbd_set_3(struct atkbd *atkbd)
{
	unsigned char param[2];

/*
 * For known special keyboards we can go ahead and set the correct set.
 * We check for NCD PS/2 Sun, NorthGate OmniKey 101 and
 * IBM RapidAccess / IBM EzButton / Chicony KBP-8993 keyboards.
 */

	if (atkbd->id == 0xaca1) {
		param[0] = 3;
		atkbd_command(atkbd, param, ATKBD_CMD_SSCANSET);
		return 3;
	}

	if (atkbd_set != 2) 
		if (!atkbd_command(atkbd, param, ATKBD_CMD_OK_GETID)) {
			atkbd->id = param[0] << 8 | param[1];
			return 2;
		}

	if (atkbd_set == 4) {
		param[0] = 0x71;
		if (!atkbd_command(atkbd, param, ATKBD_CMD_EX_ENABLE))
			return 4;
	}

/*
 * Try to set the set we want.
 */

	param[0] = atkbd_set;
	if (atkbd_command(atkbd, param, ATKBD_CMD_SSCANSET))
		return 2;

/*
 * Read set number. Beware here. Some keyboards always send '2'
 * or some other number regardless into what mode they have been
 * attempted to be set. Other keyboards treat the '0' command as
 * 'set to set 0', and not 'report current set' as they should.
 * In that case we time out, and return 2.
 */

	param[0] = 0;
	if (atkbd_command(atkbd, param, ATKBD_CMD_GSCANSET))
		return 2;

/*
 * Here we return the set number the keyboard reports about
 * itself.
 */

	return (param[0] == 3) ? 3 : 2;
}

/*
 * atkbd_probe() probes for an AT keyboard on a serio port.
 */

static int atkbd_probe(struct atkbd *atkbd)
{
	unsigned char param[2];

/*
 * Some systems, where the bit-twiddling when testing the io-lines of the
 * controller may confuse the keyboard need a full reset of the keyboard. On
 * these systems the BIOS also usually doesn't do it for us.
 */

	if (atkbd_reset)
		if (atkbd_command(atkbd, NULL, ATKBD_CMD_RESET_BAT)) 
			printk(KERN_WARNING "atkbd.c: keyboard reset failed on %s\n", atkbd->serio->phys);

/*
 * Then we check the keyboard ID. We should get 0xab83 under normal conditions.
 * Some keyboards report different values, but the first byte is always 0xab or
 * 0xac. Some old AT keyboards don't report anything.
 */

	if (atkbd_command(atkbd, param, ATKBD_CMD_GETID)) {

/*
 * If the get ID command failed, we check if we can at least set the LEDs on
 * the keyboard. This should work on every keyboard out there. It also turns
 * the LEDs off, which we want anyway.
 */
		param[0] = 0;
		if (atkbd_command(atkbd, param, ATKBD_CMD_SETLEDS))
			return -1;
		atkbd->id = 0xabba;
		return 0;
	}

	if (param[0] != 0xab && param[0] != 0xac)
		return -1;
	atkbd->id = (param[0] << 8) | param[1];

/*
 * Set the LEDs to a defined state.
 */

	param[0] = 0;
	if (atkbd_command(atkbd, param, ATKBD_CMD_SETLEDS))
		return -1;

/*
 * Disable autorepeat. We don't need it, as we do it in software anyway,
 * because that way can get faster repeat, and have less system load (less
 * accesses to the slow ISA hardware). If this fails, we don't care, and will
 * just ignore the repeated keys.
 */

	atkbd_command(atkbd, NULL, ATKBD_CMD_SETALL_MB);

/*
 * Last, we enable the keyboard to make sure  that we get keypresses from it.
 */

	if (atkbd_command(atkbd, NULL, ATKBD_CMD_ENABLE))
		printk(KERN_ERR "atkbd.c: Failed to enable keyboard on %s\n",
			atkbd->serio->phys);

	return 0;
}

/*
 * atkbd_cleanup() restores the keyboard state so that BIOS is happy after a
 * reboot.
 */

static void atkbd_cleanup(struct serio *serio)
{
	struct atkbd *atkbd = serio->private;
	atkbd_command(atkbd, NULL, ATKBD_CMD_RESET_BAT);
}

/*
 * atkbd_disconnect() closes and frees.
 */

static void atkbd_disconnect(struct serio *serio)
{
	struct atkbd *atkbd = serio->private;
	input_unregister_device(&atkbd->dev);
	serio_close(serio);
	kfree(atkbd);
}

/*
 * atkbd_connect() is called when the serio module finds and interface
 * that isn't handled yet by an appropriate device driver. We check if
 * there is an AT keyboard out there and if yes, we register ourselves
 * to the input module.
 */

static void atkbd_connect(struct serio *serio, struct serio_dev *dev)
{
	struct atkbd *atkbd;
	int i;

	if ((serio->type & SERIO_TYPE) != SERIO_8042 &&
		(((serio->type & SERIO_TYPE) != SERIO_RS232) || (serio->type & SERIO_PROTO) != SERIO_PS2SER))
		        return;

	if (!(atkbd = kmalloc(sizeof(struct atkbd), GFP_KERNEL)))
		return;

	memset(atkbd, 0, sizeof(struct atkbd));

	if ((serio->type & SERIO_TYPE) == SERIO_8042 && serio->write)
		atkbd->write = 1;

	if (atkbd->write) {
		atkbd->dev.evbit[0] = BIT(EV_KEY) | BIT(EV_LED) | BIT(EV_REP);
		atkbd->dev.ledbit[0] = BIT(LED_NUML) | BIT(LED_CAPSL) | BIT(LED_SCROLLL);
	} else  atkbd->dev.evbit[0] = BIT(EV_KEY) | BIT(EV_REP);

	atkbd->serio = serio;

	init_input_dev(&atkbd->dev);

	atkbd->dev.keycode = atkbd->keycode;
	atkbd->dev.keycodesize = sizeof(unsigned char);
	atkbd->dev.keycodemax = ARRAY_SIZE(atkbd_set2_keycode);
	atkbd->dev.event = atkbd_event;
	atkbd->dev.private = atkbd;

	serio->private = atkbd;

	if (serio_open(serio, dev)) {
		kfree(atkbd);
		return;
	}

	if (atkbd->write) {

		if (atkbd_probe(atkbd)) {
			serio_close(serio);
			kfree(atkbd);
			return;
		}
		
		atkbd->set = atkbd_set_3(atkbd);

	} else {
		atkbd->set = 2;
		atkbd->id = 0xab00;
	}

	if (atkbd->set == 4) {
		atkbd->dev.ledbit[0] |= BIT(LED_COMPOSE) | BIT(LED_SUSPEND) | BIT(LED_SLEEP) | BIT(LED_MUTE) | BIT(LED_MISC);
		sprintf(atkbd->name, "AT Set 2 Extended keyboard");
	} else
		sprintf(atkbd->name, "AT Set %d keyboard", atkbd->set);

	sprintf(atkbd->phys, "%s/input0", serio->phys);

	if (atkbd->set == 3)
		memcpy(atkbd->keycode, atkbd_set3_keycode, sizeof(atkbd->keycode));
	else
		memcpy(atkbd->keycode, atkbd_set2_keycode, sizeof(atkbd->keycode));

	atkbd->dev.name = atkbd->name;
	atkbd->dev.phys = atkbd->phys;
	atkbd->dev.id.bustype = BUS_I8042;
	atkbd->dev.id.vendor = 0x0001;
	atkbd->dev.id.product = atkbd->set;
	atkbd->dev.id.version = atkbd->id;

	for (i = 0; i < 512; i++)
		if (atkbd->keycode[i] && atkbd->keycode[i] <= 250)
			set_bit(atkbd->keycode[i], atkbd->dev.keybit);

	input_register_device(&atkbd->dev);

	printk(KERN_INFO "input: %s on %s\n", atkbd->name, serio->phys);
}


static struct serio_dev atkbd_dev = {
	.interrupt =	atkbd_interrupt,
	.connect =	atkbd_connect,
	.disconnect =	atkbd_disconnect,
	.cleanup =	atkbd_cleanup,
};

#ifndef MODULE
static int __init atkbd_setup_set(char *str)
{
        int ints[4];
        str = get_options(str, ARRAY_SIZE(ints), ints);
        if (ints[0] > 0) atkbd_set = ints[1];
        return 1;
}
static int __init atkbd_setup_reset(char *str)
{
        int ints[4];
        str = get_options(str, ARRAY_SIZE(ints), ints);
        if (ints[0] > 0) atkbd_reset = ints[1];
        return 1;
}

__setup("atkbd_set=", atkbd_setup_set);
__setup("atkbd_reset", atkbd_setup_reset);
#endif

int __init atkbd_init(void)
{
	serio_register_device(&atkbd_dev);
	return 0;
}

void __exit atkbd_exit(void)
{
	serio_unregister_device(&atkbd_dev);
}

module_init(atkbd_init);
module_exit(atkbd_exit);

Re: Dell Latitude CPi keyboard problems since 2.5.42

[Mikael Pettersson]

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);
 }
 
 /*

Re: Dell Latitude CPi keyboard problems since 2.5.42

[Vojtech Pavlik]

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

Re: Dell Latitude CPi keyboard problems since 2.5.42

[Tom Sightler]

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

Re: Dell Latitude CPi keyboard problems since 2.5.42

[Vojtech Pavlik]

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