Bug #995

DFly doesnt work on Vmware and Virtualbox

Added by araratpp over 6 years ago. Updated over 5 years ago.

Status:ClosedStart date:
Priority:LowDue date:
Assignee:tuxillo% Done:

0%

Category:-
Target version:-

Description

Hello!

DFly doesnt work on Vmware and Virtualbox

The time counter hangs in the Boot menu on the ISO

Only Qemu works

araratpp

vmware_windowsxp_dragonflybsd.jpg (120 KB) tuxillo, 05/12/2008 01:42 PM

History

#1 Updated by swildner over 6 years ago

Hmmm, are you sure about VMware? I'm pretty sure it worked for me with
VMware Server 1.0.4 some time ago.

The Virtualbox issue is a known (though unfixed) one, see:

http://www.virtualbox.org/ticket/916

Sascha

#2 Updated by araratpp over 6 years ago

I test it again on Friday with Vmware Server
2008/4/29, Sascha Wildner <>:
>
> Sascha Wildner <> added the comment:
>
>
> Hmmm, are you sure about VMware? I'm pretty sure it worked for me with
> VMware Server 1.0.4 some time ago.
>
> The Virtualbox issue is a known (though unfixed) one, see:
>
> http://www.virtualbox.org/ticket/916
>
> Sascha
>
>
> ----------
> status: unread -> chatting
>
> _____________________________________________________
> DragonFly issue tracker <>
> <https://bugs.dragonflybsd.org/issue995>
> _____________________________________________________
>

#3 Updated by fgudin2 over 6 years ago

Hi,

it works fine here with VMWare Workstation (5.5.4 build-44386 / Ubuntu "Feisty")
and DragonFly 1.12.2-RELEASE.
I use it daily without any pb.

BR,
--

SDF-EU Public Access UNIX System - http://sdf-eu.org

#4 Updated by c.turner over 6 years ago

confirm things were working using a 1.11-HEAD snapshot against a hacked
up vmware player config file (cca 12/2007) under a winXP host

#5 Updated by tuxillo over 6 years ago

I report it works on QEMU/KVM with a very nice performance.
Hardware/Software:

Gentoo Linux 2007.0 x86_64
Athlon 64 x2 3800+
2GB DDR 667
KVM 67

#6 Updated by tuxillo over 6 years ago

I've installed DF 1.12.2 in VMware Server 1.0.5 and I report it works here.
See attachment for details.

#7 Updated by rluciani over 6 years ago

Matt, seems like a few of us got different pictures from Antonio
depending on whether we used nntp or mail. We who used nntp got a
distorted bottom half of the picture. Strange =/

mail md5 was
ecce456c08d219ca8342e02064817e0e

nntp md5 was
da9525dc1af41dfef949397edca1a497

#8 Updated by dragonfly1 over 6 years ago

Hello,

I've also had issues running Dragonfly under Linux KVM. UP kernel appear
to work fine but SMP builds freeze during buildworld. The host OS shows
100% CPU usage inside the VM and DragonFly is completely unresponsive.
("make -j8 buildworld") This is with HEAD and 1.12.2. I originally put
it down to KVM but other BSDs have been Ok.

Gary

#9 Updated by tuxillo over 6 years ago

Last days I've been trying to boot a DragonFlyBSD kernel (different versions)
with FreeBSD loader in a VirtualBox VM to see if the problem resides on the
loader. It doesn't boot either, so we can almost be sure that the problem is in
the kernel.

#10 Updated by tuxillo over 6 years ago

This is the last text in the VirtualBox Log.

----------
1192:47:00.421 Display::handleDisplayResize(): uScreenId = 0,
pvVRAM=0000000000000000 w=720 h=400 bpp=0 cbLine=0x0
1192:47:00.480 Guest Log: BIOS: int13_diskette: unsupported AH=41
1192:47:15.294 Guest Log: BIOS: int13_harddisk: function 08, unmapped device for
ELDL=81
1192:47:15.294 Guest Log: BIOS: int13_harddisk: function 08, unmapped device for
ELDL=82
1192:47:15.294 Guest Log: BIOS: int13_harddisk: function 08, unmapped device for
ELDL=83
1192:47:15.294 Guest Log: BIOS: int13_harddisk: function 08, unmapped device for
ELDL=84
1192:47:15.294 Guest Log: BIOS: int13_harddisk: function 08, unmapped device for
ELDL=85
1192:47:15.294 Guest Log: BIOS: int13_harddisk: function 08, unmapped device for
ELDL=86
1192:47:15.294 Guest Log: BIOS: int13_harddisk: function 08, unmapped device for
ELDL=87
1192:47:15.311 PIT: mode=4 count=0x2 (2) - 596591.00 Hz (ch=0)

#11 Updated by jgordeev over 6 years ago

Today, after a session of colaborative debugging, Antonio "have no clue"
Huete, Jordan "doesn't run VirtualBox" Gordeev and Samuel Greear found
out that the primary problem that DragonFly had on VirtualBox was caused
by a non-terminating loop.
The loop is in sys/platform/pc32/isa/clock.c and starts at line 411 (on
HEAD).
Forcing the loop to terminate after at most 1000 iterations causes
DragonFly to successfully run with UP kernel with ACPI turned on. UP
kernels with ACPI turned off and SMP kernels remain to be fixed.
In revision 1.11 of clock.c (diff to revision 1.10 at
http://www.dragonflybsd.org/cvsweb/src/sys/platform/pc32/isa/clock.c.diff?r1=1.10&amp;r2=1.1),
the case in the loop body when delta < 0 was simplified, which
apparently affected the loop termination condition.
The change from revision 1.10 to revision 1.11 includes the following
strange change, too:

- delta = prev_tick - tick;
+ delta = tick - prev_tick;

The FreeBSD code handling the delta values looks confused, and as the
current DragonFly code fails at least on VirtualBox, I think a closer
examination of the actually occurring delta values is merited.

#12 Updated by dillon over 6 years ago

:
:- delta = prev_tick - tick;
:+ delta = tick - prev_tick;
:
:The FreeBSD code handling the delta values looks confused, and as the
:current DragonFly code fails at least on VirtualBox, I think a closer
:examination of the actually occurring delta values is merited.

Well, insofar as I can tell that particular line is correct. The
sys_cputimer is a monotonically increasing counter.

One thing that could be happening is the count value could be
completely random due to the emulation. I'm not sure if it is
possible to print out the 'tick' in that loop with a kprintf(),
it might be too early in the boot sequence, but it is worth a try
to see if the values are fluctuating wildly or not working at all.

I suspect the issue when not using ACPI is that the emulation is
not handling the 8254 timer mode correctly.

-Matt
Matthew Dillon
<>

#13 Updated by tuxillo over 6 years ago

We've been doing some investigation with Virtual Box OSE 1.6.1 (trunk version)
and thanks to selective logging (that's how vbox developers call it) I've tried
to booted DF (from 1.12.1 LiveCD without ACPI) and collected some information
about PIT.

You can find it at:
http://leaf.dragonflybsd.org/~tuxillo/bugs/995/

As it's an early boot stage so kprintf() will show nothing (console not
initalized).

I've observed that latched count comes from 0xffff and reaches 0x0001

pit_latch_count: latched_count=0x0003 / 0054922886 ns (c=0x10000 m=2)
pit_latch_count: latched_count=0x0002 / 0054923724 ns (c=0x10000 m=2)
pit_latch_count: latched_count=0x0002 / 0054923724 ns (c=0x10000 m=2)
pit_latch_count: latched_count=0x0002 / 0054923724 ns (c=0x10000 m=2)
pit_latch_count: latched_count=0x0002 / 0054923724 ns (c=0x10000 m=2)
pit_latch_count: latched_count=0x0001 / 0054924563 ns (c=0x10000 m=2)

- In FreeBSD (7.0 without ACPI) I don't see any pit latches.

As I "have no clue" I would wait for hackers' comments :))

Regards,
Antonio Huete

#14 Updated by msylvan about 6 years ago

So it's an overflow problem. Take the absolute value of (tick - prev_tick) instead?

#16 Updated by mneumann almost 6 years ago

With the following patch DragonFly runs perfectly well on VirtualBox
(acpi_load="YES"; VT-x/AMD-V deactivated).

I don't know if delta=0 is possible on a real machine and if it would do
harm to leave the loop in that case. If it would be harmful, I'd suggest
to introduce a tunable virtualbox_quirk and change the patch below
towards this one:

if (delta == 0 && virtualbox_quirk) break;

Any thoughts?

Regards,

Michael

Index: clock.c
===================================================================
RCS file: /home/dcvs/src/sys/platform/pc32/isa/clock.c,v
retrieving revision 1.55
diff -u -r1.55 clock.c
--- clock.c 2 Aug 2008 01:14:43 -0000 1.55
+++ clock.c 27 Sep 2008 00:51:09 -0000
@@ -420,6 +420,8 @@
ticks_left -= delta;
if (doswitch && ticks_left > 0)
lwkt_switch();
+ if (delta == 0) break;
+
}
#ifdef DELAYDEBUG
if (state == 1)

#17 Updated by qhwt+dfly almost 6 years ago

I was under the impression that we had a TSC-based timer and could switch
via sysctl or a loader variable, but maybe I was confused, probably it's
FreeBSD 5+.

Out of curiosity, does setting hw.i8254.walltimer to 1 or 2 change
the situation?

Do you need the patch only during the boot? If so, I'd rather try to fix
the cputimer, or add one that works for VirtualBox.

Cheers.

#18 Updated by dillon almost 6 years ago

We still use the 8254 to generate timer interrupts for the
systimer API.

A great project, if you want one, would be to use the APIC on cpu #0
(not ACPI)... the actual APIC timer, which can also generate interrupts,
instead of the 8254. So if the APIC is present, we'd use that.

I do not think it would be very hard to do, and that combined with
using the acpi timer for our real-time timebase would allow us to
avoid the use of the 8254 entirely.

-Matt
Matthew Dillon
<>

#19 Updated by msylvan almost 6 years ago

Should the timer project be added to this wiki page?
http://wiki.dragonflybsd.org/index.cgi/ProjectsPage

Also, since I'm new here -- how are projects coordinated between DFly
contributors? Out of self-interest I might want to look at porting OpenBSD
wireless drivers, for example, but I don't know if anyone else is working on it.

#20 Updated by justin almost 6 years ago

On Wed, October 1, 2008 11:08 am, Michel Salim wrote:

Say "I'm working on this" on kernel@, and if anyone else is involved, they
can speak up. It is often best to have specific questions so that people
can focus on what to answer or comment on.

#21 Updated by tuxillo over 5 years ago

It seems that VBox devels implemented a fix. Now it is time for testing:
More information on: http://www.virtualbox.org/ticket/916

#22 Updated by corecode over 5 years ago

reported as working by tuxillo

Also available in: Atom PDF