Re: Future of xenbits Linux trees

Re: Future of xenbits Linux trees

[Boris Derzhavets]

[-- Attachment #1.1: Type: text/plain, Size: 1575 bytes --]

Kernel: arch/x86/boot/vmlinuz is ready  (#2)
ERROR: "wmi_install_notify_handler" [drivers/misc/hp-wmi.ko] undefined!
ERROR: "wmi_remove_notify_handler" [drivers/misc/hp-wmi.ko] undefined!
ERROR: "wmi_has_guid" [drivers/misc/hp-wmi.ko] undefined!
ERROR: "wmi_has_guid" [drivers/misc/acer-wmi.ko] undefined!
WARNING: modpost: Found 3 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

Boris.

--- On Thu, 6/4/09, Jean Guyader <jean.guyader@gmail.com> wrote:

From: Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] Future of xenbits Linux trees
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "Keir Fraser" <keir.fraser@eu.citrix.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thursday, June 4, 2009, 2:46 PM

2009/6/4 Boris Derzhavets <bderzhavets@yahoo.com>:
>>> Our proposal is to move XCI's linux-2.6.27 tree out of the XCI subproject
>>> and make it the main user tree. Development and automated testing would
> . . . . . .
>
>> This tree is not tied up with XCI at all.
>> It can be taken as it and runs on the top of mainstream xen.
>
> How to checkout this tree ?
>


$ git clone http://xenbits.xen.org/git-http/xenclient/linux-2.6.27.git
$ cd linux-2.6.27
$ git clone http://xenbits.xen.org/git-http/xenclient/linux-2.6.27-pq.git
.git/patches
$ guilt-push -a

Make sure you have a recent enough version of guilt, 0.30 has issue
with big patches.

Jean



      

[-- Attachment #1.2: Type: text/html, Size: 2291 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Future of xenbits Linux trees

[Genki Kuroda]

Hello, Boris,

I had the same error, but I was able to compile after commenting out
the "HACK ALERT" section in /drivers/acpi/ec.c
More information seems to be in wmi.c.

Who is taking care of this kind of issue? This is my first post...

Here is the patch to show where I commented out.

diff –git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 2359480..b2c0221 100644
— a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -387,6 +387,7 @@ static int acpi_ec_read(struct acpi_ec *ec, u8
address, u8 * data)
/* HACK ALERT
* Please refer to wmi.c for an explanation on why we added this hack.
*/
+/*
if ( in_query_wmi_event_data == TRUE ) {
if ( address == 0×2b ) {
wmi_event_data_index = 0;
@@ -398,6 +399,7 @@ static int acpi_ec_read(struct acpi_ec *ec, u8
address, u8 * data)
wmi_event_data_index++;
}
}
+*/

return result;
}


-- 
Genki Kuroda
E-mail: genkikuroda@gmail.com
Website: http://mulps.wordpress.com/

On Fri, Jun 5, 2009 at 12:53 AM, Boris Derzhavets<bderzhavets@yahoo.com> wrote:
> Kernel: arch/x86/boot/vmlinuz is ready  (#2)
> ERROR: "wmi_install_notify_handler" [drivers/misc/hp-wmi.ko] undefined!
> ERROR: "wmi_remove_notify_handler" [drivers/misc/hp-wmi.ko] undefined!
> ERROR: "wmi_has_guid" [drivers/misc/hp-wmi.ko] undefined!
> ERROR: "wmi_has_guid" [drivers/misc/acer-wmi.ko] undefined!
> WARNING: modpost: Found 3 section mismatch(es).
> To see full details build your kernel with:
> 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
>
> Boris.

RE: Future of xenbits Linux trees

[Kamala Narasimhan]

[-- Attachment #1: Type: text/plain, Size: 2655 bytes --]

The xen-acpi-wmi patch in XenClient linux 2.6.27 patch queue is tied to XenClient.  I didn't expect this patch to be used outside the scope of XenClient which is why you encounter the below issues.

Could you please momentarily exclude the patch before pushing the rest or revert it if already applied and then build that branch?  Going forward, I will create a XenClient flavor of wmi.c that won't step on the base wmi implementation and configure the two to be mutually exclusive.

Kamala

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Genki Kuroda
> Sent: Friday, June 05, 2009 7:06 PM
> To: Boris Derzhavets
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] Future of xenbits Linux trees
> 
> Hello, Boris,
> 
> I had the same error, but I was able to compile after commenting out
> the "HACK ALERT" section in /drivers/acpi/ec.c
> More information seems to be in wmi.c.
> 
> Who is taking care of this kind of issue? This is my first post...
> 
> Here is the patch to show where I commented out.
> 
> diff –git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
> index 2359480..b2c0221 100644
> — a/drivers/acpi/ec.c
> +++ b/drivers/acpi/ec.c
> @@ -387,6 +387,7 @@ static int acpi_ec_read(struct acpi_ec *ec, u8
> address, u8 * data)
> /* HACK ALERT
> * Please refer to wmi.c for an explanation on why we added this hack.
> */
> +/*
> if ( in_query_wmi_event_data == TRUE ) {
> if ( address == 0×2b ) {
> wmi_event_data_index = 0;
> @@ -398,6 +399,7 @@ static int acpi_ec_read(struct acpi_ec *ec, u8
> address, u8 * data)
> wmi_event_data_index++;
> }
> }
> +*/
> 
> return result;
> }
> 
> 
> --
> Genki Kuroda
> E-mail: genkikuroda@gmail.com
> Website: http://mulps.wordpress.com/
> 
> On Fri, Jun 5, 2009 at 12:53 AM, Boris
> Derzhavets<bderzhavets@yahoo.com> wrote:
> > Kernel: arch/x86/boot/vmlinuz is ready  (#2)
> > ERROR: "wmi_install_notify_handler" [drivers/misc/hp-wmi.ko]
> undefined!
> > ERROR: "wmi_remove_notify_handler" [drivers/misc/hp-wmi.ko]
> undefined!
> > ERROR: "wmi_has_guid" [drivers/misc/hp-wmi.ko] undefined!
> > ERROR: "wmi_has_guid" [drivers/misc/acer-wmi.ko] undefined!
> > WARNING: modpost: Found 3 section mismatch(es).
> > To see full details build your kernel with:
> > 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
> > make[1]: *** [__modpost] Error 1
> > make: *** [modules] Error 2
> >
> > Boris.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Future of xenbits Linux trees

[Genki Kuroda]

Hi, Kamala,

Thank you for the information.
I didn't apply the patch, and I don't have any intention to apply the
patch for this issue.

GK

On Fri, Jun 5, 2009 at 7:17 PM, Kamala
Narasimhan<Kamala.Narasimhan@citrix.com> wrote:
> The xen-acpi-wmi patch in XenClient linux 2.6.27 patch queue is tied to XenClient.  I didn't expect this patch to be used outside the scope of XenClient which is why you encounter the below issues.
>
> Could you please momentarily exclude the patch before pushing the rest or revert it if already applied and then build that branch?  Going forward, I will create a XenClient flavor of wmi.c that won't step on the base wmi implementation and configure the two to be mutually exclusive.
>
> Kamala
>
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
>> bounces@lists.xensource.com] On Behalf Of Genki Kuroda
>> Sent: Friday, June 05, 2009 7:06 PM
>> To: Boris Derzhavets
>> Cc: xen-devel@lists.xensource.com
>> Subject: Re: [Xen-devel] Future of xenbits Linux trees
>>
>> Hello, Boris,
>>
>> I had the same error, but I was able to compile after commenting out
>> the "HACK ALERT" section in /drivers/acpi/ec.c
>> More information seems to be in wmi.c.
>>
>> Who is taking care of this kind of issue? This is my first post...
>>
>> Here is the patch to show where I commented out.
>>
>> diff –git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
>> index 2359480..b2c0221 100644
>> — a/drivers/acpi/ec.c
>> +++ b/drivers/acpi/ec.c
>> @@ -387,6 +387,7 @@ static int acpi_ec_read(struct acpi_ec *ec, u8
>> address, u8 * data)
>> /* HACK ALERT
>> * Please refer to wmi.c for an explanation on why we added this hack.
>> */
>> +/*
>> if ( in_query_wmi_event_data == TRUE ) {
>> if ( address == 0×2b ) {
>> wmi_event_data_index = 0;
>> @@ -398,6 +399,7 @@ static int acpi_ec_read(struct acpi_ec *ec, u8
>> address, u8 * data)
>> wmi_event_data_index++;
>> }
>> }
>> +*/
>>
>> return result;
>> }
>>
>>
>> --
>> Genki Kuroda
>> E-mail: genkikuroda@gmail.com
>> Website: http://mulps.wordpress.com/
>>
>> On Fri, Jun 5, 2009 at 12:53 AM, Boris
>> Derzhavets<bderzhavets@yahoo.com> wrote:
>> > Kernel: arch/x86/boot/vmlinuz is ready  (#2)
>> > ERROR: "wmi_install_notify_handler" [drivers/misc/hp-wmi.ko]
>> undefined!
>> > ERROR: "wmi_remove_notify_handler" [drivers/misc/hp-wmi.ko]
>> undefined!
>> > ERROR: "wmi_has_guid" [drivers/misc/hp-wmi.ko] undefined!
>> > ERROR: "wmi_has_guid" [drivers/misc/acer-wmi.ko] undefined!
>> > WARNING: modpost: Found 3 section mismatch(es).
>> > To see full details build your kernel with:
>> > 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
>> > make[1]: *** [__modpost] Error 1
>> > make: *** [modules] Error 2
>> >
>> > Boris.
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>

RE: Future of xenbits Linux trees

[Kamala Narasimhan]

[-- Attachment #1: Type: text/plain, Size: 3604 bytes --]

Just to clarify - You mean you encounter wmi build issues mentioned below with XenClient Linux 2.6.27 even when you *don't* apply the xen-acpi-wmi patch from XenClient Linux 2.6.27 patch queue?

Kamala

> -----Original Message-----
> From: Genki Kuroda [mailto:sfsugar@gmail.com]
> Sent: Friday, June 05, 2009 10:48 PM
> To: Kamala Narasimhan
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] Future of xenbits Linux trees
> 
> Hi, Kamala,
> 
> Thank you for the information.
> I didn't apply the patch, and I don't have any intention to apply the
> patch for this issue.
> 
> GK
> 
> On Fri, Jun 5, 2009 at 7:17 PM, Kamala
> Narasimhan<Kamala.Narasimhan@citrix.com> wrote:
> > The xen-acpi-wmi patch in XenClient linux 2.6.27 patch queue is tied
> to XenClient.  I didn't expect this patch to be used outside the scope
> of XenClient which is why you encounter the below issues.
> >
> > Could you please momentarily exclude the patch before pushing the
> rest or revert it if already applied and then build that branch?  Going
> forward, I will create a XenClient flavor of wmi.c that won't step on
> the base wmi implementation and configure the two to be mutually
> exclusive.
> >
> > Kamala
> >
> >> -----Original Message-----
> >> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> >> bounces@lists.xensource.com] On Behalf Of Genki Kuroda
> >> Sent: Friday, June 05, 2009 7:06 PM
> >> To: Boris Derzhavets
> >> Cc: xen-devel@lists.xensource.com
> >> Subject: Re: [Xen-devel] Future of xenbits Linux trees
> >>
> >> Hello, Boris,
> >>
> >> I had the same error, but I was able to compile after commenting out
> >> the "HACK ALERT" section in /drivers/acpi/ec.c
> >> More information seems to be in wmi.c.
> >>
> >> Who is taking care of this kind of issue? This is my first post...
> >>
> >> Here is the patch to show where I commented out.
> >>
> >> diff –git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
> >> index 2359480..b2c0221 100644
> >> — a/drivers/acpi/ec.c
> >> +++ b/drivers/acpi/ec.c
> >> @@ -387,6 +387,7 @@ static int acpi_ec_read(struct acpi_ec *ec, u8
> >> address, u8 * data)
> >> /* HACK ALERT
> >> * Please refer to wmi.c for an explanation on why we added this
> hack.
> >> */
> >> +/*
> >> if ( in_query_wmi_event_data == TRUE ) {
> >> if ( address == 0×2b ) {
> >> wmi_event_data_index = 0;
> >> @@ -398,6 +399,7 @@ static int acpi_ec_read(struct acpi_ec *ec, u8
> >> address, u8 * data)
> >> wmi_event_data_index++;
> >> }
> >> }
> >> +*/
> >>
> >> return result;
> >> }
> >>
> >>
> >> --
> >> Genki Kuroda
> >> E-mail: genkikuroda@gmail.com
> >> Website: http://mulps.wordpress.com/
> >>
> >> On Fri, Jun 5, 2009 at 12:53 AM, Boris
> >> Derzhavets<bderzhavets@yahoo.com> wrote:
> >> > Kernel: arch/x86/boot/vmlinuz is ready  (#2)
> >> > ERROR: "wmi_install_notify_handler" [drivers/misc/hp-wmi.ko]
> >> undefined!
> >> > ERROR: "wmi_remove_notify_handler" [drivers/misc/hp-wmi.ko]
> >> undefined!
> >> > ERROR: "wmi_has_guid" [drivers/misc/hp-wmi.ko] undefined!
> >> > ERROR: "wmi_has_guid" [drivers/misc/acer-wmi.ko] undefined!
> >> > WARNING: modpost: Found 3 section mismatch(es).
> >> > To see full details build your kernel with:
> >> > 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
> >> > make[1]: *** [__modpost] Error 1
> >> > make: *** [modules] Error 2
> >> >
> >> > Boris.
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xensource.com
> >> http://lists.xensource.com/xen-devel
> >

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Future of xenbits Linux trees

[Genki Kuroda]

Hi Kamala,

I encountered the wmi build issues after applying the linux-2.6.27-pq.git
I have no idea on what happens before applying the linux-2.6.27-pq.git

All I did was:

$ git clone http://xenbits.xen.org/git-http/xenclient/linux-2.6.27.git
$ cd linux-2.6.27
$ git clone http://xenbits.xen.org/git-http/xenclient/linux-2.6.27-pq.git
.git/patches
$ guilt-push -a
$ make --> wmi build issues.

GK

On Fri, Jun 5, 2009 at 7:53 PM, Kamala
Narasimhan<Kamala.Narasimhan@citrix.com> wrote:
> Just to clarify - You mean you encounter wmi build issues mentioned below with XenClient Linux 2.6.27 even when you *don't* apply the xen-acpi-wmi patch from XenClient Linux 2.6.27 patch queue?
>
> Kamala
>
>> -----Original Message-----
>> From: Genki Kuroda [mailto:sfsugar@gmail.com]
>> Sent: Friday, June 05, 2009 10:48 PM
>> To: Kamala Narasimhan
>> Cc: xen-devel@lists.xensource.com
>> Subject: Re: [Xen-devel] Future of xenbits Linux trees
>>
>> Hi, Kamala,
>>
>> Thank you for the information.
>> I didn't apply the patch, and I don't have any intention to apply the
>> patch for this issue.
>>
>> GK
>>
>> On Fri, Jun 5, 2009 at 7:17 PM, Kamala
>> Narasimhan<Kamala.Narasimhan@citrix.com> wrote:
>> > The xen-acpi-wmi patch in XenClient linux 2.6.27 patch queue is tied
>> to XenClient.  I didn't expect this patch to be used outside the scope
>> of XenClient which is why you encounter the below issues.
>> >
>> > Could you please momentarily exclude the patch before pushing the
>> rest or revert it if already applied and then build that branch?  Going
>> forward, I will create a XenClient flavor of wmi.c that won't step on
>> the base wmi implementation and configure the two to be mutually
>> exclusive.
>> >
>> > Kamala
>> >
>> >> -----Original Message-----
>> >> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
>> >> bounces@lists.xensource.com] On Behalf Of Genki Kuroda
>> >> Sent: Friday, June 05, 2009 7:06 PM
>> >> To: Boris Derzhavets
>> >> Cc: xen-devel@lists.xensource.com
>> >> Subject: Re: [Xen-devel] Future of xenbits Linux trees
>> >>
>> >> Hello, Boris,
>> >>
>> >> I had the same error, but I was able to compile after commenting out
>> >> the "HACK ALERT" section in /drivers/acpi/ec.c
>> >> More information seems to be in wmi.c.
>> >>
>> >> Who is taking care of this kind of issue? This is my first post...
>> >>
>> >> Here is the patch to show where I commented out.
>> >>
>> >> diff –git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
>> >> index 2359480..b2c0221 100644
>> >> — a/drivers/acpi/ec.c
>> >> +++ b/drivers/acpi/ec.c
>> >> @@ -387,6 +387,7 @@ static int acpi_ec_read(struct acpi_ec *ec, u8
>> >> address, u8 * data)
>> >> /* HACK ALERT
>> >> * Please refer to wmi.c for an explanation on why we added this
>> hack.
>> >> */
>> >> +/*
>> >> if ( in_query_wmi_event_data == TRUE ) {
>> >> if ( address == 0×2b ) {
>> >> wmi_event_data_index = 0;
>> >> @@ -398,6 +399,7 @@ static int acpi_ec_read(struct acpi_ec *ec, u8
>> >> address, u8 * data)
>> >> wmi_event_data_index++;
>> >> }
>> >> }
>> >> +*/
>> >>
>> >> return result;
>> >> }
>> >>
>> >>
>> >> --
>> >> Genki Kuroda
>> >> E-mail: genkikuroda@gmail.com
>> >> Website: http://mulps.wordpress.com/
>> >>
>> >> On Fri, Jun 5, 2009 at 12:53 AM, Boris
>> >> Derzhavets<bderzhavets@yahoo.com> wrote:
>> >> > Kernel: arch/x86/boot/vmlinuz is ready  (#2)
>> >> > ERROR: "wmi_install_notify_handler" [drivers/misc/hp-wmi.ko]
>> >> undefined!
>> >> > ERROR: "wmi_remove_notify_handler" [drivers/misc/hp-wmi.ko]
>> >> undefined!
>> >> > ERROR: "wmi_has_guid" [drivers/misc/hp-wmi.ko] undefined!
>> >> > ERROR: "wmi_has_guid" [drivers/misc/acer-wmi.ko] undefined!
>> >> > WARNING: modpost: Found 3 section mismatch(es).
>> >> > To see full details build your kernel with:
>> >> > 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
>> >> > make[1]: *** [__modpost] Error 1
>> >> > make: *** [modules] Error 2
>> >> >
>> >> > Boris.
>> >>
>> >> _______________________________________________
>> >> Xen-devel mailing list
>> >> Xen-devel@lists.xensource.com
>> >> http://lists.xensource.com/xen-devel
>> >
>

Re: Future of xenbits Linux trees

[Jean Guyader]

You can disable all the wmi-XCI patch by openning the series file
(.git/patches/master/serie)
and comment out the entry for this patch at the end of the file. Then
you do a guilt-pop -a && guilt-push -a.

2009/6/6 Genki Kuroda <sfsugar@gmail.com>:
> Hi Kamala,
>
> I encountered the wmi build issues after applying the linux-2.6.27-pq.git
> I have no idea on what happens before applying the linux-2.6.27-pq.git
>
> All I did was:
>
> $ git clone http://xenbits.xen.org/git-http/xenclient/linux-2.6.27.git
> $ cd linux-2.6.27
> $ git clone http://xenbits.xen.org/git-http/xenclient/linux-2.6.27-pq.git
> .git/patches
> $ guilt-push -a
> $ make --> wmi build issues.
>
> GK
>
> On Fri, Jun 5, 2009 at 7:53 PM, Kamala
> Narasimhan<Kamala.Narasimhan@citrix.com> wrote:
>> Just to clarify - You mean you encounter wmi build issues mentioned below with XenClient Linux 2.6.27 even when you *don't* apply the xen-acpi-wmi patch from XenClient Linux 2.6.27 patch queue?
>>
>> Kamala
>>
>>> -----Original Message-----
>>> From: Genki Kuroda [mailto:sfsugar@gmail.com]
>>> Sent: Friday, June 05, 2009 10:48 PM
>>> To: Kamala Narasimhan
>>> Cc: xen-devel@lists.xensource.com
>>> Subject: Re: [Xen-devel] Future of xenbits Linux trees
>>>
>>> Hi, Kamala,
>>>
>>> Thank you for the information.
>>> I didn't apply the patch, and I don't have any intention to apply the
>>> patch for this issue.
>>>
>>> GK
>>>
>>> On Fri, Jun 5, 2009 at 7:17 PM, Kamala
>>> Narasimhan<Kamala.Narasimhan@citrix.com> wrote:
>>> > The xen-acpi-wmi patch in XenClient linux 2.6.27 patch queue is tied
>>> to XenClient.  I didn't expect this patch to be used outside the scope
>>> of XenClient which is why you encounter the below issues.
>>> >
>>> > Could you please momentarily exclude the patch before pushing the
>>> rest or revert it if already applied and then build that branch?  Going
>>> forward, I will create a XenClient flavor of wmi.c that won't step on
>>> the base wmi implementation and configure the two to be mutually
>>> exclusive.
>>> >
>>> > Kamala
>>> >
>>> >> -----Original Message-----
>>> >> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
>>> >> bounces@lists.xensource.com] On Behalf Of Genki Kuroda
>>> >> Sent: Friday, June 05, 2009 7:06 PM
>>> >> To: Boris Derzhavets
>>> >> Cc: xen-devel@lists.xensource.com
>>> >> Subject: Re: [Xen-devel] Future of xenbits Linux trees
>>> >>
>>> >> Hello, Boris,
>>> >>
>>> >> I had the same error, but I was able to compile after commenting out
>>> >> the "HACK ALERT" section in /drivers/acpi/ec.c
>>> >> More information seems to be in wmi.c.
>>> >>
>>> >> Who is taking care of this kind of issue? This is my first post...
>>> >>
>>> >> Here is the patch to show where I commented out.
>>> >>
>>> >> diff –git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
>>> >> index 2359480..b2c0221 100644
>>> >> — a/drivers/acpi/ec.c
>>> >> +++ b/drivers/acpi/ec.c
>>> >> @@ -387,6 +387,7 @@ static int acpi_ec_read(struct acpi_ec *ec, u8
>>> >> address, u8 * data)
>>> >> /* HACK ALERT
>>> >> * Please refer to wmi.c for an explanation on why we added this
>>> hack.
>>> >> */
>>> >> +/*
>>> >> if ( in_query_wmi_event_data == TRUE ) {
>>> >> if ( address == 0×2b ) {
>>> >> wmi_event_data_index = 0;
>>> >> @@ -398,6 +399,7 @@ static int acpi_ec_read(struct acpi_ec *ec, u8
>>> >> address, u8 * data)
>>> >> wmi_event_data_index++;
>>> >> }
>>> >> }
>>> >> +*/
>>> >>
>>> >> return result;
>>> >> }
>>> >>
>>> >>
>>> >> --
>>> >> Genki Kuroda
>>> >> E-mail: genkikuroda@gmail.com
>>> >> Website: http://mulps.wordpress.com/
>>> >>
>>> >> On Fri, Jun 5, 2009 at 12:53 AM, Boris
>>> >> Derzhavets<bderzhavets@yahoo.com> wrote:
>>> >> > Kernel: arch/x86/boot/vmlinuz is ready  (#2)
>>> >> > ERROR: "wmi_install_notify_handler" [drivers/misc/hp-wmi.ko]
>>> >> undefined!
>>> >> > ERROR: "wmi_remove_notify_handler" [drivers/misc/hp-wmi.ko]
>>> >> undefined!
>>> >> > ERROR: "wmi_has_guid" [drivers/misc/hp-wmi.ko] undefined!
>>> >> > ERROR: "wmi_has_guid" [drivers/misc/acer-wmi.ko] undefined!
>>> >> > WARNING: modpost: Found 3 section mismatch(es).
>>> >> > To see full details build your kernel with:
>>> >> > 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
>>> >> > make[1]: *** [__modpost] Error 1
>>> >> > make: *** [modules] Error 2
>>> >> >
>>> >> > Boris.
>>> >>
>>> >> _______________________________________________
>>> >> Xen-devel mailing list
>>> >> Xen-devel@lists.xensource.com
>>> >> http://lists.xensource.com/xen-devel
>>> >
>>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

Re: Future of xenbits Linux trees

[Andy Burns]

2009/6/7 Pasi Kärkkäinen <pasik@iki.fi>:

> On Fri, Jun 05, 2009 at 07:51:44PM +0100, Andy Burns wrote:
>>
>> did I hear that it's likely RHEL6/CentOS6 will
>> be 2.6.27 based?
>
> Where did you hear that?

On a mailing list somewhere, but I couldn't find it to post a
reference, I've just had another look and I still can't find it,
perhaps I was mistaken.

> I don't have any facts, but I'd _assume_ RHEL6 will have 2.6.29 or 2.6.30 ..

Actually I can see plenty of hints that RHEL6 will be ~2.6.30, so if
RH plans on having dom0 in RHEL6 then building some form of
"out-of-tree" coalition around 2.6.30+pvops patches would be nice, and
maybe dom0 will be accepted into mainstream before ~2.6.42 when RHEL7
gets frozen ;-)

Re: Future of xenbits Linux trees

[M A Young]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 877 bytes --]

On Sun, 7 Jun 2009, Pasi Kärkkäinen wrote:

> On Fri, Jun 05, 2009 at 07:51:44PM +0100, Andy Burns wrote:
>> Whilst newer is better, did I hear that it's likely RHEL6/CentOS6 will
>> be 2.6.27 based? If so then 2.6.27 would be a "long lived" kernel.
>>
>
> Where did you hear that?
>
> I don't have any facts, but I'd _assume_ RHEL6 will have 2.6.29 or 2.6.30 ..
>
> Fedora 10 has 2.6.29 kernel in updates-testing, and Fedora 11 will be based
> on 2.6.29 .. But dunno :)

2.6.27 has long term upstream support according to this post
https://www.redhat.com/archives/fedora-kernel-list/2009-January/msg00098.html
Also this post suggests that RHEL6 will be based on F10 and F11
https://www.redhat.com/archives/fedora-advisory-board/2008-November/msg00037.html
though what this means with regard to which kernel RHEL6 will have I am 
not sure.

 	Michael Young

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Future of xenbits Linux trees

[Pasi Kärkkäinen]

On Fri, Jun 05, 2009 at 07:51:44PM +0100, Andy Burns wrote:
> 2009/6/5 Andrew Lyon <andrew.lyon@gmail.com>:
> 
> > I think 2.6.27 is already out of date and you should start with 2.6.29
> > using my rebased patches,
> 
> Whilst newer is better, did I hear that it's likely RHEL6/CentOS6 will
> be 2.6.27 based? If so then 2.6.27 would be a "long lived" kernel.
> 

Where did you hear that? 

I don't have any facts, but I'd _assume_ RHEL6 will have 2.6.29 or 2.6.30 ..

Fedora 10 has 2.6.29 kernel in updates-testing, and Fedora 11 will be based
on 2.6.29 .. But dunno :)

-- Pasi

Re: Future of xenbits Linux trees

[Boris Derzhavets]

[-- Attachment #1.1: Type: text/plain, Size: 6844 bytes --]

Works fine.

root@SeverUbuntuJaunty:~# xm info
host                   : SeverUbuntuJaunty
release                : 2.6.27.19-5.1
version                : #1 SMP Sat Jun 6 23:35:05 MSD 2009
machine                : x86_64
nr_cpus                : 4
nr_nodes               : 1
cores_per_socket       : 4
threads_per_core       : 1
cpu_mhz                : 2833
hw_caps                : bfebfbff:20100800:00000000:00000140:0408e3fd:00000000:00000001:00000000
virt_caps              : hvm
total_memory           : 8191
free_memory            : 7
node_to_cpu            : node0:0-3
node_to_memory         : node0:7
xen_major              : 3
xen_minor              : 4
xen_extra              : .1-rc1-pre
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=0xffff800000000000
xen_changeset          : Mon Jun 01 14:56:17 2009 +0100 19628:29d7e3522cc5
cc_compiler            : gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu12) 
cc_compile_by          : root
cc_compile_domain      : 
cc_compile_date        : Thu Jun  4 07:24:19 EDT 2009
xend_config_format     : 4

Boris.

--- On Sat, 6/6/09, Jean Guyader <jean.guyader@gmail.com> wrote:

From: Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] Future of xenbits Linux trees
To: "Genki Kuroda" <sfsugar@gmail.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Kamala Narasimhan" <Kamala.Narasimhan@citrix.com>
Date: Saturday, June 6, 2009, 5:54 AM

You can disable all the wmi-XCI patch by openning the series file
(.git/patches/master/serie)
and comment out the entry for this patch at the end of the file. Then
you do a guilt-pop -a && guilt-push -a.

2009/6/6 Genki Kuroda <sfsugar@gmail.com>:
> Hi Kamala,
>
> I encountered the wmi build issues after applying the linux-2.6.27-pq.git
> I have no idea on what happens before applying the linux-2.6.27-pq.git
>
> All I did was:
>
> $ git clone http://xenbits.xen.org/git-http/xenclient/linux-2.6.27.git
> $ cd linux-2.6.27
> $ git clone http://xenbits.xen.org/git-http/xenclient/linux-2.6.27-pq.git
> .git/patches
> $ guilt-push -a
> $ make --> wmi build issues.
>
> GK
>
> On Fri, Jun 5, 2009 at 7:53 PM, Kamala
> Narasimhan<Kamala.Narasimhan@citrix.com> wrote:
>> Just to clarify - You mean you encounter wmi build issues mentioned below with XenClient Linux 2.6.27 even when you *don't* apply the xen-acpi-wmi patch from XenClient Linux 2.6.27 patch queue?
>>
>> Kamala
>>
>>> -----Original Message-----
>>> From: Genki Kuroda [mailto:sfsugar@gmail.com]
>>> Sent: Friday, June 05, 2009 10:48 PM
>>> To: Kamala Narasimhan
>>> Cc: xen-devel@lists.xensource.com
>>> Subject: Re: [Xen-devel] Future of xenbits Linux trees
>>>
>>> Hi, Kamala,
>>>
>>> Thank you for the information.
>>> I didn't apply the patch, and I don't have any intention to apply the
>>> patch for this issue.
>>>
>>> GK
>>>
>>> On Fri, Jun 5, 2009 at 7:17 PM, Kamala
>>> Narasimhan<Kamala.Narasimhan@citrix.com> wrote:
>>> > The xen-acpi-wmi patch in XenClient linux 2.6.27 patch queue is tied
>>> to XenClient.  I didn't expect this patch to be used outside the scope
>>> of XenClient which is why you encounter the below issues.
>>> >
>>> > Could you please momentarily exclude the patch before pushing the
>>> rest or revert it if already applied and then build that branch?  Going
>>> forward, I will create a XenClient flavor of wmi.c that won't step on
>>> the base wmi implementation and configure the two to be mutually
>>> exclusive.
>>> >
>>> > Kamala
>>> >
>>> >> -----Original Message-----
>>> >> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
>>> >> bounces@lists.xensource.com] On Behalf Of Genki Kuroda
>>> >> Sent: Friday, June 05, 2009 7:06 PM
>>> >> To: Boris Derzhavets
>>> >> Cc: xen-devel@lists.xensource.com
>>> >> Subject: Re: [Xen-devel] Future of xenbits Linux trees
>>> >>
>>> >> Hello, Boris,
>>> >>
>>> >> I had the same error, but I was able to compile after commenting out
>>> >> the "HACK ALERT" section in /drivers/acpi/ec.c
>>> >> More information seems to be in wmi.c.
>>> >>
>>> >> Who is taking care of this kind of issue? This is my first post...
>>> >>
>>> >> Here is the patch to show where I commented out.
>>> >>
>>> >> diff –git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
>>> >> index 2359480..b2c0221 100644
>>> >> — a/drivers/acpi/ec.c
>>> >> +++ b/drivers/acpi/ec.c
>>> >> @@ -387,6 +387,7 @@ static int acpi_ec_read(struct acpi_ec *ec, u8
>>> >> address, u8 * data)
>>> >> /* HACK ALERT
>>> >> * Please refer to wmi.c for an explanation on why we added this
>>> hack.
>>> >> */
>>> >> +/*
>>> >> if ( in_query_wmi_event_data == TRUE ) {
>>> >> if ( address == 0×2b ) {
>>> >> wmi_event_data_index = 0;
>>> >> @@ -398,6 +399,7 @@ static int acpi_ec_read(struct acpi_ec *ec, u8
>>> >> address, u8 * data)
>>> >> wmi_event_data_index++;
>>> >> }
>>> >> }
>>> >> +*/
>>> >>
>>> >> return result;
>>> >> }
>>> >>
>>> >>
>>> >> --
>>> >> Genki Kuroda
>>> >> E-mail: genkikuroda@gmail.com
>>> >> Website: http://mulps.wordpress.com/
>>> >>
>>> >> On Fri, Jun 5, 2009 at 12:53 AM, Boris
>>> >> Derzhavets<bderzhavets@yahoo.com> wrote:
>>> >> > Kernel: arch/x86/boot/vmlinuz is ready  (#2)
>>> >> > ERROR: "wmi_install_notify_handler" [drivers/misc/hp-wmi.ko]
>>> >> undefined!
>>> >> > ERROR: "wmi_remove_notify_handler" [drivers/misc/hp-wmi.ko]
>>> >> undefined!
>>> >> > ERROR: "wmi_has_guid" [drivers/misc/hp-wmi.ko] undefined!
>>> >> > ERROR: "wmi_has_guid" [drivers/misc/acer-wmi.ko] undefined!
>>> >> > WARNING: modpost: Found 3 section mismatch(es).
>>> >> > To see full details build your kernel with:
>>> >> > 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
>>> >> > make[1]: *** [__modpost] Error 1
>>> >> > make: *** [modules] Error 2
>>> >> >
>>> >> > Boris.
>>> >>
>>> >> _______________________________________________
>>> >> Xen-devel mailing list
>>> >> Xen-devel@lists.xensource.com
>>> >> http://lists.xensource.com/xen-devel
>>> >
>>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel



      

[-- Attachment #1.2: Type: text/html, Size: 12028 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Future of xenbits Linux trees

[Andy Burns]

2009/6/5 Andrew Lyon <andrew.lyon@gmail.com>:

> I think 2.6.27 is already out of date and you should start with 2.6.29
> using my rebased patches,

Whilst newer is better, did I hear that it's likely RHEL6/CentOS6 will
be 2.6.27 based? If so then 2.6.27 would be a "long lived" kernel.

> I use pci passthrough with a pci express usb2 card

is that PV or VT-d?

Re: Future of xenbits Linux trees

[Christian Tramnitz]

Keir Fraser wrote:
> We don't need to wait for pv_ops to be merged. We just need it to have
> near-enough feature parity. Actually now it supports HVM guests I'm tempted
> to just move over to it. It would probably make sense to keep Jeremy as
> gatekeeper for that tree, which will take some of his time. Otoh I'm not
> sure spending 100% of your time banging your head against lkml is much fun.
> :-)
> 
> Probably the major thing it's missing for a simple complete changeover is
> ia64/Xen support. We could continue to point the ia64 build target at
> linux-2.6.18-xen though.

Afaik pvops (even /next) also has no pci_backend support yet and even 
the pci_frontend support is mainly untested.
Both (front/back) work great with Andrew's 2.6.29 tree, although I 
haven't seen ANY reports of IA64 running off it.

I would also consider pvops to be a moving target (you know... lkml fun) 
so I wouldn't really base anything on it until the structure has been 
approved. Maintaining two different pvops lines (one with all changes as 
requested by mainline maintainers and one "stable") might to much of a 
burden if we already have a working 2.6.29 with (hopefully) not much 
work to do other than extensive testing before announcing it as 2.6.18 
successor.


Best regards,
    Christian

Re: Future of xenbits Linux trees

[Christian Tramnitz]

Keir Fraser wrote:
> What do people think of this as a plan?

I'd opt for an approach based on the available 2.6.29 tree from Andrew 
but delayed until 2.6.30 is out.

Simple reason, there are so many fundamental changes in/before 2.6.29 
i.e. ext4 and in terms of video support (KMS, GEM) that anything before 
2.6.29 (such as the 2.6.27 XCI tree) will be a waste of efforts if that 
will be the next tree that should have long-term (until pvops merges 
upstream, haha) support.
On the other hand it might make sense to use the same kernel version 
that RHEL6 will be using to take advantage of their (driver-) 
backporting efforts (not sure how heavily that has been utilized in 
2.6.18). Any insider infos from the RH guys here on the list what kernel 
that might be? ;-)



As a side-note, there is known issue with Andrew's tree not compiling on 
x86_32 with a recent gcc. If I remember correctly that was due to 
optimizations, further details here: 
http://forums.gentoo.org/viewtopic-p-5667545.html#5667545


Best regards,
    Christian

Re: Future of xenbits Linux trees

[Boris Derzhavets]

[-- Attachment #1.1: Type: text/plain, Size: 164 bytes --]

> Hi Andy,
>Where could I get this 2.6.29 from?
>Thanks,
> Jean

wget http://gentoo-xen-kernel.googlecode.com/files/xen-patches-2.6.29-6.tar.bz2

Boris






      

[-- Attachment #1.2: Type: text/html, Size: 485 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Future of xenbits Linux trees

[Pasi Kärkkäinen]

On Fri, Jun 05, 2009 at 08:58:01AM +0100, Jean Guyader wrote:
> 2009/6/5 Andrew Lyon <andrew.lyon@gmail.com>:
> > On Thu, Jun 4, 2009 at 4:45 PM, Keir Fraser <keir.fraser@eu.citrix.com> wrote:
> >> Folks,
> >>
> >> With 3.4 out the door it is time to revisit the state of our Linux
> >> repositories. Currently we have a number of trees in various states of
> >> maintenance:
> >>  - linux-2.6.18-xen.hg: the 'original' tree. Still maintained, used and
> >> tested but increasingly long in the tooth.
> >>  - ext/linux-2.6.27-xen.hg: a snapshot of opensuse's kernel port. This
> >> clones tree is not maintained or tested.
> >>  - XCI/linux-2.6.27.git: a forward port of the Xen patches to 2.6.27.
> >> Maintained as part of XCI project.
> >>  - Jeremy's pv_ops patches against kernel.org: maintained, (somewhat)
> >> tested, but incomplete.
> >>
> >> It is probably time to kill the 2.6.18 tree, or at least stop active
> >> development within it. It is increasingly a kludged collection of backports
> >> of more recent kernel patches, and is also missing a lot of drivers for more
> >> modern hardware.
> >>
> >> Our proposal is to move XCI's linux-2.6.27 tree out of the XCI subproject
> >> and make it the main user tree. Development and automated testing would
> >> occur on that tree and of course on Jeremy's pv_ops patchset (which we want
> >> to completely move onto at some point in the future).
> >>
> >> What do people think of this as a plan?
> >>
> >>  -- Keir
> >
> > I think 2.6.27 is already out of date and you should start with 2.6.29
> > using my rebased patches, people have been using them since I did
> > 2.6.25 and 2.6.29 is the most stable one yet, as Boris said in another
> > thread the xenbits 2.6.27 tree does not shutdown cleanly but 2.6.29
> > does, I'm sure that could be fixed but right now I dont know of any
> > issues with 2.6.29 at all, so why not make the jump to the current
> > stable kernel :).
> >
> > XCI should update to 2.6.29 as well.
> >
> > I use pci passthrough with a pci express usb2 card, I also use scsi
> > passthrough with a ultrium tape drive, usually running several windows
> > hvm's and a couple of 2.6.29 pv domU's as well, no problems.
> >
> 
> Hi Andy,
> 
> Where could I get this 2.6.29 from?
> 

I believe from here:
http://gentoo-xen-kernel.googlecode.com/files/xen-patches-2.6.29-6.tar.bz2

At least that URL he posted in the other recent dom0 kernel thread.

-- Pasi

Re: Future of xenbits Linux trees

[Jean Guyader]

2009/6/5 Andrew Lyon <andrew.lyon@gmail.com>:
> On Thu, Jun 4, 2009 at 4:45 PM, Keir Fraser <keir.fraser@eu.citrix.com> wrote:
>> Folks,
>>
>> With 3.4 out the door it is time to revisit the state of our Linux
>> repositories. Currently we have a number of trees in various states of
>> maintenance:
>>  - linux-2.6.18-xen.hg: the 'original' tree. Still maintained, used and
>> tested but increasingly long in the tooth.
>>  - ext/linux-2.6.27-xen.hg: a snapshot of opensuse's kernel port. This
>> clones tree is not maintained or tested.
>>  - XCI/linux-2.6.27.git: a forward port of the Xen patches to 2.6.27.
>> Maintained as part of XCI project.
>>  - Jeremy's pv_ops patches against kernel.org: maintained, (somewhat)
>> tested, but incomplete.
>>
>> It is probably time to kill the 2.6.18 tree, or at least stop active
>> development within it. It is increasingly a kludged collection of backports
>> of more recent kernel patches, and is also missing a lot of drivers for more
>> modern hardware.
>>
>> Our proposal is to move XCI's linux-2.6.27 tree out of the XCI subproject
>> and make it the main user tree. Development and automated testing would
>> occur on that tree and of course on Jeremy's pv_ops patchset (which we want
>> to completely move onto at some point in the future).
>>
>> What do people think of this as a plan?
>>
>>  -- Keir
>
> I think 2.6.27 is already out of date and you should start with 2.6.29
> using my rebased patches, people have been using them since I did
> 2.6.25 and 2.6.29 is the most stable one yet, as Boris said in another
> thread the xenbits 2.6.27 tree does not shutdown cleanly but 2.6.29
> does, I'm sure that could be fixed but right now I dont know of any
> issues with 2.6.29 at all, so why not make the jump to the current
> stable kernel :).
>
> XCI should update to 2.6.29 as well.
>
> I use pci passthrough with a pci express usb2 card, I also use scsi
> passthrough with a ultrium tape drive, usually running several windows
> hvm's and a couple of 2.6.29 pv domU's as well, no problems.
>

Hi Andy,

Where could I get this 2.6.29 from?

Thanks,
Jean

Re: Future of xenbits Linux trees

[Keir Fraser]

On 05/06/2009 08:32, "Andrew Lyon" <andrew.lyon@gmail.com> wrote:

> I think 2.6.27 is already out of date and you should start with 2.6.29
> using my rebased patches, people have been using them since I did
> 2.6.25 and 2.6.29 is the most stable one yet, as Boris said in another
> thread the xenbits 2.6.27 tree does not shutdown cleanly but 2.6.29
> does, I'm sure that could be fixed but right now I dont know of any
> issues with 2.6.29 at all, so why not make the jump to the current
> stable kernel :).
> 
> XCI should update to 2.6.29 as well.
> 
> I use pci passthrough with a pci express usb2 card, I also use scsi
> passthrough with a ultrium tape drive, usually running several windows
> hvm's and a couple of 2.6.29 pv domU's as well, no problems.

That's certainly an option, especially if it has stuff like pciback,
blktap2, and various patches for device passthrough (e.g., using VT-d)
already ported to it, similar to the XCI 2.6.27 tree.

 -- Keir

Re: Future of xenbits Linux trees

[Pasi Kärkkäinen]

On Fri, Jun 05, 2009 at 08:32:21AM +0100, Andrew Lyon wrote:
> On Thu, Jun 4, 2009 at 4:45 PM, Keir Fraser <keir.fraser@eu.citrix.com> wrote:
> > Folks,
> >
> > With 3.4 out the door it is time to revisit the state of our Linux
> > repositories. Currently we have a number of trees in various states of
> > maintenance:
> >  - linux-2.6.18-xen.hg: the 'original' tree. Still maintained, used and
> > tested but increasingly long in the tooth.
> >  - ext/linux-2.6.27-xen.hg: a snapshot of opensuse's kernel port. This
> > clones tree is not maintained or tested.
> >  - XCI/linux-2.6.27.git: a forward port of the Xen patches to 2.6.27.
> > Maintained as part of XCI project.
> >  - Jeremy's pv_ops patches against kernel.org: maintained, (somewhat)
> > tested, but incomplete.
> >
> > It is probably time to kill the 2.6.18 tree, or at least stop active
> > development within it. It is increasingly a kludged collection of backports
> > of more recent kernel patches, and is also missing a lot of drivers for more
> > modern hardware.
> >
> > Our proposal is to move XCI's linux-2.6.27 tree out of the XCI subproject
> > and make it the main user tree. Development and automated testing would
> > occur on that tree and of course on Jeremy's pv_ops patchset (which we want
> > to completely move onto at some point in the future).
> >
> > What do people think of this as a plan?
> >
> >  -- Keir
> 
> I think 2.6.27 is already out of date and you should start with 2.6.29
> using my rebased patches, people have been using them since I did
> 2.6.25 and 2.6.29 is the most stable one yet, as Boris said in another
> thread the xenbits 2.6.27 tree does not shutdown cleanly but 2.6.29
> does, I'm sure that could be fixed but right now I dont know of any
> issues with 2.6.29 at all, so why not make the jump to the current
> stable kernel :).
> 
> XCI should update to 2.6.29 as well.
> 

Just to clear it up, Keir proposed to use the XCI 2.6.27-git tree as a
starting point, not the unmaintained and buggy 2.6.27-xen.

But anyway, I think the best option would be to start with Andrew's patches
for 2.6.29.

> I use pci passthrough with a pci express usb2 card, I also use scsi
> passthrough with a ultrium tape drive, usually running several windows
> hvm's and a couple of 2.6.29 pv domU's as well, no problems.
> 

That's good.

-- Pasi

Re: Future of xenbits Linux trees

[Boris Derzhavets]

[-- Attachment #1.1: Type: text/plain, Size: 2558 bytes --]

Kernel 2.6.29 with Andy's rebased patches seems pretty stable in QA.

Boris.

--- On Fri, 6/5/09, Andrew Lyon <andrew.lyon@gmail.com> wrote:

From: Andrew Lyon <andrew.lyon@gmail.com>
Subject: Re: [Xen-devel] Future of xenbits Linux trees
To: "Keir Fraser" <keir.fraser@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Friday, June 5, 2009, 3:32 AM

On Thu, Jun 4, 2009 at 4:45 PM, Keir Fraser <keir.fraser@eu.citrix.com> wrote:
> Folks,
>
> With 3.4 out the door it is time to revisit the state of our Linux
> repositories. Currently we have a number of trees in various states of
> maintenance:
>  - linux-2.6.18-xen.hg: the 'original' tree. Still maintained, used and
> tested but increasingly long in the tooth.
>  - ext/linux-2.6.27-xen.hg: a snapshot of opensuse's kernel port. This
> clones tree is not maintained or tested.
>  - XCI/linux-2.6.27.git: a forward port of the Xen patches to 2.6.27.
> Maintained as part of XCI project.
>  - Jeremy's pv_ops patches against kernel.org: maintained, (somewhat)
> tested, but incomplete.
>
> It is probably time to kill the 2.6.18 tree, or at least stop active
> development within it. It is increasingly a kludged collection of backports
> of more recent kernel patches, and is also missing a lot of drivers for more
> modern hardware.
>
> Our proposal is to move XCI's linux-2.6.27 tree out of the XCI subproject
> and make it the main user tree. Development and automated testing would
> occur on that tree and of course on Jeremy's pv_ops patchset (which we want
> to completely move onto at some point in the future).
>
> What do people think of this as a plan?
>
>  -- Keir

I think 2.6.27 is already out of date and you should start with 2.6.29
using my rebased patches, people have been using them since I did
2.6.25 and 2.6.29 is the most stable one yet, as Boris said in another
thread the xenbits 2.6.27 tree does not shutdown cleanly but 2.6.29
does, I'm sure that could be fixed but right now I dont know of any
issues with 2.6.29 at all, so why not make the jump to the current
stable kernel :).

XCI should update to 2.6.29 as well.

I use pci passthrough with a pci express usb2 card, I also use scsi
passthrough with a ultrium tape drive, usually running several windows
hvm's and a couple of 2.6.29 pv domU's as well, no problems.

Andy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel



      

[-- Attachment #1.2: Type: text/html, Size: 3366 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Future of xenbits Linux trees

[Andrew Lyon]

On Thu, Jun 4, 2009 at 4:45 PM, Keir Fraser <keir.fraser@eu.citrix.com> wrote:
> Folks,
>
> With 3.4 out the door it is time to revisit the state of our Linux
> repositories. Currently we have a number of trees in various states of
> maintenance:
>  - linux-2.6.18-xen.hg: the 'original' tree. Still maintained, used and
> tested but increasingly long in the tooth.
>  - ext/linux-2.6.27-xen.hg: a snapshot of opensuse's kernel port. This
> clones tree is not maintained or tested.
>  - XCI/linux-2.6.27.git: a forward port of the Xen patches to 2.6.27.
> Maintained as part of XCI project.
>  - Jeremy's pv_ops patches against kernel.org: maintained, (somewhat)
> tested, but incomplete.
>
> It is probably time to kill the 2.6.18 tree, or at least stop active
> development within it. It is increasingly a kludged collection of backports
> of more recent kernel patches, and is also missing a lot of drivers for more
> modern hardware.
>
> Our proposal is to move XCI's linux-2.6.27 tree out of the XCI subproject
> and make it the main user tree. Development and automated testing would
> occur on that tree and of course on Jeremy's pv_ops patchset (which we want
> to completely move onto at some point in the future).
>
> What do people think of this as a plan?
>
>  -- Keir

I think 2.6.27 is already out of date and you should start with 2.6.29
using my rebased patches, people have been using them since I did
2.6.25 and 2.6.29 is the most stable one yet, as Boris said in another
thread the xenbits 2.6.27 tree does not shutdown cleanly but 2.6.29
does, I'm sure that could be fixed but right now I dont know of any
issues with 2.6.29 at all, so why not make the jump to the current
stable kernel :).

XCI should update to 2.6.29 as well.

I use pci passthrough with a pci express usb2 card, I also use scsi
passthrough with a ultrium tape drive, usually running several windows
hvm's and a couple of 2.6.29 pv domU's as well, no problems.

Andy

Re: Future of xenbits Linux trees

[Jean Guyader]

2009/6/4 Keir Fraser <keir.fraser@eu.citrix.com>:
> On 04/06/2009 19:46, "Jean Guyader" <jean.guyader@gmail.com> wrote:
>
>>> How to checkout this tree ?
>>>
>> $ git clone http://xenbits.xen.org/git-http/xenclient/linux-2.6.27.git
>> $ cd linux-2.6.27
>> $ git clone http://xenbits.xen.org/git-http/xenclient/linux-2.6.27-pq.git
>> .git/patches
>> $ guilt-push -a
>>
>> Make sure you have a recent enough version of guilt, 0.30 has issue
>> with big patches.
>
> The patchqueue is the XCI-specific bits, right? We'd just have a plain
> non-patchqueued got tree for mainline development at least, I think.
>

We have a patchqueue for fixes and new stuff but that make sence for
dev to have a non-patchqueued tree.

Jean

Re: Future of xenbits Linux trees

[Keir Fraser]

On 04/06/2009 19:46, "Jean Guyader" <jean.guyader@gmail.com> wrote:

>> How to checkout this tree ?
>> 
> $ git clone http://xenbits.xen.org/git-http/xenclient/linux-2.6.27.git
> $ cd linux-2.6.27
> $ git clone http://xenbits.xen.org/git-http/xenclient/linux-2.6.27-pq.git
> .git/patches
> $ guilt-push -a
> 
> Make sure you have a recent enough version of guilt, 0.30 has issue
> with big patches.

The patchqueue is the XCI-specific bits, right? We'd just have a plain
non-patchqueued got tree for mainline development at least, I think.

 -- Keir

Re: Future of xenbits Linux trees

[Jean Guyader]

2009/6/4 Boris Derzhavets <bderzhavets@yahoo.com>:
>>> Our proposal is to move XCI's linux-2.6.27 tree out of the XCI subproject
>>> and make it the main user tree. Development and automated testing would
> . . . . . .
>
>> This tree is not tied up with XCI at all.
>> It can be taken as it and runs on the top of mainstream xen.
>
> How to checkout this tree ?
>


$ git clone http://xenbits.xen.org/git-http/xenclient/linux-2.6.27.git
$ cd linux-2.6.27
$ git clone http://xenbits.xen.org/git-http/xenclient/linux-2.6.27-pq.git
.git/patches
$ guilt-push -a

Make sure you have a recent enough version of guilt, 0.30 has issue
with big patches.

Jean

Re: Future of xenbits Linux trees

[Jean Guyader]

2009/6/4 Keir Fraser <keir.fraser@eu.citrix.com>:
> On 04/06/2009 19:08, "Espen Skoglund" <espen.skoglund@netronome.com> wrote:
>
>> Sounds reasonable.  The 2.6.18 tree is getting a bit dated now.
>>
>> One question: How complete is the XCI tree with respect to the various
>> Xen related features having been added to the 2.6.18 tree over time?
>> Is it all in there?
>
> There may be pieces missing relating to power management and device
> passthrough. They can be added down the line however, and the 2.6.18 tree
> won't be deleted.
>


We have pciback with flr,blktap2 in term of new things.

Jean

Re: Future of xenbits Linux trees

[Keir Fraser]

On 04/06/2009 19:08, "Espen Skoglund" <espen.skoglund@netronome.com> wrote:

> Sounds reasonable.  The 2.6.18 tree is getting a bit dated now.
> 
> One question: How complete is the XCI tree with respect to the various
> Xen related features having been added to the 2.6.18 tree over time?
> Is it all in there?

There may be pieces missing relating to power management and device
passthrough. They can be added down the line however, and the 2.6.18 tree
won't be deleted.

 -- Keir

Re: Future of xenbits Linux trees

[Espen Skoglund]

Sounds reasonable.  The 2.6.18 tree is getting a bit dated now.

One question: How complete is the XCI tree with respect to the various
Xen related features having been added to the 2.6.18 tree over time?
Is it all in there?

	eSk



[Keir Fraser]
> Folks,
> With 3.4 out the door it is time to revisit the state of our Linux
> repositories. Currently we have a number of trees in various states of
> maintenance:
>  - linux-2.6.18-xen.hg: the 'original' tree. Still maintained, used and
> tested but increasingly long in the tooth.
>  - ext/linux-2.6.27-xen.hg: a snapshot of opensuse's kernel port. This
> clones tree is not maintained or tested.
>  - XCI/linux-2.6.27.git: a forward port of the Xen patches to 2.6.27.
> Maintained as part of XCI project.
>  - Jeremy's pv_ops patches against kernel.org: maintained, (somewhat)
> tested, but incomplete.

> It is probably time to kill the 2.6.18 tree, or at least stop active
> development within it. It is increasingly a kludged collection of
> backports of more recent kernel patches, and is also missing a lot
> of drivers for more modern hardware.

> Our proposal is to move XCI's linux-2.6.27 tree out of the XCI
> subproject and make it the main user tree. Development and automated
> testing would occur on that tree and of course on Jeremy's pv_ops
> patchset (which we want to completely move onto at some point in the
> future).

> What do people think of this as a plan?

>  -- Keir



> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: Future of xenbits Linux trees

[Boris Derzhavets]

[-- Attachment #1.1: Type: text/plain, Size: 2187 bytes --]

>> Our proposal is to move XCI's linux-2.6.27 tree out of the XCI subproject
>> and make it the main user tree. Development and automated testing would
. . . . . .

> This tree is not tied up with XCI at all.
> It can be taken as it and runs on the top of mainstream xen.

How to checkout this tree ?

Boris.

--- On Thu, 6/4/09, Jean Guyader <jean.guyader@gmail.com> wrote:

From: Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] Future of xenbits Linux trees
To: "Keir Fraser" <keir.fraser@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thursday, June 4, 2009, 12:09 PM

2009/6/4 Keir Fraser <keir.fraser@eu.citrix.com>:
> Folks,
>
> With 3.4 out the door it is time to revisit the state of our Linux
> repositories. Currently we have a number of trees in various states of
> maintenance:
>  - linux-2.6.18-xen.hg: the 'original' tree. Still maintained, used and
> tested but increasingly long in the tooth.
>  - ext/linux-2.6.27-xen.hg: a snapshot of opensuse's kernel port. This
> clones tree is not maintained or tested.
>  - XCI/linux-2.6.27.git: a forward port of the Xen patches to 2.6.27.
> Maintained as part of XCI project.
>  - Jeremy's pv_ops patches against kernel.org: maintained, (somewhat)
> tested, but incomplete.
>
> It is probably time to kill the 2.6.18 tree, or at least stop active
> development within it. It is increasingly a kludged collection of backports
> of more recent kernel patches, and is also missing a lot of drivers for more
> modern hardware.
>
> Our proposal is to move XCI's linux-2.6.27 tree out of the XCI subproject
> and make it the main user tree. Development and automated testing would
> occur on that tree and of course on Jeremy's pv_ops patchset (which we want
> to completely move onto at some point in the future).
>
> What do people think of this as a plan?
>

This tree is not tied up with XCI at all.
It can be taken as it and runs on the top of mainstream xen.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel



      

[-- Attachment #1.2: Type: text/html, Size: 2991 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Future of xenbits Linux trees

[Tim Post]

On Thu, 2009-06-04 at 16:45 +0100, Keir Fraser wrote:

> What do people think of this as a plan?

Just tell me where to send the beer.

Cheers,
--Tim

Re: Future of xenbits Linux trees

[Jean Guyader]

2009/6/4 Keir Fraser <keir.fraser@eu.citrix.com>:
> Folks,
>
> With 3.4 out the door it is time to revisit the state of our Linux
> repositories. Currently we have a number of trees in various states of
> maintenance:
>  - linux-2.6.18-xen.hg: the 'original' tree. Still maintained, used and
> tested but increasingly long in the tooth.
>  - ext/linux-2.6.27-xen.hg: a snapshot of opensuse's kernel port. This
> clones tree is not maintained or tested.
>  - XCI/linux-2.6.27.git: a forward port of the Xen patches to 2.6.27.
> Maintained as part of XCI project.
>  - Jeremy's pv_ops patches against kernel.org: maintained, (somewhat)
> tested, but incomplete.
>
> It is probably time to kill the 2.6.18 tree, or at least stop active
> development within it. It is increasingly a kludged collection of backports
> of more recent kernel patches, and is also missing a lot of drivers for more
> modern hardware.
>
> Our proposal is to move XCI's linux-2.6.27 tree out of the XCI subproject
> and make it the main user tree. Development and automated testing would
> occur on that tree and of course on Jeremy's pv_ops patchset (which we want
> to completely move onto at some point in the future).
>
> What do people think of this as a plan?
>

This tree is not tied up with XCI at all.
It can be taken as it and runs on the top of mainstream xen.

Jean

Future of xenbits Linux trees

[Keir Fraser]

Folks,

With 3.4 out the door it is time to revisit the state of our Linux
repositories. Currently we have a number of trees in various states of
maintenance:
 - linux-2.6.18-xen.hg: the 'original' tree. Still maintained, used and
tested but increasingly long in the tooth.
 - ext/linux-2.6.27-xen.hg: a snapshot of opensuse's kernel port. This
clones tree is not maintained or tested.
 - XCI/linux-2.6.27.git: a forward port of the Xen patches to 2.6.27.
Maintained as part of XCI project.
 - Jeremy's pv_ops patches against kernel.org: maintained, (somewhat)
tested, but incomplete.

It is probably time to kill the 2.6.18 tree, or at least stop active
development within it. It is increasingly a kludged collection of backports
of more recent kernel patches, and is also missing a lot of drivers for more
modern hardware.

Our proposal is to move XCI's linux-2.6.27 tree out of the XCI subproject
and make it the main user tree. Development and automated testing would
occur on that tree and of course on Jeremy's pv_ops patchset (which we want
to completely move onto at some point in the future).

What do people think of this as a plan?

 -- Keir