Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: ACPI woes on Compaq laptop

2 views
Skip to first unread message

Rhialto

unread,
Jul 29, 2011, 7:06:30 AM7/29/11
to
On Thu 28 Jul 2011 at 22:56:01 +0200, Rhialto wrote:
> Is there anything the above acpi-"devices" have in common, which may
> point to where to search next?

Of course, after posting the above, I updated my sources and tried
again... and for now it seems to work again!

So something that was changed in the last 4 weeks or so made it work
again. (I can't say that it must have been broken in january or so,
since the older working kerneld didn't contain all ACPI things that it
could).

But looking at recently changed acpi_*.c files the following commit
sticks out:

CVS log for src/sys/dev/acpi/acpi_cpu_cstate.c
Revision 1.54: download - view: text, markup, annotated - select for
diffs
Wed Jul 13 07:34:55 2011 UTC (2 weeks, 1 day ago) by jruoho
Branches: MAIN
CVS tags: HEAD
Diff to: previous 1.53: preferred, colored
Changes since revision 1.53: +8 -18 lines

Do not disable interrupts at machine-level in the MI idle-loop entry.

since "freezing" looks a lot like "interrupts disabled".

If I had too much free time on my hands, I'd revert sources to around
the time the interrupt disabling was introduced (rev. 1.133) and check
if that broke it...

-Olaf.
--
___ Olaf 'Rhialto' Seibert -- There's no point being grown-up if you
\X/ rhialto/at/xs4all.nl -- can't be childish sometimes. -The 4th Doctor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de

Rhialto

unread,
Aug 2, 2011, 3:12:35 PM8/2/11
to
On Thu 28 Jul 2011 at 22:56:01 +0200, Rhialto wrote:
> By a process of elimination, I found that if I "boot netbsd -c" and
> disable ALL of the following, then it works (at least I tested for a few
> hours):
>
> acpibat
> vga
> out
> wmi
> dalb
> tz
> cpu
> ec

Bah, I spoke too soon about a recent -current fixing this problem. I
just tried it again, from a cold boot, and within minutes it froze up
again. Worse, even with the above list of drivers disabled, the same
thing happened again!

This seems like one of those initialisation problems, where a working
kernel puts some device in a good state so that it keeps working, and
you don't notice it with a bad kernel unless it boots very cold...

0 new messages