At Fri, 16 Apr 2021 11:44:08 +0100, David Brownlee wrote:
Subject: Re: one remaining mystery about the FreeBSD domU failure on NetBSD
XEN3_DOM0
>
> On Fri, 16 Apr 2021 at 08:41, Greg A. Woods wrote:
>
> > What else is different? What am I missing? What could be different in
>
On Fri, 16 Apr 2021 at 08:41, Greg A. Woods wrote:
> What else is different? What am I missing? What could be different in
> NetBSD current that could cause a FreeBSD domU to (mis)behave this way?
> Could the fault still be in the FreeBSD drivers -- I don't see how as
> the same root problem ca
So I wrote a little awk script so that I could write 512-byte blocks
with varying values of bytes. (Awk is the only decent programming
language on the FreeBSD mini-memstick.img which I could think of that
would do something close to what I wanted it to do. I could have
combined awk+sh+dd and done
At Wed, 14 Apr 2021 19:53:47 +0200, Jaromír Doleček
wrote:
Subject: Re: one remaining mystery about the FreeBSD domU failure on NetBSD
XEN3_DOM0
>
> You can test if this is the problem by disabling the feature in
> negotiation in NetBSD xbdback.c - comment out the code which sets
>
At Wed, 14 Apr 2021 19:53:47 +0200, Jaromír Doleček
wrote:
Subject: Re: one remaining mystery about the FreeBSD domU failure on NetBSD
XEN3_DOM0
>
> You can test if this is the problem by disabling the feature in
> negotiation in NetBSD xbdback.c - comment out the code which sets
>
Le mer. 14 avr. 2021 à 03:21, Greg A. Woods a écrit :
> However their front-end code does detect it and seems to make use of it,
> and has done for some 6 years now according to "git blame" (with no
> recent fixes beyond fixing a memory leak on their end). Here we see it
> live from FreeBSD's sys
At Tue, 13 Apr 2021 18:20:39 -0700, "Greg A. Woods" wrote:
Subject: Re: one remaining mystery about the FreeBSD domU failure on NetBSD
XEN3_DOM0
>
> So "17" seems an odd number, but it is apparently because of "Need to
> alloc one extra page to account f
At Sun, 11 Apr 2021 13:55:36 -0700, "Greg A. Woods" wrote:
Subject: Re: one remaining mystery about the FreeBSD domU failure on NetBSD
XEN3_DOM0
>
> Definitely writing to a FreeBSD domU filesystem, i.e. to a FreeBSD
> xbd(4) with a new filesystem created on it, is impossibl
wo...@planix.ca ("Greg A. Woods") writes:
>system was suffering the effects of accessing the corrupted filesystem I
>was experimenting with. Note the SIGSEGV's from processes apparently
>after the kernel has gone into its halt-spin loop (this is the first
>time I've seen this particular misbehavi
On Sun, 11 Apr 2021, Greg A. Woods wrote:
Anyway this does something slightly different (and better, or worse) on
the FreeBSD side, but still ends up with a corrupted filesystem, as seen
from both sides, though maybe not so bad from NetBSD's point of view:
# mount /dev/da1
mount: /dev/da1: unkn
On Sun, 11 Apr 2021, Greg A. Woods wrote:
NetBSD can actually make some sense of this FreeBSD filesystem though:
# fsck -n /dev/mapper/rscratch-fbsd--test.0
** /dev/mapper/rscratch-fbsd--test.0 (NO WRITE)
Invalid quota magic number
CONTINUE? yes
** File system is already clean
** Last Mounted
At Sun, 11 Apr 2021 23:04:29 - (UTC), mlel...@serpens.de (Michael van Elst)
wrote:
Subject: Re: one remaining mystery about the FreeBSD domU failure on NetBSD
XEN3_DOM0
>
> wo...@planix.ca ("Greg A. Woods") writes:
>
> >SALVAGE? [yn] ^Cada0: disk error cmd=write 8
wo...@planix.ca ("Greg A. Woods") writes:
>SALVAGE? [yn] ^Cada0: disk error cmd=write 8145-8152 status: fffe
That seems to be a message from the disk driver:
/* Operation not supported (only happens on barrier writes). */
#define BLKIF_RSP_EOPNOTSUPP -2
If I understand that correctly, a
At Sun, 11 Apr 2021 21:13:44 + (UTC), RVP wrote:
Subject: Re: one remaining mystery about the FreeBSD domU failure on NetBSD
XEN3_DOM0
>
> I've run into this before. This is a NetBSD vs. FreeBSD UFS issue. Create
> a UFS v1 FS on FreeBSD if you want to write it on NetBSD:
>
At Sun, 11 Apr 2021 13:23:31 -0700, "Greg A. Woods" wrote:
Subject: one remaining mystery about the FreeBSD domU failure on NetBSD
XEN3_DOM0
>
> In fact it only seems to be fsck that complains, possibly along
> with any attempt to write to a filesystem, that causes problems.
So, with the vnd(4) issue more or less sorted, there seems to be one
major mystery remaining w.r.t. whatever has gone wrong with the ability
of NetBSD-current XEN3_DOM0 to host FreeBSD domUs.
I still can't create a clean filesystem on a writeable disk. The
"newfs" runs fine, but a subsequent "fsc
16 matches
Mail list logo
