lkml.org 
[lkml]   [2007]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: New thread RDSL, post-2.6.20 kernels and amanda (tar) miss-fires
On Wednesday 14 March 2007, William Lee Irwin III wrote:
>On Tue, Mar 13, 2007 at 11:31:53PM -0400, Gene Heskett wrote:
>> Now, can someone suggest a patch I can revert that might fix this?
>> The total number of patches between 2.6.20 and 2.6.21-rc1 will have me
>> building kernels to bisect this till the middle of June at this rate.
>
>4 billion patches could be bisected in 34 boots. Between 2.6.20 and
>2.6.21-rc1 there are only:
>
>$ git rev-list --no-merges v2.6.20..v2.6.21-rc1 |wc -l
>3118
>
>patches, requiring 14 boots. In general ceil(log(n)/log(2))+2 boots.
>
>Of course, this is a little optimistic because it assumes no additional
>breakage occurring at the various bisection points. In any event,
>assuming (pessimistically) 10 minutes per build, this is 280 minutes or
>4 hours and 40 minutes of build time. I estimate the process should
>complete well before Friday of this week, never mind June.

Chuckle, sorry to disappoint you wli, on that 32 cpu Niagra Con was
calling 'poor equipment', maybe.

Even using ccache, its about 15-18 minutes per build, with another 10 to
edit my build script and construct the kernel tree with the proper
patches applied. Then a reboot, probably 10 minutes by the time I get
the nvidia driver installed for the new kernel and get startx'd, then its
another 2 hours or a bit less for an amanda run to test it.

I've posted to the amanda lists too, so they will be aware of it. And
because an ls -lc returns perfectly sane values for the mtimes and sizes,
I suspect the real problem may not necessarily be 100% kernel related. I
have been intermittently ranting because both the tar api stir, and the
return from tar are such a moving target that the developers are having a
hard time staying ahead of the changes to tar, backward compatibility it
seems, is the furthest thing from the tar maintainers minds. The most
recent change that I'm aware of is that tar now returns a 1 for success!
What the heck were those guys at gnu.org thinking? Or smoking as the
case may be.

I obviously have a copy of the -rc1 patch in its entirety that I could
peruse, but I'm not sure I would recognize a change that would effect tar
if it bit me, hence the questions here to those who are far more
conversant than I.

As I've said on several occasions William, at my age, the best part I can
play here is the Canary, in the coal mine scene, and something strange in
the air of 2.6.21* just killed me. It's now up to the coroner(s) to
determine the cause, and he has several dozen very very able assistants
monitoring this list in my NSH opinion. Whatever, either tar, or this
particular board in the kernels architecture surely needs fixed before
2.6.21 final. I don't even know if gnu.org has a bugzilla setup, but
I'll look around tomorrow night as I'm tied up now till late tomorrow.
If they do, I'll file it.

But, I'm also amazed that no one else has been bitten. Don't any of you
ever make a backup using tar for the pack mule?

Thanks William.

>-- wli

--
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)
Do unto others before they undo you.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-03-14 07:13    [W:0.598 / U:0.196 seconds]
©2003-2011 Jasper Spaans. Advertise on this site