All of lore.kernel.org
 help / color / mirror / Atom feed
* Unable to run windows HVM guests with xen 3.1.1
@ 2007-11-13 21:47 Guillaume Rousse
  2007-12-03  3:00 ` Mark Williamson
  0 siblings, 1 reply; 3+ messages in thread
From: Guillaume Rousse @ 2007-11-13 21:47 UTC (permalink / raw)
  To: xen-devel

Hello again.

I found another issue with the mandriva xen package: I'm unable anymore
to run windows HVM guests that worked perfectly before. Neither the
existing image, nor installing from the ISO works. In both case, the
domU domain is created, then hangs in early boot phase.

stracing the qemu-dm process show it looping around the following
syscalls: http://www.pastebin.ca/772441

I couldn't attach strace early enough to catch what is fd 17 exactly, tough.

Running Linux HVM guests works OK, tough. I only tested this in cooker
(mandriva devel version) on x86_64 host, with xen 3.1.1 (my attempt to
test 3.1 on stable release failed because of the other xend crash issue).
-- 
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Unable to run windows HVM guests with xen 3.1.1
  2007-11-13 21:47 Unable to run windows HVM guests with xen 3.1.1 Guillaume Rousse
@ 2007-12-03  3:00 ` Mark Williamson
  2007-12-03 14:14   ` Guillaume Rousse
  0 siblings, 1 reply; 3+ messages in thread
From: Mark Williamson @ 2007-12-03  3:00 UTC (permalink / raw)
  To: xen-devel; +Cc: Guillaume Rousse

> I found another issue with the mandriva xen package: I'm unable anymore
> to run windows HVM guests that worked perfectly before. Neither the
> existing image, nor installing from the ISO works. In both case, the
> domU domain is created, then hangs in early boot phase.

Weird; what version of Xen *was* this working under?  Are you using 32-bit or 
64-bit guests?

> stracing the qemu-dm process show it looping around the following
> syscalls: http://www.pastebin.ca/772441

I can't connect to that host; could you paste some of the output into the 
e-mail.  This'll also help document what happened in the archives.

> I couldn't attach strace early enough to catch what is fd 17 exactly,
> tough.
>
> Running Linux HVM guests works OK, tough. I only tested this in cooker
> (mandriva devel version) on x86_64 host, with xen 3.1.1 (my attempt to
> test 3.1 on stable release failed because of the other xend crash issue).

32-bit or 64-bit Linux?

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Unable to run windows HVM guests with xen 3.1.1
  2007-12-03  3:00 ` Mark Williamson
@ 2007-12-03 14:14   ` Guillaume Rousse
  0 siblings, 0 replies; 3+ messages in thread
From: Guillaume Rousse @ 2007-12-03 14:14 UTC (permalink / raw)
  To: Mark Williamson; +Cc: xen-devel

Mark Williamson wrote:
>> I found another issue with the mandriva xen package: I'm unable anymore
>> to run windows HVM guests that worked perfectly before. Neither the
>> existing image, nor installing from the ISO works. In both case, the
>> domU domain is created, then hangs in early boot phase.
> 
> Weird; what version of Xen *was* this working under?  Are you using 32-bit or 
> 64-bit guests?
It was working with xen 3.1 on mandriva 2007.0 (prior to update), and 
failed with xen 3.1 on mandriva 2008.0 (after update). And the guest was
Windows XP, 32 bits.

>> stracing the qemu-dm process show it looping around the following
>> syscalls: http://www.pastebin.ca/772441
> 
> I can't connect to that host; could you paste some of the output into the 
> e-mail.  This'll also help document what happened in the archives.
[pid  7579] recvfrom(16, "\3\1\0\0\0\0\2\320\1\220", 4096, 0, NULL, 
NULL) = 10
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 674333878}) = 0
[pid  7579] read(13, "\31\0\0\0", 4)    = 4
[pid  7579] write(13, "\31\0\0\0", 4)   = 4
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 674477878}) = 0
[pid  7579] ioctl(13, EVIOCGKEYCODE, 0x7fffff119ed0) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 674583878}) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 674629878}) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 679323878}) = 0
[pid  7579] select(17, [9 11 13 16], [16], [], {0, 10000}) = 2 (in [13], 
out [16], left {0, 10000})
[pid  7579] sendto(16, "\0\0\0\0", 4, 0, NULL, 0) = 4
[pid  7579] read(13, "\31\0\0\0", 4)    = 4
[pid  7579] write(13, "\31\0\0\0", 4)   = 4
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 679813878}) = 0
[pid  7579] ioctl(13, EVIOCGKEYCODE, 0x7fffff119ed0) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 679968878}) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 680026878}) = 0
[pid  7579] select(17, [9 11 13 16], [], [], {0, 10000}) = 2 (in [13 
16], left {0, 10000})
[pid  7579] recvfrom(16, "\3\1\0\0\0\0\2\320\1\220", 4096, 0, NULL, 
NULL) = 10
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 680256878}) = 0
[pid  7579] read(13, "\31\0\0\0", 4)    = 4
[pid  7579] write(13, "\31\0\0\0", 4)   = 4
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 680470878}) = 0
[pid  7579] ioctl(13, EVIOCGKEYCODE, 0x7fffff119ed0) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 680601878}) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 680672878}) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 685065878}) = 0
[pid  7579] select(17, [9 11 13 16], [16], [], {0, 10000}) = 2 (in [13], 
out [16], left {0, 10000})
[pid  7579] sendto(16, "\0\0\0\0", 4, 0, NULL, 0) = 4
[pid  7579] read(13, "\31\0\0\0", 4)    = 4
[pid  7579] write(13, "\31\0\0\0", 4)   = 4
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 685553878}) = 0
[pid  7579] ioctl(13, EVIOCGKEYCODE, 0x7fffff119ed0) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 685679878}) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 685789878}) = 0
[pid  7579] select(17, [9 11 13 16], [], [], {0, 10000}) = 2 (in [13 
16], left {0, 10000})
[pid  7579] recvfrom(16, "\3\1\0\0\0\0\2\320\1\220", 4096, 0, NULL, 
NULL) = 10
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 686011878}) = 0
[pid  7579] read(13, "\31\0\0\0", 4)    = 4
[pid  7579] write(13, "\31\0\0\0", 4)   = 4
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 686224878}) = 0
[pid  7579] mlock(0x7fffff119dd0, 4)    = 0
[pid  7579] ioctl(7, SNDCTL_DSP_RESET, 0x7fffff119de0) = 0
[pid  7579] munlock(0x7fffff119dd0, 4)  = 0
[pid  7579] ioctl(13, EVIOCGKEYCODE, 0x7fffff119ed0) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 686530878}) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 686617878}) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 691162878}) = 0
[pid  7579] select(17, [9 11 13 16], [16], [], {0, 10000}) = 2 (in [13], 
out [16], left {0, 10000})
[pid  7579] sendto(16, "\0\0\0\0", 4, 0, NULL, 0) = 4
[pid  7579] read(13, "\31\0\0\0", 4)    = 4
[pid  7579] write(13, "\31\0\0\0", 4)   = 4
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 691641878}) = 0
[pid  7579] lseek(6, 65536, SEEK_SET)   = 65536
[pid  7579] read(6, 
",\0002`\0\0\0\0`2\220\22\0\0\0\0\22\220h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGT0415.DL_,\0005`\0\0\0\0`5d\n\0\0\0\0\ndh\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGT0415.HL_,\0007`\0\0\0\0`7\266\21\0\0\0\0\21\266h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGT0416.DL_,\0:`\0\0\0\0`:\0\n\0\0\0\0\n\0h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGT0416.HL_,\0<`\0\0\0\0`<\200\22\0\0\0\0\22\200h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGT0419.DL_,\0?`\0\0\0\0`?\16\n\0\0\0\0\n\16h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGT0419.HL_,\0A`\0\0\0\0`A\250\21\0\0\0\0\21\250h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGT041D.DL_,\0D`\0\0\0\0`DT\v\0\0\0\0\vTh\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGT041D.HL_,\0F`\0\0\0\0`F\242\21\0\0\0\0\21\242h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGT041F.DL_,\0I`\0\0\0\0`I\254\n\0\0\0\0\n\254h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGT041F.HL_,\0K`\0\0\0\0`K\272\1
 7\0\0\0\0\17\272h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGT0804.DL_,\0M`\0\0\0\0`M\22\10\0\0\0\0\10\22h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGT0804.HL_,\0O`\0\0\0\0`O\322\21\0\0\0\0\21\322h\10\5\5\0\0\354
\0\0\0\1\0\0\1\vAGT0816.DL_,\0R`\0\0\0\0`R\34\n\0\0\0\0\n\34h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGT0816.HL_,\0T`\0\0\0\0`T\254\21\0\0\0\0\21\254h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGT0C0A.DL_,\0W`\0\0\0\0`W\32\n\0\0\0\0\n\32h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGT0C0A.HL_,\0Y`\0\0\0\0`Y}\26\0\0\0\0\26}h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGTCORE.JS_.\0\\`\0\0\0\0`\\{\25\0\0\0\0\25{h\10\5\5\0\0\354\0\0\0\1\0\0\1\fAGTCTL15.TL_\0,\0_`\0\0\0\0`_(\v\0\0\0\0\v(h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGTINST.IN_,\0a`\0\0\0\0`aX.\0\0\0\0.Xh\10\5\5\0\0\354\0\0\0\1\0\0\1\vAGTINTL.DL_.\0g`\0\0\0\0`g\16\4\0\0\0\0\4\16h\10\5\5\0\0\354\0\0\0\1\0\0\1\fAGTSCRP2.JS_\0.\0h`\0\0\0\0`h\254\200\0\0\0\0\200\254h\10\5\5\0\0\354\0\0\0\1\0\0\1\fAGTSCRPT.JS_\0,\0y`\0\0\0\0`yf\37\0\0\0\0\37fh\10\5\5\0\0\354\0\0\0\1\0\0\1\vAHA154X.SY_,\0}`\0\
 0\0\0`}\4\\\0\0\0\0\\\4h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAHRONBD.TT_*\0\211`\0\0\0\0`\211\243\276\0\0\0\0\276\243h\10\5\5\0\0\354\0\0\0\1\0\0\1\10AHUI.EX_\0,\0\241`\0\0\0\0`\241\330t\0\0\0\0t\
330h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAIC78U2.SY_,\0\260`\0\0\0\0`\260\30w\0\0\0\0w\30h\10\5\5\0\0\354\0\0\0\1\0\0\1\vAIC78XX.SY_,\0\277`\0\0\0\0`\277\317\35\0\0\0\0\35\317h\7\34\f48\354\0\0\0\1\0\0\1\vAICHMGT.CAT,\0\303`\0\0\0\0`\303\371\5\0\0\0\0\5\371h\3\3\26\2\30\354\0\0\0\1\0\0\1\vAICHMGT.INF.\0\304`\0\0\0\0`\304\257\17\0\0\0\0\17\257h\10\5\5\0\0\354\0\0\0\1\0\0\1\fAIRPLANE.BM_\0.\0\306`\0\0\0\0`\306\373\36\0\0\0\0\36\373h\10\5\5\0\0\354\0\0\0\1\0\0\1\fALEABANR.GI_\0(\0\312`\0\0\0\0`\312,E\0\0\0\0E,h\10\5\5\0\0\354\0\0\0\1\0\0\1\7ALG.EX_,\0\323`\0\0\0\0`\323\27\v\0\0\0\0\v\27h\10\5\5\0\0\354\0\0\0\1\0\0\1\nALIIDE.SY_\0,\0\325`\0\0\0\0`\325;$\0\0\0\0$;h\10\5\5\0\0\354\0\0\0\1\0\0\1\nALRSVC.DL_\0.\0\332`\0\0\0\0`\332\275\10\0\0\0\0\10\275h\10\5\5\0\0\354\0\0\0\1\0\0\1\fAMAIZRUL.GI_\0,\0\33
 4`\0\0\0\0`\334\263\3\0\0\0\0\3\263h\10\5\5\0\0\354\0\0\0\1\0\0\1\nAMIPRO.SA_\0,\0\335`\0\0\0\0`\335m\34\0\0\0\0\34mh\10\5\5\0\0\354\0\0\0\1\0\0\1\nAMSINT.SY_\0.\0\341`\0\0\0\0`\341\235y\0\0
\0\0y\235h\10\5\5\0\0\354\0\0\0\1\0\0\1\fAMSTREAM.DL_\0,\0\361`\0\0\0\0`\361\272<\0\0\0\0<\272h\10\5\5\0\0\354\0\0\0\1\0\0\1\vANABNR2.GI_,\0\371`\0\0\0\0`\371\3\273\0\0\0\0\273\3h\10\5\5\0\0\354\0\0\0\1\0\0\1\nANDLSO.TT_\0*\0\21a\0\0\0\0a\21\362\370\0\0\0\0\370\362h\10\5\5\0\0\354\0\0\0\1\0\0\1\tANGSA.TT_,\0001a\0\0\0\0a1\207\356\0\0\0\0\356\207h\10\5\5\0\0\354\0\0\0\1\0\0\1\nANGSAB.TT_\0,\0Oa\0\0\0\0aO\355\270\0\0\0\0\270\355h\10\5\5\0\0\354\0\0\0\1\0\0\1\nANGSAI.TT_\0,\0ga\0\0\0\0ag\315\370\0\0\0\0\370\315h\10\5\5\0\0\354\0\0\0\1\0\0\1\nANGSAU.TT_\0,\0\207a\0\0\0\0a\207\214\356\0\0\0\0\356\214h\10\5\5\0\0\354\0\0\0\1\0\0\1\vANGSAUB.TT_,\0\245a\0\0\0\0a\245\10\271\0\0"..., 
2048) = 2048
[pid  7579] ioctl(13, EVIOCGKEYCODE, 0x7fffff119ed0) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 709208878}) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 709290878}) = 0
[pid  7579] select(17, [9 11 13 16], [], [], {0, 10000}) = 1 (in [16], 
left {0, 10000})
[pid  7579] recvfrom(16, "\3\1\0\0\0\0\2\320\1\220", 4096, 0, NULL, 
NULL) = 10
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 709519878}) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 709586878}) = 0
[pid  7579] clock_gettime(CLOCK_MONOTONIC, {2927, 709652878}) = 0

>> I couldn't attach strace early enough to catch what is fd 17 exactly,
>> tough.
>>
>> Running Linux HVM guests works OK, tough. I only tested this in cooker
>> (mandriva devel version) on x86_64 host, with xen 3.1.1 (my attempt to
>> test 3.1 on stable release failed because of the other xend crash issue).
> 
> 32-bit or 64-bit Linux?
This happened on 64 bit linux.

Strangely, everything works OK now after a reboot, a minor update of xen 
package (just adding squashfs support), and a different ordering of 
network configuration at startup (no more explicit bridge setup before 
launching xend). My assumption is that xen is over-sensible to current 
network configuration: if you ever have a misconfigured interface or 
bridge, strange things may happen, such as already reported at:
http://lists.xensource.com/archives/html/xen-devel/2007-11/msg00128.html
-- 
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2007-12-03 14:14 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-11-13 21:47 Unable to run windows HVM guests with xen 3.1.1 Guillaume Rousse
2007-12-03  3:00 ` Mark Williamson
2007-12-03 14:14   ` Guillaume Rousse

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.