[Qemu-discuss] raspi2 unable to mount root fs using latest raspbian image
This could be related to a recent post[1], but I'm unable to boot the latest raspbian stretch image ("2017-09-07-raspbian-stretch-lite.img") using 2.11.0-rc2 (or master). I'm using these args: ./qemu-system-arm -M raspi2 -kernel ~/stretch/kernel7.img -append "ro earlyprintk loglevel=8 dwc_otg.lpm_enable=0 root=PARTUUID=11eccc69-02 elevator=deadline fsck.repair=yes rootfstype=ext4 console=ttyAMA0,115200 debug rootwait" -dtb ~/stretch/bcm2709-rpi-2-b.dtb -serial stdio -sd ~/stretch/2017-09-07-raspbian-stretch-lite.img And I end up with this panic: [3.414873] Waiting for root device PARTUUID=11eccc69-02... [3.432500] mmc0: host does not support reading read-only switch, assuming write-enable [3.433265] mmc0: new SDHC card at address 4567 [3.437952] mmcblk0: mmc0:4567 QEMU! 1.73 GiB [3.447732] mmcblk0: p1 p2 [3.448958] mmcblk0: p2 size 3528040 extends beyond EOD, truncated [3.551639] EXT4-fs (mmcblk0p2): bad geometry: block count 441005 exceeds size of device (440960 blocks) [3.555863] List of all partitions: [3.556767] 01004096 ram0 [3.557104] (driver?) [3.557369] 01014096 ram1 [3.557601] (driver?) [3.557801] 01024096 ram2 [3.558025] (driver?) [3.558223] 01034096 ram3 [3.558446] (driver?) [3.558640] 01044096 ram4 [3.558860] (driver?) [3.559051] 01054096 ram5 [3.559271] (driver?) [3.559453] 01064096 ram6 [3.559667] (driver?) [3.559858] 01074096 ram7 [3.560081] (driver?) [3.560278] 01084096 ram8 [3.560490] (driver?) [3.560681] 01094096 ram9 [3.560892] (driver?) [3.561097] 010a4096 ram10 [3.561324] (driver?) [3.561520] 010b4096 ram11 [3.561747] (driver?) [3.561967] 010c4096 ram12 [3.562282] (driver?) [3.562547] 010d4096 ram13 [3.562851] (driver?) [3.563126] 010e4096 ram14 [3.563865] (driver?) [3.564151] 010f4096 ram15 [3.564437] (driver?) [3.564715] b300 1810944 mmcblk0 [3.565314] driver: mmcblk [3.565924] b301 42811 mmcblk0p1 11eccc69-01[3.566267] [3.566440] b302 1763840 mmcblk0p2 11eccc69-02[3.566751] [3.566986] No filesystem could mount root, tried: [3.567299] ext4 [3.567481] [3.568053] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,2) [3.568643] CPU: 3 PID: 1 Comm: swapper/0 Tainted: GW 4.9.41-v7+ #1023 [3.569145] Hardware name: BCM2835 [3.569535] [<8010fb3c>] (unwind_backtrace) from [<8010c058>] (show_stack+0x20/0x24) [3.570357] [<8010c058>] (show_stack) from [<80455f84>] (dump_stack+0xd4/0x118) [3.571222] [<80455f84>] (dump_stack) from [<80209a28>] (panic+0xf0/0x274) [3.571925] [<80209a28>] (panic) from [<80b01464>] (mount_block_root+0x268/0x2b4) [3.572639] [<80b01464>] (mount_block_root) from [<80b016c0>] (mount_root+0x124/0x12c) [3.573387] [<80b016c0>] (mount_root) from [<80b01860>] (prepare_namespace+0x198/0x1e0) [3.573929] [<80b01860>] (prepare_namespace) from [<80b00fe8>] (kernel_init_freeable+0x2b4/0x2c8) [3.574390] [<80b00fe8>] (kernel_init_freeable) from [<8071446c>] (kernel_init+0x18/0x124) [3.574805] [<8071446c>] (kernel_init) from [<80108148>] (ret_from_fork+0x14/0x2c) [3.575710] CPU1: stopping [3.576110] CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW 4.9.41-v7+ #1023 [3.576650] Hardware name: BCM2835 [3.577035] [<8010fb3c>] (unwind_backtrace) from [<8010c058>] (show_stack+0x20/0x24) [3.577692] [<8010c058>] (show_stack) from [<80455f84>] (dump_stack+0xd4/0x118) [3.578281] [<80455f84>] (dump_stack) from [<8010e1e4>] (handle_IPI+0x2a4/0x2c4) [3.578857] [<8010e1e4>] (handle_IPI) from [<801014e0>] (bcm2836_arm_irqchip_handle_irq+0x7c/0xac) [3.579654] [<801014e0>] (bcm2836_arm_irqchip_handle_irq) from [<8071a47c>] (__irq_svc+0x5c/0x7c) [3.580249] Exception stack(0xba94bf58 to 0xba94bfa0) [3.580730] bf40: baf50470 [3.581219] bf60: ba94a000 80c0312c 0002 80c03198 80c15f08 80c15f08 [3.581669] bf80: ba94bfb4 80c040a4 ba94bfa8 80108a54 80108a58 6013 [3.582182] [<8071a47c>] (__irq_svc) from [<80108a58>] (arch_cpu_idle+0x34/0x4c) [3.582616] [<80108a58>] (arch_cpu_idle) from [<80719bc4>] (default_idle_call+0x34/0x48) [3.583116] [<80719bc4>] (default_idle_call) from [<80161df0>] (cpu_startup_entry+0xe4/0x160) [3.583666] [<80161df0>] (cpu_startup_entry) from [<8010dcf0>] (secondary_start_kernel+0x130/0x13c) [3.584686] [<8010dcf0>] (secondary_start_kernel) from [<0010196c>] (0x10196c) [3.585478] CPU0: stopping [3.585938] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW 4.9.41-v7+ #1023 [3.586425] Hardware name: BCM2835 [3.586757] [<8010fb3c>]
Re: [Qemu-discuss] s390x user-mode working example
On 11/24/2017 12:52 PM, Thomas Huth wrote: On 24.11.2017 12:19, Alex Kashchenko wrote: Unfortunately, I just found that OpenJDK's JIT requires newer instruction set than z900: $ ./s390x-linux-user/qemu-s390x ~/jdk9/build/linux-s390x-normal-server-release/images/jdk/bin/java -version # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (vm_version_s390.hpp:367), pid=26037, tid=26039 # guarantee((_features[0] & GnrlInstrExtFacilityMask) == GnrlInstrExtFacilityMask) failed: We no more support older than z10. That looks like it is missing the so-called "general instruction extension facility". You might be lucky - that's one of the extensions that can already be enabled for testing purposes with the "qemu" CPU: Try to start QEMU with the "-cpu qemu,ginste=true" parameter. If it then still complains about missing facilities, try "-cpu help" to list all recognized feature flags. "-cpu qemu,ginste=true" helps to pass the check from previous email. The following features can already be enabled with the "qemu" CPU (list has been copy-n-pasted from the sources, but I hope you'll be able to map it to the output of "-cpu help", too): S390_FEAT_DAT_ENH, S390_FEAT_IDTE_SEGMENT, S390_FEAT_STFLE, S390_FEAT_EXTENDED_IMMEDIATE, S390_FEAT_EXTENDED_TRANSLATION_2, S390_FEAT_EXTENDED_TRANSLATION_3, S390_FEAT_LONG_DISPLACEMENT, S390_FEAT_LONG_DISPLACEMENT_FAST, S390_FEAT_ETF2_ENH, S390_FEAT_STORE_CLOCK_FAST, S390_FEAT_MOVE_WITH_OPTIONAL_SPEC, S390_FEAT_ETF3_ENH, S390_FEAT_COMPARE_AND_SWAP_AND_STORE, S390_FEAT_COMPARE_AND_SWAP_AND_STORE_2, S390_FEAT_GENERAL_INSTRUCTIONS_EXT, S390_FEAT_EXECUTE_EXT, S390_FEAT_FLOATING_POINT_SUPPPORT_ENH, S390_FEAT_STFLE_45, S390_FEAT_STFLE_49, S390_FEAT_LOCAL_TLB_CLEARING, S390_FEAT_STFLE_53, Applying all the options from this list: -cpu qemu,ginste=true,dateh=true,idtes=true,stfle=true,eimm=true,etf2=true,etf3=true,ldisp=true,ldisphp=true,etf3eh=true,etf3eh=true,csst=true,csst2=true,ginste=true,exrl=true,fpseh=true,stfle45=true,stfle49=true,ltlbc=true,stfle53=true still causes the SIGILL during the JVM init though. Thanks for the list! At least I know now that the problem is not caused by some local misconfiguration. -- -Alex
Re: [Qemu-discuss] s390x user-mode working example
On 24.11.2017 12:19, Alex Kashchenko wrote: > Unfortunately, I just found that OpenJDK's JIT requires newer > instruction set than z900: > > $ ./s390x-linux-user/qemu-s390x > ~/jdk9/build/linux-s390x-normal-server-release/images/jdk/bin/java -version > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (vm_version_s390.hpp:367), pid=26037, tid=26039 > # guarantee((_features[0] & GnrlInstrExtFacilityMask) == > GnrlInstrExtFacilityMask) failed: We no more support older than z10. That looks like it is missing the so-called "general instruction extension facility". You might be lucky - that's one of the extensions that can already be enabled for testing purposes with the "qemu" CPU: Try to start QEMU with the "-cpu qemu,ginste=true" parameter. If it then still complains about missing facilities, try "-cpu help" to list all recognized feature flags. The following features can already be enabled with the "qemu" CPU (list has been copy-n-pasted from the sources, but I hope you'll be able to map it to the output of "-cpu help", too): S390_FEAT_DAT_ENH, S390_FEAT_IDTE_SEGMENT, S390_FEAT_STFLE, S390_FEAT_EXTENDED_IMMEDIATE, S390_FEAT_EXTENDED_TRANSLATION_2, S390_FEAT_EXTENDED_TRANSLATION_3, S390_FEAT_LONG_DISPLACEMENT, S390_FEAT_LONG_DISPLACEMENT_FAST, S390_FEAT_ETF2_ENH, S390_FEAT_STORE_CLOCK_FAST, S390_FEAT_MOVE_WITH_OPTIONAL_SPEC, S390_FEAT_ETF3_ENH, S390_FEAT_COMPARE_AND_SWAP_AND_STORE, S390_FEAT_COMPARE_AND_SWAP_AND_STORE_2, S390_FEAT_GENERAL_INSTRUCTIONS_EXT, S390_FEAT_EXECUTE_EXT, S390_FEAT_FLOATING_POINT_SUPPPORT_ENH, S390_FEAT_STFLE_45, S390_FEAT_STFLE_49, S390_FEAT_LOCAL_TLB_CLEARING, S390_FEAT_STFLE_53, HTH, Thomas
Re: [Qemu-discuss] Apple hyphervisor.framework availability
On 24/11/2017 12:58, Brendan Simon (eTRIX) wrote: > > Checked out the `hvf` branch, but it failed the build. Ran `mkdir build > ; cd build ; ../configure ; make` > > Am I missing some definitions or command line switches? No, I've pushed an updated version. Paolo
Re: [Qemu-discuss] Apple hyphervisor.framework availability
On 23/11/17 11:06 pm, Paolo Bonzini wrote: > On 23/11/2017 12:55, Thomas Huth wrote: >> On 23.11.2017 08:36, Brendan Simon (eTRIX) wrote: >>> Hi QEMU devs, >>> >>> Just wondering when the accelerator for Apple's hypervisor.framework >>> (hvf) will hit the git repos to build and try out? >>> >>> I get the impression that patches have been submitted, but I can't see >>> anything in the repos. Is there a special branch or fork where these >>> patches reside? >> According to >> https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg00415.html >> there is a branch in Paolo's repository. hvf apparently hasn't been >> merged into the upstream QEMU git repository yet. > Right, more testing is welcome. Checked out the `hvf` branch, but it failed the build. Ran `mkdir build ; cd build ; ../configure ; make` Am I missing some definitions or command line switches? CC i386-softmmu/hw/misc/vmport.o /Users/brendan/Sandbox/qemu-bonzini/hw/misc/vmport.c:73:21: error: use of undeclared identifier 'R_EAX'; did you mean 'R_RAX'? eax = env->regs[R_EAX]; ^ R_RAX /Users/brendan/Sandbox/qemu-bonzini/target/i386/cpu.h:63:5: note: 'R_RAX' declared here R_RAX = 0, ^ /Users/brendan/Sandbox/qemu-bonzini/hw/misc/vmport.c:77:25: error: use of undeclared identifier 'R_ECX'; did you mean 'R_RCX'? command = env->regs[R_ECX]; ^ R_RCX /Users/brendan/Sandbox/qemu-bonzini/target/i386/cpu.h:64:5: note: 'R_RCX' declared here R_RCX = 1, ^ /Users/brendan/Sandbox/qemu-bonzini/hw/misc/vmport.c:96:19: error: use of undeclared identifier 'R_EAX'; did you mean 'R_RAX'? cpu->env.regs[R_EAX] = vmport_ioport_read(opaque, addr, 4); ^ R_RAX /Users/brendan/Sandbox/qemu-bonzini/target/i386/cpu.h:63:5: note: 'R_RAX' declared here R_RAX = 0, ^ /Users/brendan/Sandbox/qemu-bonzini/hw/misc/vmport.c:103:19: error: use of undeclared identifier 'R_EBX'; did you mean 'R_RBX'? cpu->env.regs[R_EBX] = VMPORT_MAGIC; ^ R_RBX /Users/brendan/Sandbox/qemu-bonzini/target/i386/cpu.h:66:5: note: 'R_RBX' declared here R_RBX = 3, ^ /Users/brendan/Sandbox/qemu-bonzini/hw/misc/vmport.c:111:19: error: use of undeclared identifier 'R_EBX'; did you mean 'R_RBX'? cpu->env.regs[R_EBX] = 0x1177; ^ R_RBX /Users/brendan/Sandbox/qemu-bonzini/target/i386/cpu.h:66:5: note: 'R_RBX' declared here R_RBX = 3, ^ /Users/brendan/Sandbox/qemu-bonzini/hw/misc/vmport.c:121:25: error: use of undeclared identifier 'R_EAX'; did you mean 'R_RAX'? data[0] = env->regs[R_EAX]; data[1] = env->regs[R_EBX]; ^ R_RAX /Users/brendan/Sandbox/qemu-bonzini/target/i386/cpu.h:63:5: note: 'R_RAX' declared here R_RAX = 0, ^ /Users/brendan/Sandbox/qemu-bonzini/hw/misc/vmport.c:121:53: error: use of undeclared identifier 'R_EBX'; did you mean 'R_RBX'? data[0] = env->regs[R_EAX]; data[1] = env->regs[R_EBX]; ^ R_RBX /Users/brendan/Sandbox/qemu-bonzini/target/i386/cpu.h:66:5: note: 'R_RBX' declared here R_RBX = 3, ^ /Users/brendan/Sandbox/qemu-bonzini/hw/misc/vmport.c:122:25: error: use of undeclared identifier 'R_ECX'; did you mean 'R_RCX'? data[2] = env->regs[R_ECX]; data[3] = env->regs[R_EDX]; ^ R_RCX /Users/brendan/Sandbox/qemu-bonzini/target/i386/cpu.h:64:5: note: 'R_RCX' declared here R_RCX = 1, ^ /Users/brendan/Sandbox/qemu-bonzini/hw/misc/vmport.c:122:53: error: use of undeclared identifier 'R_EDX'; did you mean 'R_RDX'? data[2] = env->regs[R_ECX]; data[3] = env->regs[R_EDX]; ^ R_RDX /Users/brendan/Sandbox/qemu-bonzini/target/i386/cpu.h:65:5: note: 'R_RDX' declared here R_RDX = 2, ^ /Users/brendan/Sandbox/qemu-bonzini/hw/misc/vmport.c:123:25: error: use of undeclared identifier 'R_ESI' data[4] = env->regs[R_ESI]; data[5] = env->regs[R_EDI]; ^ /Users/brendan/Sandbox/qemu-bonzini/hw/misc/vmport.c:123:53: error: use of undeclared identifier 'R_EDI'; did you mean 'R_RDI'? data[4] = env->regs[R_ESI]; data[5] = env->regs[R_EDI]; ^ R_RDI /Users/brendan/Sandbox/qemu-bonzini/target/i386/cpu.h:70:5: note: 'R_RDI' declared here R_RDI = 7, ^ /Users/brendan/Sandbox/qemu-bonzini/hw/misc/vmport.c:131:15: error: use of undeclared identifier 'R_EAX'; did you mean 'R_RAX'? env->regs[R_EAX] = data[0]; env->regs[R_EBX] = data[1]; ^ R_RAX
Re: [Qemu-discuss] s390x user-mode working example
On 11/24/2017 05:57 AM, Thomas Huth wrote: On 23.11.2017 22:00, Alex Kashchenko wrote: Hi, I am trying to build qemu-s390x-user static binary to run a hello-world program cross-compiled with gcc-s390x-linux-gnu on linux_x86_64. I am building qemu with: ./configure --static --disable-werror --target-list=s390x-linux-user make and running example with: QEMU_STRACE=1 ./s390x-linux-user/qemu-s390x path/to/s390x-hello I tried latest git and a number of v2.x releases without success. Can see either hang (on first brk call) or various errors for newer versions and "Illegal instruction" for older ones. Tried on ubuntu 16.04 and 17.10 without success. The same steps worked for me for ppc64le hello-world. Any help on this is highly appreciated. How did you cross-compile your s390x binary? QEMU's CPU emulation only fully supports the z900 so far (more support is being worked on), so you should make sure that your program has been compiled for that CPU architecture, i.e. add "-m64 -march=z900" to your CFLAGS. Does that help? Thanks for suggestion! I was cross-compiling the example using s390x-linux-gnu-gcc without additional flags, but it seems that march=z900 is a default for this gcc build. I was able to run simple example successfully (with git master build) after deleting /etc/ld.so.cache . My ultimate goal was to cross-compile OpenJDK for s390x and run it locally with QEMU-user to be able to smoke-test s390x OpenJDK builds for fedora (I am using ubuntu for experiments because of very convenient multiarch support in it). Unfortunately, I just found that OpenJDK's JIT requires newer instruction set than z900: $ ./s390x-linux-user/qemu-s390x ~/jdk9/build/linux-s390x-normal-server-release/images/jdk/bin/java -version # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (vm_version_s390.hpp:367), pid=26037, tid=26039 # guarantee((_features[0] & GnrlInstrExtFacilityMask) == GnrlInstrExtFacilityMask) failed: We no more support older than z10. # # JRE version: (9.0) (build ) # Java VM: OpenJDK 64-Bit Server VM (9-internal+0-adhoc.u1804.jdk9, mixed mode, tiered, compressed oops, g1 gc, linux-s390x) -- -Alex
Re: [Qemu-discuss] s390x user-mode working example
On 11/24/2017 10:14 AM, Peter Maydell wrote: On 23 November 2017 at 21:00, Alex Kashchenkowrote: Hi, I am trying to build qemu-s390x-user static binary to run a hello-world program cross-compiled with gcc-s390x-linux-gnu on linux_x86_64. I am building qemu with: ./configure --static --disable-werror --target-list=s390x-linux-user make and running example with: QEMU_STRACE=1 ./s390x-linux-user/qemu-s390x path/to/s390x-hello I tried latest git and a number of v2.x releases without success. Can see either hang (on first brk call) or various errors for newer versions and "Illegal instruction" for older ones. Tried on ubuntu 16.04 and 17.10 without success. The same steps worked for me for ppc64le hello-world. Any help on this is highly appreciated. Is your target binary statically linked? If not you'll need to tell QEMU where the libraries are, or run it in a chroot with the s390x libraries etc. No, it is not statically linked, on ubuntu I am installing multiarch packet libc6:s390x (goes to /lib/s390x-linux-gnu/libc.so.6 ) for it as a dependency. (You'll also need to make sure it doesn't pick up the x86 /etc/ld.so.cache, because a glibc bug means a bigendian dynamic linker crashes when it finds a littleendian ld.so.cache, whereas same-endian-wrong-arch just ignores it.) That was it, on a git master build: $ QEMU_STRACE=1 ./qemu/s390x-linux-user/qemu-s390x ./a.out 4654 brk(NULL) = 0x00403000 4654 uname(0x4000803102) = 0 4654 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory) 4654 mmap(0x0040008030e8,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0x82a168) = 0x00400082b000 4654 access("/etc/ld.so.preload",R_OK) = -1 errno=2 (No such file or directory) 4654 open("/etc/ld.so.cache",O_RDONLY|O_CLOEXEC) = 3 4654 fstat(3,0x0040008027d0) = 0 4654 mmap(0x0040008026f8,25873,PROT_READ,MAP_PRIVATE,3,0x829098) = 0x00400082d000 4654 close(3) = 0 --- SIGSEGV {si_signo=SIGSEGV, si_code=1, si_addr=0x00409088d000} --- Segmentation fault (core dumped) Simple example now works fine for me if I delete /etc/ld.so.cache before running it. Thanks for your help! -- -Alex
Re: [Qemu-discuss] add tci module in android emulator
On 24 November 2017 at 07:21, jiang00glewrote: > The Qemu is really a good project and the android emulator is > based on the Qemu. But the version of Qemu in android 4.0 is 0.10 > which has no Tci module. > > So, is there any mature solution to add the tci module in emulator > in Android 4.0 ? This isn't really the right place to ask about the Android emulator: it's a separate project that QEMU developers don't generally have much knowledge of. However, why do you want to use TCI? TCI is incredibly slow and doesn't really have any good uses (as well as not actually being properly portable and needing to be compiled into QEMU rather than being a runtime option); we're thinking about deleting it upstream at some point. thanks -- PMM
Re: [Qemu-discuss] s390x user-mode working example
On 23 November 2017 at 21:00, Alex Kashchenkowrote: > Hi, > > I am trying to build qemu-s390x-user static binary to run a hello-world > program cross-compiled with gcc-s390x-linux-gnu on linux_x86_64. > > I am building qemu with: > > ./configure --static --disable-werror --target-list=s390x-linux-user > make > > and running example with: > > QEMU_STRACE=1 ./s390x-linux-user/qemu-s390x path/to/s390x-hello > > I tried latest git and a number of v2.x releases without success. Can see > either hang (on first brk call) or various errors for newer versions and > "Illegal instruction" for older ones. Tried on ubuntu 16.04 and 17.10 > without success. > > The same steps worked for me for ppc64le hello-world. > > Any help on this is highly appreciated. Is your target binary statically linked? If not you'll need to tell QEMU where the libraries are, or run it in a chroot with the s390x libraries etc. (You'll also need to make sure it doesn't pick up the x86 /etc/ld.so.cache, because a glibc bug means a bigendian dynamic linker crashes when it finds a littleendian ld.so.cache, whereas same-endian-wrong-arch just ignores it.) thanks -- PMM