reported as working by tuxillo

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

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.

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.

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>

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.

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)

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

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

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

:
:-		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>

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.

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)

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.

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

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

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

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

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

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

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>
>  _____________________________________________________
>

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

Hello!

DFly doesnt work on Vmware and Virtualbox

The time counter hangs in the Boot menu on the ISO

Only Qemu works

araratpp