Re: acpi_ec patch/problem attaching on boot

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

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