freebsd stable - Mar 2012 - ACPI Issues in 8-STABLE and on

All
  I was wondering if anyone has looking into this ACPI issue noted
back in 2010.

http://lists.freebsd.org/pipermail/freebsd-acpi/2010-February/006332.html

I attempted to upgrade a 7-STABLE DL385g1 with 4G of ram to 9-STABLE
and it was a disaster.

The box was able to boot once and then on a normal reboot the root
filesystem was corrupted beyond repair ( most likely unrelated , but
some unknown issue with su+j *)
and the system would not get past the point noted in the a fore
mentioned thread . I tried to boot this box with 8.2-RELASE amd64 same
issue, 9.0-BETA1 , same issue, 9.0-RELEASE same issue , and 9.0-STABLE
as I pointed out worked intermittently.

So the end result is that this box now only reliably runs 7.0-RELEASE
- 7.4-RELEASE and 7-STABLE , 6.2-RELEASE - 6.4-RELEASE and 6-STABLE
but nothing else.

As a side test , NetBSD 6.0 beta amd64 boots with out issues on this
box as well as DragonFlyBSD 3.01 amd64.

So my solutions are to migrate back to 7-STABLE or use Net or Dfly.
Does anyone know what the root issue is here ?


* The su-j issue was most likely caused by me not properly converting
the old su slice to su+j . I think I may have done a tunefs -j enable
before I did a tunefs -n disable && fsck  .

-- 
mark saad | nonesuch@longcount.org

Hi,

Have you filed PRs for this?

It seems like something you could easily(!) find the offending
commit(s) by doing kernel builds of -HEAD around the time that 8 was
branched off.

If 8.0-RELEASE fails but 7-STABLE does, that's a good starting point
to determine the lower/upper bounds for the -HEAD commit(s) that broke
things for you.

It would be really appreciated if you were able to help track this
down as I doubt the ACPI developers have the hardware.

Thanks!


Adrian