acpi_ec patch/problem attaching on boot
wbh at conducive.org
Wed Mar 2 01:12:12 PST 2005
Brock Johnson wrote:
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
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.
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
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
More information about the Submit