vnc=1 / pvgrub / close fb: backend at /local/domain/0/backend/vfb/xx/0

vnc=1 / pvgrub / close fb: backend at /local/domain/0/backend/vfb/xx/0

[Steven Haigh]

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

Hi all,

I'm toying around with having VNC accessable for some PV guests - but
having a bit of an issue.

1) When vnc is enabled, the grub menu shown via pvgrub stays until a
selection is made on the vnc console. The timeout does not seem to ever
kick in and the DomU more or less sits there churning CPU waiting for a
selection. Once a selection is made, we move to problem #2.

2) When the DomU boots, I see this as one of the last messages before
the DomU kernel takes over:

backend at /local/domain/0/backend/vfb/55/0
/local/domain/0/backend/vkbd/55/0 connected
************************** KBDFRONT
Thread "kbdfront" exited.
/local/domain/0/backend/vfb/55/0 connected
************************** FBFRONT
Thread "kbdfront close": pointer: 0x2200004550, stack: 0x3a30000
close fb: backend at /local/domain/0/backend/vfb/55/0
close kbd: backend at /local/domain/0/backend/vkbd/55/0
  Booting 'Scientific Linux (3.14.21-1.el6xen.x86_64)'

At this point, the VNC server dies and never returns. No VNC connections
are accepted at this point on - and the port (verified via netstat -lnp)
is not open.

I have tried this with both the following layouts of options:
vfb = [ 'type=vnc, vnclisten=192.168.1.1, vncpasswd=supasecret,
vncdisplay=10' ]

and;
vnc             = 1
vnclisten       = "192.168.1.1"

Has anyone had VNC working properly?

# xl info
host                   : xenhost.local
release                : 3.14.20-1.el6xen.x86_64
version                : #1 SMP Mon Oct 6 22:03:42 EST 2014
machine                : x86_64
nr_cpus                : 8
max_cpu_id             : 7
nr_nodes               : 1
cores_per_socket       : 4
threads_per_core       : 1
cpu_mhz                : 2327
hw_caps                :
bfebfbff:20000800:00000000:00000900:0004e3bd:00000000:00000001:00000000
virt_caps              : hvm
total_memory           : 20479
free_memory            : 2587
sharing_freed_memory   : 0
sharing_used_memory    : 0
outstanding_claims     : 0
free_cpus              : 0
xen_major              : 4
xen_minor              : 4
xen_extra              : .1
xen_version            : 4.4.1
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          :
xen_commandline        : dom0_mem=1G cpufreq=xen dom0_max_vcpus=1
dom0_vcpus_pin console=tty0 console=com1 com1=115200,8n1
cc_compiler            : gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)
cc_compile_by          : mockbuild
cc_compile_domain      : crc.id.au
cc_compile_date        : Tue Oct  7 01:00:52 EST 2014
xend_config_format     : 4


-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

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

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

Re: vnc=1 / pvgrub / close fb: backend at /local/domain/0/backend/vfb/xx/0

[Steven Haigh]

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

As a side note to this - if I use pygrub as a bootloader vs using
pvgrub, then VNC works perfectly.

So, what options exist to make pvgrub behave properly for booting with
VNC enabled?

On 22/10/2014 2:17 AM, Steven Haigh wrote:
> Hi all,
> 
> I'm toying around with having VNC accessable for some PV guests - but
> having a bit of an issue.
> 
> 1) When vnc is enabled, the grub menu shown via pvgrub stays until a
> selection is made on the vnc console. The timeout does not seem to ever
> kick in and the DomU more or less sits there churning CPU waiting for a
> selection. Once a selection is made, we move to problem #2.
> 
> 2) When the DomU boots, I see this as one of the last messages before
> the DomU kernel takes over:
> 
> backend at /local/domain/0/backend/vfb/55/0
> /local/domain/0/backend/vkbd/55/0 connected
> ************************** KBDFRONT
> Thread "kbdfront" exited.
> /local/domain/0/backend/vfb/55/0 connected
> ************************** FBFRONT
> Thread "kbdfront close": pointer: 0x2200004550, stack: 0x3a30000
> close fb: backend at /local/domain/0/backend/vfb/55/0
> close kbd: backend at /local/domain/0/backend/vkbd/55/0
>   Booting 'Scientific Linux (3.14.21-1.el6xen.x86_64)'
> 
> At this point, the VNC server dies and never returns. No VNC connections
> are accepted at this point on - and the port (verified via netstat -lnp)
> is not open.
> 
> I have tried this with both the following layouts of options:
> vfb = [ 'type=vnc, vnclisten=192.168.1.1, vncpasswd=supasecret,
> vncdisplay=10' ]
> 
> and;
> vnc             = 1
> vnclisten       = "192.168.1.1"
> 
> Has anyone had VNC working properly?
> 
> # xl info
> host                   : xenhost.local
> release                : 3.14.20-1.el6xen.x86_64
> version                : #1 SMP Mon Oct 6 22:03:42 EST 2014
> machine                : x86_64
> nr_cpus                : 8
> max_cpu_id             : 7
> nr_nodes               : 1
> cores_per_socket       : 4
> threads_per_core       : 1
> cpu_mhz                : 2327
> hw_caps                :
> bfebfbff:20000800:00000000:00000900:0004e3bd:00000000:00000001:00000000
> virt_caps              : hvm
> total_memory           : 20479
> free_memory            : 2587
> sharing_freed_memory   : 0
> sharing_used_memory    : 0
> outstanding_claims     : 0
> free_cpus              : 0
> xen_major              : 4
> xen_minor              : 4
> xen_extra              : .1
> xen_version            : 4.4.1
> 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          :
> xen_commandline        : dom0_mem=1G cpufreq=xen dom0_max_vcpus=1
> dom0_vcpus_pin console=tty0 console=com1 com1=115200,8n1
> cc_compiler            : gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)
> cc_compile_by          : mockbuild
> cc_compile_domain      : crc.id.au
> cc_compile_date        : Tue Oct  7 01:00:52 EST 2014
> xend_config_format     : 4
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

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

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

Re: vnc=1 / pvgrub / close fb: backend at /local/domain/0/backend/vfb/xx/0

[Ian Campbell]

On Wed, 2014-10-22 at 08:24 +1100, Steven Haigh wrote:
> As a side note to this - if I use pygrub as a bootloader vs using
> pvgrub, then VNC works perfectly.
> 
> So, what options exist to make pvgrub behave properly for booting with
> VNC enabled?

ISTR (vaguely) that way back when the backends needed to be modified to
cope with kexec (which is effectively what pvgrub does) by not exiting
when the frontend disconnects, instead sticking around waiting for a new
frontend, this relates somehow to the "online" key in xenstore.

Perhaps the pvfb backend never got that treatment, which would explain
#2? 

That was ages ago (like 2005/6?) so it seems a bit unlikely you'd be the
first to try this and notice.

I've no idea for #1 though.

Oh, is this with pvgrub 1 (the thing which ships with Xen) or pvgrub 2
(from the upstream grub project fairly recently)? Your logs hint towards
the former.

Ian.

> On 22/10/2014 2:17 AM, Steven Haigh wrote:
> > Hi all,
> > 
> > I'm toying around with having VNC accessable for some PV guests - but
> > having a bit of an issue.
> > 
> > 1) When vnc is enabled, the grub menu shown via pvgrub stays until a
> > selection is made on the vnc console. The timeout does not seem to ever
> > kick in and the DomU more or less sits there churning CPU waiting for a
> > selection. Once a selection is made, we move to problem #2.
> > 
> > 2) When the DomU boots, I see this as one of the last messages before
> > the DomU kernel takes over:
> > 
> > backend at /local/domain/0/backend/vfb/55/0
> > /local/domain/0/backend/vkbd/55/0 connected
> > ************************** KBDFRONT
> > Thread "kbdfront" exited.
> > /local/domain/0/backend/vfb/55/0 connected
> > ************************** FBFRONT
> > Thread "kbdfront close": pointer: 0x2200004550, stack: 0x3a30000
> > close fb: backend at /local/domain/0/backend/vfb/55/0
> > close kbd: backend at /local/domain/0/backend/vkbd/55/0
> >   Booting 'Scientific Linux (3.14.21-1.el6xen.x86_64)'
> > 
> > At this point, the VNC server dies and never returns. No VNC connections
> > are accepted at this point on - and the port (verified via netstat -lnp)
> > is not open.
> > 
> > I have tried this with both the following layouts of options:
> > vfb = [ 'type=vnc, vnclisten=192.168.1.1, vncpasswd=supasecret,
> > vncdisplay=10' ]
> > 
> > and;
> > vnc             = 1
> > vnclisten       = "192.168.1.1"
> > 
> > Has anyone had VNC working properly?
> > 
> > # xl info
> > host                   : xenhost.local
> > release                : 3.14.20-1.el6xen.x86_64
> > version                : #1 SMP Mon Oct 6 22:03:42 EST 2014
> > machine                : x86_64
> > nr_cpus                : 8
> > max_cpu_id             : 7
> > nr_nodes               : 1
> > cores_per_socket       : 4
> > threads_per_core       : 1
> > cpu_mhz                : 2327
> > hw_caps                :
> > bfebfbff:20000800:00000000:00000900:0004e3bd:00000000:00000001:00000000
> > virt_caps              : hvm
> > total_memory           : 20479
> > free_memory            : 2587
> > sharing_freed_memory   : 0
> > sharing_used_memory    : 0
> > outstanding_claims     : 0
> > free_cpus              : 0
> > xen_major              : 4
> > xen_minor              : 4
> > xen_extra              : .1
> > xen_version            : 4.4.1
> > 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          :
> > xen_commandline        : dom0_mem=1G cpufreq=xen dom0_max_vcpus=1
> > dom0_vcpus_pin console=tty0 console=com1 com1=115200,8n1
> > cc_compiler            : gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)
> > cc_compile_by          : mockbuild
> > cc_compile_domain      : crc.id.au
> > cc_compile_date        : Tue Oct  7 01:00:52 EST 2014
> > xend_config_format     : 4
> > 
> > 
> > 
> > 
> > _______________________________________________
> > 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

Re: vnc=1 / pvgrub / close fb: backend at /local/domain/0/backend/vfb/xx/0

[Samuel Thibault]

Ian Campbell, le Wed 22 Oct 2014 10:00:36 +0100, a écrit :
> On Wed, 2014-10-22 at 08:24 +1100, Steven Haigh wrote:
> > As a side note to this - if I use pygrub as a bootloader vs using
> > pvgrub, then VNC works perfectly.
> > 
> > So, what options exist to make pvgrub behave properly for booting with
> > VNC enabled?
> 
> ISTR (vaguely) that way back when the backends needed to be modified to
> cope with kexec (which is effectively what pvgrub does) by not exiting
> when the frontend disconnects, instead sticking around waiting for a new
> frontend, this relates somehow to the "online" key in xenstore.
> 
> Perhaps the pvfb backend never got that treatment, which would explain
> #2? 

Probably, yes.

> That was ages ago (like 2005/6?)

2007-2008 :)

> so it seems a bit unlikely you'd be the first to try this and notice.

Well, I guess there aren't so many people who use both pv-grub and a
pvfb.

> I've no idea for #1 though.

I wonder too.

> Oh, is this with pvgrub 1 (the thing which ships with Xen) or pvgrub 2
> (from the upstream grub project fairly recently)? Your logs hint towards
> the former.

Yes, the logs definitely look like mini-os, thus pvgrub 1.

Samuel

Re: vnc=1 / pvgrub / close fb: backend at /local/domain/0/backend/vfb/xx/0

[Steven Haigh]

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

On 22/10/2014 8:59 PM, Samuel Thibault wrote:
> Ian Campbell, le Wed 22 Oct 2014 10:00:36 +0100, a écrit :
>> On Wed, 2014-10-22 at 08:24 +1100, Steven Haigh wrote:
>>> As a side note to this - if I use pygrub as a bootloader vs using
>>> pvgrub, then VNC works perfectly.
>>>
>>> So, what options exist to make pvgrub behave properly for booting with
>>> VNC enabled?
>>
>> ISTR (vaguely) that way back when the backends needed to be modified to
>> cope with kexec (which is effectively what pvgrub does) by not exiting
>> when the frontend disconnects, instead sticking around waiting for a new
>> frontend, this relates somehow to the "online" key in xenstore.
>>
>> Perhaps the pvfb backend never got that treatment, which would explain
>> #2? 
> 
> Probably, yes.
> 
>> That was ages ago (like 2005/6?)
> 
> 2007-2008 :)

I found lots of talk about this - mostly in Xen versions 3.x - although
I couldn't find anything recent. As such, I assumed it was fixed.

>> so it seems a bit unlikely you'd be the first to try this and notice.
> 
> Well, I guess there aren't so many people who use both pv-grub and a
> pvfb.

It seems like thats the case sadly. We have always pushed people towards
pv-grub for that extra bit of security - but a world of documentation
ignores the existence of pv-grub. As such, I doubt most people have even
stumbled across pv-grub.

I remember talk of pygrub being phased out - but I don't recall to what
extent or what timeframe that is.

>> I've no idea for #1 though.
> 
> I wonder too.
> 
>> Oh, is this with pvgrub 1 (the thing which ships with Xen) or pvgrub 2
>> (from the upstream grub project fairly recently)? Your logs hint towards
>> the former.
> 
> Yes, the logs definitely look like mini-os, thus pvgrub 1.

Yes, this is the Xen shipped pv-grub. I haven't found any mention of
pvgrub 2 before - any links for that? I assume it can just be built and
called from within the DomU config?

-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

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

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

Re: vnc=1 / pvgrub / close fb: backend at /local/domain/0/backend/vfb/xx/0

[Samuel Thibault]

Steven Haigh, le Wed 22 Oct 2014 21:10:35 +1100, a écrit :
> > Yes, the logs definitely look like mini-os, thus pvgrub 1.
> 
> Yes, this is the Xen shipped pv-grub. I haven't found any mention of
> pvgrub 2 before - any links for that?

It is the regular grub2 source code, to which you specify the xen
platform. I don't remember the details.

> I assume it can just be built and called from within the DomU config?

Just like pvgrub1, yes.

Samuel

Re: vnc=1 / pvgrub / close fb: backend at /local/domain/0/backend/vfb/xx/0

[Ian Campbell]

On Wed, 2014-10-22 at 21:10 +1100, Steven Haigh wrote:
> It seems like thats the case sadly. We have always pushed people towards
> pv-grub for that extra bit of security - but a world of documentation
> ignores the existence of pv-grub. As such, I doubt most people have even
> stumbled across pv-grub.

I have an outstanding TODO to write a blog post about pvgrub2 and how to
use it, this stuff really does need to get better propagated.

> I remember talk of pygrub being phased out - but I don't recall to what
> extent or what timeframe that is.

That's not the case, both pygrub and pvgrub[12] have their uses (that's
not to say we wouldn't suggest people think very hard about using pygrub
in their environment)

> >> I've no idea for #1 though.
> > 
> > I wonder too.
> > 
> >> Oh, is this with pvgrub 1 (the thing which ships with Xen) or pvgrub 2
> >> (from the upstream grub project fairly recently)? Your logs hint towards
> >> the former.
> > 
> > Yes, the logs definitely look like mini-os, thus pvgrub 1.
> 
> Yes, this is the Xen shipped pv-grub. I haven't found any mention of
> pvgrub 2 before - any links for that? I assume it can just be built and
> called from within the DomU config?

I think it's mostly ./configure --with-platform=xen, followed by the
usual grub2 install steps.

http://lists.gnu.org/archive/html/grub-devel/2013-11/msg00085.html has
an outline.

Debian has a grub-xen-bin package in Jessie now but IIRC you are an RPM
kinda guy.

Ian.

Re: vnc=1 / pvgrub / close fb: backend at /local/domain/0/backend/vfb/xx/0

[Steven Haigh]

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

On 22/10/2014 9:31 PM, Ian Campbell wrote:
> On Wed, 2014-10-22 at 21:10 +1100, Steven Haigh wrote:
>> It seems like thats the case sadly. We have always pushed people towards
>> pv-grub for that extra bit of security - but a world of documentation
>> ignores the existence of pv-grub. As such, I doubt most people have even
>> stumbled across pv-grub.
> 
> I have an outstanding TODO to write a blog post about pvgrub2 and how to
> use it, this stuff really does need to get better propagated.

I would love to see this :)

>> I remember talk of pygrub being phased out - but I don't recall to what
>> extent or what timeframe that is.
> 
> That's not the case, both pygrub and pvgrub[12] have their uses (that's
> not to say we wouldn't suggest people think very hard about using pygrub
> in their environment)

It seems right now, anyone that uses VNC needs to use pygrub. Not
exactly ideal - as I'd love to be pygrub free as well :)

>>>> I've no idea for #1 though.
>>>
>>> I wonder too.
>>>
>>>> Oh, is this with pvgrub 1 (the thing which ships with Xen) or pvgrub 2
>>>> (from the upstream grub project fairly recently)? Your logs hint towards
>>>> the former.
>>>
>>> Yes, the logs definitely look like mini-os, thus pvgrub 1.
>>
>> Yes, this is the Xen shipped pv-grub. I haven't found any mention of
>> pvgrub 2 before - any links for that? I assume it can just be built and
>> called from within the DomU config?
> 
> I think it's mostly ./configure --with-platform=xen, followed by the
> usual grub2 install steps.
> 
> http://lists.gnu.org/archive/html/grub-devel/2013-11/msg00085.html has
> an outline.

Interesting.

> Debian has a grub-xen-bin package in Jessie now but IIRC you are an RPM
> kinda guy.

Yeah - I'll have to get some time to look over building this for an
individual package - with the big thing of making sure it doesn't
interfere with any installed system components. I do all my work on EL6
- so if anyone happens to have a starting point I can import, it would
be appreciated ;)

-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

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

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

Re: vnc=1 / pvgrub / close fb: backend at /local/domain/0/backend/vfb/xx/0

[Ian Campbell]

On Wed, 2014-10-22 at 11:59 +0200, Samuel Thibault wrote:
> Ian Campbell, le Wed 22 Oct 2014 10:00:36 +0100, a écrit :
> > On Wed, 2014-10-22 at 08:24 +1100, Steven Haigh wrote:
> > > As a side note to this - if I use pygrub as a bootloader vs using
> > > pvgrub, then VNC works perfectly.
> > > 
> > > So, what options exist to make pvgrub behave properly for booting with
> > > VNC enabled?
> > 
> > ISTR (vaguely) that way back when the backends needed to be modified to
> > cope with kexec (which is effectively what pvgrub does) by not exiting
> > when the frontend disconnects, instead sticking around waiting for a new
> > frontend, this relates somehow to the "online" key in xenstore.
> > 
> > Perhaps the pvfb backend never got that treatment, which would explain
> > #2? 
> 
> Probably, yes.

Adding Stefano and Anthony, since the backend in this case is in qemu.

When the frontend disconnects and the online node == 1 then the backend
is supposed to go from Closed back to InitWait and wait for a new
connection, as opposed to shutting down. This is needed for kexec (which
pvgrub uses).

I can see some handling of the online node in hw/xen/xen_backend.c but
it doesn't look like it would do what is needed here. I also don't see
any handling in either hw/block/xen_disk.c or hw/display/xenfb.c. Which
makes me suspect that as well as pvfb not working with kexec/pvgrub
neither does the qdisk backend, which would be unfortunate.

Ian.


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

Re: vnc=1 / pvgrub / close fb: backend at /local/domain/0/backend/vfb/xx/0

[Stefano Stabellini]

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

On Wed, 22 Oct 2014, Ian Campbell wrote:
> On Wed, 2014-10-22 at 11:59 +0200, Samuel Thibault wrote:
> > Ian Campbell, le Wed 22 Oct 2014 10:00:36 +0100, a écrit :
> > > On Wed, 2014-10-22 at 08:24 +1100, Steven Haigh wrote:
> > > > As a side note to this - if I use pygrub as a bootloader vs using
> > > > pvgrub, then VNC works perfectly.
> > > > 
> > > > So, what options exist to make pvgrub behave properly for booting with
> > > > VNC enabled?
> > > 
> > > ISTR (vaguely) that way back when the backends needed to be modified to
> > > cope with kexec (which is effectively what pvgrub does) by not exiting
> > > when the frontend disconnects, instead sticking around waiting for a new
> > > frontend, this relates somehow to the "online" key in xenstore.
> > > 
> > > Perhaps the pvfb backend never got that treatment, which would explain
> > > #2? 
> > 
> > Probably, yes.
> 
> Adding Stefano and Anthony, since the backend in this case is in qemu.
> 
> When the frontend disconnects and the online node == 1 then the backend
> is supposed to go from Closed back to InitWait and wait for a new
> connection, as opposed to shutting down. This is needed for kexec (which
> pvgrub uses).
> 
> I can see some handling of the online node in hw/xen/xen_backend.c but
> it doesn't look like it would do what is needed here. I also don't see
> any handling in either hw/block/xen_disk.c or hw/display/xenfb.c. Which
> makes me suspect that as well as pvfb not working with kexec/pvgrub
> neither does the qdisk backend, which would be unfortunate.

Looking at the code in xen_backend.c, it seems that on XenbusStateClosed
xen_backend is going to try to reset to XenbusStateInitialising, unless
the frontend state is XenbusStateInitialising (no idea why).  See:
xen_be_try_reset and xen_be_check_state.

Maybe it should go to XenbusStateInitWait instead?

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

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

Re: vnc=1 / pvgrub / close fb: backend at /local/domain/0/backend/vfb/xx/0

[Ian Campbell]

On Wed, 2014-10-22 at 12:57 +0100, Stefano Stabellini wrote:
> On Wed, 22 Oct 2014, Ian Campbell wrote:
> > On Wed, 2014-10-22 at 11:59 +0200, Samuel Thibault wrote:
> > > Ian Campbell, le Wed 22 Oct 2014 10:00:36 +0100, a écrit :
> > > > On Wed, 2014-10-22 at 08:24 +1100, Steven Haigh wrote:
> > > > > As a side note to this - if I use pygrub as a bootloader vs using
> > > > > pvgrub, then VNC works perfectly.
> > > > > 
> > > > > So, what options exist to make pvgrub behave properly for booting with
> > > > > VNC enabled?
> > > > 
> > > > ISTR (vaguely) that way back when the backends needed to be modified to
> > > > cope with kexec (which is effectively what pvgrub does) by not exiting
> > > > when the frontend disconnects, instead sticking around waiting for a new
> > > > frontend, this relates somehow to the "online" key in xenstore.
> > > > 
> > > > Perhaps the pvfb backend never got that treatment, which would explain
> > > > #2? 
> > > 
> > > Probably, yes.
> > 
> > Adding Stefano and Anthony, since the backend in this case is in qemu.
> > 
> > When the frontend disconnects and the online node == 1 then the backend
> > is supposed to go from Closed back to InitWait and wait for a new
> > connection, as opposed to shutting down. This is needed for kexec (which
> > pvgrub uses).
> > 
> > I can see some handling of the online node in hw/xen/xen_backend.c but
> > it doesn't look like it would do what is needed here. I also don't see
> > any handling in either hw/block/xen_disk.c or hw/display/xenfb.c. Which
> > makes me suspect that as well as pvfb not working with kexec/pvgrub
> > neither does the qdisk backend, which would be unfortunate.
> 
> Looking at the code in xen_backend.c, it seems that on XenbusStateClosed
> xen_backend is going to try to reset to XenbusStateInitialising, unless
> the frontend state is XenbusStateInitialising (no idea why).  See:
> xen_be_try_reset and xen_be_check_state.
> 
> Maybe it should go to XenbusStateInitWait instead?

Possibly?

Doesn't xen_be_check_state do that though, i.e. once you hit
XenbusStateInitialising you have:
        case XenbusStateInitialising:
            rc = xen_be_try_init(xendev);
which will push on to XenbusStateInitWait?

There's quite a few xen_be_printf surrounding these state transitions,
which ought to be printed at level >= 2. How can Steven control the
loglevel and where would they go (/var/log/xen/qemu-dm-$domname.log?)

Ian.


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

Re: vnc=1 / pvgrub / close fb: backend at /local/domain/0/backend/vfb/xx/0

[Stefano Stabellini]

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

On Wed, 22 Oct 2014, Ian Campbell wrote:
> On Wed, 2014-10-22 at 12:57 +0100, Stefano Stabellini wrote:
> > On Wed, 22 Oct 2014, Ian Campbell wrote:
> > > On Wed, 2014-10-22 at 11:59 +0200, Samuel Thibault wrote:
> > > > Ian Campbell, le Wed 22 Oct 2014 10:00:36 +0100, a écrit :
> > > > > On Wed, 2014-10-22 at 08:24 +1100, Steven Haigh wrote:
> > > > > > As a side note to this - if I use pygrub as a bootloader vs using
> > > > > > pvgrub, then VNC works perfectly.
> > > > > > 
> > > > > > So, what options exist to make pvgrub behave properly for booting with
> > > > > > VNC enabled?
> > > > > 
> > > > > ISTR (vaguely) that way back when the backends needed to be modified to
> > > > > cope with kexec (which is effectively what pvgrub does) by not exiting
> > > > > when the frontend disconnects, instead sticking around waiting for a new
> > > > > frontend, this relates somehow to the "online" key in xenstore.
> > > > > 
> > > > > Perhaps the pvfb backend never got that treatment, which would explain
> > > > > #2? 
> > > > 
> > > > Probably, yes.
> > > 
> > > Adding Stefano and Anthony, since the backend in this case is in qemu.
> > > 
> > > When the frontend disconnects and the online node == 1 then the backend
> > > is supposed to go from Closed back to InitWait and wait for a new
> > > connection, as opposed to shutting down. This is needed for kexec (which
> > > pvgrub uses).
> > > 
> > > I can see some handling of the online node in hw/xen/xen_backend.c but
> > > it doesn't look like it would do what is needed here. I also don't see
> > > any handling in either hw/block/xen_disk.c or hw/display/xenfb.c. Which
> > > makes me suspect that as well as pvfb not working with kexec/pvgrub
> > > neither does the qdisk backend, which would be unfortunate.
> > 
> > Looking at the code in xen_backend.c, it seems that on XenbusStateClosed
> > xen_backend is going to try to reset to XenbusStateInitialising, unless
> > the frontend state is XenbusStateInitialising (no idea why).  See:
> > xen_be_try_reset and xen_be_check_state.
> > 
> > Maybe it should go to XenbusStateInitWait instead?
> 
> Possibly?
> 
> Doesn't xen_be_check_state do that though, i.e. once you hit
> XenbusStateInitialising you have:
>         case XenbusStateInitialising:
>             rc = xen_be_try_init(xendev);
> which will push on to XenbusStateInitWait?
> 
> There's quite a few xen_be_printf surrounding these state transitions,
> which ought to be printed at level >= 2. How can Steven control the
> loglevel and where would they go (/var/log/xen/qemu-dm-$domname.log?)


I think that this should do:


diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index b2cb22b..d1d5d8e 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -50,7 +50,7 @@ const char *xen_protocol;
 
 /* private */
 static QTAILQ_HEAD(XenDeviceHead, XenDevice) xendevs = QTAILQ_HEAD_INITIALIZER(xendevs);
-static int debug = 0;
+static int debug = 9;
 
 /* ------------------------------------------------------------- */
 

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

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

Re: vnc=1 / pvgrub / close fb: backend at /local/domain/0/backend/vfb/xx/0

[Steven Haigh]

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

On 22/10/2014 11:13 PM, Stefano Stabellini wrote:
> On Wed, 22 Oct 2014, Ian Campbell wrote:
>> On Wed, 2014-10-22 at 12:57 +0100, Stefano Stabellini wrote:
>>> On Wed, 22 Oct 2014, Ian Campbell wrote:
>>>> On Wed, 2014-10-22 at 11:59 +0200, Samuel Thibault wrote:
>>>>> Ian Campbell, le Wed 22 Oct 2014 10:00:36 +0100, a écrit :
>>>>>> On Wed, 2014-10-22 at 08:24 +1100, Steven Haigh wrote:
>>>>>>> As a side note to this - if I use pygrub as a bootloader vs using
>>>>>>> pvgrub, then VNC works perfectly.
>>>>>>>
>>>>>>> So, what options exist to make pvgrub behave properly for booting with
>>>>>>> VNC enabled?
>>>>>>
>>>>>> ISTR (vaguely) that way back when the backends needed to be modified to
>>>>>> cope with kexec (which is effectively what pvgrub does) by not exiting
>>>>>> when the frontend disconnects, instead sticking around waiting for a new
>>>>>> frontend, this relates somehow to the "online" key in xenstore.
>>>>>>
>>>>>> Perhaps the pvfb backend never got that treatment, which would explain
>>>>>> #2? 
>>>>>
>>>>> Probably, yes.
>>>>
>>>> Adding Stefano and Anthony, since the backend in this case is in qemu.
>>>>
>>>> When the frontend disconnects and the online node == 1 then the backend
>>>> is supposed to go from Closed back to InitWait and wait for a new
>>>> connection, as opposed to shutting down. This is needed for kexec (which
>>>> pvgrub uses).
>>>>
>>>> I can see some handling of the online node in hw/xen/xen_backend.c but
>>>> it doesn't look like it would do what is needed here. I also don't see
>>>> any handling in either hw/block/xen_disk.c or hw/display/xenfb.c. Which
>>>> makes me suspect that as well as pvfb not working with kexec/pvgrub
>>>> neither does the qdisk backend, which would be unfortunate.
>>>
>>> Looking at the code in xen_backend.c, it seems that on XenbusStateClosed
>>> xen_backend is going to try to reset to XenbusStateInitialising, unless
>>> the frontend state is XenbusStateInitialising (no idea why).  See:
>>> xen_be_try_reset and xen_be_check_state.
>>>
>>> Maybe it should go to XenbusStateInitWait instead?
>>
>> Possibly?
>>
>> Doesn't xen_be_check_state do that though, i.e. once you hit
>> XenbusStateInitialising you have:
>>         case XenbusStateInitialising:
>>             rc = xen_be_try_init(xendev);
>> which will push on to XenbusStateInitWait?
>>
>> There's quite a few xen_be_printf surrounding these state transitions,
>> which ought to be printed at level >= 2. How can Steven control the
>> loglevel and where would they go (/var/log/xen/qemu-dm-$domname.log?)
> 
> 
> I think that this should do:
> 
> 
> diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
> index b2cb22b..d1d5d8e 100644
> --- a/hw/xen/xen_backend.c
> +++ b/hw/xen/xen_backend.c
> @@ -50,7 +50,7 @@ const char *xen_protocol;
>  
>  /* private */
>  static QTAILQ_HEAD(XenDeviceHead, XenDevice) xendevs = QTAILQ_HEAD_INITIALIZER(xendevs);
> -static int debug = 0;
> +static int debug = 9;
>  
>  /* ------------------------------------------------------------- */
>  
> 

I applied this patch and posted testing packages....

For completeness, this is the DomU config:
---------- DomU Config -----------
name            = "dev.vm"
memory          = 8192
vcpus           = 6
cpus            = "1-7"
disk            = [ 'phy:/dev/vg_hosting/dev.vm,xvda,w',
'file:/root/SL-65-x86_64-2013-12-05-boot.iso,xvdd:cdrom,r' ]
vif             = [ 'mac=20:34:01:36:00:42, vifname=vif.dev, bridge=br0' ]
kernel          = "/usr/lib/xen/boot/pv-grub-x86_64.gz"
extra           = "(hd0)/boot/grub/grub.conf"
#bootloader     = "pygrub"

vfb             = [ 'type=vnc, vnclisten=203.4.136.1, vncdisplay=2' ]

on_poweroff     = 'destroy'
on_reboot       = 'restart'
on_crash        = 'restart'
----------------------------------

Output using pv-grub:
Xen Minimal OS!
  start_info: 0x19ac000(VA)
    nr_pages: 0x200000
  shared_inf: 0xa5d0a000(MA)
     pt_base: 0x19af000(VA)
nr_pt_frames: 0x11
    mfn_list: 0x9ac000(VA)
   mod_start: 0x0(VA)
     mod_len: 0
       flags: 0x0
    cmd_line: (hd0)/boot/grub/grub.conf
  stack:      0x96b100-0x98b100
MM: Init
      _text: 0x0(VA)
     _etext: 0x7c814(VA)
   _erodata: 0x98000(VA)
     _edata: 0x9dd00(VA)
stack start: 0x96b100(VA)
       _end: 0x9ab700(VA)
  start_pfn: 19c3
    max_pfn: 200000
Mapping memory range 0x1c00000 - 0x200000000
setting 0x0-0x98000 readonly
skipped 0x1000
MM: Initialise page allocator for 29bc000(29bc000)-200000000(200000000)
MM: done
Demand map pfns at 200001000-2200001000.
Heap resides at 2200002000-4200002000.
Initialising timer interface
Initialising console ... done.
gnttab_table mapped at 0x200001000.
Initialising scheduler
Thread "Idle": pointer: 0x2200002050, stack: 0x3a10000
Thread "xenstore": pointer: 0x2200002800, stack: 0x3a20000
xenbus initialised on irq 1 mfn 0x3f46d1
Thread "shutdown": pointer: 0x2200002fb0, stack: 0x3a30000
Dummy main: start_info=0x98b200
Thread "main": pointer: 0x2200003760, stack: 0x3a40000
"main" "(hd0)/boot/grub/grub.conf"
vbd 51712 is hd0
******************* BLKFRONT for device/vbd/51712 **********


Shutting down ()
Shutdown requested: 3
Thread "shutdown" exited.
backend at /local/domain/0/backend/vbd/20/51712
125829120 sectors of 512 bytes
**************************
vbd 51760 is hd1
******************* BLKFRONT for device/vbd/51760 **********


backend at /local/domain/0/backend/qdisk/20/51760
Failed to read /local/domain/0/backend/qdisk/20/51760/feature-barrier.
436224 sectors of 512 bytes
**************************
Thread "kbdfront": pointer: 0x2200004580, stack: 0x3a30000
******************* FBFRONT for device/vfb/0 **********


******************* KBDFRONT for device/vkbd/0 **********


backend at /local/domain/0/backend/vkbd/20/0
backend at /local/domain/0/backend/vfb/20/0
/local/domain/0/backend/vkbd/20/0 connected
************************** KBDFRONT
Thread "kbdfront" exited.
/local/domain/0/backend/vfb/20/0 connected
************************** FBFRONT
((( Hit enter to boot a grub entry )))
Thread "kbdfront close": pointer: 0x2200004580, stack: 0x3a30000
close fb: backend at /local/domain/0/backend/vfb/21/0
close kbd: backend at /local/domain/0/backend/vkbd/21/0
  Booting 'Scientific Linux (3.14.21-1.el6xen.x86_64)'

root (hd0)
 Filesystem type is ext2fs, using whole disk
kernel /boot/vmlinuz-3.14.21-1.el6xen.x86_64 ro root=/dev/xvda
rd_NO_LUKS rd_NO
_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc
KEYTABLE=us cras
hkernel=auto console=hvc0
Thread "kbdfront close" exited.
initrd /boot/initramfs-3.14.21-1.el6xen.x86_64.img

============= Init TPM Front ================
Tpmfront:Error Unable to read device/vtpm/0/backend-id during tpmfront
initialization! error = ENOENT
Tpmfront:Info Shutting down tpmfront
close blk: backend=/local/domain/0/backend/vbd/21/51712
node=device/vbd/51712
close blk: backend=/local/domain/0/backend/qdisk/21/51760
node=device/vbd/51760

----------------------------------

This gives a VNC display on port 5092 - and the system waits at the grub
prompt (ie the timeout is never reached). I don't get a console from
this point on in either VNC or via 'xl console dev.vm'

On another note, I noticed this within the Dom0 kernel dmesg:
device vif.dev entered promiscuous mode
IPv6: ADDRCONF(NETDEV_UP): vif.dev: link is not ready
xen-blkback:ring-ref 2047, event-channel 4, protocol 1 (x86_64-abi)
qemu-system-i38[3956]: segfault at 0 ip           (null) sp
00007fffb4573638 error 4
xen-blkback:backend/vbd/21/51712: prepare for reconnect
br0: port 8(vif.dev) entered disabled state

I also noticed that if I pass console=tty0 on the grub command line in
"(hd0)/boot/grub/grub.conf" - then I get the expected console - however
the grub menu timeout still fails - almost as if a keypress has been
registered and cancelled the timeout...

For example, a 'sort of' working grub.conf for the DomU that hangs at
grub, but when manually selected, works as expected:
default=0
timeout=1
splashimage=(hd0)/boot/grub/splash.xpm.gz

title Scientific Linux (3.14.21-1.el6xen.x86_64)
        root (hd0)
        kernel /boot/vmlinuz-3.14.21-1.el6xen.x86_64 ro root=/dev/xvda
rd_NO_LUKS rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16
KEYBOARDTYPE=pc KEYTABLE=us crashkernel=auto console=tty0
        initrd /boot/initramfs-3.14.21-1.el6xen.x86_64.img

-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

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

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

Re: vnc=1 / pvgrub / close fb: backend at /local/domain/0/backend/vfb/xx/0

[Ian Campbell]

On Thu, 2014-10-23 at 02:23 +1100, Steven Haigh wrote:

> Output using pv-grub:

Can you also post the qemu logs please (under /var/log/xen somewhere I
think).

> qemu-system-i38[3956]: segfault at 0 ip           (null) sp
> 00007fffb4573638 error 4

That might be a smoking gun. Is there a core dump and/or could you try
and run qemu under gdb?

Ian.

Re: vnc=1 / pvgrub / close fb: backend at /local/domain/0/backend/vfb/xx/0

[Steven Haigh]

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

On 23/10/2014 2:40 AM, Ian Campbell wrote:
> On Thu, 2014-10-23 at 02:23 +1100, Steven Haigh wrote:
> 
>> Output using pv-grub:
> 
> Can you also post the qemu logs please (under /var/log/xen somewhere I
> think).

I get very little out of this:
-rw-r--r--  1 root root    0 Oct 23 02:45 qemu-dm-dev.vm.log
-rw-r--r--  1 root root    0 Oct 23 02:44 xen-hotplug.log
-rw-r--r--  1 root root   55 Oct 23 02:45 xl-dev.vm.log
[root@dom0 xen]# cat xl-dev.vm.log
Waiting for domain dev.vm (domid 36) to die [pid 6970]

That's it :\

>> qemu-system-i38[3956]: segfault at 0 ip           (null) sp
>> 00007fffb4573638 error 4
> 
> That might be a smoking gun. Is there a core dump and/or could you try
> and run qemu under gdb?

Any hints on doing this? I can't say I'm a gdb guru.... I can't find any
core dumps anywhere so that's not really helpful...

-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

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

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

Re: vnc=1 / pvgrub / close fb: backend at /local/domain/0/backend/vfb/xx/0

[Ian Campbell]

On Thu, 2014-10-23 at 02:53 +1100, Steven Haigh wrote:
> On 23/10/2014 2:40 AM, Ian Campbell wrote:
> > On Thu, 2014-10-23 at 02:23 +1100, Steven Haigh wrote:
> > 
> >> Output using pv-grub:
> > 
> > Can you also post the qemu logs please (under /var/log/xen somewhere I
> > think).
> 
> I get very little out of this:
> -rw-r--r--  1 root root    0 Oct 23 02:45 qemu-dm-dev.vm.log
> -rw-r--r--  1 root root    0 Oct 23 02:44 xen-hotplug.log
> -rw-r--r--  1 root root   55 Oct 23 02:45 xl-dev.vm.log
> [root@dom0 xen]# cat xl-dev.vm.log
> Waiting for domain dev.vm (domid 36) to die [pid 6970]
> 
> That's it :\

:-/ indeed.

> >> qemu-system-i38[3956]: segfault at 0 ip           (null) sp
> >> 00007fffb4573638 error 4
> > 
> > That might be a smoking gun. Is there a core dump and/or could you try
> > and run qemu under gdb?
> 
> Any hints on doing this? I can't say I'm a gdb guru.... I can't find any
> core dumps anywhere so that's not really helpful...

Fiddling with ulimit might cause core dumps to be created. If not then

https://lists.gnu.org/archive/html/qemu-devel/2014-04/msg00302.html
https://lists.gnu.org/archive/html/qemu-devel/2011-12/msg02575.html

have some hints on running qemu via gdbserver. I've also had luck by
configuring the guest with a device model which is a script that dumps
its args to a file ("echo $@ > /tmp/qemu.args") and then sleeps for an
hour, in another terminal you can then run (fairly quickly, before xl
times out) something like:
         # gdb /path/to/qemu
         (gdb) run [the content of that file]
or possibly even
        # gdb --args /path/to/qemu `cat /tmp/qemu.args
        (gdb) run
        
After it crashes the "bt" will get a back trace.

Ian.

Re: vnc=1 / pvgrub / close fb: backend at /local/domain/0/backend/vfb/xx/0

[Stefano Stabellini]

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

Hello Steven,
I have found some time to debug this myself.
I couldn't reproduce the booting issue that you reported: in my case
after seeing the grub boot menu I can successfully boot the kernel
without problems.

However I can reproduce the timeout issue that you are seeing: the
timeout doesn't work properly in graphics mode.

The reason is that the with a graphics terminal you checkkey () return 0
even when pressing no keys, resulting in wrong behaviour in run_menu. 

Does the following patch (also attached) fixes your issues?


diff --git a/stubdom/grub.patches/11graphics-keyboard.diff b/stubdom/grub.patches/11graphics-keyboard.diff
new file mode 100644
index 0000000..fe17b20
--- /dev/null
+++ b/stubdom/grub.patches/11graphics-keyboard.diff
@@ -0,0 +1,13 @@
+diff --git a/stage2/stage2.c b/stage2/stage2.c
+index 9d9fcc3..8353a3b 100644
+--- a/stage2/stage2.c
++++ b/stage2/stage2.c
+@@ -395,7 +395,7 @@ restart:
+ 	 pressed.  
+ 	 This avoids polling (relevant in the grub-shell and later on
+ 	 in grub if interrupt driven I/O is done).  */
+-      if (checkkey () >= 0 || grub_timeout < 0)
++      if (checkkey () > 0 || grub_timeout < 0)
+ 	{
+ 	  /* Key was pressed, show which entry is selected before GETKEY,
+ 	     since we're comming in here also on GRUB_TIMEOUT == -1 and



On Thu, 23 Oct 2014, Steven Haigh wrote:
> On 23/10/2014 2:40 AM, Ian Campbell wrote:
> > On Thu, 2014-10-23 at 02:23 +1100, Steven Haigh wrote:
> > 
> >> Output using pv-grub:
> > 
> > Can you also post the qemu logs please (under /var/log/xen somewhere I
> > think).
> 
> I get very little out of this:
> -rw-r--r--  1 root root    0 Oct 23 02:45 qemu-dm-dev.vm.log
> -rw-r--r--  1 root root    0 Oct 23 02:44 xen-hotplug.log
> -rw-r--r--  1 root root   55 Oct 23 02:45 xl-dev.vm.log
> [root@dom0 xen]# cat xl-dev.vm.log
> Waiting for domain dev.vm (domid 36) to die [pid 6970]
> 
> That's it :\
> 
> >> qemu-system-i38[3956]: segfault at 0 ip           (null) sp
> >> 00007fffb4573638 error 4
> > 
> > That might be a smoking gun. Is there a core dump and/or could you try
> > and run qemu under gdb?
> 
> Any hints on doing this? I can't say I'm a gdb guru.... I can't find any
> core dumps anywhere so that's not really helpful...
> 
> -- 
> Steven Haigh
> 
> Email: netwiz@crc.id.au
> Web: http://www.crc.id.au
> Phone: (03) 9001 6090 - 0412 935 897
> 
> 

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

diff --git a/stubdom/grub.patches/11graphics-keyboard.diff b/stubdom/grub.patches/11graphics-keyboard.diff
new file mode 100644
index 0000000..fe17b20
--- /dev/null
+++ b/stubdom/grub.patches/11graphics-keyboard.diff
@@ -0,0 +1,13 @@
+diff --git a/stage2/stage2.c b/stage2/stage2.c
+index 9d9fcc3..8353a3b 100644
+--- a/stage2/stage2.c
++++ b/stage2/stage2.c
+@@ -395,7 +395,7 @@ restart:
+ 	 pressed.  
+ 	 This avoids polling (relevant in the grub-shell and later on
+ 	 in grub if interrupt driven I/O is done).  */
+-      if (checkkey () >= 0 || grub_timeout < 0)
++      if (checkkey () > 0 || grub_timeout < 0)
+ 	{
+ 	  /* Key was pressed, show which entry is selected before GETKEY,
+ 	     since we're comming in here also on GRUB_TIMEOUT == -1 and

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

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

Re: vnc=1 / pvgrub / close fb: backend at /local/domain/0/backend/vfb/xx/0

[Steven Haigh]

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

Hi Stefano,

It seems that this patch fixes the grub issue for me. I no longer get
the infinite wait at the grub prompt.

On 6/11/2014 4:49 AM, Stefano Stabellini wrote:
> Hello Steven,
> I have found some time to debug this myself.
> I couldn't reproduce the booting issue that you reported: in my case
> after seeing the grub boot menu I can successfully boot the kernel
> without problems.
> 
> However I can reproduce the timeout issue that you are seeing: the
> timeout doesn't work properly in graphics mode.
> 
> The reason is that the with a graphics terminal you checkkey () return 0
> even when pressing no keys, resulting in wrong behaviour in run_menu. 
> 
> Does the following patch (also attached) fixes your issues?
> 
> 
> diff --git a/stubdom/grub.patches/11graphics-keyboard.diff b/stubdom/grub.patches/11graphics-keyboard.diff
> new file mode 100644
> index 0000000..fe17b20
> --- /dev/null
> +++ b/stubdom/grub.patches/11graphics-keyboard.diff
> @@ -0,0 +1,13 @@
> +diff --git a/stage2/stage2.c b/stage2/stage2.c
> +index 9d9fcc3..8353a3b 100644
> +--- a/stage2/stage2.c
> ++++ b/stage2/stage2.c
> +@@ -395,7 +395,7 @@ restart:
> + 	 pressed.  
> + 	 This avoids polling (relevant in the grub-shell and later on
> + 	 in grub if interrupt driven I/O is done).  */
> +-      if (checkkey () >= 0 || grub_timeout < 0)
> ++      if (checkkey () > 0 || grub_timeout < 0)
> + 	{
> + 	  /* Key was pressed, show which entry is selected before GETKEY,
> + 	     since we're comming in here also on GRUB_TIMEOUT == -1 and
> 
> 
> 
> On Thu, 23 Oct 2014, Steven Haigh wrote:
>> On 23/10/2014 2:40 AM, Ian Campbell wrote:
>>> On Thu, 2014-10-23 at 02:23 +1100, Steven Haigh wrote:
>>>
>>>> Output using pv-grub:
>>>
>>> Can you also post the qemu logs please (under /var/log/xen somewhere I
>>> think).
>>
>> I get very little out of this:
>> -rw-r--r--  1 root root    0 Oct 23 02:45 qemu-dm-dev.vm.log
>> -rw-r--r--  1 root root    0 Oct 23 02:44 xen-hotplug.log
>> -rw-r--r--  1 root root   55 Oct 23 02:45 xl-dev.vm.log
>> [root@dom0 xen]# cat xl-dev.vm.log
>> Waiting for domain dev.vm (domid 36) to die [pid 6970]
>>
>> That's it :\
>>
>>>> qemu-system-i38[3956]: segfault at 0 ip           (null) sp
>>>> 00007fffb4573638 error 4
>>>
>>> That might be a smoking gun. Is there a core dump and/or could you try
>>> and run qemu under gdb?
>>
>> Any hints on doing this? I can't say I'm a gdb guru.... I can't find any
>> core dumps anywhere so that's not really helpful...
>>
>> -- 
>> Steven Haigh
>>
>> Email: netwiz@crc.id.au
>> Web: http://www.crc.id.au
>> Phone: (03) 9001 6090 - 0412 935 897
>>

-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

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

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

Re: vnc=1 / pvgrub / close fb: backend at /local/domain/0/backend/vfb/xx/0

[Stefano Stabellini]

Hello Steven,
thanks for testing!

Regarding the other issue, which QEMU version are you using? Which Xen
version? On Xen 4.5.0-rc1 I don't see any problems.


On Thu, 6 Nov 2014, Steven Haigh wrote:
> Hi Stefano,
> 
> It seems that this patch fixes the grub issue for me. I no longer get
> the infinite wait at the grub prompt.
> 
> On 6/11/2014 4:49 AM, Stefano Stabellini wrote:
> > Hello Steven,
> > I have found some time to debug this myself.
> > I couldn't reproduce the booting issue that you reported: in my case
> > after seeing the grub boot menu I can successfully boot the kernel
> > without problems.
> > 
> > However I can reproduce the timeout issue that you are seeing: the
> > timeout doesn't work properly in graphics mode.
> > 
> > The reason is that the with a graphics terminal you checkkey () return 0
> > even when pressing no keys, resulting in wrong behaviour in run_menu. 
> > 
> > Does the following patch (also attached) fixes your issues?
> > 
> > 
> > diff --git a/stubdom/grub.patches/11graphics-keyboard.diff b/stubdom/grub.patches/11graphics-keyboard.diff
> > new file mode 100644
> > index 0000000..fe17b20
> > --- /dev/null
> > +++ b/stubdom/grub.patches/11graphics-keyboard.diff
> > @@ -0,0 +1,13 @@
> > +diff --git a/stage2/stage2.c b/stage2/stage2.c
> > +index 9d9fcc3..8353a3b 100644
> > +--- a/stage2/stage2.c
> > ++++ b/stage2/stage2.c
> > +@@ -395,7 +395,7 @@ restart:
> > + 	 pressed.  
> > + 	 This avoids polling (relevant in the grub-shell and later on
> > + 	 in grub if interrupt driven I/O is done).  */
> > +-      if (checkkey () >= 0 || grub_timeout < 0)
> > ++      if (checkkey () > 0 || grub_timeout < 0)
> > + 	{
> > + 	  /* Key was pressed, show which entry is selected before GETKEY,
> > + 	     since we're comming in here also on GRUB_TIMEOUT == -1 and
> > 
> > 
> > 
> > On Thu, 23 Oct 2014, Steven Haigh wrote:
> >> On 23/10/2014 2:40 AM, Ian Campbell wrote:
> >>> On Thu, 2014-10-23 at 02:23 +1100, Steven Haigh wrote:
> >>>
> >>>> Output using pv-grub:
> >>>
> >>> Can you also post the qemu logs please (under /var/log/xen somewhere I
> >>> think).
> >>
> >> I get very little out of this:
> >> -rw-r--r--  1 root root    0 Oct 23 02:45 qemu-dm-dev.vm.log
> >> -rw-r--r--  1 root root    0 Oct 23 02:44 xen-hotplug.log
> >> -rw-r--r--  1 root root   55 Oct 23 02:45 xl-dev.vm.log
> >> [root@dom0 xen]# cat xl-dev.vm.log
> >> Waiting for domain dev.vm (domid 36) to die [pid 6970]
> >>
> >> That's it :\
> >>
> >>>> qemu-system-i38[3956]: segfault at 0 ip           (null) sp
> >>>> 00007fffb4573638 error 4
> >>>
> >>> That might be a smoking gun. Is there a core dump and/or could you try
> >>> and run qemu under gdb?
> >>
> >> Any hints on doing this? I can't say I'm a gdb guru.... I can't find any
> >> core dumps anywhere so that's not really helpful...
> >>
> >> -- 
> >> Steven Haigh
> >>
> >> Email: netwiz@crc.id.au
> >> Web: http://www.crc.id.au
> >> Phone: (03) 9001 6090 - 0412 935 897
> >>
> 
> -- 
> Steven Haigh
> 
> Email: netwiz@crc.id.au
> Web: http://www.crc.id.au
> Phone: (03) 9001 6090 - 0412 935 897
> 
> 

Re: vnc=1 / pvgrub / close fb: backend at /local/domain/0/backend/vfb/xx/0

[Steven Haigh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I've been a bit busy at the moment and haven't had a chance to retest all of this and get some solid issues.

One thing I've come across is the different type of installs I've been playing with.. Some with a filesystem on xvda, some with a filesystem on xvda1.

As it seems you can only give one grub.conf entry in the extra domu config line, I have another issue to look at.

When I get some more free time I'll see I'd I can turn something up ...

On 6 November 2014 9:34:26 pm AEDT, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
>Hello Steven,
>thanks for testing!
>
>Regarding the other issue, which QEMU version are you using? Which Xen
>version? On Xen 4.5.0-rc1 I don't see any problems.
>
>
>On Thu, 6 Nov 2014, Steven Haigh wrote:
>> Hi Stefano,
>>
>> It seems that this patch fixes the grub issue for me. I no longer get
>> the infinite wait at the grub prompt.
>>
>> On 6/11/2014 4:49 AM, Stefano Stabellini wrote:
>> > Hello Steven,
>> > I have found some time to debug this myself.
>> > I couldn't reproduce the booting issue that you reported: in my
>case
>> > after seeing the grub boot menu I can successfully boot the kernel
>> > without problems.
>> >
>> > However I can reproduce the timeout issue that you are seeing: the
>> > timeout doesn't work properly in graphics mode.
>> >
>> > The reason is that the with a graphics terminal you checkkey ()
>return 0
>> > even when pressing no keys, resulting in wrong behaviour in
>run_menu.
>> >
>> > Does the following patch (also attached) fixes your issues?
>> >
>> >
>> > diff --git a/stubdom/grub.patches/11graphics-keyboard.diff
>b/stubdom/grub.patches/11graphics-keyboard.diff
>> > new file mode 100644
>> > index 0000000..fe17b20
>> > --- /dev/null
>> > +++ b/stubdom/grub.patches/11graphics-keyboard.diff
>> > @@ -0,0 +1,13 @@
>> > +diff --git a/stage2/stage2.c b/stage2/stage2.c
>> > +index 9d9fcc3..8353a3b 100644
>> > +--- a/stage2/stage2.c
>> > ++++ b/stage2/stage2.c
>> > +@@ -395,7 +395,7 @@ restart:
>> > + 	 pressed.
>> > + 	 This avoids polling (relevant in the grub-shell and later on
>> > + 	 in grub if interrupt driven I/O is done).  */
>> > +-      if (checkkey () >= 0 || grub_timeout < 0)
>> > ++      if (checkkey () > 0 || grub_timeout < 0)
>> > + 	{
>> > + 	  /* Key was pressed, show which entry is selected before
>GETKEY,
>> > + 	     since we're comming in here also on GRUB_TIMEOUT == -1 and
>> >
>> >
>> >
>> > On Thu, 23 Oct 2014, Steven Haigh wrote:
>> >> On 23/10/2014 2:40 AM, Ian Campbell wrote:
>> >>> On Thu, 2014-10-23 at 02:23 +1100, Steven Haigh wrote:
>> >>>
>> >>>> Output using pv-grub:
>> >>>
>> >>> Can you also post the qemu logs please (under /var/log/xen
>somewhere I
>> >>> think).
>> >>
>> >> I get very little out of this:
>> >> -rw-r--r--  1 root root    0 Oct 23 02:45 qemu-dm-dev.vm.log
>> >> -rw-r--r--  1 root root    0 Oct 23 02:44 xen-hotplug.log
>> >> -rw-r--r--  1 root root   55 Oct 23 02:45 xl-dev.vm.log
>> >> [root@dom0 xen]# cat xl-dev.vm.log
>> >> Waiting for domain dev.vm (domid 36) to die [pid 6970]
>> >>
>> >> That's it :\
>> >>
>> >>>> qemu-system-i38[3956]: segfault at 0 ip           (null) sp
>> >>>> 00007fffb4573638 error 4
>> >>>
>> >>> That might be a smoking gun. Is there a core dump and/or could
>you try
>> >>> and run qemu under gdb?
>> >>
>> >> Any hints on doing this? I can't say I'm a gdb guru.... I can't
>find any
>> >> core dumps anywhere so that's not really helpful...
>> >>
>> >> --
>> >> Steven Haigh
>> >>
>> >> Email: netwiz@crc.id.au
>> >> Web: http://www.crc.id.au
>> >> Phone: (03) 9001 6090 - 0412 935 897
>> >>
>>
>> --
>> Steven Haigh
>>
>> Email: netwiz@crc.id.au
>> Web: http://www.crc.id.au
>> Phone: (03) 9001 6090 - 0412 935 897
>>
>>

- --
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQI9BAEBCgAnBQJUW1XtIBxTdGV2ZW4gSGFpZ2ggPG5ldHdpekBjcmMuaWQuYXU+
AAoJEEGvNdV6fTHcIr4QAKvTrrgaa4zpXxlw3wfvm3bIdYuVbaW3qEeXWWuFwEC7
13cdLPEil04PhJPW/8q/S8T/2V6vEYvlrQMgPWbcTrCfZJ6KxNN5WQJzP/aJ0s9y
IWRizMx3fD+rgQGqE/HEqvSHX7ME2rhLHIHkpAw+q/KV97t76W6n8QOKFAtrwD1+
dcgcuCVdQmra2/RzC/fu028vyFJ63ZBoNyJzD/6MfyseskUL3EYfimiKOnZpXBz0
BeLa8Dyc7UgiTg3yoXJU7+m2V80r+4oBD2kbs+eMBWwY1a/fUzLe3xITxKprBp2c
lKyap/sUJJIs17fsr1VpmoCnyQCFUzDVdms9kU8RaivwVCpCqSdtPNLkiqXZmhqX
DKJ3P2xBDdwz/SH30/fIL+S7o43LfjVl2CbEdj6/t1HN/0iPRWt2BTr/HtoGt+t+
fWedzx0pfwl8C4dd9Ac3aGojnT9UwB4Na9pPVSsLgK5SuXT0pRYU4tpZ46oZNirt
bJBFcR9xrLWcH+a9k5HydruPXf6sCVmV/kwUB+mngECeiifEP2ILQN1psyls66+w
BKwrQlYKf4wJf3EfsV7soPa+GLL0rQLpLV8P+O5UHJ0W62VCzetpKonDVyuxA13o
jCFC+POP4c0dGo4sfGk5IDeh7s0z/PIpd/VjG/sgHt2AU2QWy2FOItxM+eYPq9SN
=2gPy
-----END PGP SIGNATURE-----

[PATCH] pvgrub: ignore NUL

[Stefano Stabellini]

When using pvgrub in graphical mode with vnc, the grub timeout doesn't
work: the countdown doesn't even start. With a serial terminal the
problem doesn't occur and the countdown works as expected.

It turns out that the problem is that when using a graphical terminal,
checkkey () returns 0 instead of -1 when there is no activity on the
mouse or keyboard. As a consequence grub thinks that the user typed
something and interrupts the count down.

To fix the issue simply ignore keystrokes returning 0, that is the NUL
character anyway. Add a patch to grub.patches to do that.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Steven Haigh <netwiz@crc.id.au>

diff --git a/stubdom/grub.patches/11graphics-keyboard.diff b/stubdom/grub.patches/11graphics-keyboard.diff
new file mode 100644
index 0000000..fe17b20
--- /dev/null
+++ b/stubdom/grub.patches/11graphics-keyboard.diff
@@ -0,0 +1,13 @@
+diff --git a/stage2/stage2.c b/stage2/stage2.c
+index 9d9fcc3..8353a3b 100644
+--- a/stage2/stage2.c
++++ b/stage2/stage2.c
+@@ -395,7 +395,7 @@ restart:
+ 	 pressed.  
+ 	 This avoids polling (relevant in the grub-shell and later on
+ 	 in grub if interrupt driven I/O is done).  */
+-      if (checkkey () >= 0 || grub_timeout < 0)
++      if (checkkey () > 0 || grub_timeout < 0)
+ 	{
+ 	  /* Key was pressed, show which entry is selected before GETKEY,
+ 	     since we're comming in here also on GRUB_TIMEOUT == -1 and

Re: [PATCH] pvgrub: ignore NUL

[Samuel Thibault]

Stefano Stabellini, le Thu 06 Nov 2014 10:41:28 +0000, a écrit :
> When using pvgrub in graphical mode with vnc, the grub timeout doesn't
> work: the countdown doesn't even start. With a serial terminal the
> problem doesn't occur and the countdown works as expected.
> 
> It turns out that the problem is that when using a graphical terminal,
> checkkey () returns 0 instead of -1 when there is no activity on the
> mouse or keyboard. As a consequence grub thinks that the user typed
> something and interrupts the count down.
> 
> To fix the issue simply ignore keystrokes returning 0, that is the NUL
> character anyway. Add a patch to grub.patches to do that.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Tested-by: Steven Haigh <netwiz@crc.id.au>

Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

> 
> diff --git a/stubdom/grub.patches/11graphics-keyboard.diff b/stubdom/grub.patches/11graphics-keyboard.diff
> new file mode 100644
> index 0000000..fe17b20
> --- /dev/null
> +++ b/stubdom/grub.patches/11graphics-keyboard.diff
> @@ -0,0 +1,13 @@
> +diff --git a/stage2/stage2.c b/stage2/stage2.c
> +index 9d9fcc3..8353a3b 100644
> +--- a/stage2/stage2.c
> ++++ b/stage2/stage2.c
> +@@ -395,7 +395,7 @@ restart:
> + 	 pressed.  
> + 	 This avoids polling (relevant in the grub-shell and later on
> + 	 in grub if interrupt driven I/O is done).  */
> +-      if (checkkey () >= 0 || grub_timeout < 0)
> ++      if (checkkey () > 0 || grub_timeout < 0)
> + 	{
> + 	  /* Key was pressed, show which entry is selected before GETKEY,
> + 	     since we're comming in here also on GRUB_TIMEOUT == -1 and
> 

-- 
Samuel
"And the next time you consider complaining that running Lucid Emacs
19.05 via NFS from a remote Linux machine in Paraguay doesn't seem to
get the background colors right, you'll know who to thank."
(By Matt Welsh)

Re: [PATCH] pvgrub: ignore NUL

[Stefano Stabellini]

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

On Thu, 6 Nov 2014, Samuel Thibault wrote:
> Stefano Stabellini, le Thu 06 Nov 2014 10:41:28 +0000, a écrit :
> > When using pvgrub in graphical mode with vnc, the grub timeout doesn't
> > work: the countdown doesn't even start. With a serial terminal the
> > problem doesn't occur and the countdown works as expected.
> > 
> > It turns out that the problem is that when using a graphical terminal,
> > checkkey () returns 0 instead of -1 when there is no activity on the
> > mouse or keyboard. As a consequence grub thinks that the user typed
> > something and interrupts the count down.
> > 
> > To fix the issue simply ignore keystrokes returning 0, that is the NUL
> > character anyway. Add a patch to grub.patches to do that.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Tested-by: Steven Haigh <netwiz@crc.id.au>
> 
> Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

This being a bug fix, I guess it doesn't actually need a release
exception to go in?


> > diff --git a/stubdom/grub.patches/11graphics-keyboard.diff b/stubdom/grub.patches/11graphics-keyboard.diff
> > new file mode 100644
> > index 0000000..fe17b20
> > --- /dev/null
> > +++ b/stubdom/grub.patches/11graphics-keyboard.diff
> > @@ -0,0 +1,13 @@
> > +diff --git a/stage2/stage2.c b/stage2/stage2.c
> > +index 9d9fcc3..8353a3b 100644
> > +--- a/stage2/stage2.c
> > ++++ b/stage2/stage2.c
> > +@@ -395,7 +395,7 @@ restart:
> > + 	 pressed.  
> > + 	 This avoids polling (relevant in the grub-shell and later on
> > + 	 in grub if interrupt driven I/O is done).  */
> > +-      if (checkkey () >= 0 || grub_timeout < 0)
> > ++      if (checkkey () > 0 || grub_timeout < 0)
> > + 	{
> > + 	  /* Key was pressed, show which entry is selected before GETKEY,
> > + 	     since we're comming in here also on GRUB_TIMEOUT == -1 and
> > 
> 
> -- 
> Samuel
> "And the next time you consider complaining that running Lucid Emacs
> 19.05 via NFS from a remote Linux machine in Paraguay doesn't seem to
> get the background colors right, you'll know who to thank."
> (By Matt Welsh)
> 

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

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

Re: [PATCH] pvgrub: ignore NUL

[Konrad Rzeszutek Wilk]

On Thu, Nov 06, 2014 at 03:43:42PM +0000, Stefano Stabellini wrote:
> On Thu, 6 Nov 2014, Samuel Thibault wrote:
> > Stefano Stabellini, le Thu 06 Nov 2014 10:41:28 +0000, a écrit :
> > > When using pvgrub in graphical mode with vnc, the grub timeout doesn't
> > > work: the countdown doesn't even start. With a serial terminal the
> > > problem doesn't occur and the countdown works as expected.
> > > 
> > > It turns out that the problem is that when using a graphical terminal,
> > > checkkey () returns 0 instead of -1 when there is no activity on the
> > > mouse or keyboard. As a consequence grub thinks that the user typed
> > > something and interrupts the count down.
> > > 
> > > To fix the issue simply ignore keystrokes returning 0, that is the NUL
> > > character anyway. Add a patch to grub.patches to do that.
> > > 
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > Tested-by: Steven Haigh <netwiz@crc.id.au>
> > 
> > Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
> 
> This being a bug fix, I guess it doesn't actually need a release
> exception to go in?

It should - but it depends on the on how risk averse the maintainer
of the particular subsystem is.

Regardless I believe this should go in. But more importantly - can
this also go upstream?
> 
> 
> > > diff --git a/stubdom/grub.patches/11graphics-keyboard.diff b/stubdom/grub.patches/11graphics-keyboard.diff
> > > new file mode 100644
> > > index 0000000..fe17b20
> > > --- /dev/null
> > > +++ b/stubdom/grub.patches/11graphics-keyboard.diff
> > > @@ -0,0 +1,13 @@
> > > +diff --git a/stage2/stage2.c b/stage2/stage2.c
> > > +index 9d9fcc3..8353a3b 100644
> > > +--- a/stage2/stage2.c
> > > ++++ b/stage2/stage2.c
> > > +@@ -395,7 +395,7 @@ restart:
> > > + 	 pressed.  
> > > + 	 This avoids polling (relevant in the grub-shell and later on
> > > + 	 in grub if interrupt driven I/O is done).  */
> > > +-      if (checkkey () >= 0 || grub_timeout < 0)
> > > ++      if (checkkey () > 0 || grub_timeout < 0)
> > > + 	{
> > > + 	  /* Key was pressed, show which entry is selected before GETKEY,
> > > + 	     since we're comming in here also on GRUB_TIMEOUT == -1 and
> > > 
> > 
> > -- 
> > Samuel
> > "And the next time you consider complaining that running Lucid Emacs
> > 19.05 via NFS from a remote Linux machine in Paraguay doesn't seem to
> > get the background colors right, you'll know who to thank."
> > (By Matt Welsh)
> > 

Re: [PATCH] pvgrub: ignore NUL

[Samuel Thibault]

Konrad Rzeszutek Wilk, le Thu 06 Nov 2014 14:36:11 -0500, a écrit :
> Regardless I believe this should go in. But more importantly - can
> this also go upstream?

There is no upstream for grub1 any more.

Samuel

Re: [PATCH] pvgrub: ignore NUL

[Ian Campbell]

On Thu, 2014-11-06 at 12:39 +0100, Samuel Thibault wrote:
> Stefano Stabellini, le Thu 06 Nov 2014 10:41:28 +0000, a écrit :
> > When using pvgrub in graphical mode with vnc, the grub timeout doesn't
> > work: the countdown doesn't even start. With a serial terminal the
> > problem doesn't occur and the countdown works as expected.
> > 
> > It turns out that the problem is that when using a graphical terminal,
> > checkkey () returns 0 instead of -1 when there is no activity on the
> > mouse or keyboard. As a consequence grub thinks that the user typed
> > something and interrupts the count down.
> > 
> > To fix the issue simply ignore keystrokes returning 0, that is the NUL
> > character anyway. Add a patch to grub.patches to do that.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Tested-by: Steven Haigh <netwiz@crc.id.au>
> 
> Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

I think the conclusion of the subthread was a release ack so applied,
thanks.



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

Re: [PATCH] pvgrub: ignore NUL

[Ian Campbell]

On Thu, 2014-11-06 at 12:39 +0100, Samuel Thibault wrote:
> Stefano Stabellini, le Thu 06 Nov 2014 10:41:28 +0000, a écrit :
> > When using pvgrub in graphical mode with vnc, the grub timeout doesn't
> > work: the countdown doesn't even start. With a serial terminal the
> > problem doesn't occur and the countdown works as expected.
> > 
> > It turns out that the problem is that when using a graphical terminal,
> > checkkey () returns 0 instead of -1 when there is no activity on the
> > mouse or keyboard. As a consequence grub thinks that the user typed
> > something and interrupts the count down.
> > 
> > To fix the issue simply ignore keystrokes returning 0, that is the NUL
> > character anyway. Add a patch to grub.patches to do that.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Tested-by: Steven Haigh <netwiz@crc.id.au>
> 
> Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>

I think the conclusion of the subthread was a release ack so applied,
thanks.




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