Updating src tree:
P src/bin/sh/parser.c
P src/doc/CHANGES
P src/doc/CHANGES.prev
P src/share/man/man4/eqos.4
P src/sys/arch/amd64/conf/GENERIC
P src/sys/arch/i386/conf/GENERIC
P src/sys/arch/next68k/dev/zs_kgdb.c
P src/sys/dev/ic/dwc_eqos.c
P src/sys/dev/pci/files.pci
U
On Fri, 20 Oct 2023, John D. Baker wrote:
> Thanks! HEAD built just fine, but with -10/i386, my custom kernels build
> OK, but the stock XEN3PAE_DOM0 build fails with:
>
> [...]
> # link XEN3PAE_DOM0/netbsd
> /r0/build/netbsd-10/tools/amd64/bin/i486--netbsdelf-ld -Map netbsd.map --cref
>
Hi Thomas,
Thomas Klausner wrote:
> On Fri, Oct 20, 2023 at 11:20:00PM +0200, Roland Illig wrote:
> > Am 20.10.2023 um 22:38 schrieb Thomas Klausner:
> > > Hi!
> > >
> > > I'm trying to find out what a program does, and found it does a lot of
> > > unlink syscalls, so I wanted to see what it
On Thu, 19 Oct 2023, Manuel Bouyer wrote:
> On Thu, Oct 19, 2023 at 08:46:27AM -0500, John D. Baker wrote:
>
> > [...]
> > # link VERTHANDI/netbsd
> > /r0/build/netbsd-10/tools/amd64/bin/i486--netbsdelf-ld -Map netbsd.map
> > --cref -T netbsd.ldscript -Ttext c010 -e start -X -o netbsd
On Fri, 20 Oct 2023, RVP wrote:
/*
printf("%d %d %s ", uid, pid, execname);
system("pr_realpath -p %d %s", pid, copyinstr(arg0));
printf("\n");
*/
I forgot to provide you with pr_realpath (in case you wanted the full path):
```
#include
#include
#include
On Fri, 20 Oct 2023, Thomas Klausner wrote:
I'm trying to find out what a program does, and found it does a lot of
unlink syscalls, so I wanted to see what it unlinks.
[...]
What's the proper way to do this?
Here you go (written ages ago for 9.0, should still work on -HEAD):
```
On Fri, Oct 20, 2023 at 11:20:00PM +0200, Roland Illig wrote:
> Am 20.10.2023 um 22:38 schrieb Thomas Klausner:
> > Hi!
> >
> > I'm trying to find out what a program does, and found it does a lot of
> > unlink syscalls, so I wanted to see what it unlinks.
>
> Did you try 'ktruss | grep NAMI'
Am 20.10.2023 um 22:38 schrieb Thomas Klausner:
> Hi!
>
> I'm trying to find out what a program does, and found it does a lot of
> unlink syscalls, so I wanted to see what it unlinks.
Did you try 'ktruss | grep NAMI' before diving deep into dtrace?
Roland
Hi!
I'm trying to find out what a program does, and found it does a lot of
unlink syscalls, so I wanted to see what it unlinks.
I tried
# dtrace -n syscall::unlink:entry'/pid == 27647/{ self->file = arg0; }' -n
syscall::unlink:return'{ trace(copyinstr(self->file)); self->file = 0; }'
but
A different machine has locked up, running recent netbsd-10. I was
doing pkgsrc rebuilds in zfs, in a dom0 with 4G of RAM, with 8G total
physical. It has a private patch to reduce the amount of memory used
for ARC, which has been working well.
All 3 tmux windows show something like
[
The NetBSD-current/i386 build is working again.
The following commits were made between the last failed build and the
first successful build:
2023.10.20.12.45.17 gdt src/usr.sbin/vnconfig/vnconfig.8 1.47
2023.10.20.13.04.21 wiz src/usr.sbin/vnconfig/vnconfig.8 1.48
g...@lexort.com (Greg Troxel) writes:
>I dimly knew this, but keep forgetting. Reading vndconfig(8), it does
>not explain that the normal path leads to incorrect behavior (stale
>reads from file cache even after closing the vnd, mtime).
vnd opens the backing file when the unit is created and
mlel...@serpens.de (Michael van Elst) writes:
> vnd has an optimization where the backing file isn't touched, but
> the underlying device is accessed directly. Then file cache and
> device aren't in sync and a backup program reading the file might
> read stale data. vnd should probably update the
This is an automatically generated notice of a NetBSD-current/i386
build failure.
The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2023.10.20.10.09.44.
An extract from the build.sh output follows:
93 | #define DESC_BOUNDARY (1ULL << 32)
14 matches
Mail list logo
