[DragonFlyBSD - Bug #2561] Fwd: Re: DragonFly x86_64 won't boot on qemu-kvm

[Venkatesh Srinivas via Redmine]

Issue #2561 has been updated by vsrinivas.


aggelos@ found a second place where there was an offending %cr3 register, in the x86-64 pmap:

http://leaf.dragonflybsd.org/~aggelos/0002-kernel-x86_64-Do-not-set-reserved-bits-in-CR3.patch

If you apply that and the original:
http://acm.jhu.edu/~me/0001-kernel-x86_64-Do-not-set-reserved-bits-in-CR3.patch 

it works on qemu-kvm 1.1 on a Linux 3.2 host.

If folks could test these two patches together on a few physical x86-64 systems too, to make sure that it doesn't break them, that would be really helpful.
----------------------------------------
Bug #2561: Fwd: Re: DragonFly x86_64 won't boot on qemu-kvm
http://bugs.dragonflybsd.org/issues/2561

Author: c.turner1
Status: New
Priority: Normal
Assignee: 
Category: 
Target version: 


Forwarding to bugs@ - relavent threads contain
further details.

-------- Original Message --------
Subject: Re: DragonFly x86_64 won't boot on qemu-kvm
Date: Wed, 15 May 2013 21:48:22 -0500
From: Chris Turner <c.turner at 199technologies.com>
To: users at dragonflybsd.org

On 05/15/13 11:41, Michael Neumann wrote:
> Hi,
>
> I am having exactly the same problems as described in:
>
> http://leaf.dragonflybsd.org/mailarchive/users/2012-10/msg00027.html

Indeed I am also having this problem as well

(RHEL6-stock host/kernel/etc/virt-manager on a core2-duo)

Have not yet reported since I know I haven't had time to get a debug
env properly setup.

I've tested x86-64 from ~1-2wks back, and also had tested around
september last year - have been using 32bit as a workaround since
it suits my purposes in this situation.


> It seem like FreeBSD has a similar problem:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=881579
> http://forums.freebsd.org/showthread.php?t=36761

I'm not clear from your email - did any of the workarounds work?

setting cpu flags, the kvm modprobe option, etc?

I was able to boot up when using 'pure emulation' QEMU,
(as outlined in original thread IIRC) but this is hardly ideal :D

> For now, the only solution seems to be to use i386 on that particual host (or wait that this is fixed in kvm).
> I am wondering why it fails on DF but not for example on Linux. Are they doing things differently?

It does appear that the panic happens consistently for me after 'low level' init
and right before mounting the root filesystem - IIRC this is when the actual
buffer cache/VM etc is setup, and so presumably lots would be going on w/r/t
memory pages/interrupts/etc in a fairly OS-dependent manner.

My thought was to add some spurious printfs here and maybe throw in some ASM
noops in the right places to see if that allows any narrowing down of the
problem, but again, I haven't had a chance to get a proper dev env setup
in this environment.

Unfortunately my time will likely be short until at least mid summer.
GRR! need more unix time!

... and while I'm at it - this + Bug#2133, etc.
   seem like excellent examples of the 'why keeping >=2 platforms going is a good idea'
   argument.

</soapbox>

will forward to bugs@ to get a thread going there.

Cheers,

- Chris


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account