On Thu, 2010-10-21 at 17:44 +0100, Anthony Liguori wrote:
> On 10/21/2010 11:18 AM, Gianni Tedesco wrote:
> > This prevents qemu from hanging waiting for a client to connect. I have
> > reproduced this when doing a loadvm but it may be a more general problem
> > in that poll
-off-by: Gianni Tedesco
diff --git a/ui/vnc.c b/ui/vnc.c
index 864342e..172b988 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -2736,5 +2736,6 @@ int vnc_display_open(DisplayState *ds, const char
*display)
vs->display = dpy;
}
}
+socket_set_nonblock(vs->lsock);
The BIOS boot protocol allows to continue from next device if an earlier
boot method doesn't work. In the real hardware the ROM typically only
supports one type of card. Therefore a ROM ought to be loaded and tried
from each NIC until one of the attempts successfully boots or there are
no more to try.
Anyway, you will need to post more info on your setup: what and how many
NIC's, where the ROM binaries came from...
Gianni Tedesco
On Fri, 2010-06-25 at 18:23 +0100, TJ wrote:
> On 06/25/10 12:32, Gianni Tedesco wrote:
> > A device MAY provide extended descriptors in 2 ways mentioned in the
> > spec, but ISTR finding at least one device in the wild with standard
> > descriptors extended which were no
On Thu, 2010-06-24 at 05:45 +0100, TJ wrote:
> Here is small patch that fixed my problem.
>
> In looking at the USB spec, it seems pretty clear cut about the whole
> device/config/interface/endpoint descriptor hierarchy, so the
> usb_host_claim_interfaces can be optimized instead of parsing throug
