DragonFlyBSD

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

I test it again on Friday with Vmware Server
2008/4/29, Sascha Wildner <bugs@lists.dragonflybsd.org>:

Sascha Wildner <saw@online.de> 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 <bugs@lists.dragonflybsd.org>
<https://bugs.dragonflybsd.org/issue995>
_____________________________________________

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,
--
fgudin@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdf-eu.org

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

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

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

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

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

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.

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)

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&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.

:
:- 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 
                    <dillon@backplane.com>

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

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

http://permalink.gmane.org/gmane.os.netbsd.devel.cvs/116453 ?

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)

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.

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 
                    <dillon@backplane.com>

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.

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.

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

reported as working by tuxillo