Re: [Qemu-devel] [PATCH] usb: selective endpoint initialization
On August 9, 2012 at 10:59 AM Gerd Hoffmann wrote: > > Hi Gerd, > > > > sorry for the delays, I tested the latest pulled patch queue and it's > > now fine on my Intel board, too. The dongle gets detected again without > > assertions. Thanks for your work. > > > > Still remaining are the multiple usb resets on host side before the > > dongle gets finally detected / usable on the guest. > > Can you try if the attached patch makes a difference? > > thanks, > Gerd Hi Gerd, sorry, no difference. Still the same behavior. Best regards, Erik
Re: [Qemu-devel] [PATCH] usb: selective endpoint initialization
On August 9, 2012 at 10:59 AM Gerd Hoffmann wrote: > > Hi Gerd, > > > > sorry for the delays, I tested the latest pulled patch queue and it's > > now fine on my Intel board, too. The dongle gets detected again without > > assertions. Thanks for your work. > > > > Still remaining are the multiple usb resets on host side before the > > dongle gets finally detected / usable on the guest. > > Can you try if the attached patch makes a difference? > > thanks, > Gerd Hi Gerd, it still has a lot of USB host resets with the latest QEMU master. Any ideas how to proceed? Best regards, Erik
[Qemu-devel] git bisect results (was: Re: bad USB tablet update rate on qemu-1.0)
Hi all, I assume that I found a possible source of the bad usbtablet update rate. I did some git bisectioning but I didn't get a usable result due to too many merges (or maybe my little knowledge to git), so I proceeded with some manual bisectioning by manually selecting commits and tested them. The problem was that the usbtablet update-rate in qemu-kvm-1.0 was really bad compared to qemu-kvm-0.15.0. The first commit where the cursor worked but the update rate was bad is 7cb78eec5cdf6e4131613c64cc1a29476f327242 Before this commit the usbtablet didn't work (no grabbing was possible). But in 0.15.0 it worked. So I continued searching for interesting points between these versions. One point was the SDL commit done 2011-08-05 by Jan Kiszka. There I found changes that affected the -full-screen option. So I took the version from the commit above and just started with the -full-screen option. And everything was fine (qemu-kvm-1.0 as well)! The update rate is very good with this option. But I was not able to find the real change that caused the bad update rate. Jan - is it possible to track down with this information the cause of the bad update rate? It seems to be related to SDL - the VNC option is working fine without -full-screen. I would like to work without the -full-screen option. Thanks. Best regards, Erik
Re: [Qemu-devel] git bisect results
Jan Kiszka wrote: On 2012-01-24 18:24, Erik Rull wrote: Hi all, I assume that I found a possible source of the bad usbtablet update rate. I did some git bisectioning but I didn't get a usable result due to too many merges (or maybe my little knowledge to git), so I proceeded with some manual bisectioning by manually selecting commits and tested them. The problem was that the usbtablet update-rate in qemu-kvm-1.0 was really bad compared to qemu-kvm-0.15.0. Did you bisect qemu or qemu-kvm? qemu-kvm. The first commit where the cursor worked but the update rate was bad is 7cb78eec5cdf6e4131613c64cc1a29476f327242 Before this commit the usbtablet didn't work (no grabbing was possible). That's a merge. Can you dig into the merged patches to find the one that resolved the grabbing issue? Might be 21635e121a. Then that can be backported while bisecting the tree for the other issue. How can I do that (digging into the merge)? I'm not too familiar with git, I see only the whole merge as one commit. Or do you mean digging manually in the single diffs that are in the patch and try each of them? How does the backport work? If I change something during bisecting, git complains that it cannot proceed due to changed files. But in 0.15.0 it worked. So I continued searching for interesting points between these versions. One point was the SDL commit done 2011-08-05 by Jan Kiszka. There I found changes that affected the -full-screen option. So I took the version from the commit above and just started with the -full-screen option. And everything was fine (qemu-kvm-1.0 as well)! The update rate is very good with this option. If you go full-screen there is constant grabbing. But I do not see the correlation with the update rate when in windowed mode. But I was not able to find the real change that caused the bad update rate. Jan - is it possible to track down with this information the cause of the bad update rate? It seems to be related to SDL - the VNC option is working fine without -full-screen. I would like to work without the -full-screen option. I still cannot follow, specifically as I have XP with tablet running here. Haven't noticed any problems so far, just rechecked against qemu-kvm head. Jan Which CPU do you have on your host? I have a Core2Duo T6800 and the guest running on one core. There the update rate is significant worse than on another system with a Core i7 (guest on a single core as well), on the faster system it is still visible. Maybe its related to the onboard graphics? I don't know, I just see the significant differences between fullscreen and windowed mode. Thanks for your help. Best regards, Erik
[Qemu-devel] commit 67feec6ed854b3618b37ccf050b90192cbb96e0f breaks compilation of hw/pci.c
Hi all,
from the qemu-kvm master I did some bisectioning because I cannot compile it.
My error is:
In file included from /home/erik/qemu-kvm/hw/pci.c:36:
/qmp-commands.h:3: error: expected identifier or '(' before '{' token
/qmp-commands.h:10: error: expected identifier or '(' before ',' token
/qmp-commands.h:20: error: expected identifier or '(' before ',' token
/qmp-commands.h:30: error: expected identifier or '(' before ',' token
/qmp-commands.h:40: error: expected identifier or '(' before ',' token
/qmp-commands.h:50: error: expected identifier or '(' before ',' token
/qmp-commands.h:60: error: expected identifier or '(' before ',' token
/qmp-commands.h:70: error: expected identifier or '(' before ',' token
/qmp-commands.h:80: error: expected identifier or '(' before ',' token
/qmp-commands.h:90: error: expected identifier or '(' before ',' token
/qmp-commands.h:100: error: expected identifier or '(' before ',' token
/qmp-commands.h:110: error: expected identifier or '(' before ',' token
/qmp-commands.h:120: error: expected identifier or '(' before ',' token
/qmp-commands.h:130: error: expected identifier or '(' before ',' token
/qmp-commands.h:140: error: expected identifier or '(' before ',' token
/qmp-commands.h:154: error: expected identifier or '(' before ',' token
/qmp-commands.h:164: error: expected identifier or '(' before ',' token
/qmp-commands.h:174: error: expected identifier or '(' before ',' token
/qmp-commands.h:184: error: expected identifier or '(' before ',' token
/qmp-commands.h:194: error: expected identifier or '(' before ',' token
/qmp-commands.h:204: error: expected identifier or '(' before ',' token
/qmp-commands.h:214: error: expected identifier or '(' before ',' token
/qmp-commands.h:224: error: expected identifier or '(' before ',' token
/qmp-commands.h:233: error: expected identifier or '(' before ',' token
/qmp-commands.h:244: error: expected identifier or '(' before ',' token
/qmp-commands.h:254: error: expected identifier or '(' before ',' token
/qmp-commands.h:264: error: expected identifier or '(' before ',' token
/qmp-commands.h:274: error: expected identifier or '(' before ',' token
/qmp-commands.h:284: error: expected identifier or '(' before ',' token
/qmp-commands.h:294: error: expected identifier or '(' before ',' token
/qmp-commands.h:304: error: expected identifier or '(' before ',' token
/qmp-commands.h:314: error: expected identifier or '(' before ',' token
/qmp-commands.h:323: error: expected identifier or '(' before ',' token
/qmp-commands.h:333: error: expected identifier or '(' before ',' token
/home/erik/qemu-kvm/hw/pci.c:1432: warning: no previous prototype for
'qmp_query_pci'
Here the results of the bisectioning (master against qemu-kvm-1.0)
git bisect start
# bad: [07e1e20b47d3e7841dc63a843502600d0a16542f] qemu-kvm: Resolve
unneeded diffs to upstream in pc-bios
git bisect bad 07e1e20b47d3e7841dc63a843502600d0a16542f
# good: [30c044521889195f54a9f2c21310894f545994e8] Merge commit 'v1.0' into
next
git bisect good 30c044521889195f54a9f2c21310894f545994e8
# good: [b9b2008bbff49e2714491a95109e1189e54a6491] block: dma_bdrv_* does
not return NULL
git bisect good b9b2008bbff49e2714491a95109e1189e54a6491
# good: [05c194384f836240ea4c2da5fa3be43a54bff021] pseries: Emit device
tree nodes in reg order
git bisect good 05c194384f836240ea4c2da5fa3be43a54bff021
# bad: [372951014b5008ca047e4dfbfaf4003bc27a2f6b] qemu-kvm: Fix
save/restore of in-kernel i8259
git bisect bad 372951014b5008ca047e4dfbfaf4003bc27a2f6b
# bad: [682a3c07f0e28d2532c911a44a9b6142d6299cc2] Merge commit
'c5705a7728b4a6bc9e4f2d35911adbaf28042b25' into upstream-merge
git bisect bad 682a3c07f0e28d2532c911a44a9b6142d6299cc2
# good: [2817b260e3ca57ee091fc56403bfafdcc18b6a96] vhost: avoid
cpu_get_physical_page_desc()
git bisect good 2817b260e3ca57ee091fc56403bfafdcc18b6a96
# bad: [ce00ce6a909bc9b1ecc697d826d71b2c7ab07994] Merge commit
'48a18b3c698295e4d891f34e919615e84e20f027' into upstream-merge
git bisect bad ce00ce6a909bc9b1ecc697d826d71b2c7ab07994
# bad: [90695ad2ede04a7ce6a86e8283e82f8bdbe8a54a] Merge commit
'217bfb445b54db618a30f3a39170bebd9fd9dbf2' into upstream-merge
git bisect bad 90695ad2ede04a7ce6a86e8283e82f8bdbe8a54a
# bad: [e021b07bd795c76035c48c158943dd8ee47e9c27] qemu-kvm: Move
make-release to scripts/qemu-kvm
git bisect bad e021b07bd795c76035c48c158943dd8ee47e9c27
# bad: [67feec6ed854b3618b37ccf050b90192cbb96e0f] qemu-kvm: fix improper
nmi emulation
git bisect bad 67feec6ed854b3618b37ccf050b90192cbb96e0f
final git bisect result:
67feec6ed854b3618b37ccf050b90192cbb96e0f is the first bad commit
commit 67feec6ed854b3618b37ccf050b90192cbb96e0f
Author: Lai Jiangshan
Date: Tue Oct 18 00:00:06 2011 +0800
qemu-kvm: fix improper nmi emulation
Currently, NMI interrupt is blindly sent to all the vCPUs when NMI
button event happens. This doesn't properly emulate real hardware on
which NMI button event triggers LINT1. Because of this, NMI is sent to
the processor even
Re: [Qemu-devel] git bisect results
Hi Jan,
This little change fixes my problem with the usb-tablet update rate.
Can you please verify if this has some side effects?
If not, can you post a real patch?
I don't know how to handle the whole patching and committing stuff exactly.
Thanks.
Erik
--
diff --git a/ui/sdl.c b/ui/sdl.c
index 8cafc44..ecd70db 100644
--- a/ui/sdl.c
+++ b/ui/sdl.c
@@ -769,7 +769,7 @@ static void handle_mousemotion(DisplayState *ds,
SDL_Event *ev)
{
int max_x, max_y;
-if (is_graphic_console() &&
+/*if (is_graphic_console() &&
(kbd_mouse_is_absolute() || absolute_enabled)) {
max_x = real_screen->w - 1;
max_y = real_screen->h - 1;
@@ -782,7 +782,7 @@ static void handle_mousemotion(DisplayState *ds,
SDL_Event *ev)
ev->motion.y > 0 && ev->motion.y < max_y)) {
sdl_grab_start();
}
-}
+}*/
if (gui_grab || kbd_mouse_is_absolute() || absolute_enabled) {
sdl_send_mouse_event(ev->motion.xrel, ev->motion.yrel, 0,
ev->motion.x, ev->motion.y, ev->motion.state);
Re: [Qemu-devel] commit 67feec6ed854b3618b37ccf050b90192cbb96e0f breaks compilation of hw/pci.c
Gleb Natapov wrote:
On Wed, Jan 25, 2012 at 12:22:51PM +0100, erik.r...@rdsoftware.de wrote:
Hi all,
from the qemu-kvm master I did some bisectioning because I cannot compile it.
I got the same error because of some stale .h file. Removing it resolved
the problem, but I do not remember what was the file exactly. Try "git
status"
My error is:
In file included from /home/erik/qemu-kvm/hw/pci.c:36:
/qmp-commands.h:3: error: expected identifier or '(' before '{' token
/qmp-commands.h:10: error: expected identifier or '(' before ',' token
/qmp-commands.h:20: error: expected identifier or '(' before ',' token
/qmp-commands.h:30: error: expected identifier or '(' before ',' token
/qmp-commands.h:40: error: expected identifier or '(' before ',' token
/qmp-commands.h:50: error: expected identifier or '(' before ',' token
/qmp-commands.h:60: error: expected identifier or '(' before ',' token
/qmp-commands.h:70: error: expected identifier or '(' before ',' token
/qmp-commands.h:80: error: expected identifier or '(' before ',' token
/qmp-commands.h:90: error: expected identifier or '(' before ',' token
/qmp-commands.h:100: error: expected identifier or '(' before ',' token
/qmp-commands.h:110: error: expected identifier or '(' before ',' token
/qmp-commands.h:120: error: expected identifier or '(' before ',' token
/qmp-commands.h:130: error: expected identifier or '(' before ',' token
/qmp-commands.h:140: error: expected identifier or '(' before ',' token
/qmp-commands.h:154: error: expected identifier or '(' before ',' token
/qmp-commands.h:164: error: expected identifier or '(' before ',' token
/qmp-commands.h:174: error: expected identifier or '(' before ',' token
/qmp-commands.h:184: error: expected identifier or '(' before ',' token
/qmp-commands.h:194: error: expected identifier or '(' before ',' token
/qmp-commands.h:204: error: expected identifier or '(' before ',' token
/qmp-commands.h:214: error: expected identifier or '(' before ',' token
/qmp-commands.h:224: error: expected identifier or '(' before ',' token
/qmp-commands.h:233: error: expected identifier or '(' before ',' token
/qmp-commands.h:244: error: expected identifier or '(' before ',' token
/qmp-commands.h:254: error: expected identifier or '(' before ',' token
/qmp-commands.h:264: error: expected identifier or '(' before ',' token
/qmp-commands.h:274: error: expected identifier or '(' before ',' token
/qmp-commands.h:284: error: expected identifier or '(' before ',' token
/qmp-commands.h:294: error: expected identifier or '(' before ',' token
/qmp-commands.h:304: error: expected identifier or '(' before ',' token
/qmp-commands.h:314: error: expected identifier or '(' before ',' token
/qmp-commands.h:323: error: expected identifier or '(' before ',' token
/qmp-commands.h:333: error: expected identifier or '(' before ',' token
/home/erik/qemu-kvm/hw/pci.c:1432: warning: no previous prototype for
'qmp_query_pci'
Here the results of the bisectioning (master against qemu-kvm-1.0)
git bisect start
# bad: [07e1e20b47d3e7841dc63a843502600d0a16542f] qemu-kvm: Resolve
unneeded diffs to upstream in pc-bios
git bisect bad 07e1e20b47d3e7841dc63a843502600d0a16542f
# good: [30c044521889195f54a9f2c21310894f545994e8] Merge commit 'v1.0' into
next
git bisect good 30c044521889195f54a9f2c21310894f545994e8
# good: [b9b2008bbff49e2714491a95109e1189e54a6491] block: dma_bdrv_* does
not return NULL
git bisect good b9b2008bbff49e2714491a95109e1189e54a6491
# good: [05c194384f836240ea4c2da5fa3be43a54bff021] pseries: Emit device
tree nodes in reg order
git bisect good 05c194384f836240ea4c2da5fa3be43a54bff021
# bad: [372951014b5008ca047e4dfbfaf4003bc27a2f6b] qemu-kvm: Fix
save/restore of in-kernel i8259
git bisect bad 372951014b5008ca047e4dfbfaf4003bc27a2f6b
# bad: [682a3c07f0e28d2532c911a44a9b6142d6299cc2] Merge commit
'c5705a7728b4a6bc9e4f2d35911adbaf28042b25' into upstream-merge
git bisect bad 682a3c07f0e28d2532c911a44a9b6142d6299cc2
# good: [2817b260e3ca57ee091fc56403bfafdcc18b6a96] vhost: avoid
cpu_get_physical_page_desc()
git bisect good 2817b260e3ca57ee091fc56403bfafdcc18b6a96
# bad: [ce00ce6a909bc9b1ecc697d826d71b2c7ab07994] Merge commit
'48a18b3c698295e4d891f34e919615e84e20f027' into upstream-merge
git bisect bad ce00ce6a909bc9b1ecc697d826d71b2c7ab07994
# bad: [90695ad2ede04a7ce6a86e8283e82f8bdbe8a54a] Merge commit
'217bfb445b54db618a30f3a39170bebd9fd9dbf2' into upstream-merge
git bisect bad 90695ad2ede04a7ce6a86e8283e82f8bdbe8a54a
# bad: [e021b07bd795c76035c48c158943dd8ee47e9c27] qemu-kvm: Move
make-release to scripts/qemu-kvm
git bisect bad e021b07bd795c76035c48c158943dd8ee47e9c27
# bad: [67feec6ed854b3618b37ccf050b90192cbb96e0f] qemu-kvm: fix improper
nmi emulation
git bisect bad 67feec6ed854b3618b37ccf050b90192cbb96e0f
final git bisect result:
67feec6ed854b3618b37ccf050b90192cbb96e0f is the first bad commit
commit 67feec6ed854b3618b37ccf050b90192cbb96e0f
Author: Lai Jiangshan
Date: Tue Oct 18 00:00:06 2011 +0800
qemu-kvm: fix improper nmi em
Re: [Qemu-devel] git bisect results
Jan Kiszka wrote: On 2012-01-25 12:48, erik.r...@rdsoftware.de wrote: Hi Jan, You should CC me then... :) I will do that for upcoming emails. This little change fixes my problem with the usb-tablet update rate. Can you please verify if this has some side effects? Surely as it disables in general valid code, namely the auto-grabbing feature. You should notice the difference. If not, can you post a real patch? I don't know how to handle the whole patching and committing stuff exactly. We need to understand the problem first anyway, and as I cannot reproduce it, I will need you help: Can you instrument the code, e.g. with printf, to find out which of the disabled branches is taken when, specifically how often? Can you also check if values like max_x/max_y or the ev->motion content make sense for your setup? Thanks, Jan Yes, I will add some counters and dump them in discrete timeslots to see what's the difference between the fullscreen and the windowed mode. Maybe the removed code parts do not affect my main application where the window is resized to fullscreen. But for maintenance it is definitively windowed where I haven't had any problems with the grabbing / releasing up to now. Best regards, Erik
Re: [Qemu-devel] git bisect results
Hi Jan,
here the results of the sdl printfs.
First of all the modified code:
#include
#define NO_DEBUG_PATHS 3
int paths[NO_DEBUG_PATHS] = {0,0,0};
int last_sec = 0;
struct timeval tv;
static void handle_mousemotion(DisplayState *ds, SDL_Event *ev)
{
int max_x, max_y;
if (is_graphic_console() &&
(kbd_mouse_is_absolute() || absolute_enabled)) {
paths[0]++;
max_x = real_screen->w - 1;
max_y = real_screen->h - 1;
if (gui_grab && (ev->motion.x == 0 || ev->motion.y == 0 ||
ev->motion.x == max_x || ev->motion.y == max_y)) {
printf("Status1: %d %d %d %d %d\n",gui_grab,ev->motion.x,ev->motion.y,max_x,max_y);
sdl_grab_end();
paths[1]++;
}
if (!gui_grab && SDL_GetAppState() & SDL_APPINPUTFOCUS &&
(ev->motion.x > 0 && ev->motion.x < max_x &&
ev->motion.y > 0 && ev->motion.y < max_y)) {
printf("Status2: %d %d %d %d %d %d\n",gui_grab,ev->motion.x,ev->motion.y,max_x,max_y,(SDL_GetAppState() & SDL_APPINPUTFOCUS));
sdl_grab_start();
paths[2]++;
}
}
gettimeofday(&tv, 0);
if (tv.tv_sec != last_sec)
{
int i=0;
for (i=0;i
{
printf("Path %d: %d ",i,paths[i]);
}
printf("\n");
last_sec = tv.tv_sec;
}
if (gui_grab || kbd_mouse_is_absolute() || absolute_enabled) {
sdl_send_mouse_event(ev->motion.xrel, ev->motion.yrel, 0,
ev->motion.x, ev->motion.y, ev->motion.state);
}
}
Now the results for this printf for the windowed mode - I just moved the mouse around for several seconds:
Status2: 0 514 394 1023 767 2
Path 0: 1 Path 1: 0 Path 2: 1
Status2: 0 426 402 1023 767 2
Status2: 0 415 403 1023 767 2
Status2: 0 421 405 1023 767 2
Status2: 0 565 401 1023 767 2
Status2: 0 705 367 1023 767 2
Status2: 0 941 143 1023 767 2
Status2: 0 539 6 1023 767 2
Status2: 0 445 96 1023 767 2
Status2: 0 437 346 1023 767 2
Status2: 0 667 644 1023 767 2
Status2: 0 725 434 1023 767 2
Status2: 0 549 234 1023 767 2
Status2: 0 373 308 1023 767 2
Status2: 0 331 510 1023 767 2
Status2: 0 467 546 1023 767 2
Status2: 0 503 438 1023 767 2
Status2: 0 457 276 1023 767 2
Status2: 0 343 210 1023 767 2
Status2: 0 317 410 1023 767 2
Path 0: 71 Path 1: 0 Path 2: 20
Status2: 0 509 384 1023 767 2
Status2: 0 471 228 1023 767 2
Status2: 0 373 174 1023 767 2
Status2: 0 195 172 1023 767 2
Status2: 0 121 274 1023 767 2
Status2: 0 375 400 1023 767 2
Status2: 0 611 296 1023 767 2
Status2: 0 495 168 1023 767 2
Status2: 0 391 140 1023 767 2
Status2: 0 231 242 1023 767 2
Status2: 0 245 396 1023 767 2
Status2: 0 385 484 1023 767 2
Status2: 0 489 484 1023 767 2
Status2: 0 577 356 1023 767 2
Status2: 0 459 234 1023 767 2
Status2: 0 305 246 1023 767 2
Status2: 0 255 376 1023 767 2
Status2: 0 353 540 1023 767 2
Status2: 0 437 564 1023 767 2
Status2: 0 593 518 1023 767 2
Path 0: 142 Path 1: 0 Path 2: 40
Status2: 0 535 298 1023 767 2
Status2: 0 363 274 1023 767 2
Status2: 0 279 362 1023 767 2
Status2: 0 277 464 1023 767 2
Status2: 0 313 506 1023 767 2
Status2: 0 425 514 1023 767 2
Status2: 0 447 430 1023 767 2
Status2: 0 383 304 1023 767 2
Status2: 0 378 305 1023 767 2
Status2: 0 371 311 1023 767 2
Status2: 0 377 314 1023 767 2
Path 0: 175 Path 1: 0 Path 2: 51
Status2: 0 485 268 1023 767 2
Status2: 0 603 148 1023 767 2
Status2: 0 479 74 1023 767 2
Status2: 0 355 120 1023 767 2
Status2: 0 217 240 1023 767 2
Status2: 0 259 302 1023 767 2
Status2: 0 399 306 1023 767 2
Status2: 0 553 236 1023 767 2
Status2: 0 575 188 1023 767 2
Status2: 0 501 102 1023 767 2
Status2: 0 351 124 1023 767 2
Path 0: 218 Path 1: 0 Path 2: 62
Status2: 0 281 164 1023 767 2
Status2: 0 233 208 1023 767 2
Status2: 0 195 300 1023 767 2
Status2: 0 283 378 1023 767 2
Status2: 0 525 386 1023 767 2
Status2: 0 599 348 1023 767 2
Status2: 0 549 296 1023 767 2
Status2: 0 441 274 1023 767 2
Status2: 0 383 274 1023 767 2
Status2: 0 265 320 1023 767 2
Status2: 0 235 388 1023 767 2
Status2: 0 419 494 1023 767 2
Re: [Qemu-devel] commit 67feec6ed854b3618b37ccf050b90192cbb96e0f breaks compilation of hw/pci.c
Andreas Färber wrote: Am 26.01.2012 11:32, schrieb Jan Kiszka: On 2012-01-26 11:00, Andreas Färber wrote: Am 26.01.2012 07:38, schrieb Gleb Natapov: On Wed, Jan 25, 2012 at 10:07:14PM +0100, Erik Rull wrote: Is it possible that you provide this patch? Or was it already applied somewhere? No patch needed. Just do "rm x86_64-softmmu/qmp-commands.h". Or for earlier versions "rm qmp-commands.h"; possibly also qapi-types.h and a third one. When in doubt, use a clean checkup and a dedicated build dir. Then you can just rm -rf *&& ../qemu/configure&& make -jx for each bisect step. make distclean also worked for me in those annoying cases. Usually yes. I recently had to submit dcfa486817c12ea41165265cfaaa236d11968626 to make that work (again?) for those files. Andreas make distclean fixes that from my side. I was not aware of this option, I thought that make clean would be sufficient. Thanks for pointing to that. Best regards, Erik
[Qemu-devel] USB device plugged in => windows XP guest stalls at bootup
Hi all, when having a USB device connected to a windows XP guest that is booting (or rebooting) the guest will never finish booting. It hangs before the screen gets resized and the well known Windows is starting dialog appears. If there is no usb device given to the guest, everything is fine, if I plug it in when booting is finished, I have no problem using it. With a linux guest, it works perfectly. How can I provide more information for helping debugging? I have no idea how to dig into the Windows XP boot process. I tried different XP versions - professional and embedded, on both the same. Best regards, Erik
Re: [Qemu-devel] git bisect results
Jan Kiszka wrote: On 2012-01-27 23:52, Jan Kiszka wrote: On 2012-01-26 14:10, Erik Rull wrote: I assume from these results that the gui_grab is never set to 1 when having entered the window in windowed mode with the cursor. Maybe that's why the sdl_grab_start() is called so often. It seems that the condition in sdl_grab_start() (SDL_WM_GrabInput(SDL_GRAB_ON) == SDL_GRAB_ON) is never fulfilled, otherwise the gui_grab would be set to 1. But the cursor is actually grabbed in windowed mode, otherwise I would not be able to click somewhere with the guest-windows-cursor. This might be a SDL limitation which does not show up everywhere. Here it's fine e.g. The logic dates back to "Handle SDL grabs failing (Mark McLoughlin)", 6bb816031f. Maybe we can solve that issue without relying on the obviously unreliable return value. Need to reproduce that one as well, though. Please check if git://git.kiszka.org/qemu.git queues/sdl fixes the issue for you. Namely reverting the above commit should do the trick. I obsoleted that fragile patch in my series. Thanks, Jan Hi Jan, I will test this on monday. Can you tell me how I can merge that into my cloned main qemu repository? I'm quite new to git. Thanks. Best regards, Erik
Re: [Qemu-devel] git bisect results
Jan Kiszka wrote: On 2012-01-28 13:39, Erik Rull wrote: Jan Kiszka wrote: On 2012-01-27 23:52, Jan Kiszka wrote: On 2012-01-26 14:10, Erik Rull wrote: I assume from these results that the gui_grab is never set to 1 when having entered the window in windowed mode with the cursor. Maybe that's why the sdl_grab_start() is called so often. It seems that the condition in sdl_grab_start() (SDL_WM_GrabInput(SDL_GRAB_ON) == SDL_GRAB_ON) is never fulfilled, otherwise the gui_grab would be set to 1. But the cursor is actually grabbed in windowed mode, otherwise I would not be able to click somewhere with the guest-windows-cursor. This might be a SDL limitation which does not show up everywhere. Here it's fine e.g. The logic dates back to "Handle SDL grabs failing (Mark McLoughlin)", 6bb816031f. Maybe we can solve that issue without relying on the obviously unreliable return value. Need to reproduce that one as well, though. Please check if git://git.kiszka.org/qemu.git queues/sdl fixes the issue for you. Namely reverting the above commit should do the trick. I obsoleted that fragile patch in my series. Thanks, Jan Hi Jan, I will test this on monday. Can you tell me how I can merge that into my cloned main qemu repository? I'm quite new to git. # git remote add kiszka git://git.kiszka.org/qemu.git # git fetch kiszka # git checkout kiszka/queues/sdl That way you will have what I have. Or do you need additional patches for your tests? Jan No I think this will be sufficient. Will this work if I will add it to the qemu-kvm-1.0 tagged version? I have further issues when using the current master because this version does not boot up Windows XP at the moment. I was not able to bisect up to now where this issue was added. Best regards, Erik
Re: [Qemu-devel] git bisect results
On January 28, 2012 at 3:52 PM Jan Kiszka wrote:
> On 2012-01-28 14:01, Erik Rull wrote:
> > Jan Kiszka wrote:
> >> On 2012-01-28 13:39, Erik Rull wrote:
> >>> Jan Kiszka wrote:
> >>>> On 2012-01-27 23:52, Jan Kiszka wrote:
> >>>>> On 2012-01-26 14:10, Erik Rull wrote:
> >>>>>> I assume from these results that the gui_grab is never set to 1 when
> >>>>>> having
> >>>>>> entered the window in windowed mode with the cursor.
> >>>>>>
> >>>>>> Maybe that's why the sdl_grab_start() is called so often.
> >>>>>>
> >>>>>> It seems that the condition in sdl_grab_start()
> >>>>>> (SDL_WM_GrabInput(SDL_GRAB_ON)
> >>>>>> == SDL_GRAB_ON) is never fulfilled, otherwise the gui_grab would be
> >>>>>> set to 1.
> >>>>>> But the cursor is actually grabbed in windowed mode, otherwise I
> >>>>>> would not be
> >>>>>> able to click somewhere with the guest-windows-cursor.
> >>>>>
> >>>>> This might be a SDL limitation which does not show up everywhere. Here
> >>>>> it's fine e.g.
> >>>>>
> >>>>> The logic dates back to "Handle SDL grabs failing (Mark McLoughlin)",
> >>>>> 6bb816031f. Maybe we can solve that issue without relying on the
> >>>>> obviously unreliable return value. Need to reproduce that one as well,
> >>>>> though.
> >>>>
> >>>> Please check if
> >>>>
> >>>> git://git.kiszka.org/qemu.git queues/sdl
> >>>>
> >>>> fixes the issue for you. Namely reverting the above commit should do
> >>>> the
> >>>> trick. I obsoleted that fragile patch in my series.
> >>>>
> >>>> Thanks,
> >>>> Jan
> >>>>
> >>>>
> >>>
> >>> Hi Jan,
> >>>
> >>> I will test this on monday. Can you tell me how I can merge that into my
> >>> cloned main qemu repository? I'm quite new to git.
> >>
> >> # git remote add kiszka git://git.kiszka.org/qemu.git
> >> # git fetch kiszka
> >> # git checkout kiszka/queues/sdl
> >>
> >> That way you will have what I have. Or do you need additional patches
> >> for your tests?
> >>
> >> Jan
> >>
> >
> > No I think this will be sufficient. Will this work if I will add it to
> > the qemu-kvm-1.0 tagged version?
>
> For your test, you can focus on applying
>
> http://git.kiszka.org/?p=qemu.git;a=commitdiff;h=0109c860ca59fddbecb47651be3cbf5135d8e82e
>
> on the target branch.
>
> > I have further issues when using the
> > current master because this version does not boot up Windows XP at the
> > moment. I was not able to bisect up to now where this issue was added.
>
> Hmm, works here. Which command line?
>
> Jan
>
Hi Jan,
I'm sorry, but this does not solve my issue. I applied the patch and crosschecked that the resulting file looks fine.
The final function looks like:
static void sdl_grab_start(void)
{
/*
* If the application is not active, do not try to enter grab state. This
* prevents 'SDL_WM_GrabInput(SDL_GRAB_ON)' from blocking all the
* application (SDL bug).
*/
if (!(SDL_GetAppState() & SDL_APPINPUTFOCUS)) {
return;
}
if (guest_cursor) {
SDL_SetCursor(guest_sprite);
if (!kbd_mouse_is_absolute() && !absolute_enabled)
SDL_WarpMouse(guest_x, guest_y);
} else
sdl_hide_cursor();
SDL_WM_GrabInput(SDL_GRAB_ON);
gui_grab = 1;
sdl_update_caption();
}
Best regards,
Erik
Re: [Qemu-devel] git bisect results
On January 30, 2012 at 12:52 PM Jan Kiszka wrote:
> On 2012-01-30 12:34, Erik Rull wrote:
> > Hi Jan,
> >
> > I'm sorry, but this does not solve my issue. I applied the patch and
> > crosschecked that the resulting file looks fine.
> >
> > The final function looks like:
> >
> > static void sdl_grab_start(void)
> > {
> > /*
> > * If the application is not active, do not try to enter grab state.
This
> > * prevents 'SDL_WM_GrabInput(SDL_GRAB_ON)' from blocking all the
> > * application (SDL bug).
> > */
> > if (!(SDL_GetAppState() & SDL_APPINPUTFOCUS)) {
> > return;
> > }
> > if (guest_cursor) {
> > SDL_SetCursor(guest_sprite);
> > if (!kbd_mouse_is_absolute() && !absolute_enabled)
> > SDL_WarpMouse(guest_x, guest_y);
> > } else
> > sdl_hide_cursor();
> > SDL_WM_GrabInput(SDL_GRAB_ON);
> > gui_grab = 1;
> > sdl_update_caption();
> > }
>
> That makes no sense as gui_grab must be 1 now. Please retry your
> previous instrumentation.
>
> Thanks,
> Jan
>
You're right. So I added the instrumentation again.
Still looks strange.
So I added into the sdl_grab_start() a printf.
Wow - a lot of output!
This pointed me to all other sdl_grab_start() calls (and in additon to that
all sdl_grab_end() calls).
And here are the results of the qemu voting :-)
I already assigned a usable name to the printf output that is directly one
line above the corresponding sdl_grab_*() call, so you should be able to
find this easily in your code as well.
The huge number of recurring printf's are:
sdl_grab_start() called from absolute_mouse_grab()
sdl_grab_end() called from handle_activation()
sdl_grab_start() called from absolute_mouse_grab()
sdl_grab_end() called from handle_activation()
sdl_grab_start() called from absolute_mouse_grab()
sdl_grab_end() called from handle_activation()
sdl_grab_start() called from absolute_mouse_grab()
sdl_grab_end() called from handle_activation()
sdl_grab_start() called from absolute_mouse_grab()
sdl_grab_end() called from handle_activation()
sdl_grab_start() called from absolute_mouse_grab()
sdl_grab_end() called from handle_activation()
sdl_grab_start() called from absolute_mouse_grab()
sdl_grab_end() called from handle_activation()
Any idea how to proceed?
Maybe the first two if-statements in handle_activation() cause the problem?
Because there the two given functions are called in sequence if both
if-clauses are valid one after the other. Maybe the first one sets the
state so that the second if is valid, too. Maybe a simple else if solves
the issue? I'm not familiar with the variables that are checked here, so
it's just a guess.
Best regards,
Erik
Re: [Qemu-devel] git bisect results
On January 30, 2012 at 2:48 PM Jan Kiszka wrote:
> On 2012-01-30 14:17, Erik Rull wrote:
> >
> >
> >
> > On January 30, 2012 at 12:52 PM Jan Kiszka
wrote:
> >
> >> On 2012-01-30 12:34, Erik Rull wrote:
> >>> Hi Jan,
> >>>
> >>> I'm sorry, but this does not solve my issue. I applied the patch and
> >>> crosschecked that the resulting file looks fine.
> >>>
> >>> The final function looks like:
> >>>
> >>> static void sdl_grab_start(void)
> >>> {
> >>> /*
> >>> * If the application is not active, do not try to enter grab state.
> > This
> >>> * prevents 'SDL_WM_GrabInput(SDL_GRAB_ON)' from blocking all the
> >>> * application (SDL bug).
> >>> */
> >>> if (!(SDL_GetAppState() & SDL_APPINPUTFOCUS)) {
> >>> return;
> >>> }
> >>> if (guest_cursor) {
> >>> SDL_SetCursor(guest_sprite);
> >>> if (!kbd_mouse_is_absolute() && !absolute_enabled)
> >>> SDL_WarpMouse(guest_x, guest_y);
> >>> } else
> >>> sdl_hide_cursor();
> >>> SDL_WM_GrabInput(SDL_GRAB_ON);
> >>> gui_grab = 1;
> >>> sdl_update_caption();
> >>> }
> >>
> >> That makes no sense as gui_grab must be 1 now. Please retry your
> >> previous instrumentation.
> >>
> >> Thanks,
> >> Jan
> >>
> >
> > You're right. So I added the instrumentation again.
> >
> > Still looks strange.
> >
> > So I added into the sdl_grab_start() a printf.
> > Wow - a lot of output!
> > This pointed me to all other sdl_grab_start() calls (and in additon to
that
> > all sdl_grab_end() calls).
> >
> > And here are the results of the qemu voting :-)
> >
> > I already assigned a usable name to the printf output that is directly
one
> > line above the corresponding sdl_grab_*() call, so you should be able
to
> > find this easily in your code as well.
> >
> > The huge number of recurring printf's are:
> >
> > sdl_grab_start() called from absolute_mouse_grab()
> > sdl_grab_end() called from handle_activation()
> > sdl_grab_start() called from absolute_mouse_grab()
> > sdl_grab_end() called from handle_activation()
> > sdl_grab_start() called from absolute_mouse_grab()
> > sdl_grab_end() called from handle_activation()
> > sdl_grab_start() called from absolute_mouse_grab()
> > sdl_grab_end() called from handle_activation()
> > sdl_grab_start() called from absolute_mouse_grab()
> > sdl_grab_end() called from handle_activation()
> > sdl_grab_start() called from absolute_mouse_grab()
> > sdl_grab_end() called from handle_activation()
> > sdl_grab_start() called from absolute_mouse_grab()
> > sdl_grab_end() called from handle_activation()
> >
> > Any idea how to proceed?
> >
> > Maybe the first two if-statements in handle_activation() cause the
problem?
> > Because there the two given functions are called in sequence if both
> > if-clauses are valid one after the other. Maybe the first one sets the
> > state so that the second if is valid, too. Maybe a simple else if
solves
> > the issue?
>
> ev->active.gain makes both clauses mutually exclusive - unless someone
> messes with the memory of the event object.
>
> > I'm not familiar with the variables that are checked here, so
> > it's just a guess.
>
> So handle_activation() is called directly after absolute_mouse_grab(),
> and the reported event contains
>
> state = SDL_APPINPUTFOCUS
> gain = 0
> (please validate!)
>
> That would mean we are constantly losing the input focus again after
> trying to gain it via SDL_WM_GrabInput. Weird.
>
> What's the call chain for absolute_mouse_grab()?
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux
Here the results:
Handle Activation 0: at function start (before the first if)
Handle Activation 1: between the first and the second if
Handle Activation 2: after the second if
The output is formatted like:
printf("Handle Activation 0: %d %d %d %d\n",gui_grab,(ev->active.state ==
SDL_APPINPUTFOCUS),ev->active.gain,gui_fullscreen);
Handle Activation 0: 0 1 1 0
Handle Activation 1: 0 1 1 0
absolute_mouse_grab() called from handle_activation()
sdl_grab_start() called from absolute_mouse_grab()
Handle Activation 2: 1 1 1 0
Handle Activation 0: 1 1 0 0
sdl_grab_end() called from handle_activation()
Handle Activation 1: 0 1 0 0
Handle Activation 2: 0 1 0 0
Handle Activation 0: 0 1 1 0
Handle Activation 1: 0 1 1 0
absolute_mouse_grab() called from handle_activation()
sdl_grab_start() called from absolute_mouse_grab()
Handle Activation 2: 1 1 1 0
Handle Activation 0: 1 1 0 0
sdl_grab_end() called from handle_activation()
Handle Activation 1: 0 1 0 0
Handle Activation 2: 0 1 0 0
Handle Activation 0: 0 1 1 0
Handle Activation 1: 0 1 1 0
absolute_mouse_grab() called from handle_activation()
sdl_grab_start() called from absolute_mouse_grab()
Handle Activation 2: 1 1 1 0
The gain seems to toggle between the successive calls of
handle_activation...
Next steps?
Best regards,
Erik
Re: [Qemu-devel] git bisect results
On January 30, 2012 at 3:48 PM Jan Kiszka wrote:
> On 2012-01-30 15:17, Erik Rull wrote:
> >
> >
> >
> > On January 30, 2012 at 2:48 PM Jan Kiszka
wrote:
> >
> >> On 2012-01-30 14:17, Erik Rull wrote:
> >>>
> >>>
> >>>
> >>> On January 30, 2012 at 12:52 PM Jan Kiszka
> > wrote:
> >>>
> >>>> On 2012-01-30 12:34, Erik Rull wrote:
> >>>>> Hi Jan,
> >>>>>
> >>>>> I'm sorry, but this does not solve my issue. I applied the patch
and
> >>>>> crosschecked that the resulting file looks fine.
> >>>>>
> >>>>> The final function looks like:
> >>>>>
> >>>>> static void sdl_grab_start(void)
> >>>>> {
> >>>>> /*
> >>>>> * If the application is not active, do not try to enter grab state.
> >>> This
> >>>>> * prevents 'SDL_WM_GrabInput(SDL_GRAB_ON)' from blocking all the
> >>>>> * application (SDL bug).
> >>>>> */
> >>>>> if (!(SDL_GetAppState() & SDL_APPINPUTFOCUS)) {
> >>>>> return;
> >>>>> }
> >>>>> if (guest_cursor) {
> >>>>> SDL_SetCursor(guest_sprite);
> >>>>> if (!kbd_mouse_is_absolute() && !absolute_enabled)
> >>>>> SDL_WarpMouse(guest_x, guest_y);
> >>>>> } else
> >>>>> sdl_hide_cursor();
> >>>>> SDL_WM_GrabInput(SDL_GRAB_ON);
> >>>>> gui_grab = 1;
> >>>>> sdl_update_caption();
> >>>>> }
> >>>>
> >>>> That makes no sense as gui_grab must be 1 now. Please retry your
> >>>> previous instrumentation.
> >>>>
> >>>> Thanks,
> >>>> Jan
> >>>>
> >>>
> >>> You're right. So I added the instrumentation again.
> >>>
> >>> Still looks strange.
> >>>
> >>> So I added into the sdl_grab_start() a printf.
> >>> Wow - a lot of output!
> >>> This pointed me to all other sdl_grab_start() calls (and in additon
to
> > that
> >>> all sdl_grab_end() calls).
> >>>
> >>> And here are the results of the qemu voting :-)
> >>>
> >>> I already assigned a usable name to the printf output that is
directly
> > one
> >>> line above the corresponding sdl_grab_*() call, so you should be able
> > to
> >>> find this easily in your code as well.
> >>>
> >>> The huge number of recurring printf's are:
> >>>
> >>> sdl_grab_start() called from absolute_mouse_grab()
> >>> sdl_grab_end() called from handle_activation()
> >>> sdl_grab_start() called from absolute_mouse_grab()
> >>> sdl_grab_end() called from handle_activation()
> >>> sdl_grab_start() called from absolute_mouse_grab()
> >>> sdl_grab_end() called from handle_activation()
> >>> sdl_grab_start() called from absolute_mouse_grab()
> >>> sdl_grab_end() called from handle_activation()
> >>> sdl_grab_start() called from absolute_mouse_grab()
> >>> sdl_grab_end() called from handle_activation()
> >>> sdl_grab_start() called from absolute_mouse_grab()
> >>> sdl_grab_end() called from handle_activation()
> >>> sdl_grab_start() called from absolute_mouse_grab()
> >>> sdl_grab_end() called from handle_activation()
> >>>
> >>> Any idea how to proceed?
> >>>
> >>> Maybe the first two if-statements in handle_activation() cause the
> > problem?
> >>> Because there the two given functions are called in sequence if both
> >>> if-clauses are valid one after the other. Maybe the first one sets
the
> >>> state so that the second if is valid, too. Maybe a simple else if
> > solves
> >>> the issue?
> >>
> >> ev->active.gain makes both clauses mutually exclusive - unless someone
> >> messes with the memory of the event object.
> >>
> >>> I'm not familiar with the variables that are checked here, so
> >>> it's just a guess.
> >>
> >> So handle_activation() is called directly after absolute_mouse_grab(),
> >> and the reported event contains
> >>
> >> state = SDL_APPINPUTFOCUS
> >> gain = 0
> >> (please validate!)
> >>
Re: [Qemu-devel] [PATCH 5/5] sdl: Limit sdl_grab_end in handle_activation to Windows hosts
Jan Kiszka wrote:
There are scenarios on Linux with some SDL versions where
handle_activation is continuous invoked with state = SDL_APPINPUTFOCUS
and gain = 0 while we grabbed the input. This causes a ping-pong when we
grab the input after an absolute mouse entered the window.
As this sdl_grab_end was once introduced to work around a Windows-only
issue (0294ffb9c8), limit it to that platform.
CC: Erik Rull
Signed-off-by: Jan Kiszka
---
ui/sdl.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/ui/sdl.c b/ui/sdl.c
index 73e5839..6f8091c 100644
--- a/ui/sdl.c
+++ b/ui/sdl.c
@@ -828,10 +828,14 @@ static void handle_mousebutton(DisplayState *ds,
SDL_Event *ev)
static void handle_activation(DisplayState *ds, SDL_Event *ev)
{
+#ifdef _WIN32
+/* Disable grab if the window no longer has the focus
+ * (Windows-only workaround) */
if (gui_grab&& ev->active.state == SDL_APPINPUTFOCUS&&
!ev->active.gain&& !gui_fullscreen) {
sdl_grab_end();
}
+#endif
if (!gui_grab&& ev->active.gain&& is_graphic_console()&&
(kbd_mouse_is_absolute() || absolute_enabled)) {
absolute_mouse_grab();
Hi Jan,
thanks for your help.
When will the patches be applied to the qemu-git?
Best regards,
Erik
[Qemu-devel] git bisect results: ec757c67c40a56492001487e69272f62144fd124 breaks windows boot in qemu-kvm
Hi all, first of all I'm a bit confused: What is the difference between qemu with command line option --enable-kvm and qemu-kvm? It seems to be a difference in code so far, from the performance point of view it seems to be the same... Now my issue that lead me to a git bisect on qemu-kvm: The following commit / merge breaks my windows guest boot sequence and causes resets infinitely: ec757c67c40a56492001487e69272f62144fd124 Merge branch 'upstream-merge' into next Thu, 5 Jan 2012 11:00:07 + (13:00 +0200)Avi Kivity Interesting: qemu with --enable-kvm master and the same command line options as qemu-kvm runs perfect. My command line options are: qemu-system-x86_64 -serial /dev/ttyS2 -readconfig /etc/ich9-ehci-uhci.cfg -device usb-host,bus=ehci.0 -device usb-tablet -drive file=/dev/sda2,cache=off -m 1024 -net nic,macaddr=$MACADDR -net tap,script=/etc/qemu-ifup -no-acpi -monitor stdio -L /usr/X11R6/share/qemu -boot c -localtime Best regards, Erik
Re: [Qemu-devel] git bisect results: ec757c67c40a56492001487e69272f62144fd124 breaks windows boot in qemu-kvm
On February 1, 2012 at 2:40 PM Avi Kivity wrote: > On 02/01/2012 02:52 PM, Erik Rull wrote: > > Hi all, > > > > first of all I'm a bit confused: > > > > What is the difference between qemu with command line option --enable-kvm > > and qemu-kvm? > > It seems to be a difference in code so far, from the performance point of > > view it seems to be the same... > > The differences are being reduced rapidly, thanks to Jan's efforts. > Right now what remains is PIT performance and accuracy, device > assignment, and Windows XP performance. Most guests should see the same > performance. > > > Now my issue that lead me to a git bisect on qemu-kvm: > > The following commit / merge breaks my windows guest boot sequence and > > causes resets infinitely: > > ec757c67c40a56492001487e69272f62144fd124 Merge branch 'upstream-merge' into > > next > > Thu, 5 Jan 2012 11:00:07 + (13:00 +0200)Avi Kivity > > > > > > Interesting: qemu with --enable-kvm master and the same command line > > options as qemu-kvm runs perfect. > > My command line options are: > > qemu-system-x86_64 -serial /dev/ttyS2 -readconfig /etc/ich9-ehci-uhci.cfg > > -device usb-host,bus=ehci.0 -device usb-tablet -drive > > file=/dev/sda2,cache=off -m 1024 -net nic,macaddr=$MACADDR -net > > tap,script=/etc/qemu-ifup -no-acpi -monitor stdio -L /usr/X11R6/share/qemu > > -boot c -localtime > > > > > > What version of Windows are you using? What's the contents of > /etc/ich9-ehci-uhci.cfg? > Hi Avi, the contents from the .cfg are located in docs/ich9-ehci-uhci.cfg I tried two versions of Windows XP: One is the default Windows XP SP3 that you get from MSDN, one is Windows Embedded Standard (embedded customized XP). Both show the same behavior: boots with qemu -enable-kvm and continuously reboots with qemu-kvm. Best regards, Erik
Re: [Qemu-devel] git bisect results: ec757c67c40a56492001487e69272f62144fd124 breaks windows boot in qemu-kvm
On February 1, 2012 at 3:42 PM Jan Kiszka wrote: > On 2012-02-01 15:02, Erik Rull wrote: > > > > On February 1, 2012 at 2:40 PM Avi Kivity wrote: > > > >> On 02/01/2012 02:52 PM, Erik Rull wrote: > >>> Hi all, > >>> > >>> first of all I'm a bit confused: > >>> > >>> What is the difference between qemu with command line option > > --enable-kvm > >>> and qemu-kvm? > >>> It seems to be a difference in code so far, from the performance point > > of > >>> view it seems to be the same... > >> > >> The differences are being reduced rapidly, thanks to Jan's efforts. > >> Right now what remains is PIT performance and accuracy, device > >> assignment, and Windows XP performance. Most guests should see the same > >> performance. > > MSI performance is expected to be worse with upstream as well, thus virtio. > > >> > >>> Now my issue that lead me to a git bisect on qemu-kvm: > >>> The following commit / merge breaks my windows guest boot sequence and > >>> causes resets infinitely: > >>> ec757c67c40a56492001487e69272f62144fd124 Merge branch 'upstream-merge' > > into > >>> next > >>> Thu, 5 Jan 2012 11:00:07 + (13:00 +0200)Avi Kivity > > > >>> > >>> > >>> Interesting: qemu with --enable-kvm master and the same command line > >>> options as qemu-kvm runs perfect. > >>> My command line options are: > >>> qemu-system-x86_64 -serial /dev/ttyS2 -readconfig > > /etc/ich9-ehci-uhci.cfg > >>> -device usb-host,bus=ehci.0 -device usb-tablet -drive > >>> file=/dev/sda2,cache=off -m 1024 -net nic,macaddr=$MACADDR -net > >>> tap,script=/etc/qemu-ifup -no-acpi -monitor stdio -L > > /usr/X11R6/share/qemu > >>> -boot c -localtime > >>> > >>> > >> > >> What version of Windows are you using? What's the contents of > >> /etc/ich9-ehci-uhci.cfg? > >> > > > > Hi Avi, > > > > the contents from the .cfg are located in docs/ich9-ehci-uhci.cfg > > > > I tried two versions of Windows XP: One is the default Windows XP SP3 that > > you get from MSDN, one is Windows Embedded Standard (embedded customized > > XP). > > > > Both show the same behavior: boots with qemu -enable-kvm and continuously > > reboots with qemu-kvm. > > What does qemu-kvm with -no-kvm-irqchip do? > > Jan > Wow - that works! Does this influence the guest performance?
[Qemu-devel] [Bug 441672] Re: Windos XP BSOD with HP Photosmart usb device attached
Please use qemu-1.0 + ehci. The UHCI layer seems to cause this problem when handling some USB 2.0 devices. I had similar problems but with EHCI + qemu-1.0 it was fixed. See docs/usb2.txt for USB 2.0 support. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/441672 Title: Windos XP BSOD with HP Photosmart usb device attached Status in QEMU: New Bug description: https://bugzilla.redhat.com/show_bug.cgi?id=524723 has all the details of the problem. I was just testing attaching a USB device to see if it really worked, and tried my HP Photosmart C5580 All-in-One printer/scanner, and the Windows XP box then started getting bluescreens and crashing at random (fairly short :-) intervals. My latest attempt was on a fedora rawhide system with pretty up to date software (qemu-kvm-0.11.0-2.fc12.x86_64), and the crashes still happen. A reply to that bugzilla recommended adding this upstream bug, so here it is. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/441672/+subscriptions
[Qemu-devel] [Bug 924943] [NEW] usb-host devices given by command line are routed incomplete to the guest
Public bug reported: affected qemus: qemu-1.0, qemu-kvm-1.0, qemu and qemu-kvm master branches (older versions not tested) affected guests: linux, windows test hardware: standard usb key (or any other piece of USB hardware) that works perfectly when plugged in after guest bootup Several Sequences have been tested: - start qemu with -readconfig /etc/ich9-ehci-uhci.cfg -device usb-tablet -device usb-host,bus=ehci.0 - start qemu with -readconfig /etc/ich9-ehci-uhci.cfg -device usb-tablet -S (to not start up the guest directly) + at the console prompt: "device_add usb-host" then "c" to start the guest. For the linux guest, I get a usb device listed and detected as /dev/sdb when plugging it in at runtime. At startup linux does NOT detect it. For the windows guest, I get a usb device listed and detected as "removable media" when plugging it in at runtime. At startup Windows does detect "something" that is listed in the device manager as Generic Mass Storage device, but with a yellow exclamation mark and there is no removable media listed in Explorer If you need further testings, just let me know. ** Affects: qemu Importance: Undecided Status: New ** Tags: linux qemu usb windows -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/924943 Title: usb-host devices given by command line are routed incomplete to the guest Status in QEMU: New Bug description: affected qemus: qemu-1.0, qemu-kvm-1.0, qemu and qemu-kvm master branches (older versions not tested) affected guests: linux, windows test hardware: standard usb key (or any other piece of USB hardware) that works perfectly when plugged in after guest bootup Several Sequences have been tested: - start qemu with -readconfig /etc/ich9-ehci-uhci.cfg -device usb-tablet -device usb-host,bus=ehci.0 - start qemu with -readconfig /etc/ich9-ehci-uhci.cfg -device usb-tablet -S (to not start up the guest directly) + at the console prompt: "device_add usb-host" then "c" to start the guest. For the linux guest, I get a usb device listed and detected as /dev/sdb when plugging it in at runtime. At startup linux does NOT detect it. For the windows guest, I get a usb device listed and detected as "removable media" when plugging it in at runtime. At startup Windows does detect "something" that is listed in the device manager as Generic Mass Storage device, but with a yellow exclamation mark and there is no removable media listed in Explorer If you need further testings, just let me know. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/924943/+subscriptions
Re: [Qemu-devel] git bisect results: ec757c67c40a56492001487e69272f62144fd124 breaks windows boot in qemu-kvm
On February 1, 2012 at 5:01 PM Jan Kiszka wrote: > On 2012-02-01 16:43, Erik Rull wrote: > > On February 1, 2012 at 3:42 PM Jan Kiszka wrote: > > > >> On 2012-02-01 15:02, Erik Rull wrote: > >>> > >>> On February 1, 2012 at 2:40 PM Avi Kivity wrote: > >>> > >>>> On 02/01/2012 02:52 PM, Erik Rull wrote: > >>>>> Hi all, > >>>>> > >>>>> first of all I'm a bit confused: > >>>>> > >>>>> What is the difference between qemu with command line option > >>> --enable-kvm > >>>>> and qemu-kvm? > >>>>> It seems to be a difference in code so far, from the performance > > point > >>> of > >>>>> view it seems to be the same... > >>>> > >>>> The differences are being reduced rapidly, thanks to Jan's efforts. > >>>> Right now what remains is PIT performance and accuracy, device > >>>> assignment, and Windows XP performance. Most guests should see the > > same > >>>> performance. > >> > >> MSI performance is expected to be worse with upstream as well, thus > > virtio. > >> > >>>> > >>>>> Now my issue that lead me to a git bisect on qemu-kvm: > >>>>> The following commit / merge breaks my windows guest boot sequence > > and > >>>>> causes resets infinitely: > >>>>> ec757c67c40a56492001487e69272f62144fd124 Merge branch > > 'upstream-merge' > >>> into > >>>>> next > > So commit aad3b517a1b83561f2755dc4451596a421399c19, i.e. the last merge > before that one is still fine? > > >>>>> Thu, 5 Jan 2012 11:00:07 + (13:00 +0200)Avi Kivity > >>> > >>>>> > >>>>> > >>>>> Interesting: qemu with --enable-kvm master and the same command line > >>>>> options as qemu-kvm runs perfect. > >>>>> My command line options are: > >>>>> qemu-system-x86_64 -serial /dev/ttyS2 -readconfig > >>> /etc/ich9-ehci-uhci.cfg > >>>>> -device usb-host,bus=ehci.0 -device usb-tablet -drive > >>>>> file=/dev/sda2,cache=off -m 1024 -net nic,macaddr=$MACADDR -net > >>>>> tap,script=/etc/qemu-ifup -no-acpi -monitor stdio -L > >>> /usr/X11R6/share/qemu > >>>>> -boot c -localtime > >>>>> > >>>>> > >>>> > >>>> What version of Windows are you using? What's the contents of > >>>> /etc/ich9-ehci-uhci.cfg? > >>>> > >>> > >>> Hi Avi, > >>> > >>> the contents from the .cfg are located in docs/ich9-ehci-uhci.cfg > >>> > >>> I tried two versions of Windows XP: One is the default Windows XP SP3 > > that > >>> you get from MSDN, one is Windows Embedded Standard (embedded > > customized > >>> XP). > >>> > >>> Both show the same behavior: boots with qemu -enable-kvm and > > continuously > >>> reboots with qemu-kvm. > >> > >> What does qemu-kvm with -no-kvm-irqchip do? > >> > >> Jan > >> > > > > Wow - that works! > > Does this influence the guest performance? > > > > Yes, how much depends on your workload. > > Still strange, though. We should try to understand this issue. It stays > like this up to and including current qemu-kvm.git master? > > Jan > Hi Jan, I didn't follow the branch, only the master between 1.0 and head. Here my bisect log: git bisect start # good: [30c044521889195f54a9f2c21310894f545994e8] Merge commit 'v1.0' into next git bisect good 30c044521889195f54a9f2c21310894f545994e8 # bad: [2793248c5427c0bc585fdf9c101680bab29f4839] Merge remote-tracking branch 'upstream' into next git bisect bad 2793248c5427c0bc585fdf9c101680bab29f4839 # good: [262db38871b9a2613761cc5f05c4cf697e246a68] qemu-nbd: asynchronous operation git bisect good 262db38871b9a2613761cc5f05c4cf697e246a68 # good: [9737383beb515a583fdb6f2aafa631fcd6797068] qerror: add check-qerror.sh to verify alphabetical order git bisect good 9737383beb515a583fdb6f2aafa631fcd6797068 # skip: [fb5458cd10a199e55e622a906b24f8085d922c0f] qmp: add query-block-jobs git bisect skip fb5458cd10a199e55e622a906b24f8085d922c0f # skip: [aa398a5c3a4c0fc29baf02aee5283a7fa0f202a3] blockdev: make image streaming safe across hotplug git bisect skip aa398a5c3a4c0fc29baf02aee5283a7fa0f202a3 # good: [506b7ddf8
Re: [Qemu-devel] git bisect results: ec757c67c40a56492001487e69272f62144fd124 breaks windows boot in qemu-kvm
Jan Kiszka wrote: On 2012-02-01 13:52, Erik Rull wrote: Hi all, first of all I'm a bit confused: What is the difference between qemu with command line option --enable-kvm and qemu-kvm? It seems to be a difference in code so far, from the performance point of view it seems to be the same... Now my issue that lead me to a git bisect on qemu-kvm: The following commit / merge breaks my windows guest boot sequence and causes resets infinitely: Cannot confirm yet, but I have no ACPI-free Windows installation at hand. Where does it reset, after the BIOS? ec757c67c40a56492001487e69272f62144fd124 Merge branch 'upstream-merge' into next Thu, 5 Jan 2012 11:00:07 + (13:00 +0200)Avi Kivity Interesting: qemu with --enable-kvm master and the same command line options as qemu-kvm runs perfect. My command line options are: qemu-system-x86_64 -serial /dev/ttyS2 -readconfig /etc/ich9-ehci-uhci.cfg -device usb-host,bus=ehci.0 -device usb-tablet -drive file=/dev/sda2,cache=off -m 1024 -net nic,macaddr=$MACADDR -net tap,script=/etc/qemu-ifup -no-acpi -monitor stdio -L /usr/X11R6/share/qemu -boot c -localtime Is the BIOS at /usr/X11R6/share/qemu in sync with the qemu version you try? Does leaving out options change the picture? Jan It happens directly after the windows boot progress bar is completed (I boot without logo) With the -no-kvm-irqchip it seems to be fine... Best regards, Erik
Re: [Qemu-devel] git bisect results: ec757c67c40a56492001487e69272f62144fd124 breaks windows boot in qemu-kvm
On February 1, 2012 at 11:05 PM Erik Rull wrote: > Jan Kiszka wrote: > > On 2012-02-01 13:52, Erik Rull wrote: > >> Hi all, > >> > >> first of all I'm a bit confused: > >> > >> What is the difference between qemu with command line option --enable-kvm > >> and qemu-kvm? > >> It seems to be a difference in code so far, from the performance point of > >> view it seems to be the same... > >> > >> Now my issue that lead me to a git bisect on qemu-kvm: > >> The following commit / merge breaks my windows guest boot sequence and > >> causes resets infinitely: > > > > Cannot confirm yet, but I have no ACPI-free Windows installation at > > hand. Where does it reset, after the BIOS? > > > >> ec757c67c40a56492001487e69272f62144fd124 Merge branch 'upstream-merge' into > >> next > >> Thu, 5 Jan 2012 11:00:07 + (13:00 +0200)Avi Kivity > >> > >> > >> Interesting: qemu with --enable-kvm master and the same command line > >> options as qemu-kvm runs perfect. > >> My command line options are: > >> qemu-system-x86_64 -serial /dev/ttyS2 -readconfig /etc/ich9-ehci-uhci.cfg > >> -device usb-host,bus=ehci.0 -device usb-tablet -drive > >> file=/dev/sda2,cache=off -m 1024 -net nic,macaddr=$MACADDR -net > >> tap,script=/etc/qemu-ifup -no-acpi -monitor stdio -L /usr/X11R6/share/qemu > >> -boot c -localtime > > > > Is the BIOS at /usr/X11R6/share/qemu in sync with the qemu version you > > try? Does leaving out options change the picture? > > > > Jan > > > > It happens directly after the windows boot progress bar is completed (I > boot without logo) > > With the -no-kvm-irqchip it seems to be fine... > > Best regards, > > Erik Hi Jan, I tested with an ACPI-enabled windows. Results: -no-acpi: Continuous reboots like the no-acpi-windows-version without -no-acpi: boots! So I tested the no-acpi-windows-version without -no-acpi option - still rebooting And without -no-acpi and -no-kvm-irqchip => works again Best regards, Erik
Re: [Qemu-devel] git bisect results: ec757c67c40a56492001487e69272f62144fd124 breaks windows boot in qemu-kvm
On February 2, 2012 at 2:21 PM Jan Kiszka wrote: > On 2012-02-02 14:18, Erik Rull wrote: > > > > On February 1, 2012 at 11:05 PM Erik Rull wrote: > > > >> Jan Kiszka wrote: > >>> On 2012-02-01 13:52, Erik Rull wrote: > >>>> Hi all, > >>>> > >>>> first of all I'm a bit confused: > >>>> > >>>> What is the difference between qemu with command line option > > --enable-kvm > >>>> and qemu-kvm? > >>>> It seems to be a difference in code so far, from the performance point > > of > >>>> view it seems to be the same... > >>>> > >>>> Now my issue that lead me to a git bisect on qemu-kvm: > >>>> The following commit / merge breaks my windows guest boot sequence and > >>>> causes resets infinitely: > >>> > >>> Cannot confirm yet, but I have no ACPI-free Windows installation at > >>> hand. Where does it reset, after the BIOS? > >>> > >>>> ec757c67c40a56492001487e69272f62144fd124 Merge branch 'upstream-merge' > > into > >>>> next > >>>> Thu, 5 Jan 2012 11:00:07 + (13:00 +0200)Avi > > Kivity > >>>> > >>>> > >>>> Interesting: qemu with --enable-kvm master and the same command line > >>>> options as qemu-kvm runs perfect. > >>>> My command line options are: > >>>> qemu-system-x86_64 -serial /dev/ttyS2 -readconfig > > /etc/ich9-ehci-uhci.cfg > >>>> -device usb-host,bus=ehci.0 -device usb-tablet -drive > >>>> file=/dev/sda2,cache=off -m 1024 -net nic,macaddr=$MACADDR -net > >>>> tap,script=/etc/qemu-ifup -no-acpi -monitor stdio -L > > /usr/X11R6/share/qemu > >>>> -boot c -localtime > >>> > >>> Is the BIOS at /usr/X11R6/share/qemu in sync with the qemu version you > >>> try? Does leaving out options change the picture? > >>> > >>> Jan > >>> > >> > >> It happens directly after the windows boot progress bar is completed (I > >> boot without logo) > >> > >> With the -no-kvm-irqchip it seems to be fine... > >> > >> Best regards, > >> > >> Erik > > > > > > Hi Jan, > > > > I tested with an ACPI-enabled windows. > > Results: > > -no-acpi: Continuous reboots like the no-acpi-windows-version > > without -no-acpi: boots! > > > > So I tested the no-acpi-windows-version without -no-acpi option - still > > rebooting > > And without -no-acpi and -no-kvm-irqchip => works again > > Interesting. Need to install such a version, I guess. > > What about no-acpi-windows and upstream qemu with kvm and -machine > kernel_irqchip=on? > > Jan Boots with and without -no-acpi Best regards, Erik P.S. Too many options for me :-)
[Qemu-devel] [Bug 924943] Re: usb-host devices given by command line are routed incomplete to the guest
update: it works with the following parameter set: -usb -device usb-host but then only USB 1.1 is available (very slow) it does not work with: -readconfig ich9-ehci-uhci.cfg -device usb-host,bus=ehci.0 but there I have USB 2.0 and USB 1.1 devices routed perfectly with a good speed to the guest at runtime the .cfg is taken from the docs/ directory I also tested with ehci-only parameters (no uhci / companion), same effect And: This seems only to be related to USB 2.0 devices! I tested both with a USB 1.1 device plugged in before starting the guest and there it works perfectly. it would be really great to find a solution for that -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/924943 Title: usb-host devices given by command line are routed incomplete to the guest Status in QEMU: New Bug description: affected qemus: qemu-1.0, qemu-kvm-1.0, qemu and qemu-kvm master branches (older versions not tested) affected guests: linux, windows test hardware: standard usb key (or any other piece of USB hardware) that works perfectly when plugged in after guest bootup Several Sequences have been tested: - start qemu with -readconfig /etc/ich9-ehci-uhci.cfg -device usb-tablet -device usb-host,bus=ehci.0 - start qemu with -readconfig /etc/ich9-ehci-uhci.cfg -device usb-tablet -S (to not start up the guest directly) + at the console prompt: "device_add usb-host" then "c" to start the guest. For the linux guest, I get a usb device listed and detected as /dev/sdb when plugging it in at runtime. At startup linux does NOT detect it. For the windows guest, I get a usb device listed and detected as "removable media" when plugging it in at runtime. At startup Windows does detect "something" that is listed in the device manager as Generic Mass Storage device, but with a yellow exclamation mark and there is no removable media listed in Explorer If you need further testings, just let me know. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/924943/+subscriptions
[Qemu-devel] [Bug 924943] Re: usb-host devices given by command line are routed incomplete to the guest
update: Seems to affect only USB 2.0 devices and if USB 2.0 (EHCI) is enabled. If there is only -usb -device usb-host added, it works for both USB 2.0 and USB 1.1 but extremely slow due to the missing USB 2.0 layer If the command line is given as reported above, it works for USB 1.1 devices, too! USB 2.0 devices show the problems as reported. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/924943 Title: usb-host devices given by command line are routed incomplete to the guest Status in QEMU: New Bug description: affected qemus: qemu-1.0, qemu-kvm-1.0, qemu and qemu-kvm master branches (older versions not tested) affected guests: linux, windows test hardware: standard usb key (or any other piece of USB hardware) that works perfectly when plugged in after guest bootup Several Sequences have been tested: - start qemu with -readconfig /etc/ich9-ehci-uhci.cfg -device usb-tablet -device usb-host,bus=ehci.0 - start qemu with -readconfig /etc/ich9-ehci-uhci.cfg -device usb-tablet -S (to not start up the guest directly) + at the console prompt: "device_add usb-host" then "c" to start the guest. For the linux guest, I get a usb device listed and detected as /dev/sdb when plugging it in at runtime. At startup linux does NOT detect it. For the windows guest, I get a usb device listed and detected as "removable media" when plugging it in at runtime. At startup Windows does detect "something" that is listed in the device manager as Generic Mass Storage device, but with a yellow exclamation mark and there is no removable media listed in Explorer If you need further testings, just let me know. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/924943/+subscriptions
[Qemu-devel] Windows Guest .inf File for -std vga?
Hi all, is there a .inf file that makes a Windows XP guest no longer complaining about the missing drivers for the qemu host option -vga std? I tried several manual Windows .inf file copies / merges, but either the exclamation mark in the Device Manager persisted or it falls back to 640x480 4 bit :-( Thanks! Best regards, Erik
Re: [Qemu-devel] Build failure in test-coroutine.c
On February 6, 2012 at 9:29 AM Stefan Hajnoczi wrote: > On Thu, Jan 19, 2012 at 08:06:30PM +0100, Erik Rull wrote: > > test-coroutine.c:92: warning: implicit declaration of function > > 'g_assert_cmpint' > ... > > erik@debian:~/qemu-test/qemu-kvm$ > > This must be an old Debian box. Debian stable has a new enough glib > that provides g_assert_cmpint(). > > The glib testing infrastructure requires glib 2.16 or later. It's > trivial to write a replacement g_assert_cmpint() for old systems but > unfortunately you're also missing the core testing framework > (g_test_run() and friends) so it's not that easy to backport. > > Which version of distro version are you using? Which glib version are > you using? > > Stefan > Hi Stefan, it is Debian 4.0 glib 2.0 Can you add a ./configure option to just remove the compilation of the test infrastructure? I don't need it. Currently I just modify my configure script... Best regards, Erik P.S. I'm planning to upgrade to a "more recent" version during this year...
Re: [Qemu-devel] [MASCOT CONTEST] Alex Bradbury #1
Anthony Liguori wrote: Please respond to this note with an '+1', or an Ack, to vote for this icon. +1
Re: [Qemu-devel] [MASCOT CONTEST] Clare Liguori #1
Anthony Liguori wrote: Please respond to this note with an '+1', or an Ack, to vote for this icon. +1
Re: [Qemu-devel] usb_packet_complete: Assertion ... failed
Jan Kiszka wrote: Hi Gerd, I'm getting qemu/hw/usb/core.c:410: usb_packet_complete: Assertion `((&ep->queue)->tqh_first) == p' failed. with a passed-through USB headset (UHCI controller). This was with current QEMU git head. Known issues? Anything I can do to debug it? Jan Hi all, I get this with another USB 1.1 hardware (running via UHCI) as well. Some weeks ago it was fine. @Jan: If you go back some weeks, this should work (begin of April was definitvely ok). How long does it take to get the headset fully detected in your guest so that you can use the hardware? My USB 1.1 HW takes ~ 60 seconds to work, after that everything is fine - during that I see several USB resets on the host (dmesg). Best regards, Erik
[Qemu-devel] USB passthrough filters - how to deny passing certain devices?
Hi all, is there a way to deny passing certain devices to the guest? I want to deny two devices to get assigned to the guest, all others on all ports are allowed, ony two each with a defined pid/vid should not get routed. Providing a positive list would exceed the max. command line parameter length and will never be complete :-) Best regards, Erik
Re: [Qemu-devel] USB passthrough filters - how to deny passing certain devices?
Hans de Goede wrote: Hi, On 06/25/2012 06:17 PM, Erik Rull wrote: Hi all, is there a way to deny passing certain devices to the guest? I want to deny two devices to get assigned to the guest, all others on all ports are allowed, ony two each with a defined pid/vid should not get routed. Providing a positive list would exceed the max. command line parameter length and will never be complete :-) Are you talking about network usb redirection (-device usb-redir), or host redirection (-device usb-host) here? Regards, Hans Hi Hans, I'm talking about the host redirection via -device usb-host - sorry for the confusion. Best regards, Erik
Re: [Qemu-devel] usb_packet_complete: Assertion ... failed
Jan Kiszka wrote: On 2012-06-23 11:29, Erik Rull wrote: Jan Kiszka wrote: Hi Gerd, I'm getting qemu/hw/usb/core.c:410: usb_packet_complete: Assertion `((&ep->queue)->tqh_first) == p' failed. with a passed-through USB headset (UHCI controller). This was with current QEMU git head. Known issues? Anything I can do to debug it? Jan Hi all, I get this with another USB 1.1 hardware (running via UHCI) as well. Some weeks ago it was fine. @Jan: If you go back some weeks, this should work (begin of April was definitvely ok). Interesting, will try to bisect if it's a regression. Don't have the hardware here, will try next week. How long does it take to get the headset fully detected in your guest so that you can use the hardware? My USB 1.1 HW takes ~ 60 seconds to work, after that everything is fine - during that I see several USB resets on the host (dmesg). I don't see other problems so far. The device is quickly recognized and appears to work fine otherwise. But as the assert hit frequently, I was not able to test in details. Thanks, Jan Hi Jan, did you do the bisect already? If you have the culprit, I would try the version on my side as well if it fails, too. Best regards, Erik
Re: [Qemu-devel] [PATCH] usb: selective endpoint initialization
Gerd Hoffmann wrote: Add support for (re-)initializing endpoints which belong to a specific interface only. Use this in usb-host when changing altsetting for an interface, so other interfaces are not disturbed. Hi Gerd, I tested it on my AMD test system where the issue didn't appear with the same USB hardware (also before this patch!) - so the final test on my Intel test system is pending until next week where it happened. Best regards, Erik
Re: [Qemu-devel] [PATCH] usb: selective endpoint initialization
Erik Rull wrote: Gerd Hoffmann wrote: Add support for (re-)initializing endpoints which belong to a specific interface only. Use this in usb-host when changing altsetting for an interface, so other interfaces are not disturbed. Hi Gerd, I tested it on my AMD test system where the issue didn't appear with the same USB hardware (also before this patch!) - so the final test on my Intel test system is pending until next week where it happened. Best regards, Erik Hi Gerd, sorry for the delays, I tested the latest pulled patch queue and it's now fine on my Intel board, too. The dongle gets detected again without assertions. Thanks for your work. Still remaining are the multiple usb resets on host side before the dongle gets finally detected / usable on the guest. Best regards, Erik
[Qemu-devel] Graphics performance
Hi all, which is the graphics emulation with the lowest CPU usage for 2D-only GUIs? (e.g. Win XP without Direct3D usage)? I just need to drive a virtual graphics display with 1024x768 (@16bit colors). At the moment I use the cirrus graphics card emulation. Is there something more efficient? Terminal/Console is either a real display or VNC - maybe for the two versions different adaptors bring the best performance for each of them? Thanks. Best regards, Erik
Re: [Qemu-devel] [PATCH 6/6] usb-tablet: Allow connecting to ehci
Hi Gerd, hi Hans, is my assumption correct that if I check out and compile this version from GIT master that the usb-tablet device is automatically routed to ehci without changing anything else in the qemu call arguments? (And the performance enhancement takes place automatically) If not - what has to be changed to get it working? Best regards, Erik Gerd Hoffmann wrote: From: Hans de Goede Our ehci code has is capable of significantly lowering the wakeup rate for the hcd emulation while the device is idle. It is possible to add similar code ot the uhci emulation, but that simply is not there atm, and there is no reason why a (virtual) usb-tablet can not be a USB-2 device. Making usb-hid devices connect to the emulated ehci controller instead of the emulated uhci controller on vms which have both lowers the cpuload for a fully idle vm from 20% to 2-3% (on my laptop). An alternative implementation to using a property to select the tablet type, would be simply making it a new device type, ie usb-tablet2, but the downside of that is that this will require libvirt changes to be available through libvirt at all, and then management tools changes to become the default for new vms, where as using a property will automatically get any pc-1.3 type vms the lower cpuload. [ kraxel: adapt compat property for post-1.3 merge ] Signed-off-by: Hans de Goede Signed-off-by: Gerd Hoffmann tablet compat fixup Signed-off-by: Gerd Hoffmann
Re: [Qemu-devel] Graphics performance
Hi, thanks for your quick reply. Dunrong Huang wrote: On Wed, Dec 26, 2012 at 8:04 PM, Erik Rull wrote: Hi all, which is the graphics emulation with the lowest CPU usage for 2D-only GUIs? (e.g. Win XP without Direct3D usage)? I just need to drive a virtual graphics display with 1024x768 (@16bit colors). At the moment I use the cirrus graphics card emulation. Is there something more efficient? Terminal/Console is either a real display or VNC - maybe for the two versions different adaptors bring the best performance for each of them? you shoud try spice. spice depends on qxl video card which is a paravirtual graphics card. It means you must install qxl driver in your guest to make this card work. More details, please refer: http://www.linux-kvm.org/page/SPICE Hi just had a look at this page - but it looks as if I cannot use this for a real hardware display: "" Client To connect to a virtual machine using SPICE, you need a client application. "" Is a hardware monitor capable to display the QXL format? And for my remote clients - can I still use VNC? A change in the guest would be okay, but I still must be able to use the existing client environment... Best regards, Erik
[Qemu-devel] pixman dependency - compile issue
Hi all, with the current git master and the git submodule pixman, I get the following errors when trying to "make": erik@debian:~/qemu-test/qemu-now/qemu$ make GEN x86_64-softmmu/config-devices.mak GEN config-all-devices.mak GEN config-host.h (cd /home/erik/qemu-test/qemu-now/qemu/pixman; autoreconf -v --install) autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal configure.ac:61: warning: AC_INIT: not a literal: "pix...@lists.freedesktop.org" autoreconf: configure.ac: tracing configure.ac:61: warning: AC_INIT: not a literal: "pix...@lists.freedesktop.org" autoreconf: configure.ac: not using Libtool autoreconf: running: /usr/bin/autoconf configure.ac:61: warning: AC_INIT: not a literal: "pix...@lists.freedesktop.org" configure.ac:75: error: possibly undefined macro: AC_PROG_LIBTOOL If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf: /usr/bin/autoconf failed with exit status: 1 make: *** [/home/erik/qemu-test/qemu-now/qemu/pixman/configure] Error 1 make: *** Deleting file `/home/erik/qemu-test/qemu-now/qemu/pixman/configure' My host / compiling system is Debian 6, git clone was just done an hour before this message. The submodule was added as proposed: git submodule update --init pixman Maybe I missed something simple and stupid... Compiling without pixman is not possible due to the required x86_64-softmmu target. Did you additionally assert that the pixman module works on old CentOS 9 systems / Debian 4? Some months ago there were new dependencies added to qemu that were reverted / redesigned afterwards due to bigger problems on these distros. Best regards, Erik
Re: [Qemu-devel] pixman dependency - compile issue
Libtool was missing, works now :-) Erik Rull wrote: Hi all, with the current git master and the git submodule pixman, I get the following errors when trying to "make": erik@debian:~/qemu-test/qemu-now/qemu$ make GEN x86_64-softmmu/config-devices.mak GEN config-all-devices.mak GEN config-host.h (cd /home/erik/qemu-test/qemu-now/qemu/pixman; autoreconf -v --install) autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal configure.ac:61: warning: AC_INIT: not a literal: "pix...@lists.freedesktop.org" autoreconf: configure.ac: tracing configure.ac:61: warning: AC_INIT: not a literal: "pix...@lists.freedesktop.org" autoreconf: configure.ac: not using Libtool autoreconf: running: /usr/bin/autoconf configure.ac:61: warning: AC_INIT: not a literal: "pix...@lists.freedesktop.org" configure.ac:75: error: possibly undefined macro: AC_PROG_LIBTOOL If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf: /usr/bin/autoconf failed with exit status: 1 make: *** [/home/erik/qemu-test/qemu-now/qemu/pixman/configure] Error 1 make: *** Deleting file `/home/erik/qemu-test/qemu-now/qemu/pixman/configure' My host / compiling system is Debian 6, git clone was just done an hour before this message. The submodule was added as proposed: git submodule update --init pixman Maybe I missed something simple and stupid... Compiling without pixman is not possible due to the required x86_64-softmmu target. Did you additionally assert that the pixman module works on old CentOS 9 systems / Debian 4? Some months ago there were new dependencies added to qemu that were reverted / redesigned afterwards due to bigger problems on these distros. Best regards, Erik
Re: [Qemu-devel] [PATCH 6/6] usb-tablet: Allow connecting to ehci
Hi Hans, Hans de Goede wrote: Hi, On 12/26/2012 01:07 PM, Erik Rull wrote: Hi Gerd, hi Hans, is my assumption correct that if I check out and compile this version from GIT master that the usb-tablet device is automatically routed to ehci without changing anything else in the qemu call arguments? (And the performance enhancement takes place automatically) If not - what has to be changed to get it working? That depends, if you specify a machine model, you need to change it to pc-1.4, if you don't specify a machine model you will get the change automatically, as 1.4 is the new default machine model. Regards, Hans Thanks. QEMU shows version 1.3.50 at the moment (from git), is the 1.4 model internally already active there? Best regards, Erik
[Qemu-devel] Same Display contents on different outputs?
Hi all, is it meanwhile possible to get the same screen output on a screen and on VNC? I would like to offer a "direct" terminal (with a real screen and keyboard) for user interaction and a VNC remote terminal e.g. for service access. Is it possible to configure it so that the guest sees only one video and input hardware but qemu exposes two display / input possibilities? Thanks. Best regards, Erik
[Qemu-devel] [Bug?] qemu-1.6.0 python traceback in GEN qmp-commands.h
Hi all, when using the released qemu-1.6.0.tar.bz2, I get the following error message: [...] ar: creating libfdt/libfdt.a a - libfdt/fdt.o a - libfdt/fdt_ro.o a - libfdt/fdt_wip.o a - libfdt/fdt_sw.o a - libfdt/fdt_rw.o a - libfdt/fdt_strerror.o GEN qemu-options.def GEN qmp-commands.h Traceback (most recent call last): File "/home/erik/qemu-1.6.0/scripts/qapi-commands.py", line 14, in from qapi import * File "/home/erik/qemu-1.6.0/scripts/qapi.py", line 164 except QAPISchemaError as e: ^ SyntaxError: invalid syntax make: *** [qmp-commands.h] Error 1 Any ideas how to fix that? Thanks. Best regards, Erik
Re: [Qemu-devel] [Bug?] qemu-1.6.0 python traceback in GEN qmp-commands.h
Luiz Capitulino wrote: On Fri, 16 Aug 2013 14:21:50 +0100 Peter Maydell wrote: On 16 August 2013 08:59, Erik Rull wrote: Hi all, when using the released qemu-1.6.0.tar.bz2, I get the following error message: File "/home/erik/qemu-1.6.0/scripts/qapi.py", line 164 except QAPISchemaError as e: ^ SyntaxError: invalid syntax make: *** [qmp-commands.h] Error 1 My guess is that your python is older than 2.6; I think the "except Foo as e" syntax is new in 2.6. We probably missed this because most people use a newer Python than 2.6, but configure's check only requires 2.4 or better. We should probably update the scripts to not use overly new features (or alternatively decide that 2.6 is our new minimum -- what do RHEL5 and our other oldest-supported distros ship?) For this specific case I think it needs to change to except QAPISchemaError, e: Erik, can you try that and post a patch? Would be interesting to know if this is the only problem with older python. Yes, I will try that. I never really tried to send patches to this list... My python version is 2.4 - as it was assumed already. Best regards, Erik
Re: [Qemu-devel] VNC key presses not correct
Hi Markus, I would like to try it - see the python-traceback thread - when qemu compiles, I will definitively try it with the 1.6.0. Best regards, Erik Markus Armbruster wrote: Erik Rull writes: Hi all, I'm struggling with the QEMU VNC on qemu-kvm-1.2.0 a bit, the following two things are not working properly: Have you tried to reproduce on a current version?
Re: [Qemu-devel] [Bug?] qemu-1.6.0 python traceback in GEN qmp-commands.h
> On August 19, 2013 at 6:15 PM Erik Rull wrote: > > > Luiz Capitulino wrote: > > On Fri, 16 Aug 2013 14:21:50 +0100 > > Peter Maydell wrote: > > > >> On 16 August 2013 08:59, Erik Rull wrote: > >>> Hi all, > >>> > >>> when using the released qemu-1.6.0.tar.bz2, I get the following error > >>> message: > >>> File "/home/erik/qemu-1.6.0/scripts/qapi.py", line 164 > >>> except QAPISchemaError as e: > >>> ^ > >>> SyntaxError: invalid syntax > >>> make: *** [qmp-commands.h] Error 1 > >> > >> My guess is that your python is older than 2.6; I think > >> the "except Foo as e" syntax is new in 2.6. We probably > >> missed this because most people use a newer Python than > >> 2.6, but configure's check only requires 2.4 or better. > >> > >> We should probably update the scripts to not use overly > >> new features (or alternatively decide that 2.6 is our new > >> minimum -- what do RHEL5 and our other oldest-supported > >> distros ship?) > >> > >> For this specific case I think it needs to change to > >> except QAPISchemaError, e: > > > > Erik, can you try that and post a patch? Would be interesting > > to know if this is the only problem with older python. > > > > Yes, I will try that. I never really tried to send patches to this list... > My python version is 2.4 - as it was assumed already. > > Best regards, > > Erik This "fixes" it - it compiles successfully, but my guest no longer boots up completely! Windows XP gets a bluescreen and reboots in an infinite loop. Strange is: I was requested to put some "efi*" files now on my target system for handling the network cards (qemu complains at startup via stderr when I don't have them available on my target system). But why? Where can I select to use the "pxe*" files? There seems to be no possibility to select them via ./configure or as qemu command line option. Maybe this is related to the bluescreen? 1.2.0 was working properly. Best regards, Erik
Re: [Qemu-devel] VNC key presses not correct
Markus Armbruster wrote: Erik Rull writes: Hi all, I'm struggling with the QEMU VNC on qemu-kvm-1.2.0 a bit, the following two things are not working properly: Have you tried to reproduce on a current version? Hello Markus, yes, I was able to reproduce this with the released qemu-1.6.0 from the qemu-wiki website. Character mistakes are the same when opening a Notepad on Windows XP on the guest. Maybe nobody cares because english is the layout used nearly everywhere :-) And it is not related to the host operating system, I used a Debian 6.0 and a self built linux - both with the same effect. And it is not related to the VNC client, I tried several clients on several operating systems, all with the same result. Do you see this effect with a non-english input layout on your side, too? When using SDL/direct input everything is great. Best regards, Erik
Re: [Qemu-devel] VNC key presses not correct
Markus Armbruster wrote: Erik Rull writes: Markus Armbruster wrote: Erik Rull writes: Hi all, I'm struggling with the QEMU VNC on qemu-kvm-1.2.0 a bit, the following two things are not working properly: Have you tried to reproduce on a current version? Hello Markus, yes, I was able to reproduce this with the released qemu-1.6.0 from the qemu-wiki website. Character mistakes are the same when opening a Notepad on Windows XP on the guest. Thanks! Maybe nobody cares because english is the layout used nearly everywhere :-) I nobody cared, we wouldn't ship it :) Cc'ing Gerd, who knows more about VNC than I do. And it is not related to the host operating system, I used a Debian 6.0 and a self built linux - both with the same effect. And it is not related to the VNC client, I tried several clients on several operating systems, all with the same result. Do you see this effect with a non-english input layout on your side, too? When using SDL/direct input everything is great. Your initial report has details on some keypresses. Please also tell us your complete QEMU command line, and your complete VNC client command line(s). Sure, here it is: ./qemu-system-x86_64 -drive file=../../../qemu-img/windows.img,cache=off -readconfig ../docs/ich9-ehci-uhci.cfg -device usb-tablet,bus=ehci.0 -boot c -no-acpi -monitor telnet::5100,server,nowait -vnc :1 -m 1024 --enable-kvm -cpu host Client is e.g. Ultra VNC 32 bit under Windows XP V 1.0.8.0 => Just enter the IP::Port and connect. Or RealVNC in the same way. Client OS has german keyboard and german keyboard layout - on the QEMU guest side it doesn't matter which input language is set. Guest is Windows XP SP3 32 bit. Best regards, Erik
Re: [Qemu-devel] VNC key presses not correct
> On August 23, 2013 at 7:42 AM Markus Armbruster wrote: > > > Anthony Liguori writes: > > > On Aug 22, 2013 4:55 PM, "Erik Rull" wrote: > >> > >> Markus Armbruster wrote: > >>> > >>> Erik Rull writes: > >>> > >>>> Markus Armbruster wrote: > >>>>> > >>>>> Erik Rull writes: > >>>>> > >>>>>> Hi all, > >>>>>> > >>>>>> I'm struggling with the QEMU VNC on qemu-kvm-1.2.0 a bit, the following > >>>>>> two > >>>>>> things are not working properly: > >>>>> > >>>>> > >>>>> Have you tried to reproduce on a current version? > >>>>> > >>>> > >>>> Hello Markus, > >>>> > >>>> yes, I was able to reproduce this with the released qemu-1.6.0 from > >>>> the qemu-wiki website. Character mistakes are the same when opening a > >>>> Notepad on Windows XP on the guest. > >>> > >>> > >>> Thanks! > >>> > >>>> Maybe nobody cares because english is the layout used nearly everywhere > >>>> :-) > >>> > >>> > >>> I nobody cared, we wouldn't ship it :) > >>> > >>> Cc'ing Gerd, who knows more about VNC than I do. > >>> > >>>> And it is not related to the host operating system, I used a Debian > >>>> 6.0 and a self built linux - both with the same effect. > >>>> And it is not related to the VNC client, I tried several clients on > >>>> several operating systems, all with the same result. > >>>> > >>>> Do you see this effect with a non-english input layout on your side, too? > >>>> When using SDL/direct input everything is great. > >>> > >>> > >>> Your initial report has details on some keypresses. Please also tell us > >>> your complete QEMU command line, and your complete VNC client command > >>> line(s). > >>> > >> > >> Sure, here it is: > >> ./qemu-system-x86_64 -drive file=../../../qemu-img/windows.img,cache=off > > -readconfig ../docs/ich9-ehci-uhci.cfg -device usb-tablet,bus=ehci.0 -boot > > c -no-acpi -monitor telnet::5100,server,nowait -vnc :1 -m 1024 --enable-kvm > > -cpu host > > > > You need to specify a keymap with -k > > Yes, because... > > >> Client is e.g. Ultra VNC 32 bit under Windows XP V 1.0.8.0 => Just enter > > the IP::Port and connect. Or RealVNC in the same way. > >> Client OS has german keyboard and german keyboard layout - on the QEMU > > guest side it doesn't matter which input language is set. > >> Guest is Windows XP SP3 32 bit. > > ... you use a VNC client that doesn't understand the extended key event > extension. The extension enables 100% faithful key interpretation, -k > can only approximate it. > > https://www.berrange.com/posts/2010/07/04/more-than-you-or-i-ever-wanted-to-know-about-virtual-keyboard-handling/ > Thanks, that's it! Updated to the latest VNC client version - works (btw. TigerVNC crashes when sending Ctrl+Alt+Del). One thing has to be done due to the default english keyboard layout: switch the input language on the client side to english - then all keypresses are interpreted correctly. This is acceptable due to the multilanguage user group of the guest and less effort than rebooting the guest when a user with a different keyboard layout logs in :-) Best regards, Erik
[Qemu-devel] Boot Problems Windows XP guest
Hi all, is it possible to get back to the "legacy" BIOS instead of the (u)efi based BIOS? I have problems booting the guest on a SSD HDD, there it reboots infinitely, when running the guest on a rotating HDD, it works. On qemu 1.2.0 both disks work properly. I didn't find a way to select the BIOS type in QEMU. Best regards, Erik
Re: [Qemu-devel] Boot Problems Windows XP guest
Stefan Hajnoczi wrote: On Mon, Aug 26, 2013 at 11:52:26AM +0200, Erik Rull wrote: is it possible to get back to the "legacy" BIOS instead of the (u)efi based BIOS? I have problems booting the guest on a SSD HDD, there it reboots infinitely, when running the guest on a rotating HDD, it works. On qemu 1.2.0 both disks work properly. I didn't find a way to select the BIOS type in QEMU. You can specify the BIOS blob to use with the -bios option. Not sure about the issue you are describing. SeaBIOS is a BIOS, not UEFI. Stefan Hi Stefan, which BIOS is selected by default? It's more a guess, there must be a change between 1.2.0 and 1.6.0 that prevents a simple Windows XP from booting completely, if the guest HDD image is placed on a SSD. On a rotating HDD (with the same commandline except the path to the image) it boots successfully. The only difference is the speed of the disk access. I will try an alternative BIOS, maybe this fixes it, if not I will try to do some regression tests, first trying 1.4.0. Best regards, Erik
Re: [Qemu-devel] Boot Problems Windows XP guest
> On August 27, 2013 at 11:37 PM Anthony Liguori wrote: > > > On Aug 27, 2013 4:32 PM, "Paolo Bonzini" wrote: > > > > Il 27/08/2013 22:26, Erik Rull ha scritto: > > > Hi Stefan, > > > > > > which BIOS is selected by default? > > > > QEMU only ships with SeaBIOS. > > > > > It's more a guess, there must be a > > > change between 1.2.0 and 1.6.0 that prevents a simple Windows XP from > > > booting completely, if the guest HDD image is placed on a SSD. On a > > > rotating HDD (with the same commandline except the path to the image) it > > > boots successfully. The only difference is the speed of the disk access. > > > > It could be a real difference, actually. An unexpectedly fast disk > > might screw a sloppy driver. IIRC you're not the first person reporting > > it. Stefan, do you think using block throttling could fix it (with some > > trial and error)? > > > Add cache=writethrough and I bet it'll work even on an SSD. > > > We changed the default in that timeframe. The Windows IDE drivers can have > an issue if the IRQ comes too quickly to indicate the request has > completed. This is what -win2k-hack is for. That may also work here too. > > > Regards, > > > Anthony Liguori > > > > > > I will try an alternative BIOS, maybe this fixes it, if not I will try > > > to do some regression tests, first trying 1.4.0. > > > > This could help. > > > > Paolo > > > > Hi all, thanks for the input. I tested both cache=writethrough and -win2k-hack but it didn't help. But I was able to capture a screenshot from the Windows XP bluescreen, it shows only a kind of disk access problem, but this could still be related to the "speed" of the disk access (see cropped screen attached). Even with disabled kvm it does not work, it just takes longer until it reboots. Any further ideas? Are we now too quick for XP? Best regards, Erik<>
Re: [Qemu-devel] Boot Problems Windows XP guest
> On August 28, 2013 at 9:50 AM Stefan Hajnoczi wrote: > > > On Tue, Aug 27, 2013 at 11:31:28PM +0200, Paolo Bonzini wrote: > > Il 27/08/2013 22:26, Erik Rull ha scritto: > > > It's more a guess, there must be a > > > change between 1.2.0 and 1.6.0 that prevents a simple Windows XP from > > > booting completely, if the guest HDD image is placed on a SSD. On a > > > rotating HDD (with the same commandline except the path to the image) it > > > boots successfully. The only difference is the speed of the disk access. > > > > It could be a real difference, actually. An unexpectedly fast disk > > might screw a sloppy driver. IIRC you're not the first person reporting > > it. Stefan, do you think using block throttling could fix it (with some > > trial and error)? > > That might work. You could start with something like -drive ...,iops=20 > and then disable the limit from the QEMU monitor once the guest OS is > booting (block_set_io_throttle virtio0 0 0 0 0 0 0). > > It would be easier to try -drive ...,cache=writethrough and -win2k-hack > first as Anthony suggests. > > Stefan > Thanks. I tried that, but when should I reset the throttle? When I reset it some seconds after the BIOS screen disappeared same result as without throttling. When I keep it, Windows still reboots, the cycle just takes longer (half an hour), but the progress seems to be the same as without throttle. Btw.: my disks are not virtio0, but ide-hd0 and ide-hd1 (yes, I set the throttle on both!) To exclude a damage of the image meanwhile, I went back to 1.2.0 and it boots perfectly. Best regards, Erik
Re: [Qemu-devel] Boot Problems Windows XP guest
Benoît Canet wrote: Can you whip up a patch to avoid that? Or to honor bps_max if it is specified (making avg/10 simply the default)? Pushed in the same branch (it honor bps_max if specified). Best regards Benoît Hi all, thanks for your help. I cloned the git and compiled it - but I'm not completely sure how to enable the throttling finally - there were several mails regarding averages and max values... And the "unit" of the values would be interesting. Merci beaucoup. Best regards, Erik
Re: [Qemu-devel] Boot Problems Windows XP guest
Benoît Canet wrote: thanks for your help. I cloned the git and compiled it - but I'm not completely sure how to enable the throttling finally - there were several mails regarding averages and max values... And the "unit" of the values would be interesting. Hi Erik, The main settings are bps, bps_rd and bps_wr for total, read and write bandwith throttling (unit is bytes) and iops, iops_rd, iops_wr for IO per second throttling (unit is IO operation). You should specify your settings on the -drive command line like in: -drive file=foo.raw,if=virtio,cache=none,bps=1048576 for a 1 MB total bandwith. In addition to that there is another set of parameters to configure the burst ability of the throttling. These setting are: bps_max, bps_rd_max, bps_wr_max, iops_mx, iops_rd_max, and iops_wr_max. Some bursting is enabled by default. From what Paolo said you should set bps_max = 1 to specify that the default bursting is not set. So: -drive file=foo.raw,if=virtio,cache=none,bps=1048576,bps_max=1 for a 1 MB total bandwith with almost no burst. Best regards Benoît ps: take care of updating your repository and recompiling it since I made some changes for you to use. (use git fetch origin) Great thanks! I cloned half an hour before your email, and updated right now, but there was only an "already up to date"... (git fetch origin didn't say anything git pull says Already up-to-date.) I will test it tomorrow and let you know my results. Best regards, Erik
Re: [Qemu-devel] Boot Problems Windows XP guest
> On August 28, 2013 at 9:22 PM Erik Rull wrote: > > > Benoît Canet wrote: > >> thanks for your help. I cloned the git and compiled it - but I'm not > >> completely sure how to enable the throttling finally - there were > >> several mails regarding averages and max values... And the "unit" of > >> the values would be interesting. > > > > Hi Erik, > > > > The main settings are bps, bps_rd and bps_wr for total, read and write > > bandwith > > throttling (unit is bytes) and iops, iops_rd, iops_wr for IO per second > > throttling (unit is IO operation). > > > > You should specify your settings on the -drive command line like in: > > -drive file=foo.raw,if=virtio,cache=none,bps=1048576 for a 1 MB total > > bandwith. > > > > In addition to that there is another set of parameters to configure the > > burst > > ability of the throttling. > > These setting are: bps_max, bps_rd_max, bps_wr_max, iops_mx, iops_rd_max, > > and > > iops_wr_max. > > > > Some bursting is enabled by default. > > > > From what Paolo said you should set bps_max = 1 to specify that the default > > bursting is not set. > > > > So: > > -drive file=foo.raw,if=virtio,cache=none,bps=1048576,bps_max=1 for a 1 MB > > total > > bandwith with almost no burst. > > > > Best regards > > > > Benoît > > > > ps: take care of updating your repository and recompiling it since I made > > some > > changes for you to use. (use git fetch origin) > > > > Great thanks! I cloned half an hour before your email, and updated right > now, but there was only an "already up to date"... (git fetch origin didn't > say anything git pull says Already up-to-date.) > > I will test it tomorrow and let you know my results. > > Best regards, > > Erik Hi all, it still fails :-( My commandline section is (I played with bps between 0.5 and 2.0 MB/sec and iops with 1000 and 500): -drive file=/dev/sda2,cache=none,bps=548576,bps_max=1,iops_max=1000 Within qemu it looks like that: QEMU 1.6.50 monitor - type 'help' for more information (qemu) info block ide0-hd0: /dev/sda2 (raw) I/O throttling: bps=548576 bps_rd=0 bps_wr=0 bps_max=1 bps_rd_max=0 bps_wr_max=0 iops=0 iops_rd=0 iops_wr=0 iops_max=1000 iops_rd_max=0 iops_wr_max=0 iops_size=0 (qemu) Any further ideas? Thanks. Best regards, Erik
Re: [Qemu-devel] Boot Problems Windows XP guest
> On August 29, 2013 at 11:25 AM Benoît Canet wrote: > > > > My commandline section is (I played with bps between 0.5 and 2.0 MB/sec and > > iops > > with 1000 and 500): > > -drive file=/dev/sda2,cache=none,bps=548576,bps_max=1,iops_max=1000 > > Within qemu it looks like that: > > QEMU 1.6.50 monitor - type 'help' for more information > > (qemu) info block > > ide0-hd0: /dev/sda2 (raw) > > I/O throttling: bps=548576 bps_rd=0 bps_wr=0 bps_max=1 bps_rd_max=0 > > bps_wr_max=0 iops=0 iops_rd=0 iops_wr=0 iops_max=1000 iops_rd_max=0 > > iops_wr_max=0 iops_size=0 > > (qemu) > > Why did you set iops_max but not iops ? > > Best regards > > Benoît > Good point, I added that, but it still keeps rebooting: (qemu) info block ide0-hd0: /dev/sda2 (raw) I/O throttling: bps=548576 bps_rd=0 bps_wr=0 bps_max=1 bps_rd_max=0 bps_wr_max=0 iops=500 iops_rd=0 iops_wr=0 iops_max=500 iops_rd_max=0 iops_wr_max=0 iops_size=0 Best regards, Erik
Re: [Qemu-devel] Boot Problems Windows XP guest
> On August 29, 2013 at 4:55 PM Paolo Bonzini wrote: > > > Il 29/08/2013 16:51, Erik Rull ha scritto: > > > > > >> On August 29, 2013 at 11:25 AM Benoît Canet > >> wrote: > >> > >> > >>> My commandline section is (I played with bps between 0.5 and 2.0 MB/sec > >>> and > >>> iops > >>> with 1000 and 500): > >>> -drive file=/dev/sda2,cache=none,bps=548576,bps_max=1,iops_max=1000 > >>> Within qemu it looks like that: > >>> QEMU 1.6.50 monitor - type 'help' for more information > >>> (qemu) info block > >>> ide0-hd0: /dev/sda2 (raw) > >>> I/O throttling: bps=548576 bps_rd=0 bps_wr=0 bps_max=1 bps_rd_max=0 > >>> bps_wr_max=0 iops=0 iops_rd=0 iops_wr=0 iops_max=1000 iops_rd_max=0 > >>> iops_wr_max=0 iops_size=0 > >>> (qemu) > >> > >> Why did you set iops_max but not iops ? > >> > >> Best regards > >> > >> Benoît > >> > > > > Good point, I added that, but it still keeps rebooting: > > (qemu) info block > > ide0-hd0: /dev/sda2 (raw) > > I/O throttling: bps=548576 bps_rd=0 bps_wr=0 bps_max=1 bps_rd_max=0 > > bps_wr_max=0 iops=500 iops_rd=0 iops_wr=0 iops_max=500 iops_rd_max=0 > > iops_wr_max=0 iops_size=0 > > Too bad. > > But iops_max w/o iops makes sense: it means no more than 1000 iops will > be in flight at the same time. Note that "s" is a plural in "*s_max", > not "per seconds". :) > > You could try iops_max=1 and make it higher if it works. > > Paolo > My SSD died - I took another one, cloned again from the spinning disk - works *douh* - without any throttling! If I run again in this situation, the real hardware might be the culprit. Sorry for the time this issue took. But I will try to make some deeper investigation on this issue - because it worked with 1.2.0 and 1.6.50 failed... Best regards, Erik
[Qemu-devel] VNC key presses not correct
Hi all,
I'm struggling with the QEMU VNC on qemu-kvm-1.2.0 a bit, the following two
things are not working properly:
1) Shift key pressed and hold for several seconds causes multiple shift key
press + release events => I would expect getting one press, one or more hold and
one release event (minor issue)
2) German Umlaute and german keyboard layouts are not interpreted properly. I
added some debug output into:
static void do_key_event(VncState *vs, int down, int keycode, int sym)
{
printf("do_key_event1: %d %d %d\n",down,keycode,sym);
and:
void kbd_put_keycode(int keycode)
{
if (!runstate_is_running() && !runstate_check(RUN_STATE_SUSPENDED)) {
return;
}
if (qemu_put_kbd_event) {
printf("kbd_put_keycode: %d\n",keycode);
qemu_put_kbd_event(qemu_put_kbd_event_opaque, keycode);
}
}
This reports to me when e.g. pressing "#" on a german keyboard:
do_key_event1: 1 4 35
kbd_put_keycode: 4
do_key_event1: 0 4 35
kbd_put_keycode: 132
=> This results into a "3" on the guest side...
And when I press the "3" on the german keyboard, I get the following events:
do_key_event1: 1 4 51
kbd_put_keycode: 4
do_key_event1: 0 4 51
kbd_put_keycode: 132
=> result is a "3", too...
And when pressing one of the Umlaute (ä), I get a keymap error:
Warning: no scancode found for keysym 228
do_key_event1: 1 0 228
kbd_put_keycode: 0
Warning: no scancode found for keysym 228
do_key_event1: 0 0 228
kbd_put_keycode: 128
do_key_event7: 0 0 228
=> why is 228 not transported to the guest? this is definitvely the correct sign
- according to the table in vnc_keysym.h ...
{ "adiaeresis", 0x0e4},
I tested it with several VNC clients - all with the same results.
Any hints and ideas how to get it running properly would be great.
When I use the same system directly via SDL and a real hardware keyboard, it
works perfect - without changing anything in the qemu configuration even with
different keyboard layouts (I tested US/International, German, French and Spain
keyboards)
Thanks.
Best regards,
Erik
[Qemu-devel] [Bug 1366836] [NEW] Core2Duo and KVM may not boot Win8 properly on 3.x kernels
Public bug reported: When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel 3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error. When I dump the CPU registers via "info registers", nothing changes, that means the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0. But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 or 2.0.0 on the host side it works on the Core2Duo. Also the system above but just with an i3 or i5 CPU it works fine. I already disabled networking and USB for the guest and changed the graphics card - no effect. I assume that some mean bits and bytes have to be set up properly to get the thing running. Seems to be related to a kvm/processor incompatibility. ** Affects: qemu Importance: Undecided Status: New ** Tags: core2duo kvm ** Description changed: When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel 3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error. When I dump the CPU registers via "info registers", nothing changes, that means the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0. But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 or 2.0.0 on the host side it works on the Core2Duo. Also the system above but just with an i3 or i5 CPU it works fine. I already disabled networking and USB for the guest and changed the graphics card - no effect. I assume that some mean bits and bytes have to be set up properly to get the thing running. - Seems to be related to a kvm/progressor incompatibility. + Seems to be related to a kvm/procressor incompatibility. ** Description changed: When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel 3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error. When I dump the CPU registers via "info registers", nothing changes, that means the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0. But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 or 2.0.0 on the host side it works on the Core2Duo. Also the system above but just with an i3 or i5 CPU it works fine. I already disabled networking and USB for the guest and changed the graphics card - no effect. I assume that some mean bits and bytes have to be set up properly to get the thing running. - Seems to be related to a kvm/procressor incompatibility. + Seems to be related to a kvm/processor incompatibility. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1366836 Title: Core2Duo and KVM may not boot Win8 properly on 3.x kernels Status in QEMU: New Bug description: When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel 3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error. When I dump the CPU registers via "info registers", nothing changes, that means the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0. But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 or 2.0.0 on the host side it works on the Core2Duo. Also the system above but just with an i3 or i5 CPU it works fine. I already disabled networking and USB for the guest and changed the graphics card - no effect. I assume that some mean bits and bytes have to be set up properly to get the thing running. Seems to be related to a kvm/processor incompatibility. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1366836/+subscriptions
[Qemu-devel] [Bug 1366836] Re: Core2Duo and KVM may not boot Win8 properly on 3.x kernels
** Description changed: - When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel - 3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error. - When I dump the CPU registers via "info registers", nothing changes, that means - the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0. + When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel 3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error. + When I dump the CPU registers via "info registers", nothing changes, that means the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0. + It stalls when the Windows logo is displayed and the balled circle starts rotating. - But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 or 2.0.0 on - the host side it works on the Core2Duo. Also the system above but just with an - i3 or i5 CPU it works fine. + But - when I run the very same guest using Kernel 2.6.32.12 and QEMU + 1.7.0 or 2.0.0 on the host side it works on the Core2Duo. Also the + system above but just with an i3 or i5 CPU it works fine. I already disabled networking and USB for the guest and changed the graphics card - no effect. I assume that some mean bits and bytes have to be set up properly to get the thing running. Seems to be related to a kvm/processor incompatibility. + + Windows XP runs on all combinations without any issues. Windows 8.1 + guests have the same issues as Windows 8.0. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1366836 Title: Core2Duo and KVM may not boot Win8 properly on 3.x kernels Status in QEMU: New Bug description: When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel 3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error. When I dump the CPU registers via "info registers", nothing changes, that means the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0. It stalls when the Windows logo is displayed and the balled circle starts rotating. But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 or 2.0.0 on the host side it works on the Core2Duo. Also the system above but just with an i3 or i5 CPU it works fine. I already disabled networking and USB for the guest and changed the graphics card - no effect. I assume that some mean bits and bytes have to be set up properly to get the thing running. Seems to be related to a kvm/processor incompatibility. Windows XP runs on all combinations without any issues. Windows 8.1 guests have the same issues as Windows 8.0. An example command line that does not boot Windows 8 is: qemu-system-x86_64 -machine pc-i440fx-1.5,accel=kvm,kernel_irqchip=off -daemonize -cpu kvm32,+sep,+nx -nodefaults -vga std -readconfig /usr/X11R6/X11etc/ich9-ehci-uhci.cfg -device usb-host,bus=ehci.0,hostport=1.2 -device usb-tablet -drive file=/dev/sdb,cache=writethrough,if=none,id=x -device ide-drive,drive=x -m 1024 -monitor telnet:127.0.0.1:5100,nowait,server -vnc :1 -L /usr/X11R6/share/qemu -boot c -localtime -enable-kvm -no-shutdown enabling the kernel_irqchip, removing the sep, disabling usb, changing the machine type or changing the monitor type (SDL or VNC) has no effect. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1366836/+subscriptions
[Qemu-devel] [Bug 1366836] Re: Core2Duo and KVM may not boot Win8 properly on 3.x kernels
** Description changed: When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel 3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error. When I dump the CPU registers via "info registers", nothing changes, that means the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0. It stalls when the Windows logo is displayed and the balled circle starts rotating. But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 or 2.0.0 on the host side it works on the Core2Duo. Also the system above but just with an i3 or i5 CPU it works fine. I already disabled networking and USB for the guest and changed the graphics card - no effect. I assume that some mean bits and bytes have to be set up properly to get the thing running. Seems to be related to a kvm/processor incompatibility. Windows XP runs on all combinations without any issues. Windows 8.1 guests have the same issues as Windows 8.0. + + An example command line that does not boot Windows 8 is: + qemu-system-x86_64 -machine pc-i440fx-1.5,accel=kvm,kernel_irqchip=off -daemonize -cpu kvm32,+sep,+nx -nodefaults -vga std -readconfig /usr/X11R6/X11etc/ich9-ehci-uhci.cfg -device usb-host,bus=ehci.0,hostport=1.2 -device usb-tablet -drive file=/dev/sdb,cache=writethrough,if=none,id=x -device ide-drive,drive=x -m 1024 -monitor telnet:127.0.0.1:5100,nowait,server -vnc :1 -L /usr/X11R6/share/qemu -boot c -localtime -enable-kvm -no-shutdown + + enabling the kernel_irqchip, removing the sep, disabling usb, changing + the machine type or changing the monitor type (SDL or VNC) has no + effect. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1366836 Title: Core2Duo and KVM may not boot Win8 properly on 3.x kernels Status in QEMU: New Bug description: When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel 3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error. When I dump the CPU registers via "info registers", nothing changes, that means the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0. It stalls when the Windows logo is displayed and the balled circle starts rotating. But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 or 2.0.0 on the host side it works on the Core2Duo. Also the system above but just with an i3 or i5 CPU it works fine. I already disabled networking and USB for the guest and changed the graphics card - no effect. I assume that some mean bits and bytes have to be set up properly to get the thing running. Seems to be related to a kvm/processor incompatibility. Windows XP runs on all combinations without any issues. Windows 8.1 guests have the same issues as Windows 8.0. An example command line that does not boot Windows 8 is: qemu-system-x86_64 -machine pc-i440fx-1.5,accel=kvm,kernel_irqchip=off -daemonize -cpu kvm32,+sep,+nx -nodefaults -vga std -readconfig /usr/X11R6/X11etc/ich9-ehci-uhci.cfg -device usb-host,bus=ehci.0,hostport=1.2 -device usb-tablet -drive file=/dev/sdb,cache=writethrough,if=none,id=x -device ide-drive,drive=x -m 1024 -monitor telnet:127.0.0.1:5100,nowait,server -vnc :1 -L /usr/X11R6/share/qemu -boot c -localtime -enable-kvm -no-shutdown enabling the kernel_irqchip, removing the sep, disabling usb, changing the machine type or changing the monitor type (SDL or VNC) has no effect. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1366836/+subscriptions
[Qemu-devel] [Bug 1366836] Re: Core2Duo and KVM may not boot Win8 properly on 3.x kernels
Here the register dump of the stalled Win8 QEMU 2.1.0 monitor - type 'help' for more information (qemu) info registers EAX=3e2009e3 EBX=3e2009e3 ECX=8000 EDX=8000 ESI=3e2009e3 EDI=8220c108 EBP=81f9b33c ESP=81f9b2f0 EIP=80c98d83 EFL=00010282 [--S] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0023 00c0f300 DPL=3 DS [-WA] CS =0008 00c09b00 DPL=0 CS32 [-RA] SS =0010 00c09300 DPL=0 DS [-WA] DS =0023 00c0f300 DPL=3 DS [-WA] FS =0030 80e65000 4280 00409300 DPL=0 DS [-WA] GS = LDT= TR =0028 80353000 20ab 8b00 DPL=0 TSS32-busy GDT= 80a37000 03ff IDT= 80a37400 07ff CR0=8001003b CR2=8b206090 CR3=00185000 CR4=000406e9 DR0= DR1= DR2=0005 DR3= DR6=0ff0 DR7=0400 EFER=0800 FCW=027f FSW= [ST=0] FTW=00 MXCSR=1f80 FPR0= FPR1= FPR2= FPR3= FPR4= FPR5= FPR6= FPR7= XMM00= XMM01= XMM02= XMM03= XMM04= XMM05= XMM06= XMM07= -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1366836 Title: Core2Duo and KVM may not boot Win8 properly on 3.x kernels Status in QEMU: New Bug description: When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel 3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error. When I dump the CPU registers via "info registers", nothing changes, that means the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0. It stalls when the Windows logo is displayed and the balled circle starts rotating. But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 or 2.0.0 on the host side it works on the Core2Duo. Also the system above but just with an i3 or i5 CPU it works fine. I already disabled networking and USB for the guest and changed the graphics card - no effect. I assume that some mean bits and bytes have to be set up properly to get the thing running. Seems to be related to a kvm/processor incompatibility. Windows XP runs on all combinations without any issues. Windows 8.1 guests have the same issues as Windows 8.0. An example command line that does not boot Windows 8 is: qemu-system-x86_64 -machine pc-i440fx-1.5,accel=kvm,kernel_irqchip=off -daemonize -cpu kvm32,+sep,+nx -nodefaults -vga std -readconfig /usr/X11R6/X11etc/ich9-ehci-uhci.cfg -device usb-host,bus=ehci.0,hostport=1.2 -device usb-tablet -drive file=/dev/sdb,cache=writethrough,if=none,id=x -device ide-drive,drive=x -m 1024 -monitor telnet:127.0.0.1:5100,nowait,server -vnc :1 -L /usr/X11R6/share/qemu -boot c -localtime -enable-kvm -no-shutdown enabling the kernel_irqchip, removing the sep, disabling usb, changing the machine type or changing the monitor type (SDL or VNC) has no effect. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1366836/+subscriptions
[Qemu-devel] [Bug 1366836] Re: Core2Duo and KVM may not boot Win8 properly on 3.x kernels
I found a new trace - using the ipipe patch that I have, there seems to be an issue in the 3.4 kernels, but as it looks also in the 3.10 kernels. http://www.xenomai.org/pipermail/xenomai/2013-March/027865.html Is there an update on that already existing? It was not completely clear if this issue is related either to KVM or to the ipipe patch. Thanks. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1366836 Title: Core2Duo and KVM may not boot Win8 properly on 3.x kernels Status in QEMU: New Bug description: When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel 3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error. When I dump the CPU registers via "info registers", nothing changes, that means the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0. It stalls when the Windows logo is displayed and the balled circle starts rotating. But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 or 2.0.0 on the host side it works on the Core2Duo. Also the system above but just with an i3 or i5 CPU it works fine. I already disabled networking and USB for the guest and changed the graphics card - no effect. I assume that some mean bits and bytes have to be set up properly to get the thing running. Seems to be related to a kvm/processor incompatibility. Windows XP runs on all combinations without any issues. Windows 8.1 guests have the same issues as Windows 8.0. An example command line that does not boot Windows 8 is: qemu-system-x86_64 -machine pc-i440fx-1.5,accel=kvm,kernel_irqchip=off -daemonize -cpu kvm32,+sep,+nx -nodefaults -vga std -readconfig /usr/X11R6/X11etc/ich9-ehci-uhci.cfg -device usb-host,bus=ehci.0,hostport=1.2 -device usb-tablet -drive file=/dev/sdb,cache=writethrough,if=none,id=x -device ide-drive,drive=x -m 1024 -monitor telnet:127.0.0.1:5100,nowait,server -vnc :1 -L /usr/X11R6/share/qemu -boot c -localtime -enable-kvm -no-shutdown enabling the kernel_irqchip, removing the sep, disabling usb, changing the machine type or changing the monitor type (SDL or VNC) has no effect. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1366836/+subscriptions
[Qemu-devel] [Bug 1366836] Re: Core2Duo and KVM may not boot Win8 properly on 3.x kernels
attached the trace.dat (tar-gzipped) as recommended. Hope this helps finding the issue. The file should capture the following: - windows 8 with screen that shows that the last boot attempts failed - issued system_reset on qemu commandline - startup of windows 8 that stalls ** Attachment added: "trace.tgz" https://bugs.launchpad.net/qemu/+bug/1366836/+attachment/4201430/+files/trace.tgz -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1366836 Title: Core2Duo and KVM may not boot Win8 properly on 3.x kernels Status in QEMU: New Bug description: When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel 3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error. When I dump the CPU registers via "info registers", nothing changes, that means the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0. It stalls when the Windows logo is displayed and the balled circle starts rotating. But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 or 2.0.0 on the host side it works on the Core2Duo. Also the system above but just with an i3 or i5 CPU it works fine. I already disabled networking and USB for the guest and changed the graphics card - no effect. I assume that some mean bits and bytes have to be set up properly to get the thing running. Seems to be related to a kvm/processor incompatibility. Windows XP runs on all combinations without any issues. Windows 8.1 guests have the same issues as Windows 8.0. An example command line that does not boot Windows 8 is: qemu-system-x86_64 -machine pc-i440fx-1.5,accel=kvm,kernel_irqchip=off -daemonize -cpu kvm32,+sep,+nx -nodefaults -vga std -readconfig /usr/X11R6/X11etc/ich9-ehci-uhci.cfg -device usb-host,bus=ehci.0,hostport=1.2 -device usb-tablet -drive file=/dev/sdb,cache=writethrough,if=none,id=x -device ide-drive,drive=x -m 1024 -monitor telnet:127.0.0.1:5100,nowait,server -vnc :1 -L /usr/X11R6/share/qemu -boot c -localtime -enable-kvm -no-shutdown enabling the kernel_irqchip, removing the sep, disabling usb, changing the machine type or changing the monitor type (SDL or VNC) has no effect. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1366836/+subscriptions
[Qemu-devel] [Bug 1366836] Re: Core2Duo and KVM may not boot Win8 properly on 3.x kernels
sorry for the corrupt file, this one should be fine now. ** Attachment added: "trace.tgz" https://bugs.launchpad.net/qemu/+bug/1366836/+attachment/4201455/+files/trace.tgz -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1366836 Title: Core2Duo and KVM may not boot Win8 properly on 3.x kernels Status in QEMU: New Bug description: When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel 3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error. When I dump the CPU registers via "info registers", nothing changes, that means the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0. It stalls when the Windows logo is displayed and the balled circle starts rotating. But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 or 2.0.0 on the host side it works on the Core2Duo. Also the system above but just with an i3 or i5 CPU it works fine. I already disabled networking and USB for the guest and changed the graphics card - no effect. I assume that some mean bits and bytes have to be set up properly to get the thing running. Seems to be related to a kvm/processor incompatibility. Windows XP runs on all combinations without any issues. Windows 8.1 guests have the same issues as Windows 8.0. An example command line that does not boot Windows 8 is: qemu-system-x86_64 -machine pc-i440fx-1.5,accel=kvm,kernel_irqchip=off -daemonize -cpu kvm32,+sep,+nx -nodefaults -vga std -readconfig /usr/X11R6/X11etc/ich9-ehci-uhci.cfg -device usb-host,bus=ehci.0,hostport=1.2 -device usb-tablet -drive file=/dev/sdb,cache=writethrough,if=none,id=x -device ide-drive,drive=x -m 1024 -monitor telnet:127.0.0.1:5100,nowait,server -vnc :1 -L /usr/X11R6/share/qemu -boot c -localtime -enable-kvm -no-shutdown enabling the kernel_irqchip, removing the sep, disabling usb, changing the machine type or changing the monitor type (SDL or VNC) has no effect. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1366836/+subscriptions
[Qemu-devel] [Bug 1366836] Re: Core2Duo and KVM may not boot Win8 properly on 3.x kernels
Confirmed - the current kvm.git without any ipipe patch also causes the issue. Trace File attached. ** Attachment added: "trace.tgz" https://bugs.launchpad.net/qemu/+bug/1366836/+attachment/4202192/+files/trace.tgz -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1366836 Title: Core2Duo and KVM may not boot Win8 properly on 3.x kernels Status in QEMU: New Bug description: When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel 3.4.67 or 3.10.12 to run a Windows 8.0 guest, the guest freezes at Windows 8 boot without any error. When I dump the CPU registers via "info registers", nothing changes, that means the system really stalled. Same happens with QEMU 2.0.0 and QEMU 2.1.0. It stalls when the Windows logo is displayed and the balled circle starts rotating. But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 or 2.0.0 on the host side it works on the Core2Duo. Also the system above but just with an i3 or i5 CPU it works fine. I already disabled networking and USB for the guest and changed the graphics card - no effect. I assume that some mean bits and bytes have to be set up properly to get the thing running. Seems to be related to a kvm/processor incompatibility. Windows XP runs on all combinations without any issues. Windows 8.1 guests have the same issues as Windows 8.0. An example command line that does not boot Windows 8 is: qemu-system-x86_64 -machine pc-i440fx-1.5,accel=kvm,kernel_irqchip=off -daemonize -cpu kvm32,+sep,+nx -nodefaults -vga std -readconfig /usr/X11R6/X11etc/ich9-ehci-uhci.cfg -device usb-host,bus=ehci.0,hostport=1.2 -device usb-tablet -drive file=/dev/sdb,cache=writethrough,if=none,id=x -device ide-drive,drive=x -m 1024 -monitor telnet:127.0.0.1:5100,nowait,server -vnc :1 -L /usr/X11R6/share/qemu -boot c -localtime -enable-kvm -no-shutdown enabling the kernel_irqchip, removing the sep, disabling usb, changing the machine type or changing the monitor type (SDL or VNC) has no effect. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1366836/+subscriptions
[Qemu-devel] QEMU and other libusb application cause segfaults in libusb
Hi all, I post this to both QEMU and libusb because I'm not sure where the error could be located. I have an application using libusb which is running for months without any issues on the host system. When I start QEMU - which uses libusb, too - the errors begin. I route some USB ports to my QEMU-KVM guest but NOT the port where my hardware is attached. >From time to time I start receiving things from my own application that are never sent by my USB hardware, it seems to be more a heap of memory coming from somewhere else. And sometimes the libusb gets segfaulted in libusb_handle_events_timeout_completed(). As long as my application is running alone everything is fine. And there is no dmesg output that processes are fighting for my device. When I exit QEMU early enough, the application stays alive and remains stable. Any hints how to prevent that would be appreciated. My system is an i5 CPU with a vanilla kernel 3.4.67. Thanks. Best regards, Erik
[Qemu-devel] QEMU with KVM does not start Win8 on kernel 3.4.67 and core2duo
Hi all, I did already several tests and I'm not completely sure what's going wrong, but here my scenario: When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a vanilla kernel 3.4.67 to run a Windows 8.0 guest, the guest freezes at boot without any error. When I dump the CPU registers via "info registers", nothing changes, that means the system really stalled. Same happens with QEMU 2.0.0. But - when I run the very same guest using Kernel 2.6.32.12 and QEMU 1.7.0 on the host side it works on the Core2Duo. Also the system above but just with an i3 or i5 CPU it works, too. I already disabled networking and USB for the guest and changed the graphics card - no effect. I assume that some mean bits and bytes have to be set up properly to get the thing running. Any hint what to change / test would be really appreciated. Thanks in advance, Best regards, Erik
[Qemu-devel] Mixed USB 1.1 and USB 2.0 on the same port
Hi all, how can I use a USB 1.1 device on the USB 2.0 bus? Currently the EHCI implementation complains that the device is mismatches the USB version. I want to offer one root port for both USB 2.0 and USB 1.1 devices using usb-host,... Routings to the guest. Maybe only some parameters need to be added to the qemu commandline? Any hint would be helpful. Thanks. Best regards, Erik
Re: [Qemu-devel] Mixed USB 1.1 and USB 2.0 on the same port
> On 12/31/11 13:11, Erik Rull wrote: > > Hi all, > > > > how can I use a USB 1.1 device on the USB 2.0 bus? Currently the EHCI > > implementation complains that the device is mismatches the USB version. > > -readconfig docs/ich9-ehci-uhci.cfg > > cheers, > Gerd Thanks for the hint. It looks better now. But some things are still a bit strange. Sequence: device_add usb-host,bus=ehci.0,hostbus=2,hostport=1.4 Plug in a USB 2.0 printer (gets detected by the guest, printing is possible, no bluescreen, it just works) Remove the USB 2.0 printer Plug in a USB 1.1 dongle Gets detected, etc., fine Remove the USB 1.1 dongle Plug in the USB 2.0 printer again Guest complains now, that a USB 2.0 device was plugged into a USB 1.1 port => printer is now 1.1 and does not work as if EHCI is missing now => reboot guest, everything is fine again?? Any idea what could have happened here? Same behavior when using a 2.0 USB key and the USB 1.1 dongle - also on other ports - the transfer rate is horrible after having removed the USB 1.1 device and reconnected the 2.0 device. Exchanging the two USB 2.0 devices on the same port without having the 1.1 device plugged in is fine! Any hint what is wrong here would be great. Best regards, Erik
Re: [Qemu-devel] Mixed USB 1.1 and USB 2.0 on the same port
erik.r...@rdsoftware.de wrote: On 12/31/11 13:11, Erik Rull wrote: Hi all, how can I use a USB 1.1 device on the USB 2.0 bus? Currently the EHCI implementation complains that the device is mismatches the USB version. -readconfig docs/ich9-ehci-uhci.cfg cheers, Gerd Thanks for the hint. It looks better now. But some things are still a bit strange. Sequence: device_add usb-host,bus=ehci.0,hostbus=2,hostport=1.4 Plug in a USB 2.0 printer (gets detected by the guest, printing is possible, no bluescreen, it just works) Remove the USB 2.0 printer Plug in a USB 1.1 dongle Gets detected, etc., fine Remove the USB 1.1 dongle Plug in the USB 2.0 printer again Guest complains now, that a USB 2.0 device was plugged into a USB 1.1 port => printer is now 1.1 and does not work as if EHCI is missing now => reboot guest, everything is fine again?? Any idea what could have happened here? Same behavior when using a 2.0 USB key and the USB 1.1 dongle - also on other ports - the transfer rate is horrible after having removed the USB 1.1 device and reconnected the 2.0 device. Exchanging the two USB 2.0 devices on the same port without having the 1.1 device plugged in is fine! Any hint what is wrong here would be great. Best regards, Erik Additional Information: This behavior is present on a Linux guest as well! After having removed the 1.1 Dongle and plugged in the printer, the Linux guest detects the hardware via the UHCI kernel drivers and tells me to use a faster hub for max. performance. It looks as if the speed downgrade by the 1.1 device cannot be reversed at runtime. Best regards, Erik
Re: [Qemu-devel] bad USB tablet update rate on qemu-1.0
Erik Rull wrote: Anthony Liguori wrote: On 12/19/2011 03:33 PM, Erik Rull wrote: Hi all, coming from qemu 0.14 the usbdevice tablet update rate gets really bad in qemu-1.0 with the same guest. What's the specific guest? Regards, Anthony Liguori It's a Windows XP guest. It was fine in 0.14 Thanks. Best regards, Erik Any progress here? I tested it on another CPU board there it was worse - only 1-2 cursor updates per second :-( I tried to use the wacom-tablet but didn't find a driver that works. Best regards, Erik
Re: [Qemu-devel] bad USB tablet update rate on qemu-1.0
Erik Rull wrote: Erik Rull wrote: Anthony Liguori wrote: On 12/19/2011 03:33 PM, Erik Rull wrote: Hi all, coming from qemu 0.14 the usbdevice tablet update rate gets really bad in qemu-1.0 with the same guest. What's the specific guest? Regards, Anthony Liguori It's a Windows XP guest. It was fine in 0.14 Thanks. Best regards, Erik Any progress here? I tested it on another CPU board there it was worse - only 1-2 cursor updates per second :-( I tried to use the wacom-tablet but didn't find a driver that works. Best regards, Erik Hi all, today I tested some stuff with VNC for remote access of the VM - there the update rate of the USB tablet (mouse cursor) was really great. So the question is now: - Same host operating system for 0.14 and 1.0 - Same command line parameters beside the vnc option Why is the native mouse on the qemu 0.14 system good for both vnc and native and on the qemu 1.0 system only good for vnc and bad for the native hardware mouse? Maybe this helps finding the source of evil... If you have ideas what to change / patches to test, just let me know. Best regards, Erik
Re: [Qemu-devel] bad USB tablet update rate on qemu-1.0
Erik Rull wrote: Erik Rull wrote: Anthony Liguori wrote: On 12/19/2011 03:33 PM, Erik Rull wrote: Hi all, coming from qemu 0.14 the usbdevice tablet update rate gets really bad in qemu-1.0 with the same guest. What's the specific guest? Regards, Anthony Liguori It's a Windows XP guest. It was fine in 0.14 Thanks. Best regards, Erik Any progress here? I tested it on another CPU board there it was worse - only 1-2 cursor updates per second :-( I tried to use the wacom-tablet but didn't find a driver that works. Best regards, Erik Hi all, today I tested some stuff with VNC for remote access of the VM - there the update rate of the USB tablet (mouse cursor) was really great. So the question is now: - Same host operating system for 0.14 and 1.0 - Same command line parameters beside the vnc option Why is the native mouse on the qemu 0.14 system good for both vnc and native and on the qemu 1.0 system only good for vnc and bad for the native hardware mouse? Maybe this helps finding the source of evil... If you have ideas what to change / patches to test, just let me know. Best regards, Erik
Re: [Qemu-devel] bad USB tablet update rate on qemu-1.0
Erik Rull wrote: Erik Rull wrote: Erik Rull wrote: Anthony Liguori wrote: On 12/19/2011 03:33 PM, Erik Rull wrote: Hi all, coming from qemu 0.14 the usbdevice tablet update rate gets really bad in qemu-1.0 with the same guest. What's the specific guest? Regards, Anthony Liguori It's a Windows XP guest. It was fine in 0.14 Thanks. Best regards, Erik Any progress here? I tested it on another CPU board there it was worse - only 1-2 cursor updates per second :-( I tried to use the wacom-tablet but didn't find a driver that works. Best regards, Erik Hi all, today I tested some stuff with VNC for remote access of the VM - there the update rate of the USB tablet (mouse cursor) was really great. So the question is now: - Same host operating system for 0.14 and 1.0 - Same command line parameters beside the vnc option Why is the native mouse on the qemu 0.14 system good for both vnc and native and on the qemu 1.0 system only good for vnc and bad for the native hardware mouse? Maybe this helps finding the source of evil... If you have ideas what to change / patches to test, just let me know. Best regards, Erik Hi all, I additionally tested -std vga to exclude that it might be related to the cirrus emulation - but same result. So there seems to be a difference between the captured cursor for the native X-Windows window and the VNC window that occured somewhere between 0.14 and 1.0. Best regards, Erik
[Qemu-devel] Build failure in test-coroutine.c
Hi all, I just got a copy of the current qemu-kvm but there is a build failure in test-coroutine.c: erik@debian:~/qemu-test/qemu-kvm$ make [...] CCtest-coroutine.o test-coroutine.c: In function 'test_nesting': test-coroutine.c:92: warning: implicit declaration of function 'g_assert_cmpint' test-coroutine.c:92: warning: nested extern declaration of 'g_assert_cmpint' test-coroutine.c:92: error: expected expression before '==' token test-coroutine.c:93: error: expected expression before '==' token test-coroutine.c: In function 'test_yield': test-coroutine.c:122: error: expected expression before '==' token test-coroutine.c: In function 'perf_lifecycle': test-coroutine.c:170: warning: implicit declaration of function 'g_test_timer_start' test-coroutine.c:170: warning: nested extern declaration of 'g_test_timer_start' test-coroutine.c:175: warning: implicit declaration of function 'g_test_timer_elapsed' test-coroutine.c:175: warning: nested extern declaration of 'g_test_timer_elapsed' test-coroutine.c:177: warning: implicit declaration of function 'g_test_message' test-coroutine.c:177: warning: nested extern declaration of 'g_test_message' test-coroutine.c: In function 'main': test-coroutine.c:182: warning: implicit declaration of function 'g_test_init' test-coroutine.c:182: warning: nested extern declaration of 'g_test_init' test-coroutine.c:183: warning: implicit declaration of function 'g_test_add_func' test-coroutine.c:183: warning: nested extern declaration of 'g_test_add_func' test-coroutine.c:188: warning: implicit declaration of function 'g_test_perf' test-coroutine.c:188: warning: nested extern declaration of 'g_test_perf' test-coroutine.c:191: warning: implicit declaration of function 'g_test_run' test-coroutine.c:191: warning: nested extern declaration of 'g_test_run' make: *** [test-coroutine.o] Error 1 erik@debian:~/qemu-test/qemu-kvm$ Any ideas how to fix that? Best regards, Erik
Re: [Qemu-devel] bad USB tablet update rate on qemu-1.0
Andreas Färber wrote: Am 19.01.2012 17:40, schrieb Erik Rull: Erik Rull wrote: Erik Rull wrote: Erik Rull wrote: Anthony Liguori wrote: On 12/19/2011 03:33 PM, Erik Rull wrote: Hi all, coming from qemu 0.14 the usbdevice tablet update rate gets really bad in qemu-1.0 with the same guest. What's the specific guest? Regards, Anthony Liguori It's a Windows XP guest. It was fine in 0.14 Thanks. Best regards, Erik Any progress here? I tested it on another CPU board there it was worse - only 1-2 cursor updates per second :-( I tried to use the wacom-tablet but didn't find a driver that works. Best regards, Erik Hi all, today I tested some stuff with VNC for remote access of the VM - there the update rate of the USB tablet (mouse cursor) was really great. So the question is now: - Same host operating system for 0.14 and 1.0 - Same command line parameters beside the vnc option Why is the native mouse on the qemu 0.14 system good for both vnc and native and on the qemu 1.0 system only good for vnc and bad for the native hardware mouse? Maybe this helps finding the source of evil... If you have ideas what to change / patches to test, just let me know. Best regards, Erik Hi all, I additionally tested -std vga to exclude that it might be related to the cirrus emulation - but same result. So there seems to be a difference between the captured cursor for the native X-Windows window and the VNC window that occured somewhere between 0.14 and 1.0. Then try `git bisect start v1.0 v0.14.0' to find out when exactly the perceived behavior changed. :) Andreas Hi Andreas, thanks for the hint, I haven't used git up to now. Very interesting feature. I just did a clone of the current qemu-kvm (which I use) and started to bisect, but got an error, where I don't know how to proceed: erik@debian:~/qemu-test/qemu-kvm$ git bisect good qemu-kvm-0.14.0 You need to start by "git bisect start" Do you want me to do it for you [Y/n]? erik@debian:~/qemu-test/qemu-kvm$ git bisect bad qemu-kvm-1.0 Bisecting: 2043 revisions left to test after this fatal: Entry 'roms/seabios' not uptodate. Cannot merge. erik@debian:~/qemu-test/qemu-kvm$ Any ideas? I did a git pull, but I just got the response that it is already up to date... Best regards, Erik
[Qemu-devel] Link failure with libhw64/9pfs/virtio-9p-proxy.o
Hi all, when buildung target x86_64-softmmu the final link fails: LINK x86_64-softmmu/qemu-system-x86_64 ../libhw64/9pfs/virtio-9p-proxy.o: In function `proxy_opendir': /home/erik/qemu-test/qemu/hw/9pfs/virtio-9p-proxy.c:659: undefined reference to `fdopendir' collect2: ld returned 1 exit status make[1]: *** [qemu-system-x86_64] Error 1 make: *** [subdir-x86_64-softmmu] Error 2 I assume that it might be related with the previous issues that I had with qemu-1.0 rc's and the 9pfs where my older OS does not offer these functions. Best regards, Erik
Re: [Qemu-devel] bad USB tablet update rate on qemu-1.0
Hi Andreas, Andreas Färber wrote: Hi Erik, Am 19.01.2012 20:15, schrieb Erik Rull: Andreas Färber wrote: Am 19.01.2012 17:40, schrieb Erik Rull: [...] there seems to be a difference between the captured cursor for the native X-Windows window and the VNC window that occured somewhere between 0.14 and 1.0. Then try `git bisect start v1.0 v0.14.0' to find out when exactly the perceived behavior changed. :) I just did a clone of the current qemu-kvm (which I use) and started to bisect, but got an error, where I don't know how to proceed: erik@debian:~/qemu-test/qemu-kvm$ git bisect good qemu-kvm-0.14.0 You need to start by "git bisect start" Do you want me to do it for you [Y/n]? erik@debian:~/qemu-test/qemu-kvm$ git bisect bad qemu-kvm-1.0 Bisecting: 2043 revisions left to test after this fatal: Entry 'roms/seabios' not uptodate. Cannot merge. erik@debian:~/qemu-test/qemu-kvm$ Hm, did you maybe previously do a `git submodule init'? You may need to run `git submodule update' then (which may fail as recently for roms/SLOF). Otherwise, generally when it does not compile you can try `git bisect skip' to try a different commit. Andreas Updated to the latest git version from github.com and it's fine now. I did a test bisectioning by just using bisect good and bad randomized. My test system is available again on Monday. I will keep you updated. Best regards, Erik
Re: [Qemu-devel] bad USB tablet update rate on qemu-1.0
Hi all, I'm really sorry, but the bisectioning does not work for the versions that I want to test. I get a bunch of errors when bisectioning. e.g. continuosly: erik@debian:~/qemu-test/qemu-kvm$ make CCx86_64-softmmu/monitor.o In file included from /home/erik/qemu-test/qemu-kvm/qmp-commands.h:19, from /home/erik/qemu-test/qemu-kvm/monitor.c:3145: /home/erik/qemu-test/qemu-kvm/qapi-types.h:19:34: error: qapi/qapi-types-core.h: No such file or directory In file included from /home/erik/qemu-test/qemu-kvm/qmp-commands.h:19, from /home/erik/qemu-test/qemu-kvm/monitor.c:3145: /home/erik/qemu-test/qemu-kvm/qapi-types.h:21: error: expected expression before 'typedef' make[1]: *** [monitor.o] Error 1 Additionally there seem to be differences between the 1.0 version in git and the 1.0 version for download - there it compiles... *argh* Please help. I tried several git bisect skip but that didn't help. The commit that was tested is: Bisecting: a merge base must be tested [2d2339f995d7176dcb2de10d162aed323a1ffbf3] Merge commit 'f487d6278f75f84378833b8c3a67443346d639dc' into upstream-merge I thought that only working/compiling stuff gets committed? Btw. the master does not compile either! Best regards, Erik
Re: [Qemu-devel] [PATCH] uhci: stop queue filling when we find a in-flight td
On March 21, 2012 at 6:36 PM Gerd Hoffmann wrote:
> Not only QHs can form rings, but TDs too. With the new
> queuing/pipelining support we are following TD chains and
> can actually walk in circles. An assert() prevents us from
> entering an endless loop then.
>
> Fix is easy: Just stop queuing when we figure the TD we are
> about to queue up is in flight already.
>
> Signed-off-by: Gerd Hoffmann
> ---
> hw/usb/hcd-uhci.c |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/hw/usb/hcd-uhci.c b/hw/usb/hcd-uhci.c
> index e55dad9..2be564b 100644
> --- a/hw/usb/hcd-uhci.c
> +++ b/hw/usb/hcd-uhci.c
> @@ -965,6 +965,9 @@ static void uhci_fill_queue(UHCIState *s, UHCI_TD
*td)
> }
> trace_usb_uhci_td_queue(plink & ~0xf, ptd.ctrl, ptd.token);
> ret = uhci_handle_td(s, plink, &ptd, &int_mask);
> +if (ret == TD_RESULT_ASYNC_CONT) {
> +break;
> +}
> assert(ret == TD_RESULT_ASYNC_START);
> assert(int_mask == 0);
> plink = ptd.link;
> --
> 1.7.1
>
>
Issue fixed - my Windows boots again :-)
Thanks a lot!
Best regards,
Erik
Re: [Qemu-devel] BUG: 0.14.0 -device usb-host supports only one device
Gerd Hoffmann wrote: Hi, When enabling the -device usb-host option support for adding automatically USB devices from the host to the guest, only one device gets detected. Yes. -device usb-host creates a *single* virtual usb device instance. When a matching device on the host is found the virtual device is plugged in, otherwise it is plugged out. In plugged out state qemu looks now and then (every two seconds IIRC) whenever a matching device was plugged into the host. Try -device usb-host twice if you need two virtual usb devices. cheers, Gerd Hi Gerd, hm, if I add it multiple times and plug in a USB flashdrive, then all slots are filled up with this device (duplicated)... And Windows detects them with the result, that the "not first" devices are marked with a yellow exclamation mark in the device manager. And the next device plugged in gets then not detected because all preallocated slots are full :-( Any ideas? Best regards, Erik
Re: [Qemu-devel] [PATCH 18/18] usb: add ehci adapter
David Ahern wrote: Come on Gerd. That was not an attempt to get it included. Someone asked for a patch and I took the existing tree, merged with latest and through out the patch. The v1/v2 is not in Jan's tree. That's a hack I have locally to have mixed devices. What is shows is that is not a big deal to move to latest code from Jan's last update in November. I asked for the patch and it works great for 0.14.0 :-) Except some parameter stuff that is still in the old command style, but it works. I'm looking forward for a default USB 2.0 implementation without patches by not excluding other community members "already working" work. Best regards, Erik
Re: [Qemu-devel] [PATCH 18/18] usb: add ehci adapter
Hi Gerd, could you provide a single patch file for the new USB files against the released qemu 0.14.0 or 0.14.1? I tried to create that file by assembling the patch emails but no real success. Feedback on the patch is guaranteed :-) Thanks a lot! Best regards, Erik
[Qemu-devel] USB port NULL pointer causes segv
Hi all, in usb-linux.c my qemu crashes in static int usb_host_open(USBHostDevice *dev, int bus_num, int addr, char *port, const char *prod_name, int speed) because port is NULL. The line that causes the problem is: strcpy(dev->port, port); All Ports are displayed in the qemu monitor info as (null) when changing the line to: if (port) strcpy(dev->port, port); else dev->port[0] = '\0'; everything is fine :-) Please check this issue and let me know if my workaround is okay. Best regards, Erik
[Qemu-devel] Howto - USB Port and EHCI
Hi all, is there a documentation available for the new USB EHCI and Port selection feature? I have read some patches that contained these updates, but I don't know how to tell my USB device to be exposed as EHCI device to the guest. My info usbhost shows 5x UHCI and 1x EHCI host after adding device_add usbhost. Thanks. Best regards, Erik
Re: [Qemu-devel] USB port NULL pointer causes segv
Hi Gerd, thanks a lot. I just had a look on usb-linux.c where the "port" could be identified. for those that must use /proc/bus/usb it would be possible to allow the following: read in the "Port=" and check if it is on bus level 1, then you can identify at least your real root hardware port - hubs won't work, but for most users this would help at least for basic use cases. And: My system has the /sys/bus/usb structure, but NO udev enabled! That means the /dev/bus/usb structure is missing! Running the existing usb-linux.c code, I can never use USB, because /sys/... is selected but /dev/... is used which is not checked for existance! This causes delayed problems when you want to start using usb host devices. I moved the /proc/bus/usb checking in front of the /sys/ checking and it worked for me - maybe not useful for all but then the checkings for /sys/bus/usb should be extended on the /dev/bus/usb existance check. Additionally I have bigger problems with CD and DVD usb drives, they get detected and routed to the guest, but the "claimend" message comes up on the qemu monitor every 10-15 seconds and sometimes the linux usb driver resets the port - that causes a very slow detection in the guest and I never got it finished and I was not able to access the data on the CD. Most USB keys work, but some also had a similar issue. Everything tested with qemu-kvm-0.15.0 Best regards, Erik
Re: [Qemu-devel] USB port NULL pointer causes segv
Hi Gerd, thanks a lot. I just had a look on usb-linux.c where the "port" could be identified. for those that must use /proc/bus/usb it would be possible to allow the following: read in the "Port=" and check if it is on bus level 1, then you can identify at least your real root hardware port - hubs won't work, but for most users this would help at least for basic use cases. And: My system has the /sys/bus/usb structure, but NO udev enabled! That means the /dev/bus/usb structure is missing! Running the existing usb-linux.c code, I can never use USB, because /sys/... is selected but /dev/... is used which is not checked for existance! This causes delayed problems when you want to start using usb host devices. I moved the /proc/bus/usb checking in front of the /sys/ checking and it worked for me - maybe not useful for all but then the checkings for /sys/bus/usb should be extended on the /dev/bus/usb existance check. Additionally I have bigger problems with CD and DVD usb drives, they get detected and routed to the guest, but the "claimend" message comes up on the qemu monitor every 10-15 seconds and sometimes the linux usb driver resets the port - that causes a very slow detection in the guest and I never got it finished and I was not able to access the data on the CD. Most USB keys work, but some also had a similar issue. Everything tested with qemu-kvm-0.15.0 Best regards, Erik
Re: [Qemu-devel] Keysymbol interpretation missing in QEMU's VNC server?
Hi Fabian, Fabian Holler wrote: Hello Erik, I just want to route all keypresses to the guest without interfering with the native QEMU key layout. Is that possible? Yes, if you start kvm without the "-k" option and use a linux VNC client that supports RFB extended key events (eg gtk-vnc, tigervnc). With the extension the keyboard layout only depends on the OS settings in the VM. I tried tigervnc and tightvnc for Windows - which both advertise the feature on their website - same issues as I have with UltraVNC - no AltGr combinations and no "Umlaute" available. I need a Windows VNC client that can handle that - do you know a vnc client that can do that? How does the QEMU VNC server receive the key presses? In the same manner as the direct way does by getting scancodes or via "real" characters? http://berrange.com/posts/2010/07/04/more-than-you-or-i-ever-wanted-to-know-about-virtual-keyboard-handling/ http://berrange.com/posts/2010/07/04/a-summary-of-scan-code-key-codes-sets-used-in-the-pc-virtualization-stack/ Really interesting - Linux works, Windows doesn't :-( Also when using a Linux remote X-Windows (via SSH tunnel) on my Windows PC it works - only the plain Windows VNC client corrupts the keypresses regards Fabian Best regards, Erik
Re: [Qemu-devel] Keysymbol interpretation missing in QEMU's VNC server?
Hi Fabian, Fabian Holler wrote: Howdy Erik, On Tue, May 29, 2012 at 09:22:02PM +0200, Erik Rull wrote: Fabian Holler wrote: I just want to route all keypresses to the guest without interfering with the native QEMU key layout. Is that possible? Yes, if you start kvm without the "-k" option and use a linux VNC client that supports RFB extended key events (eg gtk-vnc, tigervnc). With the extension the keyboard layout only depends on the OS settings in the VM. I tried tigervnc and tightvnc for Windows - which both advertise the feature on their website I can't find anything on the tightvnc webpage about QEMU extended key events. My information about tigervnc was wrong. Tigervnc doesn't implemented the extended key events. Its problematic in java because you can't get the original key codes in the JVM. There is this tigervnc fork which adds extended key events: https://github.com/jakobadam/vnc But it only sends the code for that key that triggers the character on a keyboard with danish layout. :) - same issues as I have with UltraVNC - no AltGr combinations and no "Umlaute" available. I need a Windows VNC client that can handle that - do you know a vnc client that can do that? No, sorry :-) How does the QEMU VNC server receive the key presses? In the same manner as the direct way does by getting scancodes or via "real" characters? http://berrange.com/posts/2010/07/04/more-than-you-or-i-ever-wanted-to-know-about-virtual-keyboard-handling/ http://berrange.com/posts/2010/07/04/a-summary-of-scan-code-key-codes-sets-used-in-the-pc-virtualization-stack/ Really interesting - Linux works, Windows doesn't :-( Also when using a Linux remote X-Windows (via SSH tunnel) on my Windows PC it works - only the plain Windows VNC client corrupts the keypresses Seems that no VNC client exists that sends the Windows virtual key code as RFB/VNC key code to the VNC server. regards Fabian Finally - the "original" RealVNC Viewer (free) can handle it on Windows! I was able to switch the keyboard layout on the guest to german and the letters are fine. So this should be the recommended client from the windows side. I will do some further testing on other hardware, but I don't think that there will be too many difficulties. Best regards, Erik
[Qemu-devel] USB Hostport Differences
Hi all, when assigning USB host devices to a guest using the hostport option, there seem to be different formats, when calling info usbhost: - On my vanilla kernel linux there is a hostport format e.g. "1.5" or "1.2" - On my Debian 6.0 full blown linux there is a hostport format "2" or "4", that means, there are no dots and only one number Where do the differences come from? I'm working on some scripts that give some dynamic qemu command line options related to the hostport - maybe there is a way of getting them to the same format? Best regards, Erik
Re: [Qemu-devel] USB Hostport Differences
Hans de Goede wrote: Hi, On 06/08/2012 06:33 PM, Erik Rull wrote: Hi all, when assigning USB host devices to a guest using the hostport option, there seem to be different formats, when calling info usbhost: - On my vanilla kernel linux there is a hostport format e.g. "1.5" or "1.2" - On my Debian 6.0 full blown linux there is a hostport format "2" or "4", that means, there are no dots and only one number Hmm, is this on the same machine, with the usb devices hooked up the same way? Normally these differences come from there being hubs in the chain, ie "2" or "4" indicate devices plugged directly into a root hub, "1.5" and "1.2" mean devices plugged into a hub, which itself is plugged into root port "1" Regards, Hans No it's on different machines - first with Intel Hardware, second with AMD Hardware. I have no hubs attached, I use the ports that are offered directly on the mainboard (EPIC Nano Connectors / ATX rear side panel). On all other Intel systems I see the same effect with the "1.x" ports. Only the AMD system shows the single numbers. Maybe the root hubs are different on Intel and AMD hardware? Best regards, Erik
Re: [Qemu-devel] USB Hostport Differences
Hans de Goede wrote: Hi, On 06/08/2012 10:56 PM, Erik Rull wrote: Hans de Goede wrote: Hi, On 06/08/2012 06:33 PM, Erik Rull wrote: Hi all, when assigning USB host devices to a guest using the hostport option, there seem to be different formats, when calling info usbhost: - On my vanilla kernel linux there is a hostport format e.g. "1.5" or "1.2" - On my Debian 6.0 full blown linux there is a hostport format "2" or "4", that means, there are no dots and only one number Hmm, is this on the same machine, with the usb devices hooked up the same way? Normally these differences come from there being hubs in the chain, ie "2" or "4" indicate devices plugged directly into a root hub, "1.5" and "1.2" mean devices plugged into a hub, which itself is plugged into root port "1" Regards, Hans No it's on different machines - first with Intel Hardware, second with AMD Hardware. I have no hubs attached, I use the ports that are offered directly on the mainboard (EPIC Nano Connectors / ATX rear side panel). On all other Intel systems I see the same effect with the "1.x" ports. Only the AMD system shows the single numbers. Those would be sandy bridge or newer Intel machines then, these no longer have an EHCI usb controller + UHCI companion controllers, but only an EHCI controller, so the root ports are USB-2 only. In order for USB-1 devices to still work the chipset has an integrated USB-2 hub (which can handle USB-1 ports), of you do lsusb you should see something like this in there: Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Which is why you get the 1.x for the motherboard ports, because there is actually a hub between the root hub and the ports. Regards, Hans Hi Hans, thanks for the explanation - so I will try to find out which way of USB handling is given on the current system and then add the correct hostport filters. Is there an easier way of finding this kind of architecture automatically beside grep'ing for such a Hub? Best regards, Erik
Re: [Qemu-devel] USB 2.0 printer passthrough very slow
Hi, please try to use the .cfg file from the docs/ directory, using this file, the USB printer speed is really good on my systems. Well it is still an emulation so you'll never get native speed, but it is far better than the USB 1.x emulation we had in 0.1x versions. Best thing to test the approx. transfer speed: Plug in a fast usb key, copy some larger data chunks and measure the time - on the same port where you attach the printer. Printing e.g. the Windows XP test page takes not really more time than on a native system. Best regards, Erik Reeted wrote: Hello all, I have virtualized a Windows 2000 machine, using usb-passthrough as in: http://fossies.org/unix/privat/qemu-1.0.1.tar.gz:a/qemu-1.0.1/docs/usb2.txt in companion controller mode, i.e. specifying "bus=ehci.0" for both 1.1 devices and 2.0 devices. I used "companion mode" because in my tests I had problems with two separate busses: attaching a 1.1 device to the emulated ehci bus was notifying errors of incompatible speed and would not work, while attaching it to the emulated 1.1 bus had another problem which I don't remember exactly... I think either it was not possible or qemu was crashing. But with companion mode it appeared to work. In my early tests I did notice that ehci emulation was rather slow: reading an USB flash key sequentially was yelding 6.5MB/sec (from the host it was much faster like 20MB/sec afair), but I guessed that would be enough for an USB printer. I have not actually tested if non-companion mode would be faster, maybe I could have tried that... If you think it would be faster please tell. After virtualizing Windows 2000 the problem became very apparent in printing! My canon IP4700 now takes 3 to 4 minutes for a print job to execute and clear from the queue. That's almost unusable. Note that the speed is normal once the actual printing initiates, I can print 10 pages in a row (in a single job) at normal speed, but it's very slow during the phase of submitting a new print job to the queue, and removing it from the queue, or submitting a "go-poweroff" command to the queue, or changing anything about printer state. I am guessing that maybe when the stream of data is mainly one way, it performs reasonably, while things like handshake with many message/response it probably goes very slow. Note that I have blacklisted usblp module in the host and noone is claiming the printer from the host. Dmesg since connecting the printer: (only 3 messages) [ 6870.292017] usb 1-3: new high speed USB device number 3 using ehci_hcd [ 6872.676028] usb 1-3: reset high speed USB device number 3 using ehci_hcd [ 6873.144032] usb 1-3: reset high speed USB device number 3 using ehci_hcd Qemu version is: Ubuntu Precise's qemu-kvm 1.0+noroms-0ubuntu6 info usbhost: Bus 1, Addr 3, Port 3, Speed 480 Mb/s Class 00: USB device 04a9:10d2, iP4700 series Auto filters: Bus 1, Addr *, Port 5, ID *:* Bus 1, Addr *, Port 4, ID *:* Bus 1, Addr *, Port 3, ID *:* Bus 4, Addr *, Port 1, ID *:* Bus 3, Addr *, Port 2, ID *:* Bus 3, Addr *, Port 1, ID *:* info usb: Device 0.2, Port 1, Speed 12 Mb/s, Product QEMU USB Tablet Device 1.0, Port 1, Speed 1.5 Mb/s, Product USB Host Device Device 1.0, Port 2, Speed 1.5 Mb/s, Product USB Host Device Device 1.1, Port 3, Speed 480 Mb/s, Product iP4700 series Device 1.0, Port 4, Speed 1.5 Mb/s, Product USB Host Device Device 1.0, Port 5, Speed 1.5 Mb/s, Product USB Host Device Device 1.2, Port 6, Speed 12 Mb/s, Product QEMU USB Hub Device 1.0, Port 6.1, Speed 1.5 Mb/s, Product USB Host Device Note I am also using usb tablet... I might remove that if you say that an ehci-only setup is likely to go faster. Libvirt usb part: generated command line: /usr/bin/kvm -S -M pc-1.0 -enable-kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1 -name windows_cl3_v3.1 -uuid 0779e165-b11a-6d1c-fa92-f60ec5bdd9a7 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/windows_cl3_v3.1.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=2012-04-02T20:37:15 -no-shutdown -boot order=c,menu=on -drive file=/dev/mapper/vg1-lv_cl3_v3.1,if=none,id=drive-ide0-0-0,format=raw,cache=writethrough,aio=native -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive file=/home/virtual_machines/ISO/ubuntu-11.10-desktop-amd64.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw,cache=writethrough,aio=native -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=18,id=hostnet0 -device virtio-net-pci,event_idx=off,netdev=hostnet0,id=net0,mac=52:54:00:12:45:88,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -device ich9-usb-ehci1,id=ehci,addr=1d.7,multifunction=on -device ich9-usb-uhci1,id=uhci-1,addr=1d.0,multifunction=on,masterbus=ehci.0,firstpo
Re: [Qemu-devel] USB 2.0 printer passthrough very slow
Hi, Reeted wrote: On 04/03/12 15:33, Erik Rull wrote: Hi, please try to use the .cfg file from the docs/ directory, The ich9-ehci-uhci.cfg ? Yes it's the same thing I am using. If you look at the section I have replicated that file exactly. I had access rights problem using the .cfg file, that's why I replicated it in the commandline, but it's the same thing really. You're right. using this file, the USB printer speed is really good on my systems. Well it is still an emulation so you'll never get native speed, but it is far better than the USB 1.x emulation we had in 0.1x versions. Best thing to test the approx. transfer speed: Plug in a fast usb key, copy some larger data chunks and measure the time - on the same port where you attach the printer. I had tested that on a linux guest and it was 6.5MB/sec (dd streaming of the device! Not file copy) as I said, but you are right, it's better if I try it on the real windows guest. I won't have a chance to test it until the weekened though. Printing e.g. the Windows XP test page takes not really more time than on a native system. And if you send a second job it follows the first one right away or it takes minutes in between? Hm, I didn't have an eye on that, but I don't see any reasons why the USB speed should slow down the Windows Printing Queue. What printer? Tested with an EPSON USB 2.0 and a HP with USB 1.1. What qemu version? I'm not sure which version is the oldest where it worked, but the current git master seems to be fine... If you have no chance to get direct GIT access you can download the master from the git web interface as .tgz. Any chance you could post here your commandline? (from ps aux ) Currently not - the system is not available this week - sorry. What's the guest setting in device management, is it ACPI Uniprocessor http://www.neowin.net/forum/uploads/post-9158-1134631266.png or ACPI Multiprocessor or Standard PC or other? Mine is ACPI Multiprocessor with 2vCPU. Other settings were almost twice slower in booting the system. Standard PC - I don't think that this is related to your issue. Best thing would be to test it on a native system. Well - Speeding up the system with a second core should increase the speed :-) (Sorry for the many questions :-) ) Thanks for your help R. Best regards, Erik
