Konishiwa ! ;)

> Sorry for my inactiveness (as the maintainer of acpi subsystem
> for NetBSD), but I'd like to see what Vincent's real problem is.

No problem. I guess, as Lennhart answered before, we are all busy. I 
currently happen to have some time, both at work and at home, so I could 
dig more deeply into this. That may not be again the case before summer.

> Vincent, could you narrow down more _where_ the reboot happens
> in ACPI-CA code?  If it happens _only_ on your laptop in the world,
> it's ok, but if not, there should be a fix for 2.0 and 3.0, not only
> for -current.  Importing a newer ACPI-CA for 2.0 or 3.0 is not
> a good idea.

I have no idea whether it happens only on my laptop or not. I guess it 
is somehow related to event report. As long as the code does not call 
the _BST control method, all is fine. When it calls it, the method 
returns OK with the valid infos. Then, suddently, a short while after, 
the whole system reboots - as if the call had somehow altered the event 
handler and made it point nowhere. There is no crash, no panic, nothing, 
just a plain and mere reboot.

Could be related to sysmon, too. Or to interrupt handling.

I accept that importing a new ACPICA version for 2.0 is useless. But I 
don't see your point for 3.0. When 3.0 is supposed to be derived from 
current?

> Without knowing what's really happening on your laptop when _BST
> is evaluated, the problem may happen in the future again even if
> we import the newer/future version of ACPI-CA, which actually
> happened in the past.

I tried to pinpoint what could have changed twixt version 2.99.12 and 
2.99.13. I found nothing meaningful, but I didn't look anywhere, 
especially not in sysmon code. I don't think it is a bug in ACPICA, 
because nothing was modified.

> I hate the idea of just upgrading the ACPI-CA to fix some of problems.
> In my past experience, a newer ACPI-CA is not always better than older ones.
> The newer one surely has some bug fixes, but also has some
> enhancements/cleanups, which means it may include some new bugs
> or errors.  So if it fixes _your_ problem, it may make _others_ not
> working.  Don't treat ACPI-CA as a black box, just replacing it will
> not make everyone happy (especially makes the developers handle many PR's :)

I see your point. Of course, my point of view is egoistic. Well, it was 
something like: "Since it seems nothing has changed between 2.99.12 and 
2.99.13, it might be a 'resident' bug in the Acpica code, so, instead of 
looking into a foreign code I might never understand, better importing 
the new version, get it to work and see if the bug is still there…"

> Also, the in-tree ACPI-CA has some backported bug-fixes and
> local changes, and newer ACPI-CA may have some equivalent of
> our local changes.  As we should not break the current behavior by
> importing the new one, we have to check whether the things will
> not break as carefully as we can.

I had to change some definitions in the Acpica code in order to glue it 
with the existing OS Layer and driver autoconf.

> With that said, now is a good opportunity to import the newer ACPI-CA,
> because the 3.0 branch is cut, and there's a lot of time to stabilize
> the new one for -current.  But it's another thing to nail down the
> real problem.
> 
> I'd like to work on importing a newer ACPI-CA for -current in a week
> or two.

I was also planning to write a driver for the processor object, by the way!

O sewa ni narimashita ! :)
Sayonara !
Vincent