Matthew Dillon wrote:
quoted text
> 
>     Can you tell the BIOS to put the SATA unit in native mode instead
>     of compatibility mode, and then boot without ACPI?  If we can get it
>     to recognize the native SATA hardware without ACPI we can narrow down
>     the cause of the problem.
> 
> 						-Matt

Well.. booted (UP) ACPI off, SATA on on the other identical machine and
got this fairly soon after startup.

dmesg for both acpi settings and abbreviated backtrace are as follows -
working on getting dumpdevs + camera setup on this machine for future
crashes / problems :)

backtrace had:

  panic
  ufs_dirbad
  ufs_lookup
  ufs_vnoprate
  vop_old_lookup
  vop_compat_nresolv
  vop_defaultop
  cache_resolve
  nlookup
  kern_mkdir
  syscall2
  ... (interrupt 80 handler routine - can't read my writing )
  syscall

Interestingly, this happened shortly after initializing a vinum volume
on another slice .. The corrupted filesystem was a regular FFS on ad4s1d
 (/usr) however.. basically 'pkg_info' lost it's ELF magic & was being
parsed as a script, so I tried to untar my pkgsrc boostrap on top when
the crash happened.

So, I'll either:

a) try to reproduce w/o vinum

   (recalling the 'fun' had with vinum recently I'm now trying
    to fix any vinum issues I find myself as a courtesy
    to everyone else :)

b) try to reproduce w/HEAD

or some combination of both, probably starting with 'a'. Incidentally,
the other machine ran for a bit more than a day and did a full bulk on
the same hardware / partitioning / etc. with vinum enabled, acpi off,
and PATA legacy mode.