tech-kern archive

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

Re: panic: ffs_valloc: dup alloc

On Mar 20, 2010, at 4:17 PM, David Holland wrote:

> 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.

Let me see if I can find my first note on the subject -- it might give a clue 
about the date of any changes.

                --Steve Bellovin,

Home | Main Index | Thread Index | Old Index