!)
--
Greg A. Woods
Planix, Inc.
wo...@planix.com +1 416 218 0099http://www.planix.com/
pgpfCHbBPXKwo.pgp
Description: PGP signature
At Fri, 29 Jan 2010 14:43:38 -0600, David Young dyo...@pobox.com wrote:
Subject: Re: kernel level multilink PPP and maybe (re)porting FreeBSD netgraph
On Fri, Jan 29, 2010 at 02:56:31PM -0500, Greg A. Woods wrote:
I need advanced kernel-level multilink PPP (MLPPP) support, including
be composed into any graph that meets one's current
requirements, and it's all done without recompiling anything.
--
Greg A. Woods
Planix, Inc.
wo...@planix.com +1 416 218 0099http
At Sat, 30 Jan 2010 15:11:03 -0600, David Young dyo...@pobox.com wrote:
Subject: Re: kernel level multilink PPP and maybe (re)porting FreeBSD netgraph
On Sat, Jan 30, 2010 at 03:59:29PM -0500, Greg A. Woods wrote:
The kernel code (if indeed it has any client code -- not sure yet)
doesn't
not with the fastest result, unless I can get help on the
FreeBSD side at making the code more portable.
--
Greg A. Woods
Planix, Inc.
wo...@planix.com +1 416 218 0099http://www.planix.com
. :-)
--
Greg A. Woods
Planix, Inc.
wo...@planix.com +1 416 218 0099http://www.planix.com/
pgpqrFxhJMuKN.pgp
Description: PGP signature
folks seem to
forget it. I think even I have been known to forget it sometimes. ;-)
Wrong. Device numbers should be irrelevant to anything but operations
on device_t objects.
Indeed.
--
Greg A. Woods
At Thu, 11 Mar 2010 10:22:29 +0900, Masao Uebayashi uebay...@gmail.com wrote:
Subject: Re: (Semi-random) thoughts on device tree structure and devfs
On Thu, Mar 11, 2010 at 4:33 AM, Greg A. Woods wo...@planix.ca wrote:
At Wed, 10 Mar 2010 08:56:36 + (GMT), Iain Hibbert
plu...@rya
with no more
persistence than tmpfs, md. or mfs.
--
Greg A. Woods
Planix, Inc.
wo...@planix.com +1 416 218 0099http://www.planix.com/
pgpbWA7E47MWU.pgp
Description: PGP signature
they are used.
--
Greg A. Woods
Planix, Inc.
wo...@planix.com +1 416 218 0099http://www.planix.com/
pgpVTS2ubXFh7.pgp
Description: PGP signature
.
--
Greg A. Woods
Planix, Inc.
wo...@planix.com +1 416 218 0099http://www.planix.com/
pgpZAMKw7TNbn.pgp
Description: PGP signature
that kind of design mistake several
times before -- but I don't know any details of your MSI board (and I
can't find any manuals or other information about it on MSI's site).
--
Greg A. Woods
Planix, Inc
if unbound was actually listening on the right interfaces.
--
Greg A. Woods
+1 416 218-0098VE3TCP RoboHack wo...@robohack.ca
Planix, Inc. wo...@planix.com Secrets of the Weird wo...@weird.com
pgp4moR2WFLUD.pgp
Description
get relatively accurate user
and system (and ISR) times per process as a result.
--
Greg A. Woods
Planix, Inc.
wo...@planix.com +1 250 762-7675http://www.planix.com/
pgpYwaAKjBz1j.pgp
At Mon, 31 Oct 2011 23:28:49 +, David Laight da...@l8s.co.uk wrote:
Subject: Re: getrusage() problems with user vs. system time reporting
On Mon, Oct 31, 2011 at 04:08:13PM -0700, Greg A. Woods wrote:
So, if I understand the way SYSCALL_TIMES_PROCTIMES is implemented it
effectively
At Tue, 01 Nov 2011 01:43:23 -0700, Greg A. Woods wo...@planix.ca wrote:
Subject: Re: getrusage() problems with user vs. system time reporting
Indeed with all this doom and gloom about TSC it seems it might be
better just to use binuptime() -- that probably won't be as fast
though
using split() or whatever uses FS normally.
--
Greg A. Woods
Planix, Inc.
wo...@planix.com +1 250 762-7675http://www.planix.com/
pgpRRsykMmxKn.pgp
Description: PGP signature
and was mounted async. Demons will fly out of your nose
--
Greg A. Woods
Planix, Inc.
wo...@planix.com +1 250 762-7675http://www.planix.com/
pgppoVyhhnBug.pgp
Description: PGP
, it
should still be used with care (i.e. recognition of the risks of
less-tested, much more complex code, and vastly changed internal
implmentation semantics implying radically different recovery modes.)
--
Greg A. Woods
At Fri, 9 Dec 2011 22:12:25 -0500, Donald Allen donaldcal...@gmail.com wrote:
Subject: Re: Lost file-system story
On Fri, Dec 9, 2011 at 8:43 PM, Greg A. Woods wo...@planix.ca wrote:
At Fri, 9 Dec 2011 15:50:35 -0500, Donald Allen donaldcal...@gmail.com
wrote:
Subject: Re: Lost file
At Mon, 12 Dec 2011 15:08:40 +, David Holland dholland-t...@netbsd.org
wrote:
Subject: Re: Lost file-system story
On Sun, Dec 11, 2011 at 06:53:26PM -0800, Greg A. Woods wrote:
No, as far as I can tell he understands perfectly well; he just
doesn't consider the behavior acceptable
a damaged file system no matter how
useful the outcome may be.
You don't put that in the manual page though, and you never give the end
user that expectation (unless it's already too late for them and they've
got yolk all over their face).
--
Greg
.
--
Greg A. Woods
Planix, Inc.
wo...@planix.com +1 250 762-7675http://www.planix.com/
pgpiHkVmGsc5g.pgp
Description: PGP signature
will be recovereable, even if something goes wrong.
Eric, what part of MNT_ASYNC don't you understand?
--
Greg A. Woods
Planix, Inc.
wo...@planix.com +1 250 762-7675http://www.planix.com
At Mon, 12 Dec 2011 14:17:35 -0600, Eric Haszlakiewicz e...@nimenees.com
wrote:
Subject: Re: Lost file-system story
On Mon, Dec 12, 2011 at 11:39:38AM -0800, Greg A. Woods wrote:
Having almost no knowledge about ext2 or any other non-Unix-based
filesystems, I'm trying to be careful
ordered operations.
There have of course also been some pretty serious bugs in various fsck
implementations across the years and vendors.
--
Greg A. Woods
Planix, Inc.
wo...@planix.com +1 250 762
, or even umount), in which case you'll not only be sure that
the filesystem is consistent and secure, but you'll know when it reaches
this state (i.e. you won't have to guess about when sync(2)'s scheduled
work completes).
--
Greg A. Woods
At Wed, 14 Dec 2011 07:50:37 + (UTC), mlel...@serpens.de (Michael van Elst)
wrote:
Subject: Re: Lost file-system story
wo...@planix.ca (Greg A. Woods) writes:
easy, if not even easier, to do a mount -u -r
Does this work again?
Not that I know of, and PR#30525 concurs, as does
use for older and very different hardware from the
current melange of almost-identical i386 derivatives is to help run as a
test base for the toolchain.
--
Greg A. Woods
Planix, Inc.
wo...@planix.com
, w.r.t. SMP? This
would maybe allow independent maintenance and testing of less widely
used protocol modules (and perhaps even drivers) by third parties.
--
Greg A. Woods
Planix, Inc.
wo...@planix.com
)
--
Greg A. Woods
Planix, Inc.
wo...@planix.com +1 250 762-7675http://www.planix.com/
pgpD3ABW7JR_U.pgp
Description: PGP signature
don't understand anyone who has the
desire to try to run build.sh on a VAX-750 to build even just a kernel,
let alone the whole distribution. I won't even bother trying that on my
Soekris board!
--
Greg A. Woods
kern.ipc.shm_use_phys = 0
kern.ipc.msgmni = 200
kern.ipc.msgseg = 16384
kern.ipc.semmni = 200
kern.ipc.semmns = 600
kern.ipc.semmnu = 300
--
Greg A. Woods
+1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgphcHNkIPNT0.pgp
Description: OpenPGP Digital Signature
At Mon, 08 Apr 2019 20:37:39 -0700, "Greg A. Woods" wrote:
Subject: Re: semaphores options
>
> RCS file: /cvs/master/m-NetBSD/main/src/sys/conf/param.c,v
>
> revision 1.65
> date: 2015-05-12 19:06:25 -0700; author: pgoyette; state: Exp; l
st astonishment.
E.g. in the example I gave, the only thing allowed would be for the
implementation to do as it please IFF and when the pointer passed was
actually a nil pointer at runtime (and perhaps in this case with a
strong hint that the best and ideal behaviour would be something akin to
cal
At Mon, 24 Feb 2020 22:15:22 -0500 (EST), Mouse
wrote:
Subject: Re: NULL pointer arithmetic issues
>
> > Greg A. Woods wrote:
> >
> > NO MORE "undefined behaviour"!!! Pick something sane and stick to it!
> >
> > The problem with mode
ay:
Modern "Standard C" is actually "Useless C" and "Unusable C"
Indeed I now say if "Standard C" follows C++ then it will be safe to say
that a good optimizing compiler will soon be able to turn all C programs
into "abort()" calls.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpdFaG78xjZR.pgp
Description: OpenPGP Digital Signature
piler assumes SIGSEGV
would/should/could happen before the other code gets a chance to run.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpGIvFrvwd81.pgp
Description: OpenPGP Digital Signature
2.396989] dk6 at sd2: "EFI system", 262144 blocks at 2048, type: msdos
[ 193342.396989] dk7 at sd2: "d3aa0396-d911-4aac-baa8-f2478557d31a", 7544832
blocks at 264192, type: ffs
I'm guessing it's a software bug with bad locking order somewhere.
--
t should die)
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpezCK6Ft2EX.pgp
Description: OpenPGP Digital Signature
At Tue, 30 Jun 2020 12:52:37 -0700, "Greg A. Woods" wrote:
Subject: So it seems "umount -f /nfs/mount" still doesn't work.
>
Curiously the kernel now does something I didn't quite expect when one
tries to reboot a system with a stuck mount. I was able to see this as
e
crash(8) is unable to do a backtrace:
# ktrace crash
Crash version 9.99.64, image version 9.99.64.
Kernel compiled without options LOCKDEBUG.
Output from a running system is unreliable.
crash> trace /t 0t4003
crash: kvm_read(0x4, 4): kvm_read: Bad address
trace: pid 4003 lid 4003
crash>
--
), but in my opinion C is just not really safe without them.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgplEU3KR6NQt.pgp
Description: OpenPGP Digital Signature
At Tue, 30 Jun 2020 14:28:38 -0700, "Greg A. Woods" wrote:
Subject: Re: So it seems "umount -f /nfs/mount" still doesn't work.
>
> At Tue, 30 Jun 2020 12:52:37 -0700, "Greg A. Woods" wrote:
> Subject: So it seems "umount -f /nfs/mount"
gt; that desire is at least mostly orthogonal to chroot.
I'm less convinced of this part though This ability has brought
more complexity (e.g. mount options to disable devices per filesystem)
than I've ever seen pay off in benefit.
--
Greg A. Woods
Kelo
unno.
I think it's a good idea for some classes of devices, but I'm not so
sure it has to be a one-size-fits-all singular solution.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgp4sxzsRR_r8.pgp
Description: OpenPGP Digital Signature
struct references within the function
implementation is here:
https://github.com/robohack/experiments/blob/master/tc99namedparams.c
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpLOiWfxFc4v.pgp
Description: OpenPGP Digital Signature
ey': AuthenticationString(os.urandom(32)),
KeyboardInterrupt
*** Error code 1 (ignored)
*** Signal 2
*** Signal 2
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpMapUqkjr1L.pgp
Description: OpenPGP Digital Signature
ptions BUFCACHE) on large-memory
# systems (as BUFCACHE cannot be set below 5%).
#
# note this value is given in bytes.
#
#vm.bufmem_hiwater=
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpSINIeXL6Sx.
m.bufcache so that it's not wasted.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgp6P_y72diVe.pgp
Description: OpenPGP Digital Signature
At Mon, 5 Apr 2021 15:37:49 -0400, Thor Lancelot Simon wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> On Sun, Apr 04, 2021 at 03:32:08PM -0700, Greg A. Woods wrote:
> >
> > BTW, to me reusing the same entropy on every reboot seems less secure.
>
t; or whatever in
front of it and hope that's enough and that it's still not too
predictable.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpxsHTzqoenJ.pgp
Description: OpenPGP Digital Signature
ch the documentation and tools
(specifically rndctl). That the core of it it is just a two-line patch
makes this fix extremely satisfying.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpWiXqu
: pid %d (%s) blocking due to lack of
entropy\n", /* xxx uprintf() instead/also? */
curproc->p_pid, curproc->p_comm);
if (ISSET(flags, ENTROPY_SIG)) {
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpbil_4h9ofy.pgp
Description: OpenPGP Digital Signature
m already has. If interrupted, either
the old seed or the new seed will be in place.
The code seems to concur.
Also the system re-saves the $random_file via /etc/security
(unconditionally, i.e. always, but only if $random_file is set).
--
Greg
t be hiding out in my garage.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpdkEisDB6Js.pgp
Description: OpenPGP Digital Signature
At Tue, 6 Apr 2021 20:21:43 +0200, Martin Husemann wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> On Tue, Apr 06, 2021 at 10:54:51AM -0700, Greg A. Woods wrote:
> >
> > And the stock implementation has no possibility of ever providing an
> > in
ruct krndsource *rs, uint64_t value)
{
- rnd_add_data(rs, , sizeof value, 0);
+ rnd_add_data(rs, , sizeof value, sizeof value * NBBY);
}
/*
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgp9RYQDmBbzG.pgp
Description: OpenPGP Digital Signature
en
>if the Entropy Source is not operating as well as predicted.
"design" != implementation
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpjs3QaPXmot.pgp
Description: OpenPGP Digital Signature
have any worry
whatsoever at the moment about one VM guest spying on, or influencing
the PRNG, in another. Zero worry. They're all _me_. I don't need some
theoretically perfect level of protection from myself.
--
Greg A. Woods
Kelowna, BC
At Sun, 4 Apr 2021 09:49:58 +, Taylor R Campbell
wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> > Date: Sat, 03 Apr 2021 12:24:29 -0700
> > From: "Greg A. Woods"
> >
> > Updating a system, even on -current, shouldn't cr
ws what they're doing, and better security
> is available, at a price, but a nice happy medium is what fits me best.
Indeed again.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpvuqMttw
n to recommend a suitable value for
rndctl_flags in /etc/rc.conf.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpnOADtmWrjC.pgp
Description: OpenPGP Digital Signature
code I fixed with my patch that was at fault.
I told the system to "count" the entropy being gathered by the
appropriate driver(s), but it was being ignored entirely.
After my fix the system behaved as I told it to.
--
Greg A. Woods
Kelowna, BC +1 25
my systems (virtual and real)
actually have.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpw8NF4N8YCU.pgp
Description: OpenPGP Digital Signature
D
> will however be ... a more challenging problem.
Leaving things like that would be totally silly.
With my patch the old way of gathering entropy from devices works just
fine as it always did, albeit with the second patch it does require a
tiny bit of extra configuration.
--
opy.collection = 1
kern.entropy.depletion = 0
kern.entropy.consolidate = -23552
kern.entropy.gather = -23552
kern.entropy.needed = 256
kern.entropy.pending = 0
kern.entropy.epoch = 19
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpZNU3eXL60M.pgp
Description: OpenPGP Digital Signature
e problem -- the hardware
should be providing plenty of entropy.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpfPcjeu55q3.pgp
Description: OpenPGP Digital Signature
202.264290] entropy: pid 7248 (cat) blocking due to lack of entropy
[ 579669.831978] entropy: ready
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
At Tue, 30 Mar 2021 10:06:19 -0700, "Greg A
At Tue, 30 Mar 2021 23:53:43 +0200, Manuel Bouyer
wrote:
Subject: Re: nothing contributing entropy in Xen domUs? (causing python3.7
rebuild to get stuck in kernel in "entropy" during an "import" statement)
>
> On Tue, Mar 30, 2021 at 02:40:18PM
ing possible, then I would have looked elsewhere to find out how
to give the system more bits of entropy. As is in my Xen domU system
the output of "rndctl -l" leads me to believe all of my devices are
collecting both timing and value samples, and using either one or the
other to gather ent
n.entropy.pending: (no description)
17:27 [1.833] # sysctl -d kern.entropy.epoch
kern.entropy.epoch: (no description)
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpE52Jkajvwh.pgp
Description: OpenPGP Digital Signature
eeing
would be one step closer, and should be extremely easy.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpOvi5MZvUCj.pgp
Description: OpenPGP Digital Signature
At Wed, 7 Apr 2021 09:52:29 +0200, Martin Husemann wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> On Tue, Apr 06, 2021 at 03:12:45PM -0700, Greg A. Woods wrote:
> > > Isn't it as simple as:
> > >
> > > dd bs=32 if=/dev/urandom of=/
includes many of us.
It doesn't have to be the default.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpgg9AaQiU92.pgp
Description: OpenPGP Digital Signature
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
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
- I just can't explain
it well enough yet.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpbUW36DVCRL.pgp
Description: OpenPGP Digital Signature
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
32740 files, 2349557 used, 1431650 free (538 frags, 178889 blocks, 0.0%
fragmentation)
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
se 1 - Check Blocks and Sizes
PARTIALLY TRUNCATED INODE I=28
SALVAGE? [yn] n
PARTIALLY TRUNCATED INODE I=112
SALVAGE? [yn] ^Cda0: disk error cmd=write 8145-8152 status: fffe
#
* FILE SYSTEM MARKED DIRTY *
#
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpELwDHrgUjQ.pgp
Description: OpenPGP Digital Signature
er/m-NetBSD/main/src/sys/uvm/uvm_page.c,v
retrieving revision 1.250
diff -u -r1.250 uvm_page.c
--- uvm/uvm_page.c 20 Dec 2020 11:11:34 - 1.250
+++ uvm/uvm_page.c 8 Apr 2021 21:41:20 -
@@ -983,8 +983,7 @@
* Attach RNG source for this CPU's VM events
*/
rnd_attach_source(>rs, ci->ci_data.cpu_name, RND_TYPE_VM,
- RND_FLAG_COLLECT_TIME|RND_FLAG_COLLECT_VALUE|
- RND_FLAG_ESTIMATE_VALUE);
+ RND_FLAG_DEFAULT);
}
/*
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpMtaoK9AMBK.pgp
Description: OpenPGP Digital Signature
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
CG 37: BAD CHECK-HASH 0x37517da4 vs 0x40c2cf31
CG 38: BAD CHECK-HASH 0xc938c503 vs 0x9b844ab6
CG 39: BAD CHECK-HASH 0x60447f31 vs 0x23129481
CG 40: BAD CHECK-HASH 0x69bfbe19 vs 0xa81f5e9
CG 41: BAD CHECK-HASH 0xc0c3042b vs 0xbd37ebd1
CG 42: BAD CHECK-HASH 0x3eaabc8c vs 0xfadfd8d1
CG 43: BAD CHE
r a given guest would not advertise the feature at
all.
I've some other things to do before I can reboot -- I'll report as soon
as that's done
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pg
2 bytes @ 28141568000: mismatch: /dev/da0[+1032] \x28 !=
/var/tmp/ckfile.1[ln#0][1032] \x22
blkchk: pread 8192 bytes @ 28141568000: mismatch: /dev/da0[+1033] \x28 !=
/var/tmp/ckfile.1[ln#0][1033] \x22
--
Greg A. Woods
Kelowna, BC +1 250 762
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
>
gically implicit
> padding would have unexpected side effects.
>
> But the code also needs to be adjusted for different sector sizes.
So since vnd->sc_size is in units of disk blocks
dg->dg_secperunit =
((vnd->sc_size * DEV_BSIZE) + DEV_BSIZE - 1) /
between 8.99.32 (2020-06-09) and 9.99.81
(2021-03-10).
Unfortunately I don't have enough hardware that's Xen-capable and up and
running well enough to allow me to do any brute-force bisecting.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675
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 caused corruption in both HVM and PVH domUs.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675
nder
+* amount, but (if it is writeable) writing into the partly
+* empty cylinder, i.e. past current end of the file, will
+* simply extend the file
+*/
vnd_set_geometry(vnd);
if (vio->vnd_flags & VNDIO
0 0 0 # (Cyl. 0*-386*)
disklabel: boot block size 0
disklabel: super block size 0
# fsck -n /dev/vnd0f
** /dev/rvnd0f (NO WRITE)
BAD SUPER BLOCK: CAN'T FIND SUPERBLOCK
/dev/rvnd0f: CANNOT FIGURE OUT SECTORS PER CYLINDER
--
Greg
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.
E? [yn] n
SUMMARY INFORMATION BAD
SALVAGE? [yn] n
BLK(S) MISSING IN BIT MAPS
SALVAGE? [yn] n
12076 files, 91642 used, 7647797 free (293 frags, 955938 blocks, 0.0%
fragmentation)
* UNRESOLVED INCONSISTENCIES REMAIN *
--
Greg A. Woods
Kelowna, BC
BSD tradition". See my previous reply.
The Unix (or "UNIX") tradition is for "stty kill" to be 'DEL' (and erase
to be either 'BS' or '#', depending on how far back you go).
In my experience NetBSD already follows the BSD tradition very well.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpwahgTRyhrJ.pgp
Description: OpenPGP Digital Signature
0" compatible and
have been made to work well enough for vi(1) to behave properly when
TERM=vt220.
Personally I think there is a massive over-use of "use=vt220" in
terminfo -- that should be reserved ONLY for true DEC VT derivatives and
updates of the real VT220.
BTW, my own loca
o help fix these two problems, but
I'm not anywhere near able to even begin to fix them on my own (well I
could hack on NetBSD to make it work with PCC, but I don't want to be a
one-man-band on a project of that scale).
--
Greg A. Woods
Kelowna, BC +
her modern
GCC or LLVM/Clang's output.
I would say the main reason is PCC doesn't (as far as I know) employ
any "Undefined Behaviour" caveat to optimize code, for example.
I'll let the reader decide which might have the "higher" quality.
--
At Wed, 23 Mar 2022 20:56:27 +0100, Anders Magnusson
wrote:
Subject: Re: pcc [was Re: valgrind]
>
> Den 2022-03-23 kl. 19:37, skrev Greg A. Woods:
> >
> > Heh. I would say PCC's generated code doesn't compare to either modern
> > GCC or LLVM/Clang's output.
> >
&
98 matches
Mail list logo
