Hello ! (This time in plain English)

> This should be "kon-nichiwa"(hello) :)

Sorry for the misspelling. My knowlege of the Japanese is scarse! :)

> Hmm, the reboot is asynchronous to the evaluation of _BST.
> Can I interpret 'reboot' as 'immediate hardware reset' (just confirming)?
> Without any trace or crash dump, it's very hard to track down,
> and it's even worse for remote debugging!

You can. It behaves exactly as if the processor executed a "reset" 
instruction.

> 3.0 is already branched from -current, and it's too late to make a
> big change like replacing ACPI CA.  But maybe we can maintain a
> separate patch for 2.0/3.0 (update to the latest ACPI CA, for people
> suffering from bugs).

Why not ? That could be nice indeed.

>>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"
> And it works ok with the new version, right?

No. It doesn't. At least it doesn't yet. Acpicad is here, but, somehow, 
the callbacks (handlers) seems not be registred properly. The code 
reports no batteries present. Acpiec ceased to work, only TZ, lid 
switch, power button seem to have survived the transition. That's why 
there _is_ some work to do! :)

>>I was also planning to write a driver for the processor object, by the way!
> When you finish writing it, I'm glad to review it.

With great pleasure! But I'd like first to make what worked work again! :)

Alligato !
Vincent