Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Gene Heskett]

On Monday 12 March 2007, Gene Heskett wrote:
>On Monday 12 March 2007, Con Kolivas wrote:
>>On 12/03/07, Gene Heskett <gene.heskett@xxxxxxxxx> wrote:
>>> On Monday 12 March 2007, Gene Heskett wrote:
>>> >To Con, I knew 2.6.20 worked with your earlier patches, so rather
>>> > than revert all the way, I just rebooted to 2.6.20.2-rdsl-0.30 and
>>> > I'm going to fire off another backup.  I suspect it will work, but
>>> > will advise the next time I wake up.
>>>
>>> After posting the above, I thought maybe I'd hit a target in the
>>> middle and build a 2.6.20.2, with your -0.30 patch, but...
>>>
>>> I'm going to have to build a 2.6.20.2, because with the rdsl-0.30
>>> patch, its going to do a level 2 on my /usr/movies directory, which
>>> hasn't been touched in 90 days and has about 8.1GB in it according to
>>> du, and its going to do nearly all of it.  It shouldn't be anything
>>> but a directory listing file. But this is what amstatus is reporting:
>>> coyote:/usr/movies            2     7271m dumping      793m ( 10.91%)
>>> (7:26:00)
>>>
>>> And its also reporting far more data than exists it seems. As is du,
>>> for /var, which might have 2 gigs, its claiming 3.7!
>>>
>>> Honest folks, I'm not smoking anything, I quit 18 years ago.  Back to
>>> bed while this one bombs out too.
>>>
>>> --
>>> Cheers, Gene
>>
>>Gene your last good kernel you said was 2.6.20 based. I don't see a
>>good reason even to use 2.6.20.2 as a base given that information.
>
>I have 2.6.20.1 building now.  I know that 2.6.20-ck1 worked well, so
> now I walking fwd from 2.6.20, trying to bisect it.  .1 wasn't much of
> a patch, but who knows at this point, I'm not 'the shadow' in a 65 year
> old radio show.  And it looks like that build is done, so here goes the
> next test.
>
>The worst thing about this is that amanda's database is being hosed
>everytime this happens, and it's been 3 runs in a row, in a dumpcycle of
>5, where this has occurred.  I can do one more bad run by pre-clearing
>the vtape +1 that's it is going to use each time because the partition
>being used for vtapes is sitting at about 93% utilization now.  Normal
>life, its about 84%, it is a 175GB partition.  That also is stirring
>around in the old girls database when I kill stuff she thinks is there,
>but its also about 3 dumpcycles back and pretty much out of the picture
>so she will recover in a couple of dumpcycles once I find this, if
> indeed I do.
>
>You've cooked up patches for all this, so it 2.6.20.1 works ok, then I
> try your patch on that one.  I tried 2.6.21-rc1, and it bombed too, but
> I just figured that was an -rc1, and we're expected to lose a pint of
> blood at most any -rc1 aren't we?, so I didn't give it any great
> thought and reverted till -rc2 came out.  But I ramble &
> times-a-wasting.
>
For those following this thread, testing is halted momentarily due to a 
bug in my amanda wrapper scripts discovered when I told it to do a flush 
so the next run had a clean slate.  Alan Pearson and I are exchanging 
emails on that.  The script problem however is not connected to this, its 
just that the wrapper needs to be right under all conditions and it 
wasn't.  A few hours lag here.

Does anybody on the Cc: list need off it?

>>--
>>-ck



-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
"I am ecstatic that some moron re-invented a 1995 windows fuckup."
        -- Alan Cox
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/