> As I said: I still think there is a lost serialization here
> that's at the root of the problem. I can't really dedicate
> the equipment I have here to reproducing the issue at this
> time, or I'd track down the race I think may be happening.
>
> -- Terry

The original panic in kern/52718 is no longer reproduceable for me at
this time. After Jeff's latest changes, the panic moved from boot time to
panicking when I did an init 6. I could _not_ reproduce the new panic
if I built a kernel with DDB, but a DDBless kernel would panic every time
after init 6. Needles to say, that makes things really tough to track
down...

After shit-canning the acpi module, it doesn't panic at all. I'm sure
the race conditions are still lying in wait, but due to a lack of
interest and the incredulous attitude of most on the mailing list, I'm
going to forget about it for the time being.

ACPI has always worked fine on my system, and I'm probably masking
problems by not loading the module. Since I'm running a desktop
system here, acpi doesn't really buy me anything, so apm is back in my
kernel.

Relevant Pages

Re: umtx/libthr SMP fixes.... >> that's at the root of the problem. ... >> the equipment I have here to reproducing the issue at this ... > if I built a kernel with DDB, but a DDBless kernel would panic every time ... > After shit-canning the acpi module,...(freebsd-current)