19 March -- TODO list locked down
2 April -- Feature Freeze
30 July -- Xen 4.2.0-rc1
8 August -- Xen 4.2.0-rc2
23 August -- Xen 4.2.0-rc3
Weekly -- RCN+1 until release << WE ARE HERE
We intend to release RC4 towards the end of this week. All being well
we intend for this to be the final release candidate. Please test!
The updated TODO list follows.
hypervisor, blockers:
* None
tools, blockers:
* libxl stable API -- we would like 4.2 to define a stable API
which downstream's can start to rely on not changing. Aspects of
this are:
* None known
* xl compatibility with xm:
* No known issues
* [CHECK] More formally deprecate xm/xend. Manpage patches already
in tree. Needs release noting and communication around -rc1 to
remind people to test xl. (DONE)
* [CHECK] Confirm that migration from Xen 4.1 -> 4.2 works. (DONE
for PV, HVM still TODO)
* Bump library SONAMES as necessary.
<20502.39440.969619.824976@mariner.uk.xensource.com>
* [BUG] qemu-traditional has 50% cpu utilization on an idle
Windows system if USB is enabled. Not 100% clear whether this is
Xen or qemu. George Dunlap thinks this is mostly down to 64-bit
syscall overhead and is not a blocker, will drop from the list.
* Disable generation id from xl. Microsoft changed the
specification of this value between W8 beta and RC and we now
implement the old spec. Disable for 4.2 and revist implementing
the new spec for 4.3. (Paul Durrant, DONE)
hypervisor, nice to have:
* [BUG(?)] Under certain conditions, the p2m_pod_sweep code will
stop halfway through searching, causing a guest to crash even if
there was zeroed memory available. This is NOT a regression
from 4.1, and is a very rare case, so probably shouldn't be a
blocker. (In fact, I'd be open to the idea that it should wait
until after the release to get more testing.)
(George Dunlap, defer until 4.3)
* S3 regression(s?) reported by Ben Guthro (Ben & Jan Beulich)
* fix high change rate to CMOS RTC periodic interrupt causing
guest wall clock time to lag (Jan Beulich, core fix DONE for
4.2, rest pushed out to post 4.2)
tools, nice to have:
* xl compatibility with xm:
* the parameter io and irq in domU config files are not
evaluated by xl. So it is not possible to passthrough a
parallel port for my printer to domU when I start the domU
with xl command. (reported by Dieter Bloms,
<20120814100704.GA19704@bloms.de>. Ian Campbell, patch posted)
* xl doesn't support the '-a' option for shutdown, to
shutdown
all domains. (Reported by Sander Eikelenboom
<885821548.20120831124902@eikelenboom.it>)
* xl.cfg(5) documentation patch for qemu-upstream
videoram/videomem support:
http://lists.xen.org/archives/html/xen-devel/2012-05/msg00250.html
qemu-upstream doesn't support specifying videomem size for the
HVM guest cirrus/stdvga. (but this works with
qemu-xen-traditional). (Pasi Kärkkäinen, patches sent)
* [BUG] 'xl vcpu-set' can't decrease the vCPU number of a HVM
guest
http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822
* Load blktap driver from xencommons initscript if available, thread at:
<db614e92faf743e20b3f.1337096977@kodo2>. To be fixed more
properly in 4.3. (DONE)
* [BUG] xl allows same PCI device to be assigned to multiple
guests. http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826
(<E4558C0C96688748837EB1B05BEED75A0FD5574A@SHSMSX102.ccr.corp.intel.com>)
* "xl cpupool-create" segfault on incorrect input. Reported by
George Dunlap,
<CAFLBxZaEci0mOcDCgFX9zk=wh3z4Nf1LD5E5Fcy7Y3=ioDAM=g@mail.gmail.com>
(Ian Jackson, DONE)
* [BUG] xl fails on config files which are missing the final
newline (Ian Jackson)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
19 March -- TODO list locked down
2 April -- Feature Freeze
30 July -- Xen 4.2.0-rc1
8 August -- Xen 4.2.0-rc2
23 August -- Xen 4.2.0-rc3
Weekly -- RCN+1 until release << WE ARE HERE
We intend to release RC4 towards the end of this week. All being well
we intend for this to be the final release candidate. Please test!
The updated TODO list follows.
hypervisor, blockers:
* None
tools, blockers:
* libxl stable API -- we would like 4.2 to define a stable API
which downstream's can start to rely on not changing. Aspects of
this are:
* None known
* xl compatibility with xm:
* No known issues
* [CHECK] More formally deprecate xm/xend. Manpage patches already
in tree. Needs release noting and communication around -rc1 to
remind people to test xl. (DONE)
* [CHECK] Confirm that migration from Xen 4.1 -> 4.2 works. (DONE
for PV, HVM still TODO)
* Bump library SONAMES as necessary.
<20502.39440.969619.824976@mariner.uk.xensource.com>
* [BUG] qemu-traditional has 50% cpu utilization on an idle
Windows system if USB is enabled. Not 100% clear whether this is
Xen or qemu. George Dunlap thinks this is mostly down to 64-bit
syscall overhead and is not a blocker, will drop from the list.
* Disable generation id from xl. Microsoft changed the
specification of this value between W8 beta and RC and we now
implement the old spec. Disable for 4.2 and revist implementing
the new spec for 4.3. (Paul Durrant, DONE)
hypervisor, nice to have:
* [BUG(?)] Under certain conditions, the p2m_pod_sweep code will
stop halfway through searching, causing a guest to crash even if
there was zeroed memory available. This is NOT a regression
from 4.1, and is a very rare case, so probably shouldn't be a
blocker. (In fact, I'd be open to the idea that it should wait
until after the release to get more testing.)
(George Dunlap, defer until 4.3)
* S3 regression(s?) reported by Ben Guthro (Ben & Jan Beulich)
* fix high change rate to CMOS RTC periodic interrupt causing
guest wall clock time to lag (Jan Beulich, core fix DONE for
4.2, rest pushed out to post 4.2)
tools, nice to have:
* xl compatibility with xm:
* the parameter io and irq in domU config files are not
evaluated by xl. So it is not possible to passthrough a
parallel port for my printer to domU when I start the domU
with xl command. (reported by Dieter Bloms,
<20120814100704.GA19704@bloms.de>. Ian Campbell, patch posted)
* xl doesn't support the '-a' option for shutdown, to
shutdown
all domains. (Reported by Sander Eikelenboom
<885821548.20120831124902@eikelenboom.it>)
* xl.cfg(5) documentation patch for qemu-upstream
videoram/videomem support:
http://lists.xen.org/archives/html/xen-devel/2012-05/msg00250.html
qemu-upstream doesn't support specifying videomem size for the
HVM guest cirrus/stdvga. (but this works with
qemu-xen-traditional). (Pasi Kärkkäinen, patches sent)
* [BUG] 'xl vcpu-set' can't decrease the vCPU number of a HVM
guest
http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1822
* Load blktap driver from xencommons initscript if available, thread at:
<db614e92faf743e20b3f.1337096977@kodo2>. To be fixed more
properly in 4.3. (DONE)
* [BUG] xl allows same PCI device to be assigned to multiple
guests. http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1826
(<E4558C0C96688748837EB1B05BEED75A0FD5574A@SHSMSX102.ccr.corp.intel.com>)
* "xl cpupool-create" segfault on incorrect input. Reported by
George Dunlap,
<CAFLBxZaEci0mOcDCgFX9zk=wh3z4Nf1LD5E5Fcy7Y3=ioDAM=g@mail.gmail.com>
(Ian Jackson, DONE)
* [BUG] xl fails on config files which are missing the final
newline (Ian Jackson)
_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users
>>> On 03.09.12 at 11:42, Ian Campbell <Ian.Campbell@citrix.com> wrote: > * [BUG] qemu-traditional has 50% cpu utilization on an idle > Windows system if USB is enabled. Not 100% clear whether this is > Xen or qemu. George Dunlap thinks this is mostly down to 64-bit > syscall overhead and is not a blocker, will drop from the list.A few percent certainly might be, but 50? Jan
Good morning, I realise I''m probably too late, but if it''s trivial then maybe it is possible to implement an ''xl reset vmname'' function before the final release. Or is this not as trivial as I think it is? -- Stay in touch, Mark van Dijk. ,--------------------------------- ----------------------------'' Tue Sep 04 07:04 UTC 2012 Today is Boomtime, the 28th day of Bureaucracy in the YOLD 3178
Good morning, I realise I''m probably too late, but if it''s trivial then maybe it is possible to implement an ''xl reset vmname'' function before the final release. Or is this not as trivial as I think it is? -- Stay in touch, Mark van Dijk. ,--------------------------------- ----------------------------'' Tue Sep 04 07:04 UTC 2012 Today is Boomtime, the 28th day of Bureaucracy in the YOLD 3178
On Tue, 2012-09-04 at 08:06 +0100, Mark van Dijk wrote:> Good morning, > > I realise I''m probably too late, but if it''s trivial then maybe it is > possible to implement an ''xl reset vmname'' function before the final > release. > > Or is this not as trivial as I think it is?What is it supposed to do? Ian.
On Tue, 2012-09-04 at 08:06 +0100, Mark van Dijk wrote:> Good morning, > > I realise I''m probably too late, but if it''s trivial then maybe it is > possible to implement an ''xl reset vmname'' function before the final > release. > > Or is this not as trivial as I think it is?What is it supposed to do? Ian.
Would reset be different than reboot? http://xenbits.xen.org/docs/unstable/man/xl.1.html On Tue, Sep 4, 2012 at 3:06 AM, Mark van Dijk <lists+xen@internecto.net>wrote:> Good morning, > > I realise I''m probably too late, but if it''s trivial then maybe it is > possible to implement an ''xl reset vmname'' function before the final > release. > > Or is this not as trivial as I think it is? > > -- > Stay in touch, > Mark van Dijk. ,--------------------------------- > ----------------------------'' Tue Sep 04 07:04 UTC 2012 > Today is Boomtime, the 28th day of Bureaucracy in the YOLD 3178 > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
Would reset be different than reboot? http://xenbits.xen.org/docs/unstable/man/xl.1.html On Tue, Sep 4, 2012 at 3:06 AM, Mark van Dijk <lists+xen@internecto.net>wrote:> Good morning, > > I realise I''m probably too late, but if it''s trivial then maybe it is > possible to implement an ''xl reset vmname'' function before the final > release. > > Or is this not as trivial as I think it is? > > -- > Stay in touch, > Mark van Dijk. ,--------------------------------- > ----------------------------'' Tue Sep 04 07:04 UTC 2012 > Today is Boomtime, the 28th day of Bureaucracy in the YOLD 3178 > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
>> I realise I''m probably too late, but if it''s trivial then maybe it is >> possible to implement an ''xl reset vmname'' function before the final >> release. >> >> Or is this not as trivial as I think it is?Ian Campbell wrote:> What is it supposed to do?Casey DeLorme wrote:> Would reset be different than reboot? > http://xenbits.xen.org/docs/unstable/man/xl.1.htmlThe already implemented ''xl reboot'' sends an instruction to the running VM. If that VM doesn''t understand this type of call then xl tells you to try issuing ''xl reboot -F'', which sends an ACPI reboot instruction. These are convenient commands to be issued to a running domain so they can properly shutdown. But today I found that these both do nothing when a domain is frozen, e.g. a windows bsod or a hard Linux crash. It looks to me like there is just one way to take care of that: (manually) destroy and recreate. Back when I used xm I remember using the ''xm reset'' command that just simply emulates a manual press of the reset button. By coincidence, today I found xl lacks this command. In effect I think all it does is ''xl destroy'', wait until the domain is properly released and then ''xl create'' it again. This is a bit more convenient than manually issuing both commands because the time it takes to destroy a VM varies. So my request is just for convenience and this is why I called it trivial. Also because one could still issue something like ''xl destroy domain; sleep 30s; xl create domain''. (In fact, in my zsh shell env I wrote an xl function that is a wrapper to the xl binary. Another thing is that it allows me to do ''xl edit VMname'' which issues e.g. ''vim /etc/xen/hosts/VMname''. And when I issue ''xl create VMname'' it actually executes ''/usr/sbin/xl create /etc/xen/hosts/VMname''. I like convenience; who doesn''t? <grin>) -- Stay in touch, Mark van Dijk. ,--------------------------------- ----------------------------'' Tue Sep 04 08:23 UTC 2012 Today is Boomtime, the 28th day of Bureaucracy in the YOLD 3178
>> I realise I''m probably too late, but if it''s trivial then maybe it is >> possible to implement an ''xl reset vmname'' function before the final >> release. >> >> Or is this not as trivial as I think it is?Ian Campbell wrote:> What is it supposed to do?Casey DeLorme wrote:> Would reset be different than reboot? > http://xenbits.xen.org/docs/unstable/man/xl.1.htmlThe already implemented ''xl reboot'' sends an instruction to the running VM. If that VM doesn''t understand this type of call then xl tells you to try issuing ''xl reboot -F'', which sends an ACPI reboot instruction. These are convenient commands to be issued to a running domain so they can properly shutdown. But today I found that these both do nothing when a domain is frozen, e.g. a windows bsod or a hard Linux crash. It looks to me like there is just one way to take care of that: (manually) destroy and recreate. Back when I used xm I remember using the ''xm reset'' command that just simply emulates a manual press of the reset button. By coincidence, today I found xl lacks this command. In effect I think all it does is ''xl destroy'', wait until the domain is properly released and then ''xl create'' it again. This is a bit more convenient than manually issuing both commands because the time it takes to destroy a VM varies. So my request is just for convenience and this is why I called it trivial. Also because one could still issue something like ''xl destroy domain; sleep 30s; xl create domain''. (In fact, in my zsh shell env I wrote an xl function that is a wrapper to the xl binary. Another thing is that it allows me to do ''xl edit VMname'' which issues e.g. ''vim /etc/xen/hosts/VMname''. And when I issue ''xl create VMname'' it actually executes ''/usr/sbin/xl create /etc/xen/hosts/VMname''. I like convenience; who doesn''t? <grin>) -- Stay in touch, Mark van Dijk. ,--------------------------------- ----------------------------'' Tue Sep 04 08:23 UTC 2012 Today is Boomtime, the 28th day of Bureaucracy in the YOLD 3178
On Tue, 2012-09-04 at 09:37 +0100, Mark van Dijk wrote:> Back when I used xm I remember using the ''xm reset'' command that just > simply emulates a manual press of the reset button. By coincidence, > today I found xl lacks this command. In effect I think all it does is > ''xl destroy'', wait until the domain is properly released and then ''xl > create'' it again. This is a bit more convenient than manually issuing > both commands because the time it takes to destroy a VM varies.I can see how that would be useful. I think it is now too late for 4.2.0 (although it might depend on the patch) but if someone were to produce a patch for 4.3 we could consider a backport for 4.2.1. I think you would just need to expose a libxl function which ended up doing "xc_domain_shutdown(CTX->xch, domid, SHUTDOWN_reboot)". This would kill the domain and set its shutdown reason to SHUTDOWN_reboot which would signal the xl daemon monitoring the domain to restart it. Wire that libxl function up to xl reset (add it to xl_cmdtable.c, xl_cmdimpl.c and docs/man/xl.cfg.pod.1) and you are good to go, I think. Let me know if you want to give it a go and require more guidance. Ian.
On Tue, 2012-09-04 at 09:37 +0100, Mark van Dijk wrote:> Back when I used xm I remember using the ''xm reset'' command that just > simply emulates a manual press of the reset button. By coincidence, > today I found xl lacks this command. In effect I think all it does is > ''xl destroy'', wait until the domain is properly released and then ''xl > create'' it again. This is a bit more convenient than manually issuing > both commands because the time it takes to destroy a VM varies.I can see how that would be useful. I think it is now too late for 4.2.0 (although it might depend on the patch) but if someone were to produce a patch for 4.3 we could consider a backport for 4.2.1. I think you would just need to expose a libxl function which ended up doing "xc_domain_shutdown(CTX->xch, domid, SHUTDOWN_reboot)". This would kill the domain and set its shutdown reason to SHUTDOWN_reboot which would signal the xl daemon monitoring the domain to restart it. Wire that libxl function up to xl reset (add it to xl_cmdtable.c, xl_cmdimpl.c and docs/man/xl.cfg.pod.1) and you are good to go, I think. Let me know if you want to give it a go and require more guidance. Ian.
Am Dienstag, 4. September 2012, 10:37:50 schrieb Mark van Dijk:> (In fact, in my zsh shell env I wrote an xl function that is a wrapper > to the xl binary. Another thing is that it allows me to do ''xl edit > VMname'' which issues e.g. ''vim /etc/xen/hosts/VMname''. And when I issue > ''xl create VMname'' it actually executes ''/usr/sbin/xl > create /etc/xen/hosts/VMname''. I like convenience; who doesn''t? <grin>)hmm, from my experience in many environments did not are "fixed" pathes or places for config files as i.e. in your /etc/xen/hosts/ (i.e. many people hold config files with other stuff in per domain directories etc.) - makes it hardly or even impossible to provide a generic "edit" or "create" natively without any other limitations - so it would be more or less "usual" that users create their own scripts or wrappers for their own environment or provide external / third party toolsets for such "typical applications". best regards, Niels. -- --- Niels Dettenbach Syndicat IT & Internet http://www.syndicat.com PGP: https://syndicat.com/pub_key.asc --- _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
On Mon, Sep 03, 2012 at 10:42:40AM +0100, Ian Campbell wrote:> > tools, nice to have: > > * xl compatibility with xm: >* xl support for "monitor" command. I don''t see it mentioned in xl.cfg docs. (the command to enable/disable access to the per-vm Qemu monitor/console from VNC, which is usually accessed with ctrl-alt-2). -- Pasi
On Mon, Sep 03, 2012 at 10:42:40AM +0100, Ian Campbell wrote:> > tools, nice to have: > > * xl compatibility with xm: >* xl support for "monitor" command. I don''t see it mentioned in xl.cfg docs. (the command to enable/disable access to the per-vm Qemu monitor/console from VNC, which is usually accessed with ctrl-alt-2). -- Pasi
On Wed, 2012-09-05 at 03:51 +0100, Pasi Kärkkäinen wrote:> On Mon, Sep 03, 2012 at 10:42:40AM +0100, Ian Campbell wrote: > > > > tools, nice to have: > > > > * xl compatibility with xm: > > > * xl support for "monitor" command. I don't see it mentioned in xl.cfg docs. > (the command to enable/disable access to the per-vm Qemu monitor/console > from VNC, which is usually accessed with ctrl-alt-2).I can't see that happening for 4.2.0 now I'm afraid. Probably best to bring it up with George in the 4.3 thread. It might be a candidate for 4.2.1 depending on the size of the patch. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
On Wed, 2012-09-05 at 03:51 +0100, Pasi Kärkkäinen wrote:> On Mon, Sep 03, 2012 at 10:42:40AM +0100, Ian Campbell wrote: > > > > tools, nice to have: > > > > * xl compatibility with xm: > > > * xl support for "monitor" command. I don't see it mentioned in xl.cfg docs. > (the command to enable/disable access to the per-vm Qemu monitor/console > from VNC, which is usually accessed with ctrl-alt-2).I can't see that happening for 4.2.0 now I'm afraid. Probably best to bring it up with George in the 4.3 thread. It might be a candidate for 4.2.1 depending on the size of the patch. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Wed, Sep 05, 2012 at 09:34:27AM +0100, Ian Campbell wrote:> On Wed, 2012-09-05 at 03:51 +0100, Pasi Kärkkäinen wrote: > > On Mon, Sep 03, 2012 at 10:42:40AM +0100, Ian Campbell wrote: > > > > > > tools, nice to have: > > > > > > * xl compatibility with xm: > > > > > * xl support for "monitor" command. I don''t see it mentioned in xl.cfg docs. > > (the command to enable/disable access to the per-vm Qemu monitor/console > > from VNC, which is usually accessed with ctrl-alt-2). > > I can''t see that happening for 4.2.0 now I''m afraid. Probably best to > bring it up with George in the 4.3 thread. It might be a candidate for > 4.2.1 depending on the size of the patch. >Yep. If "monitor2 is enabled as a default (I''m not sure about that), then it''s a security issue.. User having a VNC session to the console of the VM can run Qemu commands, so for example map .iso files from dom0 etc.. -- Pasi
On Wed, Sep 05, 2012 at 09:34:27AM +0100, Ian Campbell wrote:> On Wed, 2012-09-05 at 03:51 +0100, Pasi Kärkkäinen wrote: > > On Mon, Sep 03, 2012 at 10:42:40AM +0100, Ian Campbell wrote: > > > > > > tools, nice to have: > > > > > > * xl compatibility with xm: > > > > > * xl support for "monitor" command. I don''t see it mentioned in xl.cfg docs. > > (the command to enable/disable access to the per-vm Qemu monitor/console > > from VNC, which is usually accessed with ctrl-alt-2). > > I can''t see that happening for 4.2.0 now I''m afraid. Probably best to > bring it up with George in the 4.3 thread. It might be a candidate for > 4.2.1 depending on the size of the patch. >Yep. If "monitor2 is enabled as a default (I''m not sure about that), then it''s a security issue.. User having a VNC session to the console of the VM can run Qemu commands, so for example map .iso files from dom0 etc.. -- Pasi
Wednesday, September 5, 2012, 10:34:27 AM, you wrote:> On Wed, 2012-09-05 at 03:51 +0100, Pasi Kärkkäinen wrote: >> On Mon, Sep 03, 2012 at 10:42:40AM +0100, Ian Campbell wrote: >> > >> > tools, nice to have: >> > >> > * xl compatibility with xm: >> > >> * xl support for "monitor" command. I don't see it mentioned in xl.cfg docs. >> (the command to enable/disable access to the per-vm Qemu monitor/console >> from VNC, which is usually accessed with ctrl-alt-2).> I can't see that happening for 4.2.0 now I'm afraid. Probably best to > bring it up with George in the 4.3 thread. It might be a candidate for > 4.2.1 depending on the size of the patch.I have the feeling there are still quite some options missing from xl ? And since xm will be formally deprecated perhaps this urges for a liberal view on backporting candidates. Having to wait a full release cycle for compatibility stuff doesn't seem very attractive and might make people skip 4.2.x altogether. I have just started on the shutdown option, so hopefully that can be off the list today :-) And do it for xl reboot too, it also lacks the "-a" option. After that perhaps try to make a comparison between xm and xl to see what's still lacking in terms of compatibility and see what would be nice to have implemented, and what can perhaps be left out. -- Sander> Ian._______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Wednesday, September 5, 2012, 10:34:27 AM, you wrote:> On Wed, 2012-09-05 at 03:51 +0100, Pasi Kärkkäinen wrote: >> On Mon, Sep 03, 2012 at 10:42:40AM +0100, Ian Campbell wrote: >> > >> > tools, nice to have: >> > >> > * xl compatibility with xm: >> > >> * xl support for "monitor" command. I don't see it mentioned in xl.cfg docs. >> (the command to enable/disable access to the per-vm Qemu monitor/console >> from VNC, which is usually accessed with ctrl-alt-2).> I can't see that happening for 4.2.0 now I'm afraid. Probably best to > bring it up with George in the 4.3 thread. It might be a candidate for > 4.2.1 depending on the size of the patch.I have the feeling there are still quite some options missing from xl ? And since xm will be formally deprecated perhaps this urges for a liberal view on backporting candidates. Having to wait a full release cycle for compatibility stuff doesn't seem very attractive and might make people skip 4.2.x altogether. I have just started on the shutdown option, so hopefully that can be off the list today :-) And do it for xl reboot too, it also lacks the "-a" option. After that perhaps try to make a comparison between xm and xl to see what's still lacking in terms of compatibility and see what would be nice to have implemented, and what can perhaps be left out. -- Sander> Ian._______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
On Wed, 2012-09-05 at 09:51 +0100, Sander Eikelenboom wrote:> Wednesday, September 5, 2012, 10:34:27 AM, you wrote: > > > On Wed, 2012-09-05 at 03:51 +0100, Pasi Kärkkäinen wrote: > >> On Mon, Sep 03, 2012 at 10:42:40AM +0100, Ian Campbell wrote: > >> > > >> > tools, nice to have: > >> > > >> > * xl compatibility with xm: > >> > > >> * xl support for "monitor" command. I don't see it mentioned in xl.cfg docs. > >> (the command to enable/disable access to the per-vm Qemu monitor/console > >> from VNC, which is usually accessed with ctrl-alt-2). > > > I can't see that happening for 4.2.0 now I'm afraid. Probably best to > > bring it up with George in the 4.3 thread. It might be a candidate for > > 4.2.1 depending on the size of the patch. > > I have the feeling there are still quite some options missing from xl ? > And since xm will be formally deprecated perhaps this urges for a liberal view on backporting candidates. > > Having to wait a full release cycle for compatibility stuff doesn't > seem very attractive and might make people skip 4.2.x altogether.We have pretty much agreed that for at least 4.2.1 (and perhaps later 4.2.x too) we will take a slightly more liberal than usual approach to backports which improve xl's feature parity with xend.> I have just started on the shutdown option, so hopefully that can be off the list today :-) > And do it for xl reboot too, it also lacks the "-a" option.Great thanks.> After that perhaps try to make a comparison between xm and xl to see > what's still lacking in terms of compatibility and see what would be > nice to have implemented, and what can perhaps be left out.That would be great. Our priority would be to implement features which people actually use in practice. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
On Wed, 2012-09-05 at 09:51 +0100, Sander Eikelenboom wrote:> Wednesday, September 5, 2012, 10:34:27 AM, you wrote: > > > On Wed, 2012-09-05 at 03:51 +0100, Pasi Kärkkäinen wrote: > >> On Mon, Sep 03, 2012 at 10:42:40AM +0100, Ian Campbell wrote: > >> > > >> > tools, nice to have: > >> > > >> > * xl compatibility with xm: > >> > > >> * xl support for "monitor" command. I don't see it mentioned in xl.cfg docs. > >> (the command to enable/disable access to the per-vm Qemu monitor/console > >> from VNC, which is usually accessed with ctrl-alt-2). > > > I can't see that happening for 4.2.0 now I'm afraid. Probably best to > > bring it up with George in the 4.3 thread. It might be a candidate for > > 4.2.1 depending on the size of the patch. > > I have the feeling there are still quite some options missing from xl ? > And since xm will be formally deprecated perhaps this urges for a liberal view on backporting candidates. > > Having to wait a full release cycle for compatibility stuff doesn't > seem very attractive and might make people skip 4.2.x altogether.We have pretty much agreed that for at least 4.2.1 (and perhaps later 4.2.x too) we will take a slightly more liberal than usual approach to backports which improve xl's feature parity with xend.> I have just started on the shutdown option, so hopefully that can be off the list today :-) > And do it for xl reboot too, it also lacks the "-a" option.Great thanks.> After that perhaps try to make a comparison between xm and xl to see > what's still lacking in terms of compatibility and see what would be > nice to have implemented, and what can perhaps be left out.That would be great. Our priority would be to implement features which people actually use in practice. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Wed, 2012-09-05 at 09:39 +0100, Pasi Kärkkäinen wrote:> On Wed, Sep 05, 2012 at 09:34:27AM +0100, Ian Campbell wrote: > > On Wed, 2012-09-05 at 03:51 +0100, Pasi Kärkkäinen wrote: > > > On Mon, Sep 03, 2012 at 10:42:40AM +0100, Ian Campbell wrote: > > > > > > > > tools, nice to have: > > > > > > > > * xl compatibility with xm: > > > > > > > * xl support for "monitor" command. I don't see it mentioned in xl.cfg docs. > > > (the command to enable/disable access to the per-vm Qemu monitor/console > > > from VNC, which is usually accessed with ctrl-alt-2). > > > > I can't see that happening for 4.2.0 now I'm afraid. Probably best to > > bring it up with George in the 4.3 thread. It might be a candidate for > > 4.2.1 depending on the size of the patch. > > > > Yep. If "monitor2 is enabled as a default (I'm not sure about that), then it's a security issue..Right, we *definitely* need to make sure this is not the case before 4.2.0. I consider this aspect of monitor support a blocker.> User having a VNC session to the console of the VM can run Qemu > commands, so for example map .iso files from dom0 etc..Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
On Wed, 2012-09-05 at 09:39 +0100, Pasi Kärkkäinen wrote:> On Wed, Sep 05, 2012 at 09:34:27AM +0100, Ian Campbell wrote: > > On Wed, 2012-09-05 at 03:51 +0100, Pasi Kärkkäinen wrote: > > > On Mon, Sep 03, 2012 at 10:42:40AM +0100, Ian Campbell wrote: > > > > > > > > tools, nice to have: > > > > > > > > * xl compatibility with xm: > > > > > > > * xl support for "monitor" command. I don't see it mentioned in xl.cfg docs. > > > (the command to enable/disable access to the per-vm Qemu monitor/console > > > from VNC, which is usually accessed with ctrl-alt-2). > > > > I can't see that happening for 4.2.0 now I'm afraid. Probably best to > > bring it up with George in the 4.3 thread. It might be a candidate for > > 4.2.1 depending on the size of the patch. > > > > Yep. If "monitor2 is enabled as a default (I'm not sure about that), then it's a security issue..Right, we *definitely* need to make sure this is not the case before 4.2.0. I consider this aspect of monitor support a blocker.> User having a VNC session to the console of the VM can run Qemu > commands, so for example map .iso files from dom0 etc..Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Quoting Niels Dettenbach''s message from 04 sep 2012:>Am Dienstag, 4. September 2012, 10:37:50 schrieb Mark van Dijk: >> (In fact, in my zsh shell env I wrote an xl function that is a >> wrapper to the xl binary. Another thing is that it allows me to do >> ''xl edit VMname'' which issues e.g. ''vim /etc/xen/hosts/VMname''. And >> when I issue ''xl create VMname'' it actually executes ''/usr/sbin/xl >> create /etc/xen/hosts/VMname''. I like convenience; who doesn''t? >> <grin>)>hmm, >from my experience in many environments did not are "fixed" pathes or >places for config files as i.e. in your /etc/xen/hosts/ (i.e. many >people hold config files with other stuff in per domain directories >etc.) - makes it hardly or even impossible to provide a generic "edit" >or "create" natively without any other limitations - so it would be >more or less "usual" that users create their own scripts or wrappers >for their own environment or provide external / third party toolsets >for such "typical applications".Yes. The request I made was for ''xl reset'', the rest served only as an example. -- Anyway, time for lunch! -Mark van Dijk. ,--------------------------------- -----------------------------'' Wed Sep 05 11:56 UTC 2012 Today is Pungenday, the 29th day of Bureaucracy in the YOLD 3178
Quoting Ian Campbell''s message from 03 sep 2012:> * [CHECK] More formally deprecate xm/xend. Manpage patches already > in tree. Needs release noting and communication around -rc1 to > remind people to test xl. (DONE)I''m just wondering if it''s properly stated somewhere that the ''vfb'' line in a VM''s config has been replaced with things like: vnc=1 vnclisten="0.0.0.0" vncdisplay="10" This reminds me of a few things I found with regards to VNC just now, while testing the upstream qemu with Xen (both master and version 1.1-stable). 1) While the above syntax, it is also possible to have ''vnclisten="0.0.0.0:10"''. They do the same i.e. open a listening VNC port on port 5910. But imho the term vncdisplay is a bit vague. I realise ''display'' refers to a display port. However, I suspect that not everyone understands it just means the tcp listening port. Perhaps it would be better to just use the latter and deprecate/remove the vncdisplay line? ''vnclisten="0.0.0.0:10"'' is more common anyway, right? 2) With upstream qemu it seems that the highest possible number for both syntaxes is 99. In other words, it looks like upstream qemu ''suddenly'' enforces the VNC ports to be between 5900 and 5999. It''s just a matter of taste probably but I really dislike this new restriction. I also dislike using iptables -t nat -j REDIRECT to redirect another port number to the actual (59xx) VNC port. How do you guys feel about this? Oh, just a small disclaimer -- i''m not saying this should all be settled before 4.2 though it''s probably wise to at least state somewhere that ''the vfb line is deprecated with xl''. And it''s all up to Ian c.s. anyway ;) -- Stay in touch, Mark van Dijk. ,--------------------------------- -----------------------------'' Wed Sep 05 12:27 UTC 2012 Today is Pungenday, the 29th day of Bureaucracy in the YOLD 3178
Quoting Ian Campbell''s message from 03 sep 2012:> * [CHECK] More formally deprecate xm/xend. Manpage patches already > in tree. Needs release noting and communication around -rc1 to > remind people to test xl. (DONE)I''m just wondering if it''s properly stated somewhere that the ''vfb'' line in a VM''s config has been replaced with things like: vnc=1 vnclisten="0.0.0.0" vncdisplay="10" This reminds me of a few things I found with regards to VNC just now, while testing the upstream qemu with Xen (both master and version 1.1-stable). 1) While the above syntax, it is also possible to have ''vnclisten="0.0.0.0:10"''. They do the same i.e. open a listening VNC port on port 5910. But imho the term vncdisplay is a bit vague. I realise ''display'' refers to a display port. However, I suspect that not everyone understands it just means the tcp listening port. Perhaps it would be better to just use the latter and deprecate/remove the vncdisplay line? ''vnclisten="0.0.0.0:10"'' is more common anyway, right? 2) With upstream qemu it seems that the highest possible number for both syntaxes is 99. In other words, it looks like upstream qemu ''suddenly'' enforces the VNC ports to be between 5900 and 5999. It''s just a matter of taste probably but I really dislike this new restriction. I also dislike using iptables -t nat -j REDIRECT to redirect another port number to the actual (59xx) VNC port. How do you guys feel about this? Oh, just a small disclaimer -- i''m not saying this should all be settled before 4.2 though it''s probably wise to at least state somewhere that ''the vfb line is deprecated with xl''. And it''s all up to Ian c.s. anyway ;) -- Stay in touch, Mark van Dijk. ,--------------------------------- -----------------------------'' Wed Sep 05 12:27 UTC 2012 Today is Pungenday, the 29th day of Bureaucracy in the YOLD 3178
On Mon, Sep 03, 2012 at 10:42:40AM +0100, Ian Campbell wrote:> > tools, nice to have: >* pygrub support for ext4 on rhel5/centos5. Roger already sent a patch for this. -- Pasi
On Mon, Sep 03, 2012 at 10:42:40AM +0100, Ian Campbell wrote:> > tools, nice to have: >* pygrub support for ext4 on rhel5/centos5. Roger already sent a patch for this. -- Pasi
>> tools, nice to have: > > * pygrub support for ext4 on rhel5/centos5. > Roger already sent a patch for this.I''d love to see some kind of extlinux (or grub2) that can replace the current pv-grub. Both support ext4 and, more importantly imho, btrfs, now that is one really cool filesystem. Grub0.97 is/will be being deprecated on an increasing number of distributions. And pv-grub is safer than pygrub because pygrub executes in the dom0 and pv-grub in the domU, if I understand correctly. Anyone willing to share thoughts on the possibility of ''pv-extlinux?'' -- Stay in touch, Mark van Dijk. ,--------------------------------- -----------------------------'' Wed Sep 05 17:44 UTC 2012 Today is Pungenday, the 29th day of Bureaucracy in the YOLD 3178
>> tools, nice to have: > > * pygrub support for ext4 on rhel5/centos5. > Roger already sent a patch for this.I''d love to see some kind of extlinux (or grub2) that can replace the current pv-grub. Both support ext4 and, more importantly imho, btrfs, now that is one really cool filesystem. Grub0.97 is/will be being deprecated on an increasing number of distributions. And pv-grub is safer than pygrub because pygrub executes in the dom0 and pv-grub in the domU, if I understand correctly. Anyone willing to share thoughts on the possibility of ''pv-extlinux?'' -- Stay in touch, Mark van Dijk. ,--------------------------------- -----------------------------'' Wed Sep 05 17:44 UTC 2012 Today is Pungenday, the 29th day of Bureaucracy in the YOLD 3178
On Wed, 2012-09-05 at 16:29 +0100, Pasi Kärkkäinen wrote:> On Mon, Sep 03, 2012 at 10:42:40AM +0100, Ian Campbell wrote: > > > > tools, nice to have: > > > > * pygrub support for ext4 on rhel5/centos5. > Roger already sent a patch for this.As I said in the introduction we are intending to do the final RC on Friday (i.e. the day after tomorrow). So at this stage in the release I''m afraid you will have to do a *much* better job of justifying why any change should go on the list (and therefore be considered for inclusion in 4.2.0) than that. Ian.
On Wed, 2012-09-05 at 16:29 +0100, Pasi Kärkkäinen wrote:> On Mon, Sep 03, 2012 at 10:42:40AM +0100, Ian Campbell wrote: > > > > tools, nice to have: > > > > * pygrub support for ext4 on rhel5/centos5. > Roger already sent a patch for this.As I said in the introduction we are intending to do the final RC on Friday (i.e. the day after tomorrow). So at this stage in the release I''m afraid you will have to do a *much* better job of justifying why any change should go on the list (and therefore be considered for inclusion in 4.2.0) than that. Ian.
On Wed, Sep 05, 2012 at 07:53:07PM +0200, Mark van Dijk wrote:> >> tools, nice to have: > > > > * pygrub support for ext4 on rhel5/centos5. > > Roger already sent a patch for this. > > I''d love to see some kind of extlinux (or grub2) that can replace the > current pv-grub. Both support ext4 and, more importantly imho, > btrfs, now that is one really cool filesystem.Personally I''d love to see pv-extlinux. I chatted last week with some folks at the Linux Plumbers Conference about this, and I think it should be possible with a lot of work.> Grub0.97 is/will be being deprecated on an increasing number of > distributions. And pv-grub is safer than pygrub because pygrub executes > in the dom0 and pv-grub in the domU, if I understand correctly. > > Anyone willing to share thoughts on the possibility of ''pv-extlinux?''I believe that syslinux only builds as 32-bit, and the elf output is only an intermediate build target. Booting a 64-bit kernel with a 32-bit pv-extlinux won''t work. Also, I''m not sure that you could load the .elf output and do anything useful with it. I''ve heard a rumor that a pure-C syslinux version is in the works, which could help with this. syslinux has a really decent subset of the standard C library in com32/, and implementing the frontend drivers with it shouldn''t not be too hard. Building libxc against it might be another matter entirely. GRUB2 is currently more popular than extlinux I think, and it might lend itself to a PV port more readily. There was some initial work that made grub-emu run on top of MiniOS [1], but I''m not sure that it got much farther than that. Matt [1] http://lists.xen.org/archives/html/xen-devel/2009-05/msg00666.html
On Wed, Sep 05, 2012 at 07:53:07PM +0200, Mark van Dijk wrote:> >> tools, nice to have: > > > > * pygrub support for ext4 on rhel5/centos5. > > Roger already sent a patch for this. > > I''d love to see some kind of extlinux (or grub2) that can replace the > current pv-grub. Both support ext4 and, more importantly imho, > btrfs, now that is one really cool filesystem.Personally I''d love to see pv-extlinux. I chatted last week with some folks at the Linux Plumbers Conference about this, and I think it should be possible with a lot of work.> Grub0.97 is/will be being deprecated on an increasing number of > distributions. And pv-grub is safer than pygrub because pygrub executes > in the dom0 and pv-grub in the domU, if I understand correctly. > > Anyone willing to share thoughts on the possibility of ''pv-extlinux?''I believe that syslinux only builds as 32-bit, and the elf output is only an intermediate build target. Booting a 64-bit kernel with a 32-bit pv-extlinux won''t work. Also, I''m not sure that you could load the .elf output and do anything useful with it. I''ve heard a rumor that a pure-C syslinux version is in the works, which could help with this. syslinux has a really decent subset of the standard C library in com32/, and implementing the frontend drivers with it shouldn''t not be too hard. Building libxc against it might be another matter entirely. GRUB2 is currently more popular than extlinux I think, and it might lend itself to a PV port more readily. There was some initial work that made grub-emu run on top of MiniOS [1], but I''m not sure that it got much farther than that. Matt [1] http://lists.xen.org/archives/html/xen-devel/2009-05/msg00666.html
>>> On 03.09.12 at 11:42, Ian Campbell <Ian.Campbell@citrix.com> wrote: > hypervisor, nice to have: > > * S3 regression(s?) reported by Ben Guthro (Ben & Jan Beulich)So it looks like we got this nailed down (actually requiring two fixes). Would it be intended to still get these in before the release, or leave them for 4.3/4.2.1? Jan NB: I also found an unrelated issue earlier today where a hypercall would return success when it actually failed, but I won''t even bother sending that out if the fixes needed here aren''t to be considered, as that''s clearly minor compared to the regression here.
FWIW, I ran this through 100 suspend / resume cycles successfully, on the machine where I could only do one before. I''m still waiting for a laptop to free up that exhibited the other S3 failure where it went to sleep, but just pulsed the power LED when asked to wake up. I''m cautiously hopeful this fixes that problem, as well. Ben On Thu, Sep 6, 2012 at 8:36 AM, Jan Beulich <JBeulich@suse.com> wrote:>>>> On 03.09.12 at 11:42, Ian Campbell <Ian.Campbell@citrix.com> wrote: >> hypervisor, nice to have: >> >> * S3 regression(s?) reported by Ben Guthro (Ben & Jan Beulich) > > So it looks like we got this nailed down (actually requiring two > fixes). Would it be intended to still get these in before the > release, or leave them for 4.3/4.2.1? > > Jan > > NB: I also found an unrelated issue earlier today where a > hypercall would return success when it actually failed, but I > won''t even bother sending that out if the fixes needed here > aren''t to be considered, as that''s clearly minor compared to > the regression here. > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
Good news on this front, as well - it seems to fix the "blinky power button" failure, as well. On Thu, Sep 6, 2012 at 8:55 AM, Ben Guthro <ben@guthro.net> wrote:> FWIW, I ran this through 100 suspend / resume cycles successfully, on > the machine where I could only do one before. > > I''m still waiting for a laptop to free up that exhibited the other S3 > failure where it went to sleep, but just pulsed the power LED when > asked to wake up. > I''m cautiously hopeful this fixes that problem, as well. > > Ben > > On Thu, Sep 6, 2012 at 8:36 AM, Jan Beulich <JBeulich@suse.com> wrote: >>>>> On 03.09.12 at 11:42, Ian Campbell <Ian.Campbell@citrix.com> wrote: >>> hypervisor, nice to have: >>> >>> * S3 regression(s?) reported by Ben Guthro (Ben & Jan Beulich) >> >> So it looks like we got this nailed down (actually requiring two >> fixes). Would it be intended to still get these in before the >> release, or leave them for 4.3/4.2.1? >> >> Jan >> >> NB: I also found an unrelated issue earlier today where a >> hypercall would return success when it actually failed, but I >> won''t even bother sending that out if the fixes needed here >> aren''t to be considered, as that''s clearly minor compared to >> the regression here. >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel
I may have claimed success on this second one too soon. Subsequent tests, and expansion to other systems shows S3 still to be a problem on these laptops. Being a laptop, without a serial port, of course makes this more difficult to debug. I''ll continue to look into it. On Thu, Sep 6, 2012 at 9:40 AM, Ben Guthro <ben@guthro.net> wrote:> Good news on this front, as well - it seems to fix the "blinky power > button" failure, as well. > > > On Thu, Sep 6, 2012 at 8:55 AM, Ben Guthro <ben@guthro.net> wrote: >> FWIW, I ran this through 100 suspend / resume cycles successfully, on >> the machine where I could only do one before. >> >> I''m still waiting for a laptop to free up that exhibited the other S3 >> failure where it went to sleep, but just pulsed the power LED when >> asked to wake up. >> I''m cautiously hopeful this fixes that problem, as well. >> >> Ben >> >> On Thu, Sep 6, 2012 at 8:36 AM, Jan Beulich <JBeulich@suse.com> wrote: >>>>>> On 03.09.12 at 11:42, Ian Campbell <Ian.Campbell@citrix.com> wrote: >>>> hypervisor, nice to have: >>>> >>>> * S3 regression(s?) reported by Ben Guthro (Ben & Jan Beulich) >>> >>> So it looks like we got this nailed down (actually requiring two >>> fixes). Would it be intended to still get these in before the >>> release, or leave them for 4.3/4.2.1? >>> >>> Jan >>> >>> NB: I also found an unrelated issue earlier today where a >>> hypercall would return success when it actually failed, but I >>> won''t even bother sending that out if the fixes needed here >>> aren''t to be considered, as that''s clearly minor compared to >>> the regression here. >>> >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xen.org >>> http://lists.xen.org/xen-devel
On Thu, Sep 06, 2012 at 10:35:44AM -0400, Ben Guthro wrote:> I may have claimed success on this second one too soon. Subsequent > tests, and expansion to other systems shows S3 still to be a problem > on these laptops. > > Being a laptop, without a serial port, of course makes this more > difficult to debug. > I''ll continue to look into it. >You probably know this already but here goes anyway.. you could use an expresscard serial card, or if the laptop has Intel vPro (AMT), then it has a Serial Over LAN (SOL) port, which can be used for Xen debugging/logging. -- Pasi> On Thu, Sep 6, 2012 at 9:40 AM, Ben Guthro <ben@guthro.net> wrote: > > Good news on this front, as well - it seems to fix the "blinky power > > button" failure, as well. > > > > > > On Thu, Sep 6, 2012 at 8:55 AM, Ben Guthro <ben@guthro.net> wrote: > >> FWIW, I ran this through 100 suspend / resume cycles successfully, on > >> the machine where I could only do one before. > >> > >> I''m still waiting for a laptop to free up that exhibited the other S3 > >> failure where it went to sleep, but just pulsed the power LED when > >> asked to wake up. > >> I''m cautiously hopeful this fixes that problem, as well. > >> > >> Ben > >> > >> On Thu, Sep 6, 2012 at 8:36 AM, Jan Beulich <JBeulich@suse.com> wrote: > >>>>>> On 03.09.12 at 11:42, Ian Campbell <Ian.Campbell@citrix.com> wrote: > >>>> hypervisor, nice to have: > >>>> > >>>> * S3 regression(s?) reported by Ben Guthro (Ben & Jan Beulich) > >>> > >>> So it looks like we got this nailed down (actually requiring two > >>> fixes). Would it be intended to still get these in before the > >>> release, or leave them for 4.3/4.2.1? > >>> > >>> Jan > >>> > >>> NB: I also found an unrelated issue earlier today where a > >>> hypercall would return success when it actually failed, but I > >>> won''t even bother sending that out if the fixes needed here > >>> aren''t to be considered, as that''s clearly minor compared to > >>> the regression here. > >>> > >>> > >>> _______________________________________________ > >>> Xen-devel mailing list > >>> Xen-devel@lists.xen.org > >>> http://lists.xen.org/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
On Thu, Sep 6, 2012 at 10:45 AM, Pasi Kärkkäinen <pasik@iki.fi> wrote:> On Thu, Sep 06, 2012 at 10:35:44AM -0400, Ben Guthro wrote: >> I may have claimed success on this second one too soon. Subsequent >> tests, and expansion to other systems shows S3 still to be a problem >> on these laptops. >> >> Being a laptop, without a serial port, of course makes this more >> difficult to debug. >> I''ll continue to look into it. >> > > You probably know this already but here goes anyway.. > you could use an expresscard serial card, or if the laptop has Intel vPro (AMT), > then it has a Serial Over LAN (SOL) port, which can be used for Xen debugging/logging.This particular machine has neither. I''ll look around for an alternate. Ben> > -- Pasi > >> On Thu, Sep 6, 2012 at 9:40 AM, Ben Guthro <ben@guthro.net> wrote: >> > Good news on this front, as well - it seems to fix the "blinky power >> > button" failure, as well. >> > >> > >> > On Thu, Sep 6, 2012 at 8:55 AM, Ben Guthro <ben@guthro.net> wrote: >> >> FWIW, I ran this through 100 suspend / resume cycles successfully, on >> >> the machine where I could only do one before. >> >> >> >> I''m still waiting for a laptop to free up that exhibited the other S3 >> >> failure where it went to sleep, but just pulsed the power LED when >> >> asked to wake up. >> >> I''m cautiously hopeful this fixes that problem, as well. >> >> >> >> Ben >> >> >> >> On Thu, Sep 6, 2012 at 8:36 AM, Jan Beulich <JBeulich@suse.com> wrote: >> >>>>>> On 03.09.12 at 11:42, Ian Campbell <Ian.Campbell@citrix.com> wrote: >> >>>> hypervisor, nice to have: >> >>>> >> >>>> * S3 regression(s?) reported by Ben Guthro (Ben & Jan Beulich) >> >>> >> >>> So it looks like we got this nailed down (actually requiring two >> >>> fixes). Would it be intended to still get these in before the >> >>> release, or leave them for 4.3/4.2.1? >> >>> >> >>> Jan >> >>> >> >>> NB: I also found an unrelated issue earlier today where a >> >>> hypercall would return success when it actually failed, but I >> >>> won''t even bother sending that out if the fixes needed here >> >>> aren''t to be considered, as that''s clearly minor compared to >> >>> the regression here. >> >>> >> >>> >> >>> _______________________________________________ >> >>> Xen-devel mailing list >> >>> Xen-devel@lists.xen.org >> >>> http://lists.xen.org/xen-devel >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel
On Thu, Sep 06, 2012 at 10:47:24AM -0400, Ben Guthro wrote:> On Thu, Sep 6, 2012 at 10:45 AM, Pasi Kärkkäinen <pasik@iki.fi> wrote: > > On Thu, Sep 06, 2012 at 10:35:44AM -0400, Ben Guthro wrote: > >> I may have claimed success on this second one too soon. Subsequent > >> tests, and expansion to other systems shows S3 still to be a problem > >> on these laptops. > >> > >> Being a laptop, without a serial port, of course makes this more > >> difficult to debug. > >> I''ll continue to look into it. > >> > > > > You probably know this already but here goes anyway.. > > you could use an expresscard serial card, or if the laptop has Intel vPro (AMT), > > then it has a Serial Over LAN (SOL) port, which can be used for Xen debugging/logging. > > This particular machine has neither. > I''ll look around for an alternate. >Does it have mini PCI express? (the slot where you can put wlan adapter etc). http://www.amazon.com/StarTech-com-RS232-Express-Serial-MPEX2S952/dp/B003OCRW1Q -- Pasi> > > Ben > > > > > -- Pasi > > > >> On Thu, Sep 6, 2012 at 9:40 AM, Ben Guthro <ben@guthro.net> wrote: > >> > Good news on this front, as well - it seems to fix the "blinky power > >> > button" failure, as well. > >> > > >> > > >> > On Thu, Sep 6, 2012 at 8:55 AM, Ben Guthro <ben@guthro.net> wrote: > >> >> FWIW, I ran this through 100 suspend / resume cycles successfully, on > >> >> the machine where I could only do one before. > >> >> > >> >> I''m still waiting for a laptop to free up that exhibited the other S3 > >> >> failure where it went to sleep, but just pulsed the power LED when > >> >> asked to wake up. > >> >> I''m cautiously hopeful this fixes that problem, as well. > >> >> > >> >> Ben > >> >> > >> >> On Thu, Sep 6, 2012 at 8:36 AM, Jan Beulich <JBeulich@suse.com> wrote: > >> >>>>>> On 03.09.12 at 11:42, Ian Campbell <Ian.Campbell@citrix.com> wrote: > >> >>>> hypervisor, nice to have: > >> >>>> > >> >>>> * S3 regression(s?) reported by Ben Guthro (Ben & Jan Beulich) > >> >>> > >> >>> So it looks like we got this nailed down (actually requiring two > >> >>> fixes). Would it be intended to still get these in before the > >> >>> release, or leave them for 4.3/4.2.1? > >> >>> > >> >>> Jan > >> >>> > >> >>> NB: I also found an unrelated issue earlier today where a > >> >>> hypercall would return success when it actually failed, but I > >> >>> won''t even bother sending that out if the fixes needed here > >> >>> aren''t to be considered, as that''s clearly minor compared to > >> >>> the regression here. > >> >>> > >> >>> > >> >>> _______________________________________________ > >> >>> Xen-devel mailing list > >> >>> Xen-devel@lists.xen.org > >> >>> http://lists.xen.org/xen-devel > >> > >> _______________________________________________ > >> Xen-devel mailing list > >> Xen-devel@lists.xen.org > >> http://lists.xen.org/xen-devel
>>> On 06.09.12 at 16:35, Ben Guthro <ben@guthro.net> wrote: > I may have claimed success on this second one too soon. Subsequent > tests, and expansion to other systems shows S3 still to be a problem > on these laptops.Blinking LEDs generally mean Linux crashed (Xen doesn''t do any blinking).> Being a laptop, without a serial port, of course makes this more > difficult to debug.And the screen isn''t back to be visible yet I understand. Is that even if you run the screen in 80x25 text mode? Does that laptop have a EHCI debug port? Jan