kern/52916 (vinum start/stop panic)

[Paweł Małachowski]

> 15. Kernel panic happens right now, before splx(s), however sometimes splx()
>     is called and biowait() returns with 0 before panic happens.

Actually, this finishing biowait() is not the one called by vinum (bp is
different).


Let's summarize:

It looks that when open_drive() is called, some data in memory are getting
corrupted. After tsleep() [kern/vfs_bio.c, biowait() called from dsinit()],
some other processes have ability to work with disk, however, they usually
fail as described earlier in audit-trail (,,Input/output error'' etc., also
,,handle_workitem_freeblocks: block count'').
In most cases system panics in dscheck() while syncing because of invalid lp
pointer.
Probably this is not an issue when starting vinum from rc.conf, cause / fs
is mounted read-only so write requests are not handled.

This might give a real clue,
I'm testing this on the following HDD configuration:
ad0 - / fs mounted rw (/dev/ad0s1a) and swap (/dev/ad0s1b),
      there are no more partitions or slices
da0 - /dev/da0s1b, used only as a dumpdev
da1 - not used
Running FreeBSD 4.8-STABLE. No vinum slices defined.


When I run: vinum read /dev/da0; vinum stop; ...
it will NOT panic. :)

When I run: vinum read /dev/ad0; vinum stop; ...
it WILL panic.

If I force vinum at vinum_scandisk() to call dscheck()
only for ('b'<=x<'i') partitions and run: vinum read /dev/ad0; vinum stop; ...
seems it will NOT panic.

If I force vinum at vinum_scandisk() to call dscheck()
for ('a'<=x<'i', excluding 'c' and 'b') partition and run:
vinum read /dev/ad0; vinum stop; ...
seems it will NOT panic.

If I force vinum at vinum_scandisk() to call dscheck()
only for ('a'<=x<'c') partitions and run: vinum read /dev/ad0; vinum stop; ...
it WILL panic, but not too fast.

If I force vinum at vinum_scandisk() to call dscheck()
only for ('a'<=x<'b') partition and run: vinum read /dev/ad0; vinum stop; ...
seems it will NOT panic.

where:
,,seems it will NOT panic'' == >500 iterations of read/stop loop without
problem during ad0s1a (cd /usr/ports && make clean) activity.



-- 
Paweł Małachowski