Page fault, GEOM problem??

[Xin LI]

Hi, Johan,

On 11/18/05, Johan Ström <johan at stromnet.org> wrote:
> On 18 nov 2005, at 10.17, Xin LI wrote:
[snip]
> Doesnt look like I got any "usable" dump devices..
> When booting i get
[...]
> Loading configuration files.
> No suitable dump device was found.
> Entropy harvesting:
> interrupts
> ethernet
> point_to_point
> kickstart
> .
> swapon: adding /dev/mirror/gm0s1b as swap device

I see, so your both SATA disks are in the same mirror group...

> Then naturally:
> /etc/rc: WARNING: Dump device does not exist.  Savecore not run.
>
> Looked around in the rc-scripts and tried to figure out what it did,
> the dumpon script
> tries to autolookup a good dump device but finds none..

Unfortunately, kernel dumps currently does not support every device,
for some technical reasons (probably to simplify the crash code so
they do not make more mistakes^Wdamages)

> According to the page you linked to, the dumpon command has to be
> executed AFTER swapon.. Why is the rc scripts trying to run it before
> swapon then?

I guess this is because that dumpon now can detect dump device
automatically, but I'm not quite sure about this.  Will look for the
reason.  I think either Handbook should be updated, or the code should
be corrected.

What I am very curious is that why dumpon is "BEFORE" savecore.  Maybe
I have some misunderstanding...

> Anyway, tried to do dumpon manually on my swap drive:
>
> $ dumpon -v /dev/mirror/gm0s1b
> dumpon: ioctl(DIOCSKERNELDUMP): Operation not supported
>
> Didn't work too good..
> Also tried savecore manually:
>
> $ savecore /var/crash/ /dev/mirror/gm0s1b
> savecore: no dumps found
>
> Didnt work very good either (but probably expected since there was no
> working dumps..)
> Google showed me some other thread in this list about gmirror swap
> dump, just a question (if it was supported) w/o any answers tho. Same
> error as I got.

It seems that this could not be workaround'ed easily.  If possible, my
suggestion is that you attach a third disk and create a swap partition
on it for the crash dump.  If this is not feasible, then adding DDB
and KDB may give us a chance to catch the panic and you can use
"trace" command at the ddb> prompt to obtain a simplified backtrace,
and there is good chance that it would reveal what is happening.

I have cc'ed to Pawel who is very knowledgeable in this area, and
let's see whether he has some better suggestions :-)

Cheers,
--
Xin LI <delphij at delphij.net> http://www.delphij.net