acpi_ec patch/problem attaching on boot

[Bill Hacker]

Brock Johnson wrote:

Hey all,

I got a new laptop about a month ago, promptly put DragonFly on it, and 
acpi worked fine with GENERIC. However, once I switched to a custom 
kernel config (mostly removing unused drivers), acpi_ec wouldn't always 
attach, sometimes it would, sometimes it wouldn't, I started playing 
around with my kernel configs and couldnt find anything definitive, 
though it seemed to be a timing issue, dependant upon the size of the 
kernel binary. So, I went digging through the FreeBSD commit logs for 
anything to do with timing and saw the message from revision 1.56

"date: 2004-07-01 00:51:31 +0000;  author: njl;  state: Exp;  lines: +35 
-48
Rework the code that waits for a response from the EC.  Use an sx lock
instead of a mutex so we do not unblock it in msleep().  If we do this,
another event could occur, resetting the status register since reads
reset it.  While I'm here, remove the backoff approach.  Instead, sleep
in 10 ms chunks for up to the configured timeout using either DELAY (if
we aren't booted yet) or tsleep."

Looking at the commit, we already had similiar logic in EcWaitEvent() in 
our acpi_ec.c, however, the check to determine if acpi was up or not, 
wasn't in ours. So, I brought this over and presto!, acpi_ec attaches 
everytime now. I'm not sure this is correct though, and I didn't take 
the time to go through the acpi code to figure out if this was the 
"right thing"(tm), so I'm hoping an acpi guru will read this and  comment.

Thanks,
Brock
Good work!  You may have also turned up a clue as to why FreeBSD 5.X 
will sometimes 'lose'
an add-on ethernet NIC (or freeze up) after about 20 minutes of sitting 
idle.

Happened on 3 different highly-integrated 'All-in One' consumer MB,
all of which FreeBSD 4.X loved, but not on simpler industrial SBC's.
DragonFlyBSD, on one of the same boards (old A-Open K6) had just started 
exhibiting a different,
but potentially related, problem - jamming the LAN with garbage after 
sitting idle for a longish period.

Time to update ..... (board today, code as soon as it makes it into HEAD).

Will dig into it only if new hardware still has the problem. Not fussed 
about antiques.

Thanks!

Bill Hacker
Bill