While trying out a Dell Latitude E6400, I notice sluggish keyboard
behaviour. This occurs both in 4.5 as well as the Oct. 2 snapshot
(-current). In each case, I use the amd64 snapshots. The issues
disappear when disabling ACPI via UKC.

What I see is the following: some keypresses being 'missed',
occasional repeats of keys pressed (though only once). Additionally, I
sometimes see a briefly non-responsive mousepad in X.

Trying acpidump(8) results in a segfault (and accompanying coredump).
Are others seeing this as well? I included dmesg and acpidump output
at the links below. Other than that, this laptop seems to work fine
(but I wouldn't be surprised if Dell does some undocumented dark magic
in its ACPI somewhere).

Are others seeing this sort of issue as well or does anyone have a
suggestion as to what to try?


dmesg 4.6-current (Oct. 2 snapshot, amd64)
http://pastebin.com/f40be7a33

acpidump 4.6-current (Oct. 2 snapshot, amd64)
http://pastebin.com/f10da9f0c
(acpidump segfaults when run; if desired, I have the core file saved)

Any insight appreciated,

Rogier

[ message continues ]

This fixes it.  I need to come up with a way to get this in the tree
without breaking IBM T21.

Index: acpiec.c
===================================================================
RCS file: /cvs/src/sys/dev/acpi/acpiec.c,v
retrieving revision 1.28
diff -u -p -r1.28 acpiec.c
--- acpiec.c	11 Mar 2009 20:37:46 -0000	1.28
+++ acpiec.c	1 Jun 2009 21:08:30 -0000
@@ -102,10 +102,7 @@ acpiec_wait(struct acpiec_softc *sc, u_i
 	while (((stat = acpiec_status(sc)) & mask) != val) {
 		if (stat & EC_STAT_SCI_EVT)
 			sc->sc_gotsci = 1;
-		if (cold)
-			delay(1);
-		else
-			tsleep(sc, PWAIT, "ecwait", 1);
+		delay(1);
 	}
 
 	dnprintf(40, "%s: EC wait_ns, stat: %b\n", DEVNAME(sc), (int)stat,


[ message continues ]

Thank you very much, Marco. I can't wait to try the diff. Unfortunately,
I don't have time today or tomorrow, so you'll have to wait for
potential feedback...

Rogier: I experience the same thing. Among a couple of other dmesg@
mails, I sent the following mail in August:

----- Forwarded message from Martin Toft <mt@martintoft.dk> -----

Date: Wed, 5 Aug 2009 11:31:09 +0200
From: Martin Toft <mt@martintoft.dk>
To: dmesg@openbsd.org
Subject: Re: Dell Latitude E6400, everything works, had to switch disk controller to ATA (from IRR) in BIOS to detect disk

Some things I've discovered since I sent the dmesg:

- The cdrom drive isn't detected when the disk controller is set to ATA
  in BIOS. This is also the case in Ubuntu Linux 9.04 (I dual-boot
  OpenBSD and Ubuntu).
- The laptop's keyboard is very annoying in OpenBSD. With about 10-20
  second intervals, either single key presses are lost or a key press is
  repeated 5-10 times. My guess is that it's an USB keyboard, and
  OpenBSD is probably not powering down (or up) the relevant USB
  controller properly in connection with halt (or boot). It's a wild
  guess, of course.

As a non-expert, I unfortunately have no solution for the keyboard
problem. I'm ready to test anything sent in my direction.

Thanks for a great OS.

Best regards,
Martin

----- End forwarded message -----

[ message continues ]

Indeed it does. Where I originally noticed the problem very quickly
after system startup, it now seems to have disappeared. I still see
acpidump segfaulting (but I can't tell whether that's a related issue
or not). Tested on GENERIC.MP built this morning.

dmesg 4.6-current (Oct. 4, amd64)
http://pastebin.com/f605fda4d

acpidump 4.6-current (Oct. 4, amd64)
http://pastebin.com/f45f19d9d
(acpidump still segfaults when run; if desired, I have the core file saved)

If I can be of help testing further, please let me know. Thanks for
the quick response.

Regards,

Rogier

[ message continues ]