DragonflyBSD port procedure

[Matthew Dillon]

A double fault is a hard one.  The panic message is just related to the
double fault.. there was either a panic before that one or something else
that caused the issue that led to the double-fault.  There is no easy way
to debug this.  It could be anything, including issues with the
virtualization itself.  Here are some suggestions:

* You are running the VM with 16 cpu cores so one thing to try would be to
try just running the VM with one cpu core and see if that stops the panic.

* You can try a raw image (not qcow2), in case its a virtio issue of some
sort.

* You can try with and without hardware acceleration (though yah, I know...
gonna be nasty slow without).

-Matt

On Wed, May 14, 2025 at 6:02 PM Matthew Dillon <dillon at apollo.backplane.com>
wrote:

> In e-mail of Wed, 30 Apr 2025 11:41:36 -0600 on this list, I reported
> a problem with the new DragonFlyBSD 6.4.1 installerl.  Subsequent
> discussions led to a solution, and 6.4.1 is now stable and working
> fine at Utah.
>
> On Saturday, I tried an install of the new 6.4.2, and was pleased to
> find that it installed normally, and recognized the correct size
> (80GB) of its qcow2 disk image.  I then installed my usual large
> collection of DragonFlyBSD packages --- about 150 of them, and that
> too was successful.
>
> To save unnecessary work, I then ran an rsync to copy our $prefix tree
> of locally added software from 6.4.1 to 6.4.2: it ran for awhile, then
> died with a kernel panic. I photographed the console screen, which
> looked something like this (leaving out numeric addresses);
>
>         Fatal double fault
>         rip = ...
>         rip = ...
>         rip = ...
>         cpuid = 1 ; lapic id = 1
>         panic: assertion "count & TOK_COUNTMASK" failed in _lwkt_reltokref
>                at /usr/sys/kern/lwkt_token.c:458
>         cpuid = 1
>         Trace beginning at ...
>         ...
>         Debugger("panic")
>         CPU1 stopping CPUS; 0x00000fffd
>         ...
>
> I rebooted the system at that point, restarted the rsync, and after
> several minutes of rsync running, got a different kernel panic, which
> I, alas, neglected to photograph.
>
> Another reboot, and restart of the rsync: it ran to completion.  I
> reran it one more time, just in case there was file corruption from
> the kernel crashes.  That final rsync reported a clean copy, and since
> then, 6.4.2 has been stable.
>
> I am now copying the installation disk image tree from campus to my
> home machine (both physical machines run Ubuntu 24.04), and I'll bring
> 6.4.2 up at home so as to have the new DragonFlyBSD version on an
> independent physical machine; the two have completely different
> manufacturers.  One has dual Intel Xeon Silver 4316 CPUs, and the
> other has a single Xeon Platinum 8253 CPU.
>
> By early June, I expect to have a brand new rack-mounted large memory
> and large core count server installed in our machine room, and I may
> use that as a third platform to test DragonFlyBSD on.
>
> Have other list members got stable DragonFlyBSD 6.4.2 installations?
> Or seen unexpected crashes with 6.4.2?
>
> Failure reports aren't terribly helpful for developers unless they can
> be reliably reproduced at independent sites :^).
>
>
> -------------------------------------------------------------------------------
> - Nelson H. F. Beebe                    Tel: +1 801 581 5254
>     -
> - University of Utah
>     -
> - Department of Mathematics, 110 LCB    Internet e-mail:
> beebe at math.utah.edu  -
> - 155 S 1400 E RM 233                       beebe at acm.org
> beebe at computer.org -
> - Salt Lake City, UT 84112-0090, USA    URL:
> https://www.math.utah.edu/~beebe -
>
> -------------------------------------------------------------------------------
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20250514/87948136/attachment.htm>