2.6.18 kernel status

2.6.18 kernel status

[John Hannfield]

Hello,

I am just trying out the 2.6.18 kernel in xen-unstable.hg , but on doing a
make linux-2.6-xen0-build I'm getting to the following error.

drivers/built-in.o: In function `take_machine_down':
machine_reboot.c:(.text+0xc2a42): undefined reference to `cpu_initialized_map'
make[4]: *** [.tmp_vmlinux1] Error 1
make[3]: *** [vmlinuz] Error 2
make[2]: *** [vmlinuz] Error 2
make[2]: Leaving directory
`/home/hal/code/xen/xen-unstable.hg/build-linux-2.6.18-xen0_x86_64'
make[1]: *** [build] Error 2
make[1]: Leaving directory `/home/hal/code/xen/xen-unstable.hg'
make: *** [linux-2.6-xen0-install] Error 2

Does the kernel compile cleanly on x86_64?  I guess it's a moving target in
xen-unstable, so it might work tomorrow.

Also I am just wondering what the roadmap is for getting 2.6.18  in
the released branches.
Is it likely to be offered in 3.0.5  or will it have to wait for 3.1.x
or 4.0.x ?

Thanks

-- 

John

Re: 2.6.18 kernel status

[Keir Fraser]

On 5/3/07 23:53, "John Hannfield" <hal9020@gmail.com> wrote:

> I am just trying out the 2.6.18 kernel in xen-unstable.hg , but on doing a
> make linux-2.6-xen0-build I'm getting to the following error.

This is fixed but the patch is stuck in our staging tree until regression
tests pass.

 -- Keir

Re: 2.6.18 kernel status

[John Hannfield]

> This is fixed but the patch is stuck in our staging tree until regression
> tests pass.

OK great. Though I am not that familiar with the automated testing.
When does this happen? Is it daily/weekly etc?

-- 

John

Re: 2.6.18 kernel status

[Mark Williamson]

> > This is fixed but the patch is stuck in our staging tree until regression
> > tests pass.
>
> OK great. Though I am not that familiar with the automated testing.
> When does this happen? Is it daily/weekly etc?

I think it's a case of "when the tests pass" rather than a regular push 
scheule: the regression tests run when new stuff has been pushed to the 
staging tree.  If/when the tests on the contents of staging pass, they get 
pushed out to the mainline tree.

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

Re: 2.6.18 kernel status

[John Hannfield]

> I think it's a case of "when the tests pass" rather than a regular push

Oh ok. But from your experience when does this usually happen? Is it likely
to be a few days or weeks? I'm just trying to get a handle on when I should
re-try a hg pull to get this patch.

Cheers,

-- 

John

Re: 2.6.18 kernel status

[Daniel P. Berrange]

On Tue, Mar 06, 2007 at 10:28:38AM +0000, Keir Fraser wrote:
> 
> On 5/3/07 23:53, "John Hannfield" <hal9020@gmail.com> wrote:
> 
> > I am just trying out the 2.6.18 kernel in xen-unstable.hg , but on doing a
> > make linux-2.6-xen0-build I'm getting to the following error.
> 
> This is fixed but the patch is stuck in our staging tree until regression
> tests pass.

How about making your staging tree publically viewable so people get better
visibility into whether patches sent to xen-devel have been picked up and
integrated into the tree ? Sure, we don't want people to be actually working
against a staging tree, but I think being able to see what's coming along
in the staging tree would be good for transparency / communications with
the non-XenSource people whom are posting patches. 

In this particular instance it would also allow for end-user testing of
the aforementioned kernel patch in parallel with the automated tests,
rather than serializing the test proces.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

RE: 2.6.18 kernel status

[Petersson, Mats]

 

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com 
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of 
> Daniel P. Berrange
> Sent: 06 March 2007 17:20
> To: Keir Fraser
> Cc: John Hannfield; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] 2.6.18 kernel status
> 
> On Tue, Mar 06, 2007 at 10:28:38AM +0000, Keir Fraser wrote:
> > 
> > On 5/3/07 23:53, "John Hannfield" <hal9020@gmail.com> wrote:
> > 
> > > I am just trying out the 2.6.18 kernel in xen-unstable.hg 
> , but on doing a
> > > make linux-2.6-xen0-build I'm getting to the following error.
> > 
> > This is fixed but the patch is stuck in our staging tree 
> until regression
> > tests pass.
> 
> How about making your staging tree publically viewable so 
> people get better
> visibility into whether patches sent to xen-devel have been 
> picked up and
> integrated into the tree ? Sure, we don't want people to be 
> actually working
> against a staging tree, but I think being able to see what's 
> coming along
> in the staging tree would be good for transparency / 
> communications with
> the non-XenSource people whom are posting patches. 

The whole point of the staging tree is to get xen-unstable a bit more
stable. All changes come to the Xen-unstable tree eventually - and
usually within hours of hitting the staging tree. 

As you probably are aware, the stability of Xen-unstable isn't always
wonderfull DESPITE going through the "basic test suite" - because it's
just basic automated testing. 

Adding a "unstabler-unstable" isn't a great idea for MOST people - so it
would be of fairly limited use. 

> 
> In this particular instance it would also allow for end-user 
> testing of
> the aforementioned kernel patch in parallel with the automated tests,
> rather than serializing the test proces.

In some circumstances this may be to an advantage, but for most cases, I
would say it's not particularly helpful. 

--
Mats
> 
> Regards,
> Dan.
> -- 
> |=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 
> 978 392 2496 -=|
> |=-           Perl modules: http://search.cpan.org/~danberr/  
>             -=|
> |=-               Projects: http://freshmeat.net/~danielpb/   
>             -=|
> |=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF 
> F742 7D3B 9505  -=| 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> 
> 

RE: 2.6.18 kernel status

[Ian Pratt]

> How about making your staging tree publically viewable so people get
> better
> visibility into whether patches sent to xen-devel have been picked up
> and
> integrated into the tree ? Sure, we don't want people to be actually
> working
> against a staging tree, but I think being able to see what's coming
> along
> in the staging tree would be good for transparency / communications
with
> the non-XenSource people whom are posting patches.

The staging tree is not widely advertised as most folk are much better
off using the post-RT'ed tree. The location has been posted on this list
several times, you must just have missed it: Just add 'staging' as a
directory name to the URL. If you want to know about commits just
subscribe to the RSS feed [it currently looks like there are well over
100 people who do this]

Best,
Ian 

Re: 2.6.18 kernel status

[Daniel P. Berrange]

On Tue, Mar 06, 2007 at 05:37:55PM -0000, Ian Pratt wrote:
> > How about making your staging tree publically viewable so people get
> > better
> > visibility into whether patches sent to xen-devel have been picked up
> > and
> > integrated into the tree ? Sure, we don't want people to be actually
> > working
> > against a staging tree, but I think being able to see what's coming
> > along
> > in the staging tree would be good for transparency / communications
> with
> > the non-XenSource people whom are posting patches.
> 
> The staging tree is not widely advertised as most folk are much better
> off using the post-RT'ed tree. The location has been posted on this list
> several times, you must just have missed it: Just add 'staging' as a
> directory name to the URL. If you want to know about commits just
> subscribe to the RSS feed [it currently looks like there are well over
> 100 people who do this]

Excellant - that's just what I wanted to know thanks :-)

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

Re: 2.6.18 kernel status

[Mark Williamson]

> > I think it's a case of "when the tests pass" rather than a regular push
>
> Oh ok. But from your experience when does this usually happen? Is it likely
> to be a few days or weeks? I'm just trying to get a handle on when I should
> re-try a hg pull to get this patch.

I believe it can be a matter of hours if the tests pass first time.  If one of 
the changesets in the staging tree causes the tests to fail then they'll all 
be stuck there until a fix is added and the tests finally pass - this can 
sometimes take a few days, I think, but shouldn't be the usual case.

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

Re: 2.6.18 kernel status

[Ian Campbell]

On Tue, 2007-03-06 at 17:44 +0000, Mark Williamson wrote:
> > > I think it's a case of "when the tests pass" rather than a regular push
> >
> > Oh ok. But from your experience when does this usually happen? Is it likely
> > to be a few days or weeks? I'm just trying to get a handle on when I should
> > re-try a hg pull to get this patch.
> 
> I believe it can be a matter of hours if the tests pass first time.  If one of 
> the changesets in the staging tree causes the tests to fail then they'll all 
> be stuck there until a fix is added and the tests finally pass - this can 
> sometimes take a few days, I think, but shouldn't be the usual case.

There's a few gremlins in the testing infrastructure at the moment.
People are looking into it and it ought to pass soon ;-)

Ian.