Bug#402289: using -kernel-kqemu causes kernel panics in guest OS
On Mon, Apr 16, 2007, Sam Morris wrote: Given that it is not likely that QEMU's patches (which are more extensive in QEMU's CVS trunk) are not likely to be merged upstream into bochs any time soon, I think it's best if a separate bochsbios-qemu source package is introduced, that will build the required BIOS file. Thoughts? Sounds sane; are the QEMU patches distributed with QEMU or separately? In the first case, I think it shouldn't need a new source package, int eh second case perhaps it should, perhaps not. Oh, I've not looked into the vgabios.diff or any of the other binaries missing from Debian's qemu package since I'm assuming they are not necessary for -kernel-qemu to function. Ideally it'd be nice to get them built eventually. I think these should be dealt with too; I got plenty of crashes in seemingly graphical drivers too. -- Loïc Minier
Bug#402289: using -kernel-kqemu causes kernel panics in guest OS
On Mon, Jul 09, 2007 at 11:34:35AM +0200, Loïc Minier wrote: On Mon, Apr 16, 2007, Sam Morris wrote: Given that it is not likely that QEMU's patches (which are more extensive in QEMU's CVS trunk) are not likely to be merged upstream into bochs any time soon, I think it's best if a separate bochsbios-qemu source package is introduced, that will build the required BIOS file. Thoughts? Sounds sane; are the QEMU patches distributed with QEMU or separately? In the first case, I think it shouldn't need a new source package, int eh second case perhaps it should, perhaps not. Most of the patches are actually merged into bochs CVS. The diff against the bochs bios is in the QEMU sources and is currently 1600 bytes long. The problem is that you have to build it with -DQEMU (or something like that), which is in favor of having two different packages for bochs and QEMU. But we could maybe keep one source package. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402289: using -kernel-kqemu causes kernel panics in guest OS
On Mon, 2007-07-09 at 11:34 +0200, Loïc Minier wrote: On Mon, Apr 16, 2007, Sam Morris wrote: Given that it is not likely that QEMU's patches (which are more extensive in QEMU's CVS trunk) are not likely to be merged upstream into bochs any time soon, I think it's best if a separate bochsbios-qemu source package is introduced, that will build the required BIOS file. Thoughts? Sounds sane; are the QEMU patches distributed with QEMU or separately? In the first case, I think it shouldn't need a new source package, int eh second case perhaps it should, perhaps not. Ah, I forgot about this bug! Anyway, I tried to do this myself but couldn't even get bochsbios to build. Some of the patches didn't even apply to the latest bochs CVS checkout, and no one upstream was able to tell me how to check out the sources that were necessary to reproduce the binary BIOS files that Qemu ships. The result is that Qemu upstream is presumably violating the license of bochs. But due to the lack of any activity on the part of upstream WRT this bug (even documenting the situation in README.Debian would be better than nothing) I lost motivation to actually do anything about it. Which is a shame because it means that Debian users can't use one of Qemu's best features, and so are more likely to fall back to the non-free VMware, or even to switch to a non-broken distribution altogether. :( -- Sam Morris [EMAIL PROTECTED]
Bug#402289: using -kernel-kqemu causes kernel panics in guest OS
On Mon, Jul 09, 2007, Aurelien Jarno wrote: Most of the patches are actually merged into bochs CVS. The diff against the bochs bios is in the QEMU sources and is currently 1600 bytes long. The problem is that you have to build it with -DQEMU (or something like that), which is in favor of having two different packages for bochs and QEMU. But we could maybe keep one source package. Ok; perhaps we can manage this patch as a file in the Boch source package and build it in two flavors, one regular and one qemu? Another approach, a bit more heavyweight, would be to provide a bochs-src package and let qemu ship the patch and build a boch-qemu flavor based on this source. Do you think one of the two is feasible? -- Loïc Minier
Bug#402289: using -kernel-kqemu causes kernel panics in guest OS
Apparently the QEMU folks build their bios.bin from bochs' CVS trunk. bochs 2.3 is far too old--it does not even include the files patched by QEMU's bios.diff. Presumably we don't want to force the bochs maintainers to keep updating their bochs packages to the latest version in bochs' cvs, and/or to keep updating their package with QEMU's bios.diff. Given that it is not likely that QEMU's patches (which are more extensive in QEMU's CVS trunk) are not likely to be merged upstream into bochs any time soon, I think it's best if a separate bochsbios-qemu source package is introduced, that will build the required BIOS file. Thoughts? Oh, I've not looked into the vgabios.diff or any of the other binaries missing from Debian's qemu package since I'm assuming they are not necessary for -kernel-qemu to function. Ideally it'd be nice to get them built eventually. -- Sam Morris http://robots.org.uk/ PGP key id 1024D/5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 signature.asc Description: This is a digitally signed message part
Bug#402289: using -kernel-kqemu causes kernel panics in guest OS
On Wed, Feb 14, 2007 at 04:28:26PM -0500, Michael Gilbert [EMAIL PROTECTED] wrote: On 2/14/07, Robert Millan wrote: So, why not just updating bochs to CVS version? that makes sense. the concern would be potentially introducing RC bugs with the new bochs (since the etch release is nigh). Why not apply the second part of the qemu patch to the bochs bios to the bochs source, which doesn't have any impact on the build, and do a 2-pass build for the bios, both with and without the BX_QEMU macro defined. That would build the current bios unmodified and the qemu variant. Then qemu would need to be modified to use the qemu variant, be it put in a separate package or in a different file. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402289: using -kernel-kqemu causes kernel panics in guest OS
On 2/14/07, Robert Millan wrote: So, why not just updating bochs to CVS version? that makes sense. the concern would be potentially introducing RC bugs with the new bochs (since the etch release is nigh). i'd say the only option in the etch-timeframe is to disable the -kernel-kqemu flag, but you could perhaps talk to the release managers about this. mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402289: using -kernel-kqemu causes kernel panics in guest OS
This is caused by qemu using the PC-BIOS from the bochsbios package instead of the one packages with the qemu tarball. It's from bochs, but a much more recent CVS version. if this is the case, then there should be two versions of the bochsbios package (similar to what is done for python, the kernel, gcc, etc). one version should be bochsbios2.1 (that supports the current bochs release in testing and whatever other apps depend on that version) and another should be bochsbios2.3 (that supports the latest needs of qemu 0.8.2). this is a pretty big problem, and i think that the -kernel-kqemu option should be disabled until it is fixed. i wouldn't want to see etch released with a major bug like this. mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402289: using -kernel-kqemu causes kernel panics in guest OS
what is the status of this? the problem is still existing and makes qemu debian packages pretty useless for me. i'm aware of the fact that you rebuild the upstream tarball without the pc-bios files, but as they are pretty important, is there any special reason why you are pulling them out, except for avoiding the dublication of shipping them? -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402289: using -kernel-kqemu causes kernel panics in guest OS
This is caused by qemu using the PC-BIOS from the bochsbios package instead of the one packages with the qemu tarball. It's from bochs, but a much more recent CVS version. Marc. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402289: using -kernel-kqemu causes kernel panics in guest OS
Package: qemu Version: 0.8.2-4 Severity: normal When using the qemu from the Debian repositories, trying to use -kernel-kqemu results in a kernel panic in the guest OS - this has been tested with both Debian Etch and Fedora Core 6 as the guest OS. This is with kqemu either from the Debian repositories or from source. Swapping in QEMU built from the official source results in no such problems. Thanks -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-k7 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages qemu depends on: ii bochsbios2.3-2 BIOS for the Bochs emulator ii libasound2 1.0.13-1ALSA library ii libc62.3.6.ds1-8 GNU C Library: Shared libraries ii libncurses5 5.5-5 Shared libraries for terminal hand ii libsdl1.2debian 1.2.11-7Simple DirectMedia Layer ii openhackware 0.4.1-2 OpenFirmware emulator for PowerPC ii proll18-2JavaStation PROM 2.x compatible re ii vgabios 0.6a-1 VGA BIOS software for the Bochs an ii zlib1g 1:1.2.3-13 compression library - runtime Versions of packages qemu recommends: pn debootstrap none (no description available) ii sharutils 1:4.2.1-15 shar, unshar, uuencode, uudecode pn vde none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
