Bug#736902: qemu: multiboot header always sets mem_upper as 0k
Control: reassign -1 seabios/1.7.4-1 Control: tag -1 + confirmed patch pending 28.01.2014 15:34, Michael Tokarev wrote: 28.01.2014 15:31, Michael Tokarev wrote: It fails when using seabios, however. With 1.7.0, and current seabios from jessie, it shows your zeros: I mean, when using previous version of seabios -- 1.7.3 works, 1.7.4 fails. So after playing with this further, I found out the cause. It is the wrong debian/optionrom/multiboot.S file in debian seabios package. I wanted to update it, even mentioned the right commitID in the debian/optionrom/README file, but actually used the wrong version of that file. So it is a local-to-debian problem (just debian packaging problme) and I'll fix it in the next upload, hope to do it today or soon. This is entirely my fault. 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#736902: qemu: multiboot header always sets mem_upper as 0k
28.01.2014 08:17, Peter Chubb wrote: Package: qemu Version: 1.7.0+dfsg-3 Severity: important Dear Maintainer, Our operating system no longer boots on qemu-system-i386 because the multiboot header is no longer set up correctly. To check, run the multiboot tests inside the source tree. I see the same thing upstream on the standard branch, but the linaro branch works OK. Thank you for a very detailed bugreport. However, can we please know what is this our operating system, which source tree to use to run tests, and which linaro branch you're talking about? 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#736902: qemu: multiboot header always sets mem_upper as 0k
Michael == Michael Tokarev m...@tls.msk.ru writes: Michael 28.01.2014 08:17, Peter Chubb wrote: Package: qemu Version: 1.7.0+dfsg-3 Severity: important Dear Maintainer, Our operating system no longer boots on qemu-system-i386 because the multiboot header is no longer set up correctly. To check, run the multiboot tests inside the source tree. I see the same thing upstream on the standard branch, but the linaro branch works OK. Michael Thank you for a very detailed bugreport. Michael However, can we please know what is this our operating Michael system, which source tree to use to run tests, and which Michael linaro branch you're talking about? Which OS is not important, but if you want to know, it's seL4. The Linaro branch is from git://git.linaro.org/qemu/qemu-linaro.git The main upstream branch is at git://git.qemu.org/qemu.git But to test you can do: apt-get source qemu cd qemu-1.7.0+dfsg debuild -b cd tests/multiboot QEMU=../../debian/qemu-system-x86/usr/bin/qemu-system-x86_64 ./run_test.sh Hope this helps! -- Dr Peter Chubb peter.chubb AT nicta.com.au http://www.ssrg.nicta.com.au Software Systems Research Group/NICTA -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736902: qemu: multiboot header always sets mem_upper as 0k
28.01.2014 14:00, Peter Chubb wrote: [] Michael However, can we please know what is this our operating Michael system, which source tree to use to run tests, and which Michael linaro branch you're talking about? Which OS is not important, but if you want to know, it's seL4. Ah. I thought you're referring to your OS tests, not qemu tests. Now when I know which test it is, I tried it here - from qemu git. And here, it is not 0k: == FAIL mmap (output difference) --- mmap.out2014-01-28 15:09:38.238713979 +0400 +++ test.log2014-01-28 15:21:00.147125386 +0400 @@ -58,16 +58,16 @@ === Running test case: mmap.elf -m 4G === Lower memory: 639k -Upper memory: 3668984k +Upper memory: 3144696k e820 memory map: 0x0 - 0x9fc00: type 1 [entry size: 20] 0x9fc00 - 0xa: type 2 [entry size: 20] 0xf - 0x10: type 2 [entry size: 20] -0x10 - 0xdfffe000: type 1 [entry size: 20] -0xdfffe000 - 0xe000: type 2 [entry size: 20] +0x10 - 0xbfffe000: type 1 [entry size: 20] +0xbfffe000 - 0xc000: type 2 [entry size: 20] 0xfffc - 0x1: type 2 [entry size: 20] -0x1 - 0x12000: type 1 [entry size: 20] +0x1 - 0x14000: type 1 [entry size: 20] mmap start: 0x9000 mmap end: 0x90a8 @@ -77,16 +77,16 @@ === Running test case: mmap.elf -m 8G === Lower memory: 639k -Upper memory: 3668984k +Upper memory: 3144696k e820 memory map: 0x0 - 0x9fc00: type 1 [entry size: 20] 0x9fc00 - 0xa: type 2 [entry size: 20] 0xf - 0x10: type 2 [entry size: 20] -0x10 - 0xdfffe000: type 1 [entry size: 20] -0xdfffe000 - 0xe000: type 2 [entry size: 20] +0x10 - 0xbfffe000: type 1 [entry size: 20] +0xbfffe000 - 0xc000: type 2 [entry size: 20] 0xfffc - 0x1: type 2 [entry size: 20] -0x1 - 0x22000: type 1 [entry size: 20] +0x1 - 0x24000: type 1 [entry size: 20] mmap start: 0x9000 mmap end: 0x90a8 == However, on upstream 1.7.0 and 1.6.0 it works fine. It fails when using seabios, however. With 1.7.0, and current seabios from jessie, it shows your zeros: -Upper memory: 130040k +Upper memory: 0k ... It also works fine with current qemu in jessie/sid and with previous seabios. Now, I've no idea what's going on, will try to dig further and ask around :) 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#736902: qemu: multiboot header always sets mem_upper as 0k
28.01.2014 15:31, Michael Tokarev wrote: It fails when using seabios, however. With 1.7.0, and current seabios from jessie, it shows your zeros: I mean, when using previous version of seabios -- 1.7.3 works, 1.7.4 fails. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736902: qemu: multiboot header always sets mem_upper as 0k
Package: qemu Version: 1.7.0+dfsg-3 Severity: important Dear Maintainer, Our operating system no longer boots on qemu-system-i386 because the multiboot header is no longer set up correctly. To check, run the multiboot tests inside the source tree. I see the same thing upstream on the standard branch, but the linaro branch works OK. This is what I see: FAIL mmap (exit code 69) FAIL mmap (output difference) --- mmap.out2014-01-28 14:46:29.648461373 +1100 +++ test.log2014-01-28 14:59:34.252755481 +1100 @@ -4,25 +4,24 @@ === Running test case: mmap.elf === Lower memory: 639k -Upper memory: 130040k +Upper memory: 0k e820 memory map: 0x0 - 0x9fc00: type 1 [entry size: 20] 0x9fc00 - 0xa: type 2 [entry size: 20] 0xf - 0x10: type 2 [entry size: 20] -0x10 - 0x7ffe000: type 1 [entry size: 20] -0x7ffe000 - 0x800: type 2 [entry size: 20] -0xfffc - 0x1: type 2 [entry size: 20] +0x10 - 0x118000: type 1 [entry size: 20] +0x118000 - 0x11a000: type 2 [entry size: 20] mmap start: 0x9000 -mmap end: 0x9090 -real mmap end:0x9090 +mmap end: 0x9078 +real mmap end:0x9078 === Running test case: mmap.elf -m 1.1M === Lower memory: 639k -Upper memory: 96k +Upper memory: 0k e820 memory map: 0x0 - 0x9fc00: type 1 [entry size: 20] @@ -30,64 +29,58 @@ 0xf - 0x10: type 2 [entry size: 20] 0x10 - 0x118000: type 1 [entry size: 20] 0x118000 - 0x11a000: type 2 [entry size: 20] -0xfffc - 0x1: type 2 [entry size: 20] mmap start: 0x9000 -mmap end: 0x9090 -real mmap end:0x9090 +mmap end: 0x9078 +real mmap end:0x9078 === Running test case: mmap.elf -m 2G === Lower memory: 639k -Upper memory: 2096120k +Upper memory: 0k e820 memory map: 0x0 - 0x9fc00: type 1 [entry size: 20] 0x9fc00 - 0xa: type 2 [entry size: 20] 0xf - 0x10: type 2 [entry size: 20] -0x10 - 0x7fffe000: type 1 [entry size: 20] -0x7fffe000 - 0x8000: type 2 [entry size: 20] -0xfffc - 0x1: type 2 [entry size: 20] +0x10 - 0x118000: type 1 [entry size: 20] +0x118000 - 0x11a000: type 2 [entry size: 20] mmap start: 0x9000 -mmap end: 0x9090 -real mmap end:0x9090 +mmap end: 0x9078 +real mmap end:0x9078 === Running test case: mmap.elf -m 4G === Lower memory: 639k -Upper memory: 3668984k +Upper memory: 0k e820 memory map: 0x0 - 0x9fc00: type 1 [entry size: 20] 0x9fc00 - 0xa: type 2 [entry size: 20] 0xf - 0x10: type 2 [entry size: 20] -0x10 - 0xdfffe000: type 1 [entry size: 20] -0xdfffe000 - 0xe000: type 2 [entry size: 20] -0xfffc - 0x1: type 2 [entry size: 20] -0x1 - 0x12000: type 1 [entry size: 20] +0x10 - 0x118000: type 1 [entry size: 20] +0x118000 - 0x11a000: type 2 [entry size: 20] mmap start: 0x9000 -mmap end: 0x90a8 -real mmap end:0x90a8 +mmap end: 0x9078 +real mmap end:0x9078 === Running test case: mmap.elf -m 8G === Lower memory: 639k -Upper memory: 3668984k +Upper memory: 0k e820 memory map: 0x0 - 0x9fc00: type 1 [entry size: 20] 0x9fc00 - 0xa: type 2 [entry size: 20] 0xf - 0x10: type 2 [entry size: 20] -0x10 - 0xdfffe000: type 1 [entry size: 20] -0xdfffe000 - 0xe000: type 2 [entry size: 20] -0xfffc - 0x1: type 2 [entry size: 20] -0x1 - 0x22000: type 1 [entry size: 20] +0x10 - 0x118000: type 1 [entry size: 20] +0x118000 - 0x11a000: type 2 [entry size: 20] mmap start: 0x9000 -mmap end: 0x90a8 -real mmap end:0x90a8 +mmap end: 0x9078 +real mmap end:0x9078 -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13.0 (SMP w/8 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages qemu depends on: ii qemu-system 1.7.0+dfsg-3 ii qemu-user1.7.0+dfsg-3 ii qemu-utils 1.7.0+dfsg-3 qemu recommends no packages. Versions of packages qemu suggests: ii qemu-user-static 1.7.0+dfsg-3 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
