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
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
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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? > > -- KeirI 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
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? > > -- KeirI 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Hi Andy, >Where could I get this 2.6.29 from? >Thanks, > Jeanwget http://gentoo-xen-kernel.googlecode.com/files/xen-patches-2.6.29-6.tar.bz2 Boris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 05/06/2009 14:26, "Christian Tramnitz" <chris.ace@gmx.net> wrote:> 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.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. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Makes perfect sense to move over to pvops (in mainline) directly : - Many of us have already used pvops-git and it works - Other branches (2.6.27/29/30 or whatever) would be a single-chunk forward port, with more scope for latent bugs (and no long-term benefits). - We anyway need to make pvops happen. The more we wait, greater will be the feature parity. ... and many more reasons. Please make it happen ! -dulloor On Fri, Jun 5, 2009 at 9:36 AM, Keir Fraser <keir.fraser@eu.citrix.com>wrote:> On 05/06/2009 14:26, "Christian Tramnitz" <chris.ace@gmx.net> wrote: > > > 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. > > 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. > > -- Keir > > > > _______________________________________________ > 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
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Makes perfect sense to move over to pvops (in mainline) directly : > - Many of us have already used pvops-git and it works > - Other branches (2.6.27/29/30 or whatever) would be a single-chunk > forward port, with more scope for latent bugs (and no long-term benefits). > - We anyway need to make pvops happen. The more we wait, greater will be > the feature parity. > ... and many more reasons.One of the reasons cited for sticking on 2.6.18 was that it would hopefully encourage folk to use pv_ops if they wanted anything more modern. I''m not sure that worked out too well... One argument for using 2.6.27 is that I believe it''s the kernel used by SLES11, so there should be good availability of drivers backported to it. It strikes me it''s not a bad plan to have two trees, one based off the latest stable enterprise distro (in this case SLES11), and the pvops tree based off the latest kernel.org release. Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 06/05/09 15:36, Keir Fraser wrote:> On 05/06/2009 14:26, "Christian Tramnitz"<chris.ace@gmx.net> wrote: > >> 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. > > 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.Go ahead! It is really time to stop forward-porting stuff. The time is much better spent in adding the missing features to pv_ops/dom0. Also just after the 3.4 release is the perfect moment for that move, 3.5 should be able to ship with a pv_ops based kernel then. cheers, Gerd _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 06/05/09 16:37, Ian Pratt wrote:> One of the reasons cited for sticking on 2.6.18 was that it would > hopefully encourage folk to use pv_ops if they wanted anything more > modern. I''m not sure that worked out too well...Making the pv_ops kernel the officially one in xen-unstable should work better I think.> It strikes me it''s not a bad plan to have two trees, one based > off the latest stable enterprise distro (in this case SLES11), and > the pvops tree based off the latest kernel.org release.As you''ve noticed above having two trees (2.6.18 + pv_ops) didn''t work out very well so far. I doubt s/2.6.18/2.6.27/ will change that ... cheers, Gerd _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Carsten Schiers
2009-Jun-05 17:58 UTC
AW: Re: [Xen-devel] Re: Future of xenbits Linux trees
> Go ahead! It is really time to stop forward-porting stuff. The timeis> much better spent in adding the missing features to pv_ops/dom0. Also> just after the 3.4 release is the perfect moment for that move, 3.5 > should be able to ship with a pv_ops based kernel then.I''d vote for that, too. Whatever comes out of that discussion on "coolness" on lkml ;o), I guess pv_ops is what will be the outcome. Inside or outside the linux kernel tree. What I''d like to add is that I would prefer a better tagging of the kernel repo to identify subversion of the kernel that belong to a certain version of Xen, whatever kernel that might be. Fixes and improvements are happening so quickly that on the pure user''s side the combination can make a difference, no matter how much effort you put in to keep it independent. BR, Carsten. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2009-Jun-05 18:49 UTC
Re: AW: Re: [Xen-devel] Re: Future of xenbits Linux trees
On 05/06/2009 18:58, "Carsten Schiers" <carsten@schiers.de> wrote:> What I''d like to add is that I would prefer a better tagging of the > kernel > repo to identify subversion of the kernel that belong to a certain > version > of Xen, whatever kernel that might be. Fixes and improvements are > happening > so quickly that on the pure user''s side the combination can make a > difference, > no matter how much effort you put in to keep it independent.As I''ve said so many times, the kernel version and Xen version are *not* tied. We don''t do kernel releases tied to Xen versions, at all. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 cardis that PV or VT-d? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Carsten Schiers
2009-Jun-05 21:02 UTC
AW: Re: AW: Re: [Xen-devel] Re: Future of xenbits Linux trees
I know and it''s not my decision. But my problems on TSC skew disappeared only by using a combination of recent version pulled at approximately the same time. You might argue that cpufreq=dom0-kernel moves functionality that should belong to xen into the Dom0 kernel. Yes, you''re right. From that point of view I have nothing to put in the balance. BR, Carsten. -----Ursprüngliche Nachricht----- Von: Keir Fraser [mailto:keir.fraser@eu.citrix.com] Gesendet: Freitag, 5. Juni 2009 20:49 An: Carsten Schiers; kraxel Cc: chris.ace; jeremy; xen-devel; yamahata Betreff: Re: AW: Re: [Xen-devel] Re: Future of xenbits Linux trees On 05/06/2009 18:58, "Carsten Schiers" <carsten@schiers.de> wrote:> What I''d like to add is that I would prefer a better tagging of the > kernel > repo to identify subversion of the kernel that belong to a certain > version > of Xen, whatever kernel that might be. Fixes and improvements are > happening > so quickly that on the pure user''s side the combination can make a > difference, > no matter how much effort you put in to keep it independent.As I''ve said so many times, the kernel version and Xen version are *not* tied. We don''t do kernel releases tied to Xen versions, at all. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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
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
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
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
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
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
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 ;-) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel