Sorry, I haven’t been paying attention, this was in response to the
thread with the virtio problem. Yeah, I have been updating precisely
because of this; during the update, it seemed rather stable, even though
it had a lot do do, with a few ports compiling, hammer cleanup running
and something
I’ve compiled it two days ago; was the fix in between there?
I’ll try to hunt down another real machine so that I can somehow at
least inject the kernel onto the server; right now, I can’t get it to
boot up no matter what I do, im past attempt number twenty and feel like
a lunatic for keeping at
On Wed, Jul 6, 2016 at 6:17 AM, Stefan Unterweger
<232.20...@chiffre.aleturo.com> wrote:
> Sorry for the long delay. Other, more urgent projects kept me so busy
> that I didn’t manage to catch up with this thread.
>
>
> * Matthew Dillon on Fri, May 27, 2016 at 10:08:06AM -0700:
>> Virtio (for
I forgot to add the output of ‚trace‘, here it is, beginning from the
most recent panic.
| db> trace
| mpipe_alloc_callback() at mpipe_alloc_callback+0x13d 0x80606056
| dmtc_crypto_read_start() at dmtc_crypto_read_start+0x54 0x826bd572
| dmtc_bio_read_done() at
Since I’m currently stuck staring at rebooting screeny anyway, I thought
I might as well copy the contents of the kernel page as plain text, for
easier reference. I hope I haven’t mistyped too many of those horribly
long memory addresses in the process.
Fatal trap 12: page fault while in kernel
Sorry for the long delay. Other, more urgent projects kept me so busy
that I didn’t manage to catch up with this thread.
* Matthew Dillon on Fri, May 27, 2016 at 10:08:06AM -0700:
> Virtio (for block storage devices) could be the cause. There are known
> bugs in the DragonFly driver for virtio
Yet another problem on the same virtualised host as in the other thread
a few weeks back.
As before, this is a presumably KVM virtualised host. With the
exception of a small boot partition, all storage volumes are encrypted
via cryptsetup‘s LUKS mode.
It looks like a race condition of some
Hello
I am booting DragonFly via UEFI on a macbookpro and running into
issues with console. UEFI puts console into a resolution 1680x1050,
but as soon as kernel has loaded and starts it switches to 40x25 mode
(or something similar, i.e. the default mode one sees at say CD boot),
but does not
