Cannot start ubuntu, archlinux ... with hax #74
Comments
|
Thanks for the report. I don't think we have ever tested an Arch Linux image, so you've probably discovered a HAXM bug. We'll see if we can reproduce this issue on our side tomorrow. |
|
Thank you for fast answer. So i decided to help you to avoid from full install process of archlinux. below my build_slave.img packed by 7z and uploaded to yandex disk( it's about ~500mb in archive and 1.8gb unpacked) system not clean - i already installed some packages(of course with tcg accel) - but it's don't matters besides i am developer too - and have mvs on my pc - so i decided to build latest IntelHasm driver myself and test it. But nothing changed, after i replace IntelHaxm.sys in my system directory and reboot. :( Maybe i did something wrong..? |
|
I forgot: host machine is win 7 64bit |
|
As i say i tried ubuntu 18.04 - i installed it with tcg accel, redirected console to ttyS0(to make log) and then turn on hax - and got... very similar kernel panic So even folk ubuntu - not works :( i attach this log here: |
|
It seems like the same issue as #39. |
|
I have the same issue on the host Windows 7 64bits, qemu 2.12 haxm 7.2.0 with the guest archlinux 2018.07.01
|
|
We could reproduce this issue with attached build_slave.7z. But unfortunately there is no error/warning log in haxm driver when kernel panic happens. We are looking for reasons about what might introduce this issue in haxm. |
64-bit Windows 7 won't load a driver unless it's got a legitimate digital signature. When you build HAXM yourself using the Debug build configuration, you only get either a test-signed binary, which is not trusted by Windows. The only way to remove that restriction is to turn on Test Mode. You could try a fairly recent 64-bit |
|
I have test sign mode turned on permanently in my system(cos i developed (and still support) some win driver)- just forgot to say. |
|
That's great. I'd still recommend that you check out that link and follow the instructions there to download |
|
just now I tested driver from issue #40 - bad luck - behavior identical :( |
|
We are still working on this issue, and try to narrow down that which guest OS behavior might introduce haxm handling error. |
|
It looks issue is related with SSE instructions support. We are working on fix. |
Guest OS kernel/app might use SSE instruction and registers. When Guest OS VMM exits, these registers should be saved, or else it might be corrupted by host OS/app. In next time guest VMM enter, guest's SSE registers context might be corrupted. Guest app segment fault, coredump, and kernel panic were reported which should be related with this issue. This change is to remove is_fpu_used flag so guest FPU registers could be saved in VM exit and restored in VM enter unconditionally. Fixes #39, fixes #74.
Guest OS kernel/app might use SSE instruction and registers. When Guest OS VMM exits, these registers should be saved, or else it might be corrupted by host OS/app. In next time VM entry, guest's SSE registers context might be corrupted. Guest app segfault and kernel panic were reported which should be related with this issue. This change is to remove is_fpu_used flag so guest FPU registers could be saved in VM exit and restored in VM entry unconditionally. Fixes #39, fixes #74.
Guest OS kernel/app might use SSE instruction and registers. When Guest OS VM exits, these registers should be saved, or else it might be corrupted by host OS/app. In next time VM entry, guest's SSE registers context might be corrupted. Guest app segfault and kernel panic were reported which should be related with this issue. This change is to remove is_fpu_used flag so guest FPU registers could be saved in VM exit and restored in VM entry unconditionally. Fixes #39, fixes #74.
Guest OS kernel/app might use SSE instruction and registers. When Guest OS VM exits, these registers should be saved, or else it might be corrupted by host OS/app. In next time VM entry, guest's SSE registers context might be corrupted. Guest app segfault and kernel panic were reported which should be related with this issue. This change is to remove is_fpu_used flag so guest FPU registers could be saved in VM exit and restored in VM entry unconditionally. Fixes #39, fixes #74.
I have qemu windows build 2.12.90, haxm 7.2.0. Ubuntu, nor arch linux does not works when i turn on hax acceleration. Permanent kernel panics, black screen freezing and other crashes happens when i run qemu.
Qemu crashed with hax - when i ran it from iso. It crashed on already installed system - it's not matters.
Versions:
archlinux-2018.07.01-x86_64
ubuntu-18.04-live-server-amd64.iso
I run qemu-system-x86_64.exe binary.
qemu-system-x86_64.exe -drive file=build_slave.img,index=0,media=disk,format=qcow2 -m 2G -accel hax -name build_slaveMy CPU:
core i7 2600k
My Host:
Windows 7 64bit
The text was updated successfully, but these errors were encountered: