Bug#741873: qemu-kvm: crashes booting gnumach (Hurd) with multiboot options
23.03.2014 03:55, Gabriele Giacone wrote: Bisected. It works fine on wheezy. http://git.qemu.org/?p=qemu.git;a=commitdiff;h=4de6467cbc8f3ddff7f2dcb63f427b0e92de0e9d Ok, thank you! I'll file a SPU with both #719633 and #741873 patches. Michael, if you have other changes, integrate. Unfortunately, due to some family issues, I don't have any time these days for anything, so I can't. :( Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741873: qemu-kvm: crashes booting gnumach (Hurd) with multiboot options
On Thu, Mar 20, 2014 at 3:26 AM, Gabriele Giacone 1o5g4...@gmail.com wrote: On Wed, Mar 19, 2014 at 5:52 AM, Michael Tokarev m...@tls.msk.ru wrote: However, if we're to made a new stable release, I'd like to include quite some more changes too, which are useful for other users. Not that right now I have time for that :( I'm sure, as you already reminded, you would have to explain importance of each one. At the moment, I could propose #719633 debdiff if you agree about backporting it. Bisected. It works fine on wheezy. http://git.qemu.org/?p=qemu.git;a=commitdiff;h=4de6467cbc8f3ddff7f2dcb63f427b0e92de0e9d I'll file a SPU with both #719633 and #741873 patches. Michael, if you have other changes, integrate. -- G..e -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741873: qemu-kvm: crashes booting gnumach (Hurd) with multiboot options
On Wed, Mar 19, 2014 at 5:52 AM, Michael Tokarev m...@tls.msk.ru wrote: 19.03.2014 06:17, Gabriele Giacone wrote: [] Current qemu on wheezy (1.1.2) can boot hurd CD only on systems with hwaccel and by specifying --enable-kvm. it crashes without hwaccel, see [0]. Not a real problem on jenkins.d.n which has hwaccel, but IMHO [0] is important enough to get an upload to stable, it makes installing a hurd VM on a wheezy host hardware dependent. Whereas this bug affects Debian infrastructure, assuming d.n as part of Debian infrastructure and assuming that would count something if it was d.o. Please note that without hwaccel, it is just tooo slow to be useful. In my opinion anyway. This hardware dependency only means x86 (because on other arches we'll have to emulate the CPU anyway, and a. this bug will show up, and b. it will be painfully slow due to emulation), but x86 is the majority of debian machines these days. Other than that, -- it is difficult to find real (non-trash) x86 machine without hwaccel. Almost all machines without svn/vmx are just too old and slow to be useful. Very slow would be better than nothing due to crash IMO. From time to time, on #hurd someone without hwaccel joins interested in trying Hurd images/CDs; with current wheezy, user can not do that (unless using wheezy-backports). How about identifying changes to backport fixing this bug and proposing both to release team? [0] https://bugs.debian.org/719633 Here's the fix, which is rather simple (and is included into upstream 1.7.1 stable release): http://git.qemu.org/?p=qemu.git;a=commitdiff;h=33dfdb56f2f3c8686d218395b871ec12fd5bf30b I know, that let me backporting it and confirming that it fixes #719633 on wheezy as well. I meant changes to fix this one, #741873. At least finding out what released version fixed it should be easier than bisecting once version is found. Once someone points to them, another option (workaround) pops up: Holger might then evaluate to simply rebuild 1.1.2 + #741873 patch and install it on jenkins.d.n. 08:04 h01ger but i'm not interested in running anything else than wheezy+wheezy-backports there atn Hurd multiboot does work with current qemu on wheezy-backports (1.7.0+dfsg-2~bpo70+2). Is it enough? However, if we're to made a new stable release, I'd like to include quite some more changes too, which are useful for other users. Not that right now I have time for that :( I'm sure, as you already reminded, you would have to explain importance of each one. At the moment, I could propose #719633 debdiff if you agree about backporting it. -- G..e -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741873: qemu-kvm: crashes booting gnumach (Hurd) with multiboot options
On Thu, Mar 20, 2014 at 3:26 AM, Gabriele Giacone 1o5g4...@gmail.com wrote: Very slow would be better than nothing due to crash IMO. From time to time, on #hurd someone without hwaccel joins interested in trying Hurd images/CDs; with current wheezy, user can not do that (unless using wheezy-backports). (Err, not yet. 1.7.0+dfsg-4 aka 1.7.1 has not been backported yet). -- G..e -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741873: qemu-kvm: crashes booting gnumach (Hurd) with multiboot options
Hi Gabriele, thanks for filing this bug! And even more thanks for working on getting hurd tested on jenkins.d.n.! (as a very minor comment on this: why hurd-i386 and not hurd-amd64?) On Montag, 17. März 2014, Gabriele Giacone wrote: The intention is adding hurd-i386 to jenkins.d.n CI [0]. Currently VMs are booted with --kernel/--initrd options to pass preseed file url [1]. I'm about proposing changes to boot hurd with qemu multiboot options [2]. is multiboot the only way to boot the hurd from within qemu? cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#741873: qemu-kvm: crashes booting gnumach (Hurd) with multiboot options
[CC'ing d-hurd@ to get more ideas/opinions] On Tue, Mar 18, 2014 at 4:00 PM, Holger Levsen hol...@layer-acht.org wrote: (as a very minor comment on this: why hurd-i386 and not hurd-amd64?) (http://www.gnu.org/software/hurd/faq/64-bit.html) On Montag, 17. März 2014, Gabriele Giacone wrote: The intention is adding hurd-i386 to jenkins.d.n CI [0]. Currently VMs are booted with --kernel/--initrd options to pass preseed file url [1]. I'm about proposing changes to boot hurd with qemu multiboot options [2]. is multiboot the only way to boot the hurd from within qemu? We could boot it from CD but I guess we should recreate netinst CD to pass preseed file url to kernel or automate url insertion on grub with vncdo. With multiboot, I just tried to adhere to current (linux) configuration as much as possible. Current qemu on wheezy (1.1.2) can boot hurd CD only on systems with hwaccel and by specifying --enable-kvm. it crashes without hwaccel, see [0]. Not a real problem on jenkins.d.n which has hwaccel, but IMHO [0] is important enough to get an upload to stable, it makes installing a hurd VM on a wheezy host hardware dependent. Whereas this bug affects Debian infrastructure, assuming d.n as part of Debian infrastructure and assuming that would count something if it was d.o. How about identifying changes to backport fixing this bug and proposing both to release team? No way? wheezy-backports. [0] https://bugs.debian.org/719633 -- G..e -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741873: qemu-kvm: crashes booting gnumach (Hurd) with multiboot options
19.03.2014 06:17, Gabriele Giacone wrote: [] Current qemu on wheezy (1.1.2) can boot hurd CD only on systems with hwaccel and by specifying --enable-kvm. it crashes without hwaccel, see [0]. Not a real problem on jenkins.d.n which has hwaccel, but IMHO [0] is important enough to get an upload to stable, it makes installing a hurd VM on a wheezy host hardware dependent. Whereas this bug affects Debian infrastructure, assuming d.n as part of Debian infrastructure and assuming that would count something if it was d.o. Please note that without hwaccel, it is just tooo slow to be useful. In my opinion anyway. This hardware dependency only means x86 (because on other arches we'll have to emulate the CPU anyway, and a. this bug will show up, and b. it will be painfully slow due to emulation), but x86 is the majority of debian machines these days. Other than that, -- it is difficult to find real (non-trash) x86 machine without hwaccel. Almost all machines without svn/vmx are just too old and slow to be useful. How about identifying changes to backport fixing this bug and proposing both to release team? [0] https://bugs.debian.org/719633 Here's the fix, which is rather simple (and is included into upstream 1.7.1 stable release): http://git.qemu.org/?p=qemu.git;a=commitdiff;h=33dfdb56f2f3c8686d218395b871ec12fd5bf30b However, if we're to made a new stable release, I'd like to include quite some more changes too, which are useful for other users. Not that right now I have time for that :( Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741873: qemu-kvm: crashes booting gnumach (Hurd) with multiboot options
16.03.2014 23:24, Gabriele Giacone wrote: Package: qemu-kvm Version: 1.1.2+dfsg-6 Severity: important Tags: wheezy Control: fixed -1 1.7.0+dfsg-3 [ jessie machine with qemu packages from wheezy ] Hello. Thank you for the bugreport. It is always nice when the bug is submitted in already-fixed form. But I'm not really sure what to do with it. Maybe it is possible to find the necessary change which fixed the issue in later versions and backport it to wheezy -- is that what you have in mind? We'll have to explain to the release team that this change is safe and is important to have in wheezy in this case. Please note that this looks to me like a very specific use-case, which can, hopefully (with my lack of knowlege about gnumach), be worked around using different booting method. Can you please elaborate a bit what do you have in mind and expect from the maintainer to do? Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741873: qemu-kvm: crashes booting gnumach (Hurd) with multiboot options
[ CC'ing debian-qa@l.d.o ] On Mon, Mar 17, 2014 at 7:02 AM, Michael Tokarev m...@tls.msk.ru wrote: 16.03.2014 23:24, Gabriele Giacone wrote: Package: qemu-kvm Version: 1.1.2+dfsg-6 Severity: important Tags: wheezy Control: fixed -1 1.7.0+dfsg-3 [ jessie machine with qemu packages from wheezy ] Hello. Hi Michael, Thank you for the bugreport. It is always nice when the bug is submitted in already-fixed form. But I'm not really sure what to do with it. Maybe it is possible to find the necessary change which fixed the issue in later versions and backport it to wheezy -- is that what you have in mind? We'll have to explain to the release team that this change is safe and is important to have in wheezy in this case. Please note that this looks to me like a very specific use-case, which can, hopefully (with my lack of knowlege about gnumach), be worked around using different booting method. Can you please elaborate a bit what do you have in mind and expect from the maintainer to do? The intention is adding hurd-i386 to jenkins.d.n CI [0]. Currently VMs are booted with --kernel/--initrd options to pass preseed file url [1]. I'm about proposing changes to boot hurd with qemu multiboot options [2]. Given jenkins.d.o is wheezy and I was told such multiboot options make qemu 1.1.2 crash on wheezy, I filed this bug. If debian-qa decide to install qemu from wheezy-backports (1.7.0 atm), multiboot will work, no need to backport anything. As alternative, as you already explained, cherry-picking needed changes to upload to stable, trying to satisfy all requirements that implies. [0] http://jenkins.debian.net [1] http://anonscm.debian.org/gitweb/?p=users/holger/jenkins.debian.net.git;a=blob;f=bin/g-i-installation.sh;h=ced44aff86a872cdda9160cf58f450bdc9f0c3d7;hb=HEAD#l135 [2] http://darnassus.sceen.net/~hurd-web/hurd/running/qemu/#index9h1 Thanks, -- G..e -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741873: qemu-kvm: crashes booting gnumach (Hurd) with multiboot options
On Sun, Mar 16, 2014 at 08:24:03PM +0100, Gabriele Giacone wrote:
$ kvm -m 1024 --kernel gnumach --initrd initrd.gz
\$(ramdisk-create),ext2fs.static
--multiboot-command-line=\${kernel-command-line}
--host-priv-port=\${host-port}
--device-master-port=\${device-port} --exec-server-task=\${exec-task} -T
typed
gunzip:device:rd0 \$(task-create) \$(task-resume),ld.so.1 /hurd/exec
\$(exec-task=task-create)
KVM internal error. Suberror: 1
emulation failure
Just adding that it crashes without hwaccel as well, different way:
$ qemu-system-x86_64 -m 1024 --kernel gnumach --initrd initrd.gz \
\$(ramdisk-create),ext2fs.static
--multiboot-command-line=\${kernel-command-line} \
--host-priv-port=\${host-port} --device-master-port=\${device-port} \
--exec-server-task=\${exec-task} -T typed gunzip:device:rd0 \$(task-create) \
\$(task-resume),ld.so.1 /hurd/exec \$(exec-task=task-create)
qemu: fatal: Trying to execute code outside RAM or ROM at 0x8010
EAX=2badb002 EBX=9500 ECX=8010 EDX=0511
ESI= EDI=009fd000 EBP= ESP=6f34
EIP=8010 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00cf9300 DPL=0 DS [-WA]
CS =0008 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00cf9300 DPL=0 DS [-WA]
DS =0010 00cf9300 DPL=0 DS [-WA]
FS =0010 00cf9300 DPL=0 DS [-WA]
GS =0010 00cf9300 DPL=0 DS [-WA]
LDT= 8200 DPL=0 LDT
TR = 8b00 DPL=0 TSS32-busy
GDT= 000ca268 0027
IDT= 03ff
CR0=0011 CR2= CR3= CR4=
DR0= DR1= DR2=
DR6=
DR6=0ff0 DR7=0400
CCS=004a8000 CCD=0095 CCO=SHLL
EFER=
FCW=037f FSW= [ST=0] FTW=00 MXCSR=1f80
FPR0= FPR1=
FPR2= FPR3=
FPR4= FPR5=
FPR6= FPR7=
XMM00=
XMM01=
XMM02=
XMM03=
XMM04=
XMM05=
XMM06=
XMM07=
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741873: qemu-kvm: crashes booting gnumach (Hurd) with multiboot options
Package: qemu-kvm
Version: 1.1.2+dfsg-6
Severity: important
Tags: wheezy
Control: fixed -1 1.7.0+dfsg-3
[ jessie machine with qemu packages from wheezy ]
To reproduce it, see
http://darnassus.sceen.net/~hurd-web/hurd/running/qemu/#index9h1
and below.
$ kvm -m 1024 --kernel gnumach --initrd initrd.gz
\$(ramdisk-create),ext2fs.static
--multiboot-command-line=\${kernel-command-line} --host-priv-port=\${host-port}
--device-master-port=\${device-port} --exec-server-task=\${exec-task} -T typed
gunzip:device:rd0 \$(task-create) \$(task-resume),ld.so.1 /hurd/exec
\$(exec-task=task-create)
KVM internal error. Suberror: 1
emulation failure
EAX=2badb002 EBX=9500 ECX=8010 EDX=0511
ESI= EDI=009fd000 EBP= ESP=6f34
EIP=8010 EFL=0016 [AP-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00c09300 DPL=0 DS [-WA]
CS =0008 00c09b00 DPL=0 CS32 [-RA]
SS =0010 00c09200 DPL=0 DS [-W-]
DS =0010 00c09300 DPL=0 DS [-WA]
FS =0010 00c09300 DPL=0 DS [-WA]
GS =0010 00c09300 DPL=0 DS [-WA]
LDT= 8200 DPL=0 LDT
TR = 8b00 DPL=0 TSS32-busy
GDT= 000ca268 0027
IDT= 03ff
CR0=0011 CR2= CR3= CR4=
DR0= DR1= DR2=
DR3=
DR6=0ff0 DR7=0400
EFER=
Code=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
