DragonFly bugs List (threaded) for 2004-08
Re: ACPI experience
:On Tue, 17 Aug 2004, Matthew Dillon wrote:
:> A 'ps' would help, but what would *really* help would be a kernel core...
:It's set up to dump, but won't write core to /dev/ar0b. Unless
:others have had success with Promise cards, I suspect the problem
:is every partition (including swap) is hanging off of a Promise
:RAID controller. dumpdev is set, but it just doesn't write the
:kernel core as if it weren't.
No, it's a driver issue. There is no driver support for core dumping
through promise cards. (dumping is a matter of having a way to send
device commands and poll for results without using interrupts).
:BTW, how would one go about setting the dump device in DDB (the
:system hangs before it even comes up into multi-user)? Is it just
:a matter of setting kern.dumpdev? Hmmm major minor... how would
:that actually look in DDB or loader.conf?
My hope was that it was getting far enough to pull in the rc dumpdev
configuration. FreeBSD-4 used to have a way to set the dump device in
the kernel config but some bozo pulled it out (long before we forked).
If you want to experiment you could try downloading and burning
various SNAPshots to locate the approximate date range where it
started failing on you again.
:Anyway, for now I'm happy with not running w/ACPI. If it helps,
:here's a "ps ax" -- nothing unusual, running 3 jails with postfix,
It's possible that it reaches multi-user but doesn't get through
the program startup. postfix does do a lot of locking at startup.
It may be worth breaking into the debugger and doing a 'ps'. Maybe
don't try to write down the whole thing :-) But look to see if any
standard processes like 'init' are running, or if any services are
Another thing you could try doing is booting into single-user mode.
If you can boot into single user mode with ACPI turned on then the
issue might be related to some service the system is starting up.