kern/175757: xen pvhvm looses keyboard input from VNC
>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
Date: Thu, 31 Jan 2013 17:24:48 +
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"
kern/175759: Correct data types for fields of struct qm_trace{} from
>Number: 175759
>Category: kern
>Synopsis: Correct data types for fields of struct qm_trace{} from
>
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: change-request
>Submitter-Id: current-users
>Arrival-Date: Fri Feb 01 11:50:00 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator: Andrey Simonenko
>Release:FreeBSD 9.1-STABLE amd64
>Organization:
>Environment:
>Description:
If QUEUE_MACRO_DEBUG is defined and WARNS >= 4, then a program that
uses some macro definitions from cannot be built because
of "warning: assignment discards qualifiers from pointer target type"
warnings.
1. File name fields should have "const char *" type.
2. Line number fields should have "long" or "unsigned long" type,
considering C99 standard and its values for [U]INT_MAX, __LINE__
and #line.
>How-To-Repeat:
>Fix:
--- queue.h.orig2012-12-11 21:00:44.0 +0200
+++ queue.h 2013-01-31 13:37:13.0 +0200
@@ -105,10 +105,10 @@
#ifdef QUEUE_MACRO_DEBUG
/* Store the last 2 places the queue element or head was altered */
struct qm_trace {
- char * lastfile;
- int lastline;
- char * prevfile;
- int prevline;
+ const char *lastfile;
+ unsigned long lastline;
+ const char *prevfile;
+ unsigned long prevline;
};
#defineTRACEBUFstruct qm_trace trace;
>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"
Re: kern/175759: Correct data types for fields of struct qm_trace{} from
The following reply was made to PR kern/175759; it has been noted by GNATS.
From: Gleb Smirnoff
To: Andrey Simonenko
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: kern/175759: Correct data types for fields of struct qm_trace{}
from
Date: Fri, 1 Feb 2013 17:04:27 +0400
On Fri, Feb 01, 2013 at 01:43:46PM +0200, Andrey Simonenko wrote:
A> If QUEUE_MACRO_DEBUG is defined and WARNS >= 4, then a program that
A> uses some macro definitions from cannot be built because
A> of "warning: assignment discards qualifiers from pointer target type"
A> warnings.
Can you please provide a sample file? I can reproduce this with simple
declaration of TAILQ_HEAD for example, neither with gcc nor clang.
A> 1. File name fields should have "const char *" type.
Paragraph 6.10.8 of standard says that __FILE__ is "a character string
literal". It doesn't say that it can be referenced only by a pointer
with const qualifier.
However, the proposed change definitely makes sence.
A> 2. Line number fields should have "long" or "unsigned long" type,
A>considering C99 standard and its values for [U]INT_MAX, __LINE__
A>and #line.
Paragraph 6.10.8 of standard says that __LINE__ is "an integer constant".
Paragraph 6.4.4.1 on integer constants says that "The type of an integer
constant is the first of the corresponding list in which its value can
be represented." The corresponding list starts with "int". According to
paragraph 6.10.4 line number can't get bigger that 2147483647 (INT_MAX),
and this value can be represented by int.
Thus, I don't see where standard says that line number should be long.
Correct me please, if I am wrong.
--
Totus tuus, Glebius.
___
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"
Re: kern/175759: Correct data types for fields of struct qm_trace{} from
The following reply was made to PR kern/175759; it has been noted by GNATS.
From: Andrey Simonenko
To: Gleb Smirnoff
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: kern/175759: Correct data types for fields of struct qm_trace{}
from
Date: Fri, 1 Feb 2013 15:49:07 +0200
On Fri, Feb 01, 2013 at 05:04:27PM +0400, Gleb Smirnoff wrote:
> On Fri, Feb 01, 2013 at 01:43:46PM +0200, Andrey Simonenko wrote:
> A> If QUEUE_MACRO_DEBUG is defined and WARNS >= 4, then a program that
> A> uses some macro definitions from cannot be built because
> A> of "warning: assignment discards qualifiers from pointer target type"
> A> warnings.
>
> Can you please provide a sample file? I can reproduce this with simple
> declaration of TAILQ_HEAD for example, neither with gcc nor clang.
Tested on 9.1-STABLE with gcc (from the base system) and clang (from ports).
queue.c:
-
#include
#include
struct foo {
int x;
};
TAILQ_HEAD(foo_tailq, foo);
int
main(void)
{
struct foo_tailq foo_tailq;
TAILQ_INIT(&foo_tailq);
return (0);
}
-
Makefile:
-
PROG=queue
DEBUG_FLAGS=-DQUEUE_MACRO_DEBUG
WARNS=4
NO_MAN=
.include
-
>
> A> 1. File name fields should have "const char *" type.
>
> Paragraph 6.10.8 of standard says that __FILE__ is "a character string
> literal". It doesn't say that it can be referenced only by a pointer
> with const qualifier.
>
> However, the proposed change definitely makes sence.
Yes, but values these pointers are pointed to are not expected
to be modified and pointing (char *) to __FILE__ will generate above
given warning message.
>
> A> 2. Line number fields should have "long" or "unsigned long" type,
> A>considering C99 standard and its values for [U]INT_MAX, __LINE__
> A>and #line.
>
> Paragraph 6.10.8 of standard says that __LINE__ is "an integer constant".
>
> Paragraph 6.4.4.1 on integer constants says that "The type of an integer
> constant is the first of the corresponding list in which its value can
> be represented." The corresponding list starts with "int". According to
> paragraph 6.10.4 line number can't get bigger that 2147483647 (INT_MAX),
> and this value can be represented by int.
>
> Thus, I don't see where standard says that line number should be long.
5.2.4.2.1 says "Their implementation-defined values shall be equal or
greater in magnitude (absolute value) to those shown, with the same sign."
-- maximum value for an object of type int
INT_MAX +32767 // 2^15-1
-- maximum value for an object of type unsigned int
UINT_MAX 65535 // 2^16-1
-- maximum value for an object of type long int
LONG_MAX +2147483647 // 2^31-1
-- maximum value for an object of type unsigned long int
ULONG_MAX 4294967295 // 2^32-1
According to this information the closest integer data type to the maximum
value of a line number given in #line is "long" or "unsigned long".
Even if we assume that INT_MAX is bigger that 2^31-1 then specifying
"unsigned long" in that structure (without changing the order of its fields)
will not change its size on i386 and amd64.
Also I think there is sense to give initial values for TRACEBUF in
TAILQ_HEAD_INITIALIZER, since gcc and clang generate warnings for WARNS>=3.
___
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"
Re: kern/175759: Correct data types for fields of struct qm_trace{} from
The following reply was made to PR kern/175759; it has been noted by GNATS.
From: Andrey Simonenko
To: Gleb Smirnoff
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: kern/175759: Correct data types for fields of struct qm_trace{}
from
Date: Fri, 1 Feb 2013 16:03:15 +0200
On Fri, Feb 01, 2013 at 03:49:07PM +0200, Andrey Simonenko wrote:
>
> Even if we assume that INT_MAX is bigger that 2^31-1 then specifying
> "unsigned long" in that structure (without changing the order of its fields)
> will not change its size on i386 and amd64.
Typos correction:
Even if we assume that INT_MAX is equal to 2^31-1 then specifying
"unsigned long" in that structure (without changing the order of its fields)
will not change its size on i386 and amd64.
___
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"
Re: misc/175645: tcpdump incorrectly decodes pflog'ged UDP packet as ATALK
The following reply was made to PR bin/175645; it has been noted by GNATS. From: Dmitry Dvoinikov To: Gleb Smirnoff Cc: freebsd-gnats-sub...@freebsd.org Subject: Re: misc/175645: tcpdump incorrectly decodes pflog'ged UDP packet as ATALK Date: Sat, 2 Feb 2013 13:01:46 +0600 > Was this packet recorded on FreeBSD or on OpenBSD system? > > -- > Totus tuus, Glebius. It's all on the same machine, FreeBSD 8.3 as per uname. ___ 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"
