Re: panic: ffs_valloc: dup alloc

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sat, Mar 20, 2010 at 04:06:32PM -0400, Steven Bellovin wrote:
 > > That suggests that something is flushing buffers to a device that's
 > > suspended and it's throwing them away instead of rejecting them or
 > > panicing.
 > 
 > Possibly....

Although it doesn't quite make sense, because in most cases this could
only corrupt the fs if the same block was left untouched afterwards
for long enough for the (allegedly) clean buffer to be discarded, and
that shouldn't cause a panic right after resume. Unless the fs was
already broken from a previous suspend, I guess.

Maybe there's suspend code somewhere that writes out and also discards
buffers in the hopes of cleaning up for some future suspend-to-disk
work? Could be, I guess, but I'd tend to think not. I ought to go look
at the code but I don't think I have time for that this weekend. :-|

 > > Does stuffing a couple sync calls somewhere before it starts
 > > suspending devices (wherever that is, I don't know) make the problems
 > > go away?
 >
 > No -- I've had a sync call in my suspend script for years.  More
 > precisely, at the moment it's
 > 
 >      sync; sleep 1
 > 
 > to let things flush.  No joy.

That might not be late enough; I was thinking of inside the kernel.

 > Of course, rejecting them wouldn't seem to do any good; what's
 > needed, I suspect, is for the device to queue them (as usual) but
 > not fire up the disk when in suspending mode.

Or for the writes to not be issued at all until after resume.

ISTM it must be either the syncer firing at the wrong time or
something's gotten out of order in the suspend sequencing.

-- 
David A. Holland
dholland%netbsd.org@localhost