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:50 PM, Steven Bellovin wrote:

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

Turns out that I sendpr-ed it in September: kern/42104.

                --Steve Bellovin,

Home | Main Index | Thread Index | Old Index