Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Yet another test regression: fs/ffs/t_snapshot_log/snapshotstress

On May 6, 2013, at 12:34 PM, Antti Kantee <> wrote:

> On 02.05.2013 18:13, J. Hannken-Illjes wrote:
>> On May 1, 2013, at 3:08 PM, Andreas Gustafsson <> 
>> wrote:
>>> The "snapshotstress" test case of the fs/ffs/t_snapshot_log program has
>>> recently started failing with "signal 6 (core dumped)".  The first
>>> recorded failure with those particular symptoms in the babylon5 i386
>>> tests was with source date 2013.
>>> It also failed in the previous test run (2013., but so
>>> did with 644 other tests, so it's hard to say if that's relevant or
>>> not.
> The change that causes KASSERT(BC_BUSY) to fire is most likely the one which 
> made the rump kernel block driver do asynchronous I/O, where it always 
> previously was synchronous inside the rump kernel (the async part was 
> completely hidden in the hypervisor -- it used mmap/msync).
> Juergen, since your knowledge of vfs is more current than mine, could you 
> have a quick look through the panicking code path with the above-mentioned 
> sync->async change in mind and see if I've missed an obvious wait somewhere.

Looks like RUMP has become much more aggressive regarding scheduling
and block i/o. The buffer in question is DONE and BUSY which means it
is about to be brelse'd.  The assertion was wrong -- should be fixed
with ffs_snapshot.c rev 1.122.

J. Hannken-Illjes - - TU Braunschweig 

Home | Main Index | Thread Index | Old Index