>Number: 175757
>Category: kern
>Synopsis: xen pvhvm looses keyboard input from VNC
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Fri Feb 01 10:40:00 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator: Roger Pau Monné
>Release: 9.1 and HEAD
>Organization:
Citrix
>Environment:
FreeBSD 9.1-RELEASE FreeBSD 9.1-RELEASE #0: Thu Jan 31 18:37:40 CET 2013
root@:/usr/obj/root/freebsd/freebsd/sys/XENHVM amd64
>Description:
I've tried a FreeBSD guest using the XENHVM kernel (release
9.1), and I've found that when using the XENHVM kernel the keyboard
input form the vnc client stops working (output to the vnc seems to be
ok thought), so I have to set up a serial port before switching to
XENHVM or there's no way to interact with the guest (apart from
ssh of course).
HEAD also seems to be experiencing the same issue. Is this
expected/know? I'm using Xen unstable and the device model is
Qemu-upstream.
>How-To-Repeat:
Install a FeeeBSD guest in Xen and switch to the XENHVM kernel, the keyboard on
the VNC stops sending keys to the guest.
>Fix:
The problem is that we set all devices in xenstore that we don't know how to
handle to state '6' (closed), which is not right. We should not mess with the
state of devices that we cannot handle. The following patch fixes the problem
by probing the devices first, and only try to attach the ones that we can
handle.
---
From: Roger Pau Monne <roger....@citrix.com>
Date: Thu, 31 Jan 2013 17:24:48 +0000
Subject: [PATCH] xenbus: fix device detection
Devices that cannot be handled should not be closed, instead leave
them as is. This prevents closing the vkbd device, which has the
effect of making Qemu stop sending keys to the guest.
Tested with qemu-xen-traditional, qemu-xen and qemu stubdomains, all
working as expected.
---
sys/xen/xenbus/xenbusb.c | 19 ++++++++++++++++++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/sys/xen/xenbus/xenbusb.c b/sys/xen/xenbus/xenbusb.c
index 3e2d56f..8370195 100644
--- a/sys/xen/xenbus/xenbusb.c
+++ b/sys/xen/xenbus/xenbusb.c
@@ -418,6 +418,9 @@ xenbusb_probe_children(device_t dev)
device_t *kids;
struct xenbus_device_ivars *ivars;
int i, count;
+ struct xenbusb_softc *xbs;
+
+ xbs = device_get_softc(dev);
if (device_get_children(dev, &kids, &count) == 0) {
for (i = 0; i < count; i++) {
@@ -430,7 +433,21 @@ xenbusb_probe_children(device_t dev)
continue;
}
- if (device_probe_and_attach(kids[i])) {
+ if (device_probe(kids[i])) {
+ /*
+ * Don't mess the state of devices the kernel
+ * cannot handle.
+ */
+ xenbusb_delete_child(dev, kids[i]);
+
+ mtx_lock(&xbs->xbs_lock);
+ xbs->xbs_connecting_children--;
+ mtx_unlock(&xbs->xbs_lock);
+
+ continue;
+ }
+
+ if (device_attach(kids[i])) {
/*
* Transition device to the closed state
* so the world knows that attachment will
>Release-Note:
>Audit-Trail:
>Unformatted:
_______________________________________________
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
