Re: system freeze on "slice too large"

[Chris Turner <c.turner@xxxxxxxxxxxxxxxxxxx>]

Simon 'corecode' Schubert wrote:

> hey,
> 
> i've now had twice a nasty freeze (kind of) with something like this
> (hand transcribed):
> 
> dscheck(#ad/0x20021): slice too large 2/2

I'm definitely under the impression that vinum is unhappy with the new
labels.

2 things perhaps worth discussion:

 - your 'a' partition overlaps the vinum - I assume this means
   you're using a vinum root?
 - was your volume set created prior to upgrading past the disklabel
   changes?
 - is this an occasional crash, or a constant one?

just chiming in to get some more data points out on this I suppose..
b/c this is most definably over my kernel-n00b head :)

test findings here from last night :

 - able to create a new disk set (see the other thread)
 - unable to use the disk set after reboot without a vinum resetconfig,
   reload config files kind of thing (e.g. vinum 'start' messes up and
   needs to be reminded of the disk layout)
 - having 'vinum_enable="YES"' in rc.conf keeps me from booting up,
   as it appears to make the kernel very confused about it's various
   mount points (e.g. after vinum start, it 'forget's about existing
   'raw partition' mounts and can't find getty, etc...)

when I booted with no vinum_enable and 'vinum list' yields no drives,
and 'vinum start'ed  causes the 'raw partition amneisia' to set in,  I
get some of those dscheck messages like you saw. I then couldn't drop to
the debugger, and cntrl-alt-del resulted in some very interesting
infinite loop printouts ..

perhaps the mountpoint confusion explains why the dump didn't work for you?

unfortunately, I don't have the problem machine hooked up to a
serial console yet to snag the output, and due to other events I'm going
to be unable to test for the next few weeks..