Re: [Qemu-devel] QCOW(2) image corruption under QEMU 0.9.0 reproducible
herbie hancock wrote: Hello, i had also a reproducible disk crash: info of the last good image, size is about 3,5GB I never experienced such a bad problem with qemu before, maybe it is a problem with qcow2 format ? After the problems with qcow2 images which I reported here a few weeks ago, I've only been using qcow images (under QEMU 0.9.0), without such surprises. So it seems qemu has some bug related to qcow2 images, maybe manifesting itself only after they get larger than 4GB... Best regards J Esteves ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] pcnet32 driver change, please test
In message: [EMAIL PROTECTED]
Andreas Schwab [EMAIL PROTECTED] writes:
: Paul Brook [EMAIL PROTECTED] writes:
:
: : I find this curious... C99 (6.7.2.1) says the allocation order of
: : bit-fields within a unit (high-order to low-order or low-order to
: : high-order) is implementation defined. I can't see any requirement
: : for this, so is it just convention that bitfields on big endian systems
: : start from the most significant bit, and those on little endian systems
: : start from the least significant bit? (My thinking is that endianness
: : usually refers to byte ordering and not so much bit ordering.)
:
: This is a convention that goes back a very long ways. It was this way
: in the mid 1980's, and has remained true through today. I've
: personally observed this to be the case on many different MIPS
: compilers, ARM compilers and SPARC compilers over the years.
:
: I'm fairly sure I've seen targets that use other bitfield orderings, though
I
: can't remember offhand what they were.
:
: Bi-endian targets are examples of this. The bitfield ordering is normally
: independent of the selected byte order. For example, big-endian MIPS has
: little endian bit order.
Except that compilers use the convention that was described above.
Big endian MIPS definitely uses a different bit ordering for C bit
fields than little endian MIPS. This is true for compilers from SGI,
DEC and GNU and NetBSD, FreeBSD, Linux, Ultrix, OSF, and IRIX. All of
them use the following, or variants for, say, the IP header:
struct ip {
#if BYTE_ORDER == LITTLE_ENDIAN
unsigned int ip_hl:4, /* header length */
ip_v:4;/* version */
#endif
#if BYTE_ORDER == BIG_ENDIAN
unsigned int ip_v:4,/* version */
ip_hl:4; /* header length */
#endif
...
Warner
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] pcnet32 driver change, please test
In message: [EMAIL PROTECTED] Stuart Brady [EMAIL PROTECTED] writes: : On Fri, Mar 02, 2007 at 08:09:49PM +, Thiemo Seufer wrote: : Hello All, : : I changed the pcnet32 driver to get rid of bitfields in its : implementation, now it works also on big endian host systems. : : I find this curious... C99 (6.7.2.1) says the allocation order of : bit-fields within a unit (high-order to low-order or low-order to : high-order) is implementation defined. I can't see any requirement : for this, so is it just convention that bitfields on big endian systems : start from the most significant bit, and those on little endian systems : start from the least significant bit? (My thinking is that endianness : usually refers to byte ordering and not so much bit ordering.) This is a convention that goes back a very long ways. It was this way in the mid 1980's, and has remained true through today. I've personally observed this to be the case on many different MIPS compilers, ARM compilers and SPARC compilers over the years. Warner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] pcnet32 driver change, please test
In message: [EMAIL PROTECTED] Paul Brook [EMAIL PROTECTED] writes: : : I find this curious... C99 (6.7.2.1) says the allocation order of : : bit-fields within a unit (high-order to low-order or low-order to : : high-order) is implementation defined. I can't see any requirement : : for this, so is it just convention that bitfields on big endian systems : : start from the most significant bit, and those on little endian systems : : start from the least significant bit? (My thinking is that endianness : : usually refers to byte ordering and not so much bit ordering.) : : This is a convention that goes back a very long ways. It was this way : in the mid 1980's, and has remained true through today. I've : personally observed this to be the case on many different MIPS : compilers, ARM compilers and SPARC compilers over the years. : : I'm fairly sure I've seen targets that use other bitfield orderings, though I : can't remember offhand what they were. None of them are supported by FreeBSD and/or NetBSD... Warner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QCOW image corruption under QEMU 0.9.0
J M Cerqueira Esteves wrote: After shutting down the guest, I inspected its image files with qemu-info, which reported for hda image: nisaba.hda.qcow file format: raw virtual size: 4.3G (4596273152 bytes) disk size: 4.3G but hda was supposed to have a virtual size of approximately 20 GB, QCOW2 format and a saved snapshot... And now I got another corrupted image: This time, after installing some packages in a similar Debian guest, the system froze while shutting down (using 100% CPU on host). I then noticed that its supposed QCOW2 image file (a 20 GB virtual disk, in a by then more than 4GB file) was no longer considered to be a QCOW2 image, as above. Curiously this damaged image file has 4543348736 bytes. I wonder if there some new bug triggered by the image file size, for some size around 45 bytes... Fortunately this time I have a backup copy of the virtual disk state just before it was corrupted. I'll try to see what happens if I convert it from qcow2 to qcow before proceeding. Any suggestions? Best regards J Esteves ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QCOW image corruption under QEMU 0.9.0
J M Cerqueira Esteves wrote: Curiously this damaged image file has 4543348736 bytes. I wonder if there some new bug triggered by the image file size, for some size around 45 bytes... I have a copy of the disk image file as it was just before starting the qemu run which damaged it, and now I noticed that, during that qemu run, the image file size did not change: 4543348736 bytes. However, comparing both images with cmp -l shows extensive changes. Just an example, from the first bytes (byte number, original value, corrupted value): 1 121 0 2 106 0 3 111 0 4 373 0 8 2 0 24 14 0 28 5 0 39 50 0 47 20 0 52 1 0 55 20 0 60 2 0 1881 0 200 1887 0 40 1889 0 200 1895 0 100 9049 200 0 9054 1 0 9055 220 0 9057 200 0 9061 60 0 9062 115 0 9063 100 0 ... many more zeroed out... 49487 220 0 49569 200 0 49573 325 0 49574 357 0 49575 300 0 49665 0 147 49666 0 145 49667 0 55 49668 0 62 49669 0 56 49670 0 66 49671 0 56 49672 0 61 49673 0 70 49674 0 55 49675 0 63 49676 0 55 49677 0 153 ... many more un-zeroed ... 49853 0 40 49854 0 151 49855 0 163 49856 0 40 49857 200 141 49858 0 166 49859 0 141 49860 0 151 49861 46 154 49862 174 141 49863 140 142 49864 0 154 49865 0 145 ... many more un-zeroed ... 49983 0 142 49984 0 157 49985 200 157 49986 0 164 49987 0 40 49988 0 171 49989 15 157 49990 354 165 49991 200 162 49992 0 40 49993 200 155 49994 0 141 49995 0 143 49996 0 150 49997 16 151 49998 1 156 4 260 145 5 0 56 50001 0 12 50002 0 12 ... Best regards J Esteves ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QCOW image corruption under QEMU 0.9.0
J M Cerqueira Esteves wrote: This time, after installing some packages in a similar Debian guest, the [guest] system froze while shutting down (using 100% CPU on host). I then noticed that its supposed QCOW2 image file (a 20 GB virtual disk, in a by then more than 4GB file) was no longer considered to be a QCOW2 image, as above. Curiously this damaged image file has 4543348736 bytes. I wonder if there some new bug triggered by the image file size, for some size around 45 bytes... I took a copy of that qcow2 image file (made just before the 'fatal' qemu session), converted it to qcow, restarted qemu using this qcow version, reinstalled the additional Debian packages I had installed during the corrupting session (and more), even rebooted with a Debian pre-built 2.6.18 k7 kernel (the previous one there was the '686' variant). The resulting image file now has 4555382784 bytes (a bit larger than the previously damaged image) and it is still recognized as a qcow image. It seems there is some qcow2-specifig bug... Best regards J Esteves ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] QCOW image corruption under QEMU 0.9.0
Greetings I got some error messages shortly after booting a Debian guest under QEMU 0.9.0. I did not annotate those, but they made me believe there could be disk access problems, and if fact something weird happened to one of the disk images (this was using two images, for hda and hdb): After shutting down the guest, I inspected its image files with qemu-info, which reported for hda image: nisaba.hda.qcow file format: raw virtual size: 4.3G (4596273152 bytes) disk size: 4.3G but hda was supposed to have a virtual size of approximately 20 GB, QCOW2 format and a saved snapshot... The hdb image still seems OK: image: nisaba.hdb.qcow file format: qcow2 virtual size: 2.0G (2147483648 bytes) disk size: 216M cluster_size: 4096 Snapshot list: IDTAG VM SIZEDATE VM CLOCK 1 2007021766M 2007-02-17 05:58:40 46:06:17.193 I'll keep a copy of the damaged image in case someone competent on qemu and qcow wishes to inspect it, but in case this may be suggestive: I noticed that the only non-zero bytes until byte 12288 (where a first 'more random' sequence starts) are: byte 4102: 0x20 4110: 0x30 4118: 0x40 ... and so on, until 4206: 0xf0 4221-4222: 0x0110 4229-4230: 0x0120 4237-4238: 0x0130 4245-4246: 0x0140 4252-4254: 0xd547b0 4260-4262: 0xd547c0 ... 8180-8182: 0xd56660 8188-8190: 0xd56670 11776-11791: 0x6c6f3d 6c6f0a 6574 68303d 6574 68300a Unvortunately I don't have an older copy of the hda image with which to compare this broken one. In any case I have been running, in the same host, several 32-bit guests with Debian and one with Windows XP, almost without any problems, first under QEMU 0.8.2 and since February 11 under QEMU 0.9.0 (with some images then migrated from QCOW to QCOW2). Details on the configuration: Host: AMD Athlon 64 3500+ (HP dx5150 MT) with Ubuntu 6.06 LTS, kernel 2.6.15-28-amd64-k8. VDE: 'backported' (just rebuilding the package) from Debian testing's vde 1.5.11-1. QEMU: 0.9.0, configured with --cc=gcc-3.4 --enable-alsa kqemu: 1.3.0pre11 Guest: Debian Etch (32-bit), with kernel 2.6.18-k7 (if I remember correctly); / was on hda, the failed image file; /tmp and swap on hdb, the surviving image. QEMU was invoked with vdeq qemu-system-x86_64 \ -kernel-kqemu \ -pidfile nisaba.pid \ -m 192 \ -std-vga \ -net nic,vlan=0,model=rtl8139,macaddr=4A:4D:23:00:00:01 \ -net vde,vlan=0,sock=/var/run/vde/tap-vde-1.ctl \ -hda nisaba.hda.qcow -hdb nisaba.hdb.qcow Best regards J Esteves ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: QCOW image corruption under QEMU 0.9.0
J M Cerqueira Esteves wrote: 11776-11791: 0x6c6f3d 6c6f0a 6574 68303d 6574 68300a 6c6f 3d 6c6f 0a 65746830 3d 65746830 0a or, of course (duh, I should have noticed, although I'm not sure this can help), lo=lo\n eth0=eth0\n ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] FreeBSD Support
In message: [EMAIL PROTECTED]
Ben Taylor [EMAIL PROTECTED] writes:
: Start with the configure script and Makefiles, and any very specfic, targeted
: and small patches and let those changes slowly propogate out.
Most of the FreeBSD ports patches are relatively easy to justify and
explain. For example, FreeBSD port system defines SDL_CONFIG in a way
that's overridable. There's a patch that looks like:
Index: qemu/configure
@@ -204,7 +204,7 @@
if test -z $sdl ; then
-sdl_config=sdl-config
+sdl_config=${SDL_CONFIG}
sdl=no
sdl_static=no
which is straight forward enought, but still wrong... It should be:
Index: qemu/configure
@@ -204,7 +204,7 @@
if test -z $sdl ; then
-sdl_config=sdl-config
+sdl_config=${SDL_CONFIG:-sdl-config}
sdl=no
sdl_static=no
to still work on non-FreeBSD systems or on FreeBSD systems not using
the ports
There's a lot of niggles like this, however...
Warner
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Fix char signedness
In message: [EMAIL PROTECTED]
Andreas Schwab [EMAIL PROTECTED] writes:
: Johannes Schindelin [EMAIL PROTECTED] writes:
:
: It has been a really long time I have been working on a broken system that
: did not default to signed.
:
: The only thing that is broken is your knowlege of C.
gcc on ARM systems default to unsigned. The C standard specifically
states that char is either signed or unsigned at the whim of the
implementor:
Section 6.2.5 para 15:
[#15] The three types char, signed char, and unsigned char
are collectively called the character types. The
implementation shall define char to have the same range,
representation, and behavior as either signed char or
unsigned char.30)
...
30)CHAR_MIN, defined in limits.h, will have one of the
values 0 or SCHAR_MIN, and this can be used to
distinguish the two options. Irrespective of the choice
made, char is a separate type from the other two and is
not compatible with either.
...
I just confirmed that gcc on arm does indeed default to unsigned
chars:
% cat xxx.c
signed char cs = -1;
unsigned char cu = -1;
char c = -1;
void foo()
{
int i = 0;
if (cs 0) i++;
if (cu 0) i++;
if (c 0) i++;
}
% gcc -v
Using built-in specs.
Configured with: FreeBSD/arm system compiler
Thread model: posix
gcc version 3.4.4 [FreeBSD] 20050518
% gcc -W -c xxx.c
xxx.c: In function `foo':
xxx.c:9: warning: comparison is always false due to limited range of data type
xxx.c:10: warning: comparison is always false due to limited range of data type
%
Note: line 10 is the naked char.
Warner
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Fix char signedness
In message: [EMAIL PROTECTED] Johannes Schindelin [EMAIL PROTECTED] writes: : Hi, : : On Fri, 27 Oct 2006, Andreas Schwab wrote: : : Johannes Schindelin [EMAIL PROTECTED] writes: : : It has been a really long time I have been working on a broken system that : did not default to signed. : : The only thing that is broken is your knowlege of C. : : Okay. : : And what system did you encounter this behaviour on? It is the default for arm with gcc, for one. The behavior is standards conforming, per section 6.2.5, para 15 of ANSI-C (1989) standard. Your characterization of it as 'broken' is wrong. Warner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] config file support
In message: [EMAIL PROTECTED] Rob Landley [EMAIL PROTECTED] writes: : Seems to me they both address roughly the same : issues with roughly the same considerations. : : Using a *.PIF file is the Windows way. Using the command line is Linux. Except for complicated things, like, say, X's config file. Warner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] keyboard patch for Brazilian ABNT-2 keyboard
Hi, QEMU developers I'm using qemu 0.8.1 and 0.8.2 with keyboard wit Brazilian layout (ABNT-2). I was unable to use some of the keys so I had to use the attached patch. I hope it will be useful for everybody. Best regards -- Carlos A. M. dos Santos patch-sdl.c Description: Binary data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] ENOMEDIUM OS X patch
In message: [EMAIL PROTECTED] Eric Lowe [EMAIL PROTECTED] writes: : Yes you are correct Solaris does not define this : either, and I doubt other *nix systems do. : : Can this just be changed to : : #ifndef ENOMEDIUM : #define ENOMEDIUM blahblah : #endif : : or somesuch? None of the BSDs define it either. At least not FreeBSD nor OpenBSD. It isn't suprising then that OS X doesn't define it. It wasn't in BSD 4.4-lite. Warner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] DSC timeouts using all of -hda -hdb -hdc -cdrom
J M Cerqueira Esteves wrote: vdeq qemu-system-x86_64 .. -hda .. -hdb .. -hdd .. -cdrom .. -boot d On many CD reading attempts there were longer-than-normal waits, for which the kernel reported hdc: DSC timeout [...] But it *didn't* happen when I tried the same installation process only using one virtual disk image (-hda ... -cdrom ...). Also: - had DSC timeouts with -hda ... -hdd ... -cdrom - didn't have DSC timeouts with -hda ... -hdb ... -cdrom So the culprit of the cdrom timeouts seems to be -hdd ... but why? -- +351 939838775 Skype:jmcerqueira http://del.icio.us/jmce ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] -kernel-kqemu issue? hwclock w/ libc6-i686: segmentation fault on reboot
I submited the attached report to the Debian bug tracking system, but just now I noticed that that segfault of hwclock with libc6-i686 (in a guest Debian testing system) only occurs if the virtual machine is started with -kernel-kqemu. Could this be related to some kqemu bug? Best regards J Esteves -- +351 939838775 Skype:jmcerqueira http://del.icio.us/jmce ---BeginMessage--- Package: util-linux Version: 2.12r-10 Severity: normal Additional system information: This occurred inside a QEMU virtual machine running Debian testing (etch) i386, under the following QEMU HOST SETUP: host CPU: AMD Athlon 64 3500+ host operating system: Ubuntu 6.06 LTS, kernel: Ubuntu 2.6.15-26-amd64-k8 kqemu: 1.3.0pre9 QEMU: 0.8.2, configured with -cc=gcc-3.4 --enable-alsa invoked with qemu-system-x86_64 ... -kernel-kqemu ... In the Debian etch guest system, When libc6-i686 is installed hwclock segfaults on reboots: /etc/rc6.d/K25hwclock.sh: line 58: 3584 Segmentation fault /sbin/hwclock --systohc $GMT $HWCLOCKPARS $BADYEAR This does not occur when libc6-i686 is not installed. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages util-linux depends on: ii libc6 2.3.6-15 GNU C Library: Shared libraries ii libncurses5 5.5-2 Shared libraries for terminal hand ii libslang2 2.0.6-2The S-Lang programming library - r ii libuuid1 1.39-1 universally unique id library ii lsb-base 3.1-10 Linux Standard Base 3.1 init scrip ii zlib1g1:1.2.3-13 compression library - runtime util-linux recommends no packages. -- no debconf information ---End Message--- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu under x86_64: grub segfault, ld-linux.so segfault, lost ticks
As I said before, under Host CPU: AMD Athlon 64 3500+ (machine: HP dx5150 MT) Host operating system: Ubuntu 6.06 LTS Host kernel: one of the Ubuntu pre-packaged ones, 2.6.15-26-amd64-k8 (SMP PREEMPT) QEMU: 0.8.2, configured with -cc=gcc-3.4 --enable-alsa kqemu: 1.3.0pre9 I couldn't install Debian amd64 testing (etch) in a vm because of an Unexpected exception 0x0d on the host, crashing qemu. I'm able to install If I *disable* use of kqemu, but: - grub segfaults, failing to install the boot loader on the guest hard disk (previously also noticed this installing a kubuntu guest), so I used lilo; - installing new Debian amd64 kernel packages seems to work, except that I get an error like this on the console: ld-linux.so.2[5145]: segfault at bffc rip 56565019 rsp 8100c000 error 6 - I get warnings about lost ticks and the clock runs too fast: warning: many lost ticks Your time source seems to be instable or some driver is hogging interrupts Best regards J Esteves -- +351 939838775 Skype:jmcerqueira http://del.icio.us/jmce ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] kqemu in x86_64: (host) exception 0x0d in monitor space
Greetings Summary: qemu-system-x86_64 with kqemu (running under Ubuntu on a Athlon 64) crashes while installing a guest Debian amd64 testing (etch) system, with the host reporting (in kernel logs): kqemu: aborting: Unexpected exception 0x0d in monitor space Host CPU: AMD Athlon 64 3500+ (machine: HP dx5150 MT) Host operating system: Ubuntu 6.06 LTS Host kernel: one of the Ubuntu pre-packaged ones, 2.6.15-26-amd64-k8 (SMP PREEMPT) VDE: 'backported' (just rebuilding the package) from Debian testing's vde 1.5.11-1. QEMU: 0.8.2, configured with -cc=gcc-3.4 --enable-alsa kqemu: 1.3.0pre9 I tried to install Debian amd64 testing (etch) from a snapshot netinst iso image downloaded yesterday, invoking vdeq qemu-system-x86_64 \ -pidfile /srv/qemu/nisaba.pid \ -m 160 \ -net nic,vlan=0,model=rtl8139,macaddr=4A:4D:23:00:00:01 \ -net vde,vlan=0,sock=/var/run/vde/tap-vde-1.ctl \ -hda /srv/qemu/$NAME.qcow \ -cdrom /srv/ark/cd/debian-testing-amd64-netinst-20060810.iso \ -boot d Booted in expert mode, chose language, keyboard layout, country, locale parameters, and just after I chose detect and mount cdrom qemu crashed (apparently immediately after (very briefly) showing a progress bar with detecting hardware to find cd-rom drives), with the (host-side) output ES = CS =0033 00affa00 SS =002b 00cff200 DS = FS = GS = LDT= 8000 TR =0040 8030e000 206f 80008930 GDT= 8030c000 0080 IDT= 8030d000 1000 CR0=8005003b CR2=2b599766f800 CR3=074c4000 CR4=06e0 Unsupported return value: 0x In a second attempt I got RAX=2b80af1d7d20 RBX=2b80af1d49e8 RCX=0008 RDX=0008 RSI=2b80af393800 RDI=0053f478 RBP=7f9fa2c0 RSP=7f9fa1d8 R8 =2b80af393800 R9 = R10=0053f478 R11=0002 R12= R13=0005 R14=2b80af0d54b0 R15=00402a18 RIP=2b80af0ce390 RFL=00010287 [--S--PC] CPL=3 II=0 A20=1 HLT=0 ES = CS =0033 00affa00 SS =002b 00cff200 DS = FS = GS = LDT= 8000 TR =0040 8030e000 206f 80008930 GDT= 8030c000 0080 IDT= 8030d000 1000 CR0=8005003b CR2=2b80af393800 CR3=07b48000 CR4=06e0 Unsupported return value: 0x For every such test, the host's dmesg and kernel logs reported the following: kqemu: aborting: Unexpected exception 0x0d in monitor space err= CS:EIP=f180:f0002806 SS:SP=:f00c7e00 The above crash does not happen when qemu-system-x86_64 is invoked with the additional option -no-kqemu. In case this issue is already known: is there any way to avoid this crash (maybe some boot time parameter for the Debian guest kernel?) without disabling kqemu? Any suggestions for additional information gathering here which could help solve this issue? Best regards (and *many* thanks for QEMU) J Esteves -- +351 939838775 Skype:jmcerqueira http://del.icio.us/jmce ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] kqemu in x86_64: (host) exception 0x0d in monitor space
J M Cerqueira Esteves wrote: Summary: qemu-system-x86_64 with kqemu (running under Ubuntu on a Athlon 64) crashes while installing a guest Debian amd64 testing (etch) system, with the host reporting (in kernel logs): kqemu: aborting: Unexpected exception 0x0d in monitor space I forgot to mention that a (32 bit) Windows XP Pro guest has been running without problems on the same qemu-system-x86_64. -- +351 939838775 Skype:jmcerqueira http://del.icio.us/jmce ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] kqemu in x86_64: (host) exception 0x0d in monitor space
J M Cerqueira Esteves wrote: Summary: qemu-system-x86_64 with kqemu (running under Ubuntu on a Athlon 64) crashes while installing a guest Debian amd64 testing (etch) system, with the host reporting (in kernel logs): kqemu: aborting: Unexpected exception 0x0d in monitor space However, with the same setup, and with kqemu active, I was able to install Kubuntu 6.06 amd64, without experiencing such a crash. Still, two issues with that Kubuntu instance: - grub segfaulted, failing to install the boot loader on the hard disk image (I ended up using lilo instead); this also happened previously when trying to install debian testing amd64 *without using kqemu* (maybe some grub bug?); - without or without the kernel option clock=pit I got, already at boot time: Losing some ticks... checking if CPU frequency changed [...] warning: many lost ticks Your time source seems to be instable or some driver is hogging interupts and now, about 1.5 hour after booting, the guest clock is about 1.5 hour ahead of the host clock (maybe because the host has been idle and working at about 1/2 the full clock speed?) This clock shifting did not occur with a Windows XP Pro guest, which usually remained late by less than 1 minute. Best regards J Esteves -- +351 939838775 Skype:jmcerqueira http://del.icio.us/jmce ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: kqemu in x86_64: (host) exception 0x0d in monitor space
Anthony Liguori wrote: On Fri, 11 Aug 2006 07:57:41 +0100, J M Cerqueira Esteves wrote: Summary: qemu-system-x86_64 with kqemu (running under Ubuntu on a Athlon 64) crashes while installing a guest Debian amd64 testing (etch) system, with the host reporting (in kernel logs): kqemu: aborting: Unexpected exception 0x0d in monitor space Sounds like a kqemu bug. 0x0d == 14 == page fault. The only person who can help you here is Fabrice... Meanwhile I got some hope for a temporary trick when I tried the option -smp 2 and this error did not show up... but then I noticed that, with the -smp 2 option, kqemu is disabled... Best regards J Esteves -- +351 939838775 Skype:jmcerqueira http://del.icio.us/jmce ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] ?off? ide/code editor under linux
In message: [EMAIL PROTECTED] NyOS [EMAIL PROTECTED] writes: : #ifndef _FOO_H //capitals! : #define _FOO_H //capitals! You sould avoid using _FOO_H for the define here. That's in the implementation space and strictly speaking off limits to programmers that merely use the system. FOO_H is better, and likely sufficiently unambiguous. Warner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU GUI
In message: [EMAIL PROTECTED] Johannes Schindelin [EMAIL PROTECTED] writes: : I personally don't like tcl as a language, and prefer to code in C++ for : efficiency. : : Hmmm. C++ and efficiency _does_ constitute a contradiction. Just think : operator+(). Honestly, the most inefficient code I saw was done in C++. : You really should get a weapon's license before coding in C++. You can hunt game or foot with C++. Only one will feed your family :-) Warner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu vl.h Makefile.target hw/pci.c hw/pcnet.c
In message: [EMAIL PROTECTED] Fabrice Bellard [EMAIL PROTECTED] writes: : Note: I commited the pcnet patch as some people might be interested by : it. I was unable to use it with a Knoppix distribution of 2003 so fixes : are needed. Fabrice, how is pcnet different than ne2000? I'd always seen the two used to mean the same thing... Warner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] why is kqemu closed?
In message: [EMAIL PROTECTED] Sebastian Kaliszewski [EMAIL PROTECTED] writes: : andrzej zaborowski wrote: : Now, whether using kqemu together with a linux kernel will still be : legal is a different issue, but here the question is whether the user : is breaking the law, not the author. : : : And then GPL explicitly allows user to do anything (s)he wishes, including : (but not limited to) linking with closed source software, incorporating into : closed source software, etc. until resultant binary is used internally : (i.e. is not spread further). I think that you ment to say so long as the rather than until here. Warner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] why is kqemu closed?
In message: [EMAIL PROTECTED] Paul Brook [EMAIL PROTECTED] writes: : 4. There is a slippery slope here - : : There's a slippery slope both ways. If you assume vital parts of your system : are going to be closed source then why bother with open source at all. Just : use Windows or HPUX. : : if Linux kernel policies can change : to force all kernel-space binding to be GPL (even though Linus decreed : that this is not the case years ago), what's next? Libraries that make : kernel interface calls should be GPL rather than LGPL? : : Now you're talking total nonsense. : : The GPL explicitly says that OS is exempt from the requirements placed on an : application: : : the source code distributed need not include : anything that is normally distributed (in either source or binary : form) with the major components (compiler, kernel, and so on) of the : operating system on which the executable runs, unless that component : itself accompanies the executable. I think that you are missing the point. He's not saying that you have to distribute the source (which is what that exemption is about). He's saying that the license on a mere library cannot and should not force applications linked with that library to become a derived work. And he's right about that being a dangerous precident. If I call write(2) in my application, the mere fact that the kernel is GPL'd shouldn't matter for the license of my application. It is not a derived work. The circumlocutions that some people go through to try to show that somehow using internal kernel interfaces make something a derived work do border on the absurd and are a very agressive interpretation of what makes a work a derived work. That interpretation needs to be curbed, otherwise we'd have a slipperly slope where libc becomes GPL'd and merely linking against it once and providing that binary infects the application with the GPL (a position that no court has endorced). Warner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] why is kqemu closed?
In message: [EMAIL PROTECTED] Paul Brook [EMAIL PROTECTED] writes: : I think that you are missing the point. He's not saying that you have : to distribute the source (which is what that exemption is about). : He's saying that the license on a mere library cannot and should not : force applications linked with that library to become a derived work. : And he's right about that being a dangerous precident. If I call : write(2) in my application, the mere fact that the kernel is GPL'd : shouldn't matter for the license of my application. It is not a : derived work. : : Well, the whole point of the GPL is that you have to provide : sufficient sources for the user to be able to regenerate your : binary. If your application includes closed-source code then by : definition you've broken that requirement. The problem with that belief is that it might not be what the law requires. The GPL cannot be used to force users that do not create derived works to do anything. The entire power of the GPL is based in copyright law. Copyright law is about verbatim copies and creating derived works. Anything outside of these activities, the GPL cannot regulate. One of the reasons for the OS Exception is because no other license tries to dictate which license to use when you link with OS compoents. It merely recongizes common practice in the industry that says linking against libc doesn't create a derived work. : The circumlocutions that some people go through to try to show that : somehow using internal kernel interfaces make something a derived work : do border on the absurd and are a very agressive interpretation of : what makes a work a derived work. That interpretation needs to be : curbed, otherwise we'd have a slipperly slope where libc becomes GPL'd : and merely linking against it once and providing that binary infects : the application with the GPL (a position that no court has endorced). : : You can't legally distribute a GPL application linked against a : closed-source library. Acutally, closed-source vs open-source isn't the issue. The issue is GPL compatible or not GPL compatible. There are many libraries that the source is available for which do not meet this definition. Were it not for the OS exception, you couldn't use GPL'd products on systems whose libc wasn't released under the GPL, or a compatible license. You couldn't have gcc on Solaris, becuase libc on solaris is closed-source. You couldn't have gcc on FreeBSD because FreeBSD's libc has files in it which contain the advertising clause. : In the same way you can't distribute a GPL : library as part of a closed source application. This is true, with the same caveat. It isn't just closed-source applications, but rather everything has to be compatible with the GPL. GPL'd libraries are difficult to use. There's also some ambiguity in this statement, because one could have a shared library based on non-GPL'd technology with the same ABI as the GPL'd one. In those cases, it is hard to argue that linking dynamically against one or the other creates a derived work. The whole issue hinges on what is a derive work, and as I've stated before, that's an area of the law that's not well defined when it comes to thinks like the GPL. : Libraries : (eg. glibc) that want to allow linking with proprietary code have : LGPL or additional licence exceptions to permit this. Alternatively, their license can be written not to need a special exception. : I'd guess : linking against the system libc is reasonably covered by the : exception I quoted. The exception that you quoted says I don't have to provide source for libc and other system libraries that a user may be reasonably expected to have in binary format. The purpose of the GPL is so that people can make changes to the application, and have all the parts needed to rebuild the application. : Linking against 3rd party libc probably isn't, : which IMHO is prefectly reasonably. Otherwise a proprietary product : could just take GPL code, modify it and put all the interesting : proprietary bits in a library called libc.so. Linking against a 3rd party libc is perfectly acceptible, depending on how it is done. Static linking likely isn't OK unless that 3rd party libc is available to others. Dynamic linking almost certainly is. If one has a drop-in replacement for libc.so, say, then one can certainly use that drop-in replacement. The trickier legal issues arise when one tries to define what exactly is an OS, and how are OS vendors. Merely calling something libc.so doesn't make it part of the OS, so you are right about that. : If the GPL doesn't cover linking against libraries then it's effectively : useless for its stated purpose. The coverage isn't as absolute as you might think. It all hinges on what is a derived work. Does calling a kernel that's GPL'd make something a drived work. Why is the kernel different than a userland library that's GPL'd from a copyright
Re: [Qemu-devel] why is kqemu closed?
In message: [EMAIL PROTECTED] Auke Kok [EMAIL PROTECTED] writes: : : : On Mon, 10 Apr 2006 17:20:54 +0200, Hetz Ben Hamo [EMAIL PROTECTED] wrote: : Fabrice is the owner of the KQEMU code, and he decides for his own : reasons to put the code under closed source license. : : I'm sure that Fabrice knows and that I'm beating a dead horse, but this is (strictly speaking, discussions pending ;^)) violating the linux kernel license agreement. While that topic is unclear[*], at best, at the moment, I'll point out that it isn't a violation of the FreeBSD license. so everyone should use FreeBSD :-) Warner [*] Different people who own large parts of the copyrights to Linux have said different things on the topic. Authoritative statements on the topic therefore cannot be authoritative... ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Missing ARMv6 instructions?
In message: [EMAIL PROTECTED] Karel Gardas [EMAIL PROTECTED] writes: : On Sun, 2 Apr 2006, Jamie Lokier wrote: : : Chris Wilson wrote: : I find it strange that ARM would restrict emulation of their architecture : -- that could hardly pose a threat to their business, I would say. : : Unfortunately, I don't. ARM probably makes quite a lot of money from : their development tools (compilers, debuggers, simulators) as well as : actual chips, and they have been an extensive user of software patents, : even in the EU where they are probably not valid. : : How about we target OpenCores instead of ARM? : : I like the idea, but do you know of anyone using OpenCores devices : implemented in silicon? It seems to me the motivation for ARM : emulation is to be able to simulate embedded devices that people may : feasibly end up using. : : IMHO majority of embedded devices is still ARM7TDMI based and this : instruction set (ARMv4 IIRC) should be emulated well in Qemu. Also please : have a look at www.skyeye.org project to see how other projects do : emulation for actual embedded devices. You mean badly emulate the embedded devices, and only few of them to boot? Warner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel][PATCH] Tap and VLAN socket support for win32
In message: [EMAIL PROTECTED] David Fraser [EMAIL PROTECTED] writes: : Fabrice Bellard wrote: : Jim C. Brown wrote: : On Thu, Feb 02, 2006 at 12:10:36AM +0100, Fabrice Bellard wrote: : : Hi, : : I merged your patches and I made important changes to simplify them. I : did not do any tests so tell me if you see problems. : : Regards, : : Fabrice. : : : : Have you decided to accept the GPL license on it then? : : http://lists.gnu.org/archive/html/qemu-devel/2004-10/msg00217.html : : Yes because the features are packed in a single file which can be : removed if needed. : Just checking, would that make it illegal to use this feature together : with kqemu? No. The GPL is about distribution, not use. It might make certain binary packages contrary to rights granted by the GPL. Warner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] ARM ethernet fixes
In message: [EMAIL PROTECTED] Daniel Jacobowitz [EMAIL PROTECTED] writes: : On Sun, Dec 18, 2005 at 04:51:02PM +, Paul Brook wrote: : Something like the attached patch. : : After getting myself, and probably Paul, completely confused about : array indexing, I agree that this version is right :-) It also boots : and appears to work. Network performance is not very good (averaging : about 10K/s - 30K/s most of the time, but occasionally spiking higher), : but there may be something we can do about that later. Thanks. Given all these improvements in arm support, what's the status of system level support for arm, and what system is emulated? You don't need device emulation to do userland stuf... Warner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] ARM ethernet fixes
In message: [EMAIL PROTECTED] Paul Brook [EMAIL PROTECTED] writes: : Given all these improvements in arm support, what's the status of : system level support for arm, and what system is emulated? : : Short answer is it should work. A default linux kernel config doesn't quite : work because it hangs probing for a non-existant VGA card. Disable the VGA : console driver and it's fine. : : It emulates most of an Arm Integrator/CP board with an arm1026E cpu. : Available peripherals are two UARTs, and a NIC. More than enough to boot : linux :-) Well, I'm hoping to boot FreeBSD/arm on the thing. two uarts and a nic is more than enough to boot FreeBSD as well :-) : You don't need device emulation to do userland stuf... : : No, but it's a diskless board. You either run everything off an initrd, or you : need network. That's good to know. Warner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QNX 6.3 and a PCI network card
In message: [EMAIL PROTECTED] Shaun Jackman [EMAIL PROTECTED] writes: : 2005/11/19, M. Warner Losh [EMAIL PROTECTED]: : Since it is short, here is the patch that I have in the FreeBSD ports : tree for this issue. It works sufficiently for FreeBSD's RTL : subdriver of ed to be happy. : : Thanks for the patch, Warner. Unfortunately, the PCI network card is : still not detected for me by QNX 6.3, but it does work using the : `-isa' option! The root of the issue might be a problem with the : simulated PCI BIOS and not the simulated network card (stabbing in the : dark, here). I'm running the QEMU package distributed by Debian, which : I understand provides their own BIOS image. Perhaps I'll try running : QNX using the standard BIOS image distributed by QEMU. FreeBSD doesn't use the PCI BIOS enumeration, but rather gets its idea of which PCI cards/chips are there from direct examination of the PCI space. So you may be onto something there... Warner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Screenshot?
Lasse Luttermann Poulsen escribió: Is'nt it possible to take screenshots of the contens of the emulator?? I can't seem to find anything in the documentation. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel If you emulate Gnome, you have an specific menu for this (take screenshot). Regars. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QNX 6.3 and a PCI network card
In message: [EMAIL PROTECTED] Shaun Jackman [EMAIL PROTECTED] writes: : I've discovered that QNX 6.3 [1] does not detect the simulated PCI : NE2000 network card. I found a post [2] on the OpenQNX forum : corroborating the same. : : The poster suggests that the issues is with the simulated PCI system, : as the the network card works when simulating an ISA system with qemu : -isa. : : Any suggestions? : : A 30-day evaluation of QNX can be downloaded for free [3] after registering. : : Shaun : : [1] http://www.qnx.com : [2] http://www.openqnx.com/PNphpBB2-viewtopic-t2497-.html : [3] http://www.qnx.com/download/index.html I've run into issues with qemu's emulation of the RTL8129 that is claimed with changes I made to the FreeBSD ed driver. While I've fixed the ed driver to be more tolerent of the old emulation, I've fixed these issues in qemu with some patches that were posted here a while ago. Basically, it adds support for the id registers as well as the status registers that a RTL8129 driver might expect to be there (my patches always reports 10/baseT full duplex). These patches are in the FreeBSD ports collection right now. I can dig them up if there's a need. I hope they get applied to qemu soon. Warner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] -nographic segfaults
In message: [EMAIL PROTECTED] Juergen Lock [EMAIL PROTECTED] writes: : Am I really the only one seeing this? I saw it too when I was chasing down ne2000 emulation issues... Warner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] NEC PC-9821
Has anybody made qemu emulate the NEC PC-9821 family of computer products from NEC, also known as Japanese PC? Warner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] NEC PC-9821
In message: [EMAIL PROTECTED] Hetz Ben Hamo [EMAIL PROTECTED] writes: : Not really. I think you'll need a BIOS for it which is copyrighted and : not freely distributable, and I think some specs are different, but I : didn't see any patches floating around. The specifications are quite a bit different than an IBM-AT compatible. I have seen a couple of pc98 emulators that run on Windows, and they have their own BIOS implementation. However, they are slow and run on Windows... :-(. I have a newer pc98 machine I can get the BIOS from for my own personal use (say using it on that machine), but you are right, there would be problems distributing it. I'd kinda hoped that one of the Japanese hackers had created qemu patches that google somehow overlooked in my search. The details of a PC98 machine are complex... Maybe I have a new project :-). Warner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
