Re: aarch64-current build failure

[Chavdar Ivanov]

On Sun, 12 May 2024 at 09:14, Chavdar Ivanov  wrote:
>
> Hi,
>
> I am getting:
> 
> #create  libEGL/loader.d
> CC=/dumps/sysbuild/evbarm64/tools/bin/aarch64--netbsd-gcc
> /dumps/sysbuild/evbarm64/tools/bin/nbmkdep -f loader.d.tmp  --
> -std=gnu99 -Werror  --sysroot=/dumps/sysbuild/evbarm64/de
> stdir -I/usr/xsrc/external/mit/MesaLib/dist/include
> -I/usr/xsrc/external/mit/MesaLib/dist/include/drm-uapi
> -I/usr/xsrc/external/mit/MesaLib/dist/src/gbm/main
> -I/usr/xsrc/external/m
> it/MesaLib/dist/src/egl/main
> -I/usr/xsrc/external/mit/MesaLib/dist/src/gbm/backends/dri
> -I/usr/xsrc/external/mit/MesaLib/dist/src/loader
> -I/usr/xsrc/external/mit/MesaLib/dist/src -
> I/dumps/sysbuild/evbarm64/destdir/usr/X11R7/include/libdrm
> -DDEFAULT_DRIVER_DIR=\"/usr/X11R7/lib/modules/dri\"
> -D_EGL_NATIVE_PLATFORM=_EGL_PLATFORM_X11 -D_EGL_DRIVER_SEARCH_DIR=\"/
> usr/X11R7/lib\" -D_EGL_OS_UNIX=1 -DHAVE_X11_PLATFORM
> -DHAVE_DRM_PLATFORM -DHAVE_TIMESPEC_GET -DHAVE_PTHREAD -DHAVE_LIBDRM
> -DHAVE_MINCORE -DCSRG_BASED -DFUNCPROTO=15 -DNARROWPROTO -
> I/dumps/sysbuild/evbarm64/destdir/usr/X11R7/include
> -I/usr/xsrc/external/mit/MesaLib/dist/src/util
> -I/usr/xsrc/external/mit/MesaLib/dist/../src/util
> -I/usr/xsrc/external/mit/M
> esaLib/dist/src/mesa  -I/usr/xsrc/external/mit/MesaLib/dist/src
> -DDEFAULT_DRIVER_DIR=\"/usr/X11R7/lib/modules/dri\"  -DUSE_DRICONF
> -DHAVE_LIBDRM /usr/xsrc/external/mit/MesaLib.ol
> d/dist/src/loader/loader.c &&  mv -f loader.d.tmp loader.d
> /usr/xsrc/external/mit/MesaLib.old/dist/src/loader/loader.c:54:10:
> fatal error: util/xmlpool.h: No such file or directory
>54 | #include "util/xmlpool.h"
>   |  ^~~~
>
> 
>

Must have been failure of the update build - after several attempts I
wiped out obj, destdir and tools and the build finished.

> Chavdar
>
>
> --
> 



-- 

lldb 18.1.5 build failure under aarch64-current

[Chavdar Ivanov]

Hi,

Just noticing that wip/lldb and manually configured llvm that includes
lldb fail to complete under aarch64 -current. It builds OK under
amd64. Earlier versions used to work under both, so there is some
regression with respect to NetBSD support. I build it as I regularly
rebuild and test zig, which recently switched to llvm-18.

---
ld: lib/liblldbPluginProcessNetBSD.a(NativeThreadNetBSD.cpp.o): in
function `lldb_private:
:process_netbsd::NativeThreadNetBSD::NativeThreadNetBSD(lldb_private::process_netbsd::Nati
veProcessNetBSD&, unsigned long)':
NativeThreadNetBSD.cpp:(.text._ZN12lldb_private14process_netbsd18NativeThreadNetBSDC2ERNS0
_19NativeProcessNetBSDEm+0x6c): undefined reference to
`lldb_private::process_netbsd::Nati
veRegisterContextNetBSD::CreateHostNativeRegisterContextNetBSD(lldb_private::ArchSpec
cons
t&, lldb_private::NativeThreadProtocol&)'
NativeThreadNetBSD.cpp:(.text._ZN12lldb_private14process_netbsd18NativeThreadNetBSDC2ERNS0
_19NativeProcessNetBSDEm+0x6c): relocation truncated to fit:
R_AARCH64_CALL26 against unde
fined symbol 
`lldb_private::process_netbsd::NativeRegisterContextNetBSD::CreateHostNativeR
egisterContextNetBSD(lldb_private::ArchSpec const&,
lldb_private::NativeThreadProtocol&)'
[5299/5775] Building CXX object
tools/bugpoint/CMakeFiles/bugpoint.dir/CrashDebugger.cpp.o
ninja: build stopped: subcommand failed.



Chavdar


-- 

aarch64-current build failure

[Chavdar Ivanov]

Hi,

I am getting:

#create  libEGL/loader.d
CC=/dumps/sysbuild/evbarm64/tools/bin/aarch64--netbsd-gcc
/dumps/sysbuild/evbarm64/tools/bin/nbmkdep -f loader.d.tmp  --
-std=gnu99 -Werror  --sysroot=/dumps/sysbuild/evbarm64/de
stdir -I/usr/xsrc/external/mit/MesaLib/dist/include
-I/usr/xsrc/external/mit/MesaLib/dist/include/drm-uapi
-I/usr/xsrc/external/mit/MesaLib/dist/src/gbm/main
-I/usr/xsrc/external/m
it/MesaLib/dist/src/egl/main
-I/usr/xsrc/external/mit/MesaLib/dist/src/gbm/backends/dri
-I/usr/xsrc/external/mit/MesaLib/dist/src/loader
-I/usr/xsrc/external/mit/MesaLib/dist/src -
I/dumps/sysbuild/evbarm64/destdir/usr/X11R7/include/libdrm
-DDEFAULT_DRIVER_DIR=\"/usr/X11R7/lib/modules/dri\"
-D_EGL_NATIVE_PLATFORM=_EGL_PLATFORM_X11 -D_EGL_DRIVER_SEARCH_DIR=\"/
usr/X11R7/lib\" -D_EGL_OS_UNIX=1 -DHAVE_X11_PLATFORM
-DHAVE_DRM_PLATFORM -DHAVE_TIMESPEC_GET -DHAVE_PTHREAD -DHAVE_LIBDRM
-DHAVE_MINCORE -DCSRG_BASED -DFUNCPROTO=15 -DNARROWPROTO -
I/dumps/sysbuild/evbarm64/destdir/usr/X11R7/include
-I/usr/xsrc/external/mit/MesaLib/dist/src/util
-I/usr/xsrc/external/mit/MesaLib/dist/../src/util
-I/usr/xsrc/external/mit/M
esaLib/dist/src/mesa  -I/usr/xsrc/external/mit/MesaLib/dist/src
-DDEFAULT_DRIVER_DIR=\"/usr/X11R7/lib/modules/dri\"  -DUSE_DRICONF
-DHAVE_LIBDRM /usr/xsrc/external/mit/MesaLib.ol
d/dist/src/loader/loader.c &&  mv -f loader.d.tmp loader.d
/usr/xsrc/external/mit/MesaLib.old/dist/src/loader/loader.c:54:10:
fatal error: util/xmlpool.h: No such file or directory
   54 | #include "util/xmlpool.h"
  |  ^~~~



Chavdar


-- 

panic on -current amd64

[Chavdar Ivanov]

Hi,

While building -current i386 I got:

...
panic: kernel diagnostic assertion "cache_key(ncp->nc_name, namelen)
== ncp->nc_key"
   failed: file "/home/sysbuild/src/sys/kern/vfs_cache.c", line 384
cpu0: Begin traceback...
vpanic() at netbsd:vpanic+0x173
kern_assert() at netbsd:kern_assert+0x4b
cache_remove() at netbsd:cache_remove+0x28c
cache_enter() at netbsd:cache_enter+0x41b
zfs_netbsd_lookup() at zfs:zfs_netbsd_lookup+0x223
VOP_LOOKUP() at netbsd:VOP_LOOKUP+0x44
lookup_once() at netbsd:lookup_once+0x1a6
namei_tryemulroot() at netbsd:namei_tryemulroot+0xbb5
namei() at netbsd:namei+0x29
do_sys_statat() at netbsd:do_sys_statat+0x1db
sys___lstat50() at netbsd:sys___lstat50+0x25
syscall() at netbsd:syscall+0x17a
--- syscall (number 441) ---
netbsd:syscall+0x17a:
cpu0: End traceback...
...

(my build directories are on a zfs, this hasn't caused problems so far).

Chavdar


-- 

Re: amd64-current live image build failure

[Chavdar Ivanov]

On Sun, 21 Apr 2024 at 06:42, Izumi Tsutsui  wrote:
>
> > cat  work.mbr.truncated work.efi imgroot.fs work.gpt > work.img
> > /dumps/sysbuild/amd64/tools/bin/nbgpt  work.img biosboot -i 2
> >   -c 
> > /dumps/sysbuild/amd64/obj/home/sysbuild/src/distrib/amd64/liveimage/emuimage/work/usr/mdec/gptmbr.bin
> > nbgpt: work.img: No primary GPT header; run create or recover
>
> If you are trying an update build (with -u) and your previous build
> was using source tree files before UEFI changes against liveimage,
>  https://mail-index.netbsd.org/source-changes/2024/04/13/msg150802.html
> a stale work.mbr (${WORKMBR}) image doesn't contain GPT (but MBR)
> so ${TOOL_GPT} on the update build may fail.

That explains it - I do use update build, but on occasion, when
something fails, I tend to remove the destdir and|or obj. In this case
I started afresh a little earlier than the abovementioned commit.

BTW my next question was to be 'Why live image is only MBR, as the
install image is GPT?', but I see I am late for it...

>
> The similar issue (against the secondary GPT headers) occured
> if IMAGE size is changed:
>  https://gnats.netbsd.org/56132
>
> Maybe we should note it (remove work.mbr on updating builds)
> in doc/UPDATING?
>
> ---
> Izumi Tsutsui

Thanks,

Chavdar

-- 

amd64-current live image build failure

[Chavdar Ivanov]

Hi,

I am presently getting:


mv work.rootfs imgroot.fs
create EFI system partition...
/dumps/sysbuild/amd64/tools/bin/x86_64--netbsd-install -c -m 0644
work/usr/mdec/bootx64.efi work.efidir/EFI/boot/`basename
work/usr/mdec/bootx64.efi`
/dumps/sysbuild/amd64/tools/bin/x86_64--netbsd-install -c -m 0644
work/usr/mdec/bootia32.efi work.efidir/EFI/boot/`basename
work/usr/mdec/bootia32.efi`
rm -f work.efi
/dumps/sysbuild/amd64/tools/bin/nbmakefs -M 128m -m 128m
  -B 1234
   -t
msdos -o F=32,c=1work.efi work.efidir
Creating `work.efi'
work.efi: 258078 sectors in 258078 FAT32 clusters (512 bytes/cluster)
MBR type: 11
bps=512 spc=1 res=32 nft=2 mid=0xf0 spt=63 hds=255 hid=0 bsec=262144
bspf=2017 rdcl=2 infs=1 bkbs=2
Populating `work.efi'
Image `work.efi' complete
cat  work.mbr.truncated work.efi imgroot.fs work.gpt > work.img
/dumps/sysbuild/amd64/tools/bin/nbgpt  work.img biosboot -i 2
  -c 
/dumps/sysbuild/amd64/obj/home/sysbuild/src/distrib/amd64/liveimage/emuimage/work/usr/mdec/gptmbr.bin
nbgpt: work.img: No primary GPT header; run create or recover
*** Failed target: NetBSD-10.99.10-amd64-live.img
*** Failed commands:
${CAT} ${TARGET_BLOCKS} > ${WORKIMG}
=> cat  work.mbr.truncated work.efi imgroot.fs work.gpt > work.img
${TOOL_GPT} ${GPT_TIMESTAMP} ${WORKIMG} biosboot -i 2
  -c ${.OBJDIR}/${WORKDIR}/usr/mdec/gptmbr.bin
=> /dumps/sysbuild/amd64/tools/bin/nbgpt  work.img biosboot -i
2 -c
/dumps/sysbuild/amd64/obj/home/sysbuild/src/distrib/amd64/liveimage/emuimage/work/usr/md
ec/gptmbr.bin
${TOOL_GPT} ${GPT_TIMESTAMP} ${WORKIMG} set -a bootme -i 2
=> /dumps/sysbuild/amd64/tools/bin/nbgpt  work.img set -a bootme -i 2
mv ${WORKIMG} ${.TARGET}
=> mv work.img NetBSD-10.99.10-amd64-live.img
*** [NetBSD-10.99.10-amd64-live.img] Error code 1



No idea why...


Chavdar


-- 

Re: amd64-current live image build failure

[Chavdar Ivanov]

On Sat, 20 Apr 2024 at 17:49, Chavdar Ivanov  wrote:
>
> Hi,
>
> I am presently getting:
> 
>
> mv work.rootfs imgroot.fs
> create EFI system partition...
> /dumps/sysbuild/amd64/tools/bin/x86_64--netbsd-install -c -m 0644
> work/usr/mdec/bootx64.efi work.efidir/EFI/boot/`basename
> work/usr/mdec/bootx64.efi`
> /dumps/sysbuild/amd64/tools/bin/x86_64--netbsd-install -c -m 0644
> work/usr/mdec/bootia32.efi work.efidir/EFI/boot/`basename
> work/usr/mdec/bootia32.efi`
> rm -f work.efi
> /dumps/sysbuild/amd64/tools/bin/nbmakefs -M 128m -m 128m
>   -B 1234
>-t
> msdos -o F=32,c=1work.efi work.efidir
> Creating `work.efi'
> work.efi: 258078 sectors in 258078 FAT32 clusters (512 bytes/cluster)
> MBR type: 11
> bps=512 spc=1 res=32 nft=2 mid=0xf0 spt=63 hds=255 hid=0 bsec=262144
> bspf=2017 rdcl=2 infs=1 bkbs=2
> Populating `work.efi'
> Image `work.efi' complete
> cat  work.mbr.truncated work.efi imgroot.fs work.gpt > work.img
> /dumps/sysbuild/amd64/tools/bin/nbgpt  work.img biosboot -i 2
>   -c 
> /dumps/sysbuild/amd64/obj/home/sysbuild/src/distrib/amd64/liveimage/emuimage/work/usr/mdec/gptmbr.bin
> nbgpt: work.img: No primary GPT header; run create or recover
> *** Failed target: NetBSD-10.99.10-amd64-live.img
> *** Failed commands:
> ${CAT} ${TARGET_BLOCKS} > ${WORKIMG}
> => cat  work.mbr.truncated work.efi imgroot.fs work.gpt > work.img
> ${TOOL_GPT} ${GPT_TIMESTAMP} ${WORKIMG} biosboot -i 2
>   -c ${.OBJDIR}/${WORKDIR}/usr/mdec/gptmbr.bin
> => /dumps/sysbuild/amd64/tools/bin/nbgpt  work.img biosboot -i
> 2 -c
> /dumps/sysbuild/amd64/obj/home/sysbuild/src/distrib/amd64/liveimage/emuimage/work/usr/md
> ec/gptmbr.bin
> ${TOOL_GPT} ${GPT_TIMESTAMP} ${WORKIMG} set -a bootme -i 2
> => /dumps/sysbuild/amd64/tools/bin/nbgpt  work.img set -a bootme -i 2
> mv ${WORKIMG} ${.TARGET}
> => mv work.img NetBSD-10.99.10-amd64-live.img
> *** [NetBSD-10.99.10-amd64-live.img] Error code 1
> 
>
>
> No idea why...
>
>

Forgot to say that build completes otherwise OK, the ISO is built.

> Chavdar
>
>
> --
> 



-- 

vmt driver

[Chavdar Ivanov]

Hi,

Can anybody enlighten me regards the vmt driver? I have a few VMs
running under VMWare Workstation (17.5.1 at present) and Player. My
console is spammed by continuous messages, repeating

[70.197688] vmt0: unknown command: "Set_Option toolScripts.afterPowerOn 1"
[70.197688] vmt0: unknown command: "Set_Option toolScripts.beforePowerOff 1"
[70.197688] vmt0: unknown command: "Set_Option toolScripts.afterResume 1"
[70.210302] vmt0: unknown command: "Set_Option toolScripts.beforeSuspend 1"
[70.210302] vmt0: unknown command: "Set_Option
time.synchronize.tools.slewCorrection 1"
[70.219876] vmt0: unknown command: "Set_Option
time.synchronize.tools.percentCorrection 0"
[70.219876] vmt0: unknown command: "Set_Option mapRootHgfsShare 0"
[70.219876] vmt0: unknown command: "Set_Option linkRootHgfsShare 0"
[70.228936] vmt0: unknown command: "Set_Option enableMessageBusTunnel 0"
[70.228936] vmt0: unknown command: "Set_Option enableAppInfo 1"
[70.228936] vmt0: unknown command: "Set_Option enableDeviceHelper disabled"
[71.237928] vmt0: unknown command: "Set_Option synctime 0"
[71.237928] vmt0: unknown command: "Set_Option copypaste 1"
[71.237928] vmt0: unknown command: "Set_Option autohide 0"
[71.237928] vmt0: unknown command: "Set_Option enableDnD 1"
[71.249744] vmt0: unknown command: "Set_Option synctime.period 0"
[71.249744] vmt0: unknown command: "Set_Option
time.synchronize.tools.enable 1"
[71.249744] vmt0: unknown command: "Set_Option
time.synchronize.guest.resync 0"
[71.260250] vmt0: unknown command: "Set_Option
time.synchronize.guest.resync.timeout 0"
[71.260250] vmt0: unknown command: "Set_Option
time.synchronize.tools.startup.backward 0"
[71.268356] vmt0: unknown command: "Set_Option
time.synchronize.tools.startup 1"

which makes the console unusable. I guess I can disable vmt, these
will disappear, but I don't know what the consequences of this would
be. The guest is running -current from week ago and fully updated
pkgsrc, including the latest open-vm-tools installed and configures
according to the message from the package.

Otherwise, the machine works reasonably well. The mouse speed is
somewhat slower than usual when using the touchpad of my ThinkPad, the
red pug works better (this is probably due to the 2560x1600 resolution
of the host).

I checked the site pointed out in
https://nxr.netbsd.org/xref/src/sys/arch/x86/x86/vmt.c as the source
of the driver, but it doesn't exist.

Chavdar


-- 

Re: Failure building -current amd64

[Chavdar Ivanov]

All good with the latest update (distrib/sets/lists/[base|debug]32/md.amd64).

On Fri, 12 Apr 2024 at 13:08, Chavdar Ivanov  wrote:
>
> On Fri, 12 Apr 2024 at 10:05, Paul Goyette  wrote:
> >
> > On Fri, 12 Apr 2024, Chavdar Ivanov wrote:
> >
> > > Does anybody else have the same problem? My last amd64 build is from
> > > the 31st of March.
> >
> > We are aware of the current breakage in HEAD
>
> Thank you very much. As usual, I was thinking there is something wrong
> with my own setup.
>
> BTW I just finished a build on aarch64 with no problems - but that is
> probably obvious looking at the errors I receive on amd64.
>
>
> >
> > +-+--+--+
> > | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:|
> > | (Retired)   | 1B11 1849 721C 56C8 F63A | p...@whooppee.com|
> > | Software Developer  | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org  |
> > | & Network Engineer  |  | pgoyett...@gmail.com |
> > +-+--+--+
>
>
>
> --
> 



-- 

Re: Failure building -current amd64

[Chavdar Ivanov]

On Fri, 12 Apr 2024 at 10:05, Paul Goyette  wrote:
>
> On Fri, 12 Apr 2024, Chavdar Ivanov wrote:
>
> > Does anybody else have the same problem? My last amd64 build is from
> > the 31st of March.
>
> We are aware of the current breakage in HEAD

Thank you very much. As usual, I was thinking there is something wrong
with my own setup.

BTW I just finished a build on aarch64 with no problems - but that is
probably obvious looking at the errors I receive on amd64.


>
> +-+--+--+
> | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:|
> | (Retired)   | 1B11 1849 721C 56C8 F63A | p...@whooppee.com|
> | Software Developer  | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org  |
> | & Network Engineer  |  | pgoyett...@gmail.com |
> +-+--+--+



-- 

Re: Failure building -current amd64

[Chavdar Ivanov]

On Thu, 11 Apr 2024 at 08:50, Chavdar Ivanov  wrote:
>
> On Wed, 10 Apr 2024 at 17:16, nia  wrote:
> >
> > On Wed, Apr 10, 2024 at 11:44:04AM +0100, Chavdar Ivanov wrote:
> > > Any ideas? A stale location in one of the flists?
> >
> > I was working on reworking the set lists on my private tree,
> > then christos committed some new files and I had to do the awkward
> > job of merging the changes. My bad...
> >
> > The missing directory was not added.
>
> Unfortunately for me after yet another removal of obj/destdir/tools my
> overnight fails in exactly the same way.

Getting worse:

===  1 extra files in DESTDIR  =
Files in DESTDIR but missing from flist.
File is obsolete or flist is out of date ?
--
./usr/libdata/debug/usr/lib/i386/security
=  end of 1 extra files  ===
==  4 missing files in DESTDIR  
Files in flist but missing from DESTDIR.
File wasn't installed ?
--
./usr/lib/i386/./usr/libdata/debug/usr/lib/security
./usr/lib/i386/libc++.so
./usr/lib/i386/libc++.so.1
./usr/lib/i386/libc++.so.1.0
  end of 4 missing files  ==


This again is with new tools, obj and destdir directories, and after
running 'make cleandir' in [x]src.

Does anybody else have the same problem? My last amd64 build is from
the 31st of March.


>
> Chavdar
>
>
>
>
> --
> 



-- 

Re: Failure building -current amd64

[Chavdar Ivanov]

On Wed, 10 Apr 2024 at 17:16, nia  wrote:
>
> On Wed, Apr 10, 2024 at 11:44:04AM +0100, Chavdar Ivanov wrote:
> > Any ideas? A stale location in one of the flists?
>
> I was working on reworking the set lists on my private tree,
> then christos committed some new files and I had to do the awkward
> job of merging the changes. My bad...
>
> The missing directory was not added.

Unfortunately for me after yet another removal of obj/destdir/tools my
overnight fails in exactly the same way.

Chavdar




-- 

Failure building -current amd64

[Chavdar Ivanov]

Hi,

My last four attempts to build current fail as follows:
.
===  1 extra files in DESTDIR  =
Files in DESTDIR but missing from flist.
File is obsolete or flist is out of date ?
--
./usr/libdata/debug/usr/lib/i386/security
=  end of 1 extra files  ===
==  1 missing files in DESTDIR  
Files in flist but missing from DESTDIR.
File wasn't installed ?
--
./usr/lib/i386/./usr/libdata/debug/usr/lib/security
  end of 1 missing files  ==
*** Failed target: checkflist


My obj, destdir and tools directories are on a zfs. I've cleaned
everything ('make calendir' in [x]sr, as well as obj, tools and
destdir directories) and am still getting the above.

Any ideas? A stale location in one of the flists?

Chavdar


-- 

Re: Unacceptable firefox behavior with nouveau graphics card

[Chavdar Ivanov]

FWIW, I have an old

radeon0 at pci1 dev 0 function 0: ATI Technologies FirePro W5000 (rev. 0x00)

which works close enough to perfect for me under -current (why stick
to 10.99.4, BTW ?). Firefox is GL-accelerated, cad.onshape.com/check
returns rather decent numbers, comparable to what I remember I ran on
the same card years ago under W10 or Linux (but it has been running
NetBSD for at least 7 years now, always following -current from within
a week distance). I've had no key issues with Firefox, apart from the
brief period when the current version did not have accelerated GL at
all and I had to revert to the LTS version, which had it. So, I can
attest this card works well under NetBSD. I have had occasional issues
- when I forget the screen running xfce4 and the screensaver kicks
out, some of the 3D savers are perhaps buggy or something similar and
I've seen the system left pingable but unable to connect to.

Last time I checked my other laptop with Intel 530 graphics {and 3D
controller: NVIDIA Corporation GM107M [GeForce GTX 950M] (rev a2),
which I could never get to work with nouveau}  also had firefox 3D
accelerated and no particular issues. My current laptop also perhaps
*should work* - a P16s with on-chip Radeon 680 - but I haven't
bothered to test it, as the WiFi chip is not recognized (Qualcomm
WCN685x), last time I checked.

On Tue, 5 Mar 2024 at 12:08, Riccardo Mottola
 wrote:
>
> Hi,
>
> Paul Goyette wrote:
> >
> > 1) Does this sound familiar to anyone else?  Or am I just a set-of-1 ?
>
> I use firefox on Linux with nouveau and it works quite well, performance
> is not to the same level of a Mac or Windows "equivalent", but quite
> nice. Just to mean that Firefox+Nouveau "can" work.
> I wonder if it is a specific issue for you video card, an issue with
> NetBSD or else.
>
> >
> > 2) Are there any alternatives to firefox?
>
> Hot topic. I think you have
> 1) Chromium and all its other derivates. They have their own shares of
> issues. You might not like the interface, how it works
> 2) Firefox.. and derivates. There you might have some luck
>
> I have NetBSD on a laptop with an old nvidia card. Do you have a
> specific way to reproduce the lag?. e.g. startup? opening a specific
> site? new tab?
> Does it have to do with video? WebGL?
>
> >
> > 3) Any recommendations on potential replacement of the video card?
>
> If you are on a cheap side, you could get another nvidia card, used, try
> your luck and even "compare".
>
> You might want to tweak things in firefox. Disable Acceleration. Check
> crashes.
> Go into about:config and look for:
>
> webgl.*
>
> gfx.blacklist.*
>
> Try to tweak gfx.webrender.software.opengl
>
> bold items are changed values!
>
> Riccardo



-- 

Re: unlink_if_ordinary undefined...

[Chavdar Ivanov]

On Sun, 31 Dec 2023 at 16:02, Chavdar Ivanov  wrote:
>
> On Sun, 31 Dec 2023 at 15:56, Chavdar Ivanov  wrote:
> >
> > On Sun, 31 Dec 2023 at 15:25, Martin Husemann  wrote:
> > >
> > > On Sun, Dec 31, 2023 at 02:19:01PM +, Chavdar Ivanov wrote:
> > > > As far as I could tell, the only place where this is defined in the 
> > > > system is in
> > > >
> > > >  nm /usr/libexec/lto-wrapper | grep unlink_if
> > > > 0006a842 T unlink_if_ordinary
> > > >
> > > > No idea about this, my google-fu apparently is not so strong to
> > > > suggest anything useful.
> > >
> > > It is a GNU libiberty utility function and probably should not be a 
> > > dynamic
> > > symbol anywhere (but staticaly linked from -liberty).
> >
> > I just found that I can't build any other rust projects, which used to
> > work ok, like helix, for instance, because of that.
> >
> > So it must be something very recent - my last successful helix build
> > is from 29th of December, I rebuilt the system on the 30th, but in the
> > meantime I switched from rust-bin to source (because of a problem with
> > shells/nushell dumping core upon reading birthdates of mounted /kern
> > ).
>
> I switched back to rust-bin 1.73 - this didn't change anything - I
> still can't build anything with cargo.

While the original query is perhaps valid, the rest turned out to be a
simple case of PEBCAK - at one of the runs I had a message about an
invalid make parameters and decided to see if that could be overcome
with gnu make - so I set my PATH starting with /usr/pkg/gnu/bin 
Moral of the story - don't do this...

As far as zellij is concerned, it appears to fail about two thirds of
the build when building region 3.0.0:

  Compiling region v3.0.0
error[E0412]: cannot find type `QueryIter` in module `os`
 --> 
/home/ci4/.cargo/registry/src/index.crates.io-6f17d22bba15001f/region-3.0.0/src/query.rs:7:24
  |
7 |   iterator: Option,
  |^ not found in `os`
  |
help: consider importing this struct through its public re-export
  |
1 + use crate::QueryIter;
  |
help: if you import `QueryIter`, refer to it directly
  |
7 -   iterator: Option,
7 +   iterator: Option,
  |

error[E0433]: failed to resolve: could not find `QueryIter` in `os`
  --> 
/home/ci4/.cargo/registry/src/index.crates.io-6f17d22bba15001f/region-3.0.0/src/query.rs:15:9
   |
15 | os::QueryIter::new(origin, size).map(|iterator| Self {
   | ^ could not find `QueryIter` in `os`
   |
help: consider importing this struct through its public re-export
   |
1  + use crate::QueryIter;
   |
help: if you import `QueryIter`, refer to it directly
   |
15 - os::QueryIter::new(origin, size).map(|iterator| Self {
15 + QueryIter::new(origin, size).map(|iterator| Self {
   |



Chavdar

>
> >
> > >
> > > Martin
> >
> >
> >
> > --
> > 
>
>
>
> --
> 



-- 

Re: unlink_if_ordinary undefined...

[Chavdar Ivanov]

On Sun, 31 Dec 2023 at 15:56, Chavdar Ivanov  wrote:
>
> On Sun, 31 Dec 2023 at 15:25, Martin Husemann  wrote:
> >
> > On Sun, Dec 31, 2023 at 02:19:01PM +0000, Chavdar Ivanov wrote:
> > > As far as I could tell, the only place where this is defined in the 
> > > system is in
> > >
> > >  nm /usr/libexec/lto-wrapper | grep unlink_if
> > > 0006a842 T unlink_if_ordinary
> > >
> > > No idea about this, my google-fu apparently is not so strong to
> > > suggest anything useful.
> >
> > It is a GNU libiberty utility function and probably should not be a dynamic
> > symbol anywhere (but staticaly linked from -liberty).
>
> I just found that I can't build any other rust projects, which used to
> work ok, like helix, for instance, because of that.
>
> So it must be something very recent - my last successful helix build
> is from 29th of December, I rebuilt the system on the 30th, but in the
> meantime I switched from rust-bin to source (because of a problem with
> shells/nushell dumping core upon reading birthdates of mounted /kern
> ).

I switched back to rust-bin 1.73 - this didn't change anything - I
still can't build anything with cargo.

>
> >
> > Martin
>
>
>
> --
> 



-- 

Re: unlink_if_ordinary undefined...

[Chavdar Ivanov]

On Sun, 31 Dec 2023 at 15:25, Martin Husemann  wrote:
>
> On Sun, Dec 31, 2023 at 02:19:01PM +, Chavdar Ivanov wrote:
> > As far as I could tell, the only place where this is defined in the system 
> > is in
> >
> >  nm /usr/libexec/lto-wrapper | grep unlink_if
> > 0006a842 T unlink_if_ordinary
> >
> > No idea about this, my google-fu apparently is not so strong to
> > suggest anything useful.
>
> It is a GNU libiberty utility function and probably should not be a dynamic
> symbol anywhere (but staticaly linked from -liberty).

I just found that I can't build any other rust projects, which used to
work ok, like helix, for instance, because of that.

So it must be something very recent - my last successful helix build
is from 29th of December, I rebuilt the system on the 30th, but in the
meantime I switched from rust-bin to source (because of a problem with
shells/nushell dumping core upon reading birthdates of mounted /kern
).

>
> Martin



-- 

unlink_if_ordinary undefined...

[Chavdar Ivanov]

Hi,

I've been trying from time to time to build zellij(1) under NetBSD; it
used to fall because of some Linux-specific call in the rust
dependencies. Now I can't get even as far as that, instead I am
getting on a number of dependencies:
...
 "-o" "/home/xci
/src/zellij/target/debug/build/corosensei-a36b402a4a09a331/build_script_build-a36b402a4a09a331"
"-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now"
"-Wl,-rpath,/usr/pkg/lib"
  = note: ld: /usr/libexec/liblto_plugin.so: error loading plugin:
/usr/libexec/liblto_plugin.so: Undefined PLT symbol
"unlink_if_ordinary" (symnum = 47)
...

As far as I could tell, the only place where this is defined in the system is in

 nm /usr/libexec/lto-wrapper | grep unlink_if
0006a842 T unlink_if_ordinary

No idea about this, my google-fu apparently is not so strong to
suggest anything useful.

Any pointers?

Chavdar

---
1) https://github.com/zellij-org/zellij - I suspect there won't be
many not yet heard of it, it is a tmux/screen type session manager on
steroids (not that tmux is bad or not enough, but still - this one
doesn't need any configuration in order to become useful, and there is
no learning curve as such...)


-- 

Re: LinkQuotaExceeded

[Chavdar Ivanov]

On Mon, 27 Nov 2023 at 14:25, Simon Burge  wrote:
>
> Chavdar Ivanov wrote:
>
> > I wonder if it is because of some limitation in the (ufs2) filesystem
> > the build is going on.
>
> UFS has a limit of 32767 links per file and this limit applies to the
> number of subdirectories a directory can have too.  Does
>
>   find . -links +3
>
> find anything when you see the error?  This might get a lot of output if
> you really have files with many links, but will show just a single entry
> for a directory that has lots of subdirectories.

This probably is the reason indeed. Right now after cleaning the zig
cache directories and just building the compiler I have one directory
with more than 3000 links; when the tests are run, they get much more,
although I haven't checked the amount. I'll try again.


I might move the zig build directory to zfs for the sake of a try,
it's easy enough.

>
> Cheers,
> Simon.

Thanks,

Chavdar


-- 

LinkQuotaExceeded

[Chavdar Ivanov]

Hi,

On -current amd64 ond aarch64 I regularly build lang/zig - not from
pkgsrc, but from the git repo, using self-built llvm-17. It works as
well as it can be expected. When I run zig's test suite, from a
certain point onwards I get the above message and the corresponding
test items obviously fail. I have no idea where this comes from, the
test routine creates a substantial number of files in a zig-cache
directory, which I clean in advance.

I have seen the same message also when installing something using
'cargo install', which goes away when I clean the corresponding
directory under .cache.

I wonder if it is because of some limitation in the (ufs2) filesystem
the build is going on.

Chavdar


-- 

Panic on -current alpha

[Chavdar Ivanov]

Hi,

While running atf under qemu via anita, I got:
...
bin/sh/t_patterns (20/940): 3 test cases
case_matching: [15.225923s] Passed.
filename_expansion: [ 837.8609104] panic: kernel diagnostic
assertion "timo != 0 || intr" failed: file
"/usr/src/sys/kern/kern_synch.c", line 249
[ 837.8944929] cpu0: Begin traceback...
[ 837.8944929] alpha trace requires known PC =eject=
[ 837.8944929] cpu0: End traceback...

[ 837.8944929] dumping to dev 4,1 offset 196607
[ 837.8944929] dump 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 succeeded



-- 

Re: weird hangs in current (ghc, gnucash)

[Chavdar Ivanov]

On Thu, 2 Nov 2023 at 10:33, Martin Husemann  wrote:
>
> On Wed, Nov 01, 2023 at 10:49:12AM +0100, Thomas Klausner wrote:
> > Should we back out ad's changes until he has time to look at them?
>
> I just did that on behalf of core.
> Can you test if this solves your problem?

I rebuilt the system a few hours ago. now previously failing packages
(e.g. devel/hs-assoc) build.

I can restart my present rolling replace, I guess.

>
> Martin

Chavdar


-- 

Re: weird hangs in current (ghc, gnucash)

[Chavdar Ivanov]

This weird hang still takes place on

❯ uname -a
NetBSD ymir.lorien.lan 10.99.10 NetBSD 10.99.10 (GENERIC) #13: Mon Oct
30 19:45:39 GMT 2023
sysbu...@ymir.lorien.lan:/dumps/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/com
pile/GENERIC amd64

- again during building a haskell package:

===> Configuring for hs-tagged-0.8.8
[1 of 2] Compiling Main ( Setup.lhs, Setup.o )


Htop gives weird output for the process not-yet-created:

11506 root63   0 33283   873 S   0.0  0.0  0:00.00 |  `- make
20458 root62   0 34832   613 S   0.0  0.0  0:00.00 |  `-
/bin/sh -c set -e; test -n "" && echo 1>&2 "ERROR:"  && exit
1;  exec 3<&0;??? whil
24942 root63   0 33296   882 S   0.0  0.0  0:00.00 |  `-
/usr/bin/make _MAKE=/usr/bin/make OPSYS=NetBSD OS_VERSION=10.99.10
OPSYS_VERSION=109910 LOWE
21643 root58   0 34302   606 S   0.0  0.0  0:00.00 |  `-
/bin/sh -c set -e;? if test -n "" &&  /usr/pkg/sbin/pkg_info -K
/usr/pkg/pkgdb -qe hs
19149 root63   0 34367   920 S   0.0  0.0  0:00.00 |  `-
/usr/bin/make LOWER_OPSYS=netbsd _PKGSRC_BARRIER=yes
ALLOW_VULNERABLE_PACKAGES= reinst
23303 root58   0 33685   603 S   0.0  0.0  0:00.00 |   `-
/bin/sh -c set -e; ulimit -d `ulimit -H -d`; ulimit -v `ulimit -H -v`;
cd /usr/pkgs
27078 root21   0  256G 37735 S   0.0  0.9  0:00.00 | `-
/usr/pkg/lib/ghc-9.6.3/bin/./ghc-9.6.3 -B/usr/pkg/lib/ghc-9.6.3/lib
-package-env
22058 root   -22   0 0 0 Z   0.0  0.0  0:00.00 |
`- gcc   <==
---


I guess it is back to the kernel from the 9th of October.

Chavdar

-

On Mon, 23 Oct 2023 at 09:27, Chavdar Ivanov  wrote:
>
> I can confirm that after reverting to the kernel from 9th of October 
> devel/happy builds OK.
>
> On Mon, 23 Oct 2023 at 05:56, Markus Kilbinger  wrote:
>>
>> ... and probably
>>
>> 3. PR kern/57660
>> https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=57660
>>
>> Markus
>>
>> Am So., 22. Okt. 2023 um 23:10 Uhr schrieb Thomas Klausner :
>> >
>> > On Sun, Oct 22, 2023 at 11:06:25PM +0200, Thomas Klausner wrote:
>> > > On Sun, Oct 22, 2023 at 10:37:54PM +0200, Thomas Klausner wrote:
>> > > > I've just updated my kernel from 10.99.10 to 10.99.10 (~ Oct 11 to Oct
>> > > > 20) to test the rge(4) changes, and started a bulk build, and the
>> > > > packages using ghc seem to wait for something and make no progress.
>> > > ...
>> > > > I see one other new weird behaviour on that machine - gnucash doesn't
>> > > > finish starting up.
>> > >
>> > > I've backed out ad's changes from the 13th, and both problems are gone.
>> > >
>> > > I'll attach my local change.
>> > >
>> > > Andrew, can you please take a look?
>> >
>> > Two test cases to see the problem I have:
>> >
>> > 1. start gnucash, it doesn't finish starting up, the splash screen hangs.
>> >
>> > 2. cd /usr/pkgsrc/devel/hs-data-array-byte && make
>> >The 'build' step has two parts, it hangs after the first one.
>> >
>> >  Thomas
>
>
>
> --
> 



-- 

10.99.9 amd64 panic

[Chavdar Ivanov]

Buidling mail/thunderbird appears to be causing trouble on this system; I got 
three times in a row the first line below, caused by ld filling all the 
available 16GB of memory and 8GB swap, the panic happened at the time of the 
last occasion, and has happened previously - there is a 2.5GB/s Realtek network 
adapter in use:
...
Sep 29 01:53:13 ymir /netbsd: [ 161049.4497964] UVM: pid 9902.9902 (ld), uid 0 
killed: out of swap 
Sep 29 01:53:13 ymir /netbsd: [ 228407.9443196] panic: kernel diagnostic 
assertion "offset < map->dm_mapsize" failed: file 
"/home/sysbuild/src/sys/arch/x86/x86/bus_dma.c", line 826
 bad offset 0x0 >= 0x0
Sep 29 01:53:13 ymir /netbsd: [ 228407.9543802] cpu0: Begin traceback...
Sep 29 01:53:13 ymir /netbsd: [ 228407.9543802] vpanic() at netbsd:vpanic+0x173
Sep 29 01:53:13 ymir /netbsd: [ 228407.9543802] kern_assert() at 
netbsd:kern_assert+0x4b
Sep 29 01:53:13 ymir /netbsd: [ 228407.9543802] bus_dmamap_sync() at 
netbsd:bus_dmamap_sync+0x326
Sep 29 01:53:13 ymir /netbsd: [ 228407.9543802] rge_rxeof() at 
netbsd:rge_rxeof+0x179
Sep 29 01:53:13 ymir /netbsd: [ 228407.9543802] rge_intr() at 
netbsd:rge_intr+0x16f
Sep 29 01:53:13 ymir /netbsd: [ 228407.9543802] intr_biglock_wrapper() at 
netbsd:intr_biglock_wrapper+0x41
Sep 29 01:53:13 ymir /netbsd: [ 228407.9543802] Xhandle_ioapic_edge21() at 
netbsd:Xhandle_ioapic_edge21+0x75
Sep 29 01:53:13 ymir /netbsd: [ 228407.9543802] --- interrupt ---
Sep 29 01:53:13 ymir /netbsd: [ 228407.9543802] x86_mwait() at 
netbsd:x86_mwait+0xd
Sep 29 01:53:13 ymir /netbsd: [ 228407.9543802] acpicpu_cstate_idle() at 
netbsd:acpicpu_cstate_idle+0x19a
Sep 29 01:53:13 ymir /netbsd: [ 228407.9543802] idle_loop() at 
netbsd:idle_loop+0x114
Sep 29 01:53:13 ymir /netbsd: [ 228407.9543802] cpu0: End traceback...
Sep 29 01:53:13 ymir /netbsd:
Sep 29 01:53:13 ymir /netbsd: [ 228407.9543802] dumping to dev 168,2 (offset=8, 
size=4189743):
...

There was some discussion about Thunderbird requiring a lot of resource; the 
last version I built was from the 3rd of September, 115.1.1, I didn't have any 
problems then. 

Chavdar 

Re: security/mozilla-rootcerts-openssl post certificate inclusion in base

[Chavdar Ivanov]

On Tue, 26 Sept 2023 at 12:21, Greg Troxel  wrote:
>
> Chavdar Ivanov  writes:
>
> > lack cause anything? On top of this, I seem not to be able to remove
> > mozilla-rootcerts-openssl, as it is required by hs-x509-system, itself
> > required eventually by converters/pandoc. (I sorted this out by
>
> That's a bug.  It is against policy for a package to require
> mozilla-rootcerts-openssl.
>
> > replacing the latter package after cvs updating - the NetBSD
> > condiitional in the Makefile has been removed so after that nothing
> > stopped me from removing mozilla-rootcerts-openssl; leaving the
> > comments in the mail as someone else may find himself in the same
> > situation).
>
> And it's fixed.

sure,

>
> > The query is then about the 198 certificates present in the package
> > but missing in base - are they likely to cause any problems?
>
> I would uninstall mozilla-rootcerts-openssl and then make sure your cert
> dir is ok.
>
> Are you saying that mozilla-rootcerts-openssl has CAs that base does
> not, separately from the history of how your system got be how it is?

I just did a clean installation of -current from yesterday. This
leaves /etc/openssl/certs with one single file and 280 links to files
and links is /usr/share/certs/mozilla. However, the real files in that
directory are 170 - exactly the number of real files in the package
(which contains 169 links and 170 files). As the number of files
appears the same, I'd say that base provides what is needed, even if
it looks much different... I will replace /etc/openssl/certs on my
historical system with the contents from the cleanly installed one,
that should do the job. I believe no other package should have added
anything there.

The confusion was created by the package which was still dependent on
mozilla-rootcerts-openssl at the time of invoking 'pkg_admin rebuild'
prior to pkg_rolling-replace.

There are other small bits which can cause trouble - e.g. my
yesterday's -current works just fine (as a VMWare Workstation guest),
but when I selected the option of setting up pkgin during the
installation (my build host serves it locally via ftp), it did all the
setting up but could not actually invoke pkgin - as it was missing
/usr/lib/libarchive.so.4.0 - the system now has 5.0 and pkgin was
still not updated - I was about to start the rolling replace. I copied
the older version onto the new system until the rolling replace
completes on the build one. It is -current, after all; I build it
usually every two weeks or so and it usually is very stable, but one
has to be prepared to deal with such issues from time to time.





-- 

security/mozilla-rootcerts-openssl post certificate inclusion in base

[Chavdar Ivanov]

Hi,

When I upgraded my -current build host to the version with included in
base certificates, to complete the check process I just renamed
/etc/openssl/certs to .../certs.OLD and the script then installed the
supplied certificates as expected. Now 'pkg_admin check' finds a lot
of missing files from mozilla-rootcerts-openssl, together with many
that are still present:

$ pkg_info -L mozilla-rootcerts-openssl-2.12 | grep ^/ | xargs ls -1
2>&1 | grep No\ such  | wc -l
 198
$ pkg_info -L mozilla-rootcerts-openssl-2.12 | grep ^/ | xargs ls -1
2>&1 | grep -v  No\ such  | wc -l
 141
$ ls -1 /etc/openssl/certs  | wc -l
 281

There are a lot of common to both sets of certificates and quite a few
that belong to only one of them. So far, with the renamed certs
directory from the pkgsrc package the system has been working as
expected, I haven't noticed any problems accessing sites etc., but I
am not clear as far as these 198 files are concerned - could their
lack cause anything? On top of this, I seem not to be able to remove
mozilla-rootcerts-openssl, as it is required by hs-x509-system, itself
required eventually by converters/pandoc. (I sorted this out by
replacing the latter package after cvs updating - the NetBSD
condiitional in the Makefile has been removed so after that nothing
stopped me from removing mozilla-rootcerts-openssl; leaving the
comments in the mail as someone else may find himself in the same
situation).

The query is then about the 198 certificates present in the package
but missing in base - are they likely to cause any problems?

Chavdar



-- 

Re: ERROR: No valid Python version

[Chavdar Ivanov]

On Thu, 31 Aug 2023 at 14:14, Greg Troxel  wrote:
>
> Chavdar Ivanov  writes:
>
> >
> > ---
> > ===> Building binary package for libxslt-1.1.38nb1
> > => Creating binary package /usr/pkgsrc/packages/All/libxslt-1.1.38nb1.tgz
> > ===> Installing binary package of libxslt-1.1.38nb1
> > pkg_add: A different version of libxslt-1.1.38nb1 is already
> > installed: libxslt-1.1.38
> > pkg_add: 1 package addition failed
> > *** Error code 1
> > 
> >
> > The test run of 'pkg_chk -uq' has identified libxslt as a target for
> > upgrade, but it is for some reason missing from the final list of
> > installed packages as found by it, so it tries to install it instead
> > of replace.
> >
> > This is done after 'pkgin ar', 'pkg_admin rebuild-tree', 'pkg_admin
> > rebuild' and the above. I was running 'pkg_rolling-replace -suv' at
> > the time.
>
> You snipped too much log; presumably it was replacing something else.

Yes, it was replacing cmake at the time, which eventually needed libxslt.

>
> I don't know what's going on, and would suggest turning  on set -x and
> tracing the logs to see.

My assumption on duty in these occasions is always that the problem is
with my local tree and with the occasional messing I do with it; I try
to avoid bothering the list with these and to find a solution myself;
I mentioned the issue as I have had it a few times before. One reason
might be that I started using  'pkg_rr -suv'  recently, before I used
to use ' -uvk', which, albeit not safe, at least goes through the
whole process without intervention and usually does the job (but I
understand why it shouldn't be used). I'll try to trace it.

Chavdar



-- 

Re: ERROR: No valid Python version

[Chavdar Ivanov]

While on the topic of pkg_rr, if I'm permitted to cut in, I have been
getting strange errors suggesting a problem with the topological order
of replacement perhaps:

---
===> Building binary package for libxslt-1.1.38nb1
=> Creating binary package /usr/pkgsrc/packages/All/libxslt-1.1.38nb1.tgz
===> Installing binary package of libxslt-1.1.38nb1
pkg_add: A different version of libxslt-1.1.38nb1 is already
installed: libxslt-1.1.38
pkg_add: 1 package addition failed
*** Error code 1


The test run of 'pkg_chk -uq' has identified libxslt as a target for
upgrade, but it is for some reason missing from the final list of
installed packages as found by it, so it tries to install it instead
of replace.

This is done after 'pkgin ar', 'pkg_admin rebuild-tree', 'pkg_admin
rebuild' and the above. I was running 'pkg_rolling-replace -suv' at
the time.

So it's manual replace and restart - again.

Chavdar


On Wed, 30 Aug 2023 at 14:59, Greg Troxel  wrote:
>
> Riccardo Mottola  writes:
>
> > Hi,
> >
> > Greg Troxel wrote:
> >> did you cd to devel/scons (or really the PKGPATH of the installed pkg)
> >> and type "make replace".  The pkg_rr man page says, or should say, to do
> >> that, and then to deal with that error as if it were not from pkg_rr.
> >
> > no, I didn't... I thought to have encountered some weird setup
> > error. I did now. It fails with a cryptic message:
>
> the man page for pkg_rr asks that people not report "some make replace
> that pkg_rr did failed" as a pkg_rr problem, because it's not really
> true but mostly because the subset of peopel that don't like pkg_rr then
> ignore your report, whereas some of them could perhaps be helpful if it
> is properly reported as a simpler failure.
>
> >> perhaps, scons 3 is now limited to py27.
> >
> > Well it is trying to build the py27 version, also it is more "sane
> > now" since it says:
> > py27-scons-3.1.2nb7while with pkg_rr it was confused between the py310
> > and the "none" version:
> >
> > RR> Replacing py310-scons-3.1.2nb4
> > ===> Cleaning for none-scons-3.1.2nb7
> >
> > In fact at the moment I have this one installed, according to pkg_info
> >
> > py310-scons-3.1.2nb4 Python-based, open-source build system
> >
> > so I suppose pkg_rr was right trying to subdtitute the py3 version
>
> Yes, the basic issue is that new scons3 dropped support for py3, and the
> basic solution is to upgrade to 4, but we don't really have support for
> that, and 99% people only have scons as a build tool (because somebody
> else wrongly thought it was better than autoconf 5 years ago :-).
>
> >> I recommend "pkgin ar" before a rebuild run.
> >
> > Now it is a little late :-P
>
> You can still do it and continue.   Unless you actually *want* scons3,
> removing it is best.  The tools that are needed for other things will
> get built.
>


-- 

Re: i386 -current build failure

[Chavdar Ivanov]

On Mon, 14 Aug 2023 at 13:50, Chavdar Ivanov  wrote:
>
> On Mon, 14 Aug 2023 at 10:35, Martin Husemann  wrote:
> >
> > On Mon, Aug 14, 2023 at 09:23:37AM +0100, Chavdar Ivanov wrote:
> > > Hi,
> > > ERROR: nbctfmerge: Input file adiantum_selftest.o was partially built
> > > from C sources, but no CTF data was present
> >
> > Can you reproduce it after removing that .o file (or the whole kernel build
> > directory)?
>
> I did reproduce it once more after removing that .o file. Subsequently
> I nuked the entire obj directory and restarted.
>
> I suspect this was a result of my previous attempt to build it on that
> particular host using NJOBS=4 - it is a quite old now system with an
> i7-2600K CPU on an Intel motherboard; it has some memory problems
> under heavier multicore load (memtest+ passes each individual stick
> fine, but whenever more than one stick is in use, any conbination of
> the four, two tests fail, one of them Intel says is not actually a
> failure, but apparently the other is...). I run the builds normally
> with NJOBS=1 and I am now so repeating the full i386 build.

 which completed OK; there were no intervening cvs updates at all,
so the reason for the failure must have been exactly the above.

> >
> > This symptom often shows up when one of the ctf tools died in an earlier
> > run.
> >
> > Martin
>
> Chavdar
>
>
> --
> 



-- 

Re: i386 -current build failure

[Chavdar Ivanov]

On Mon, 14 Aug 2023 at 10:35, Martin Husemann  wrote:
>
> On Mon, Aug 14, 2023 at 09:23:37AM +0100, Chavdar Ivanov wrote:
> > Hi,
> > ERROR: nbctfmerge: Input file adiantum_selftest.o was partially built
> > from C sources, but no CTF data was present
>
> Can you reproduce it after removing that .o file (or the whole kernel build
> directory)?

I did reproduce it once more after removing that .o file. Subsequently
I nuked the entire obj directory and restarted.

I suspect this was a result of my previous attempt to build it on that
particular host using NJOBS=4 - it is a quite old now system with an
i7-2600K CPU on an Intel motherboard; it has some memory problems
under heavier multicore load (memtest+ passes each individual stick
fine, but whenever more than one stick is in use, any conbination of
the four, two tests fail, one of them Intel says is not actually a
failure, but apparently the other is...). I run the builds normally
with NJOBS=1 and I am now so repeating the full i386 build.
>
> This symptom often shows up when one of the ctf tools died in an earlier
> run.
>
> Martin

Chavdar


-- 

i386 -current build failure

[Chavdar Ivanov]

Hi,

Does anybody else get the following while building i396 -current:

---
#  link  INSTALL_XEN3PAE_DOMU/netbsd
/dumps/sysbuild/i386/tools/bin/i486--netbsdelf-ld -Map netbsd.map
--cref -T netbsd.ldscript -Ttext 0xc010 -e start -X -o netbsd
${SYSTEM_OBJ:[@]:Nswapnetbsd.o} ${EXTRA_OBJ} vers.o swapnetbsd.o
/dumps/sysbuild/i386/tools/bin/i486--netbsdelf-ld: warning: netbsd has
a LOAD segment with RWX permissions
NetBSD 10.99.7 (INSTALL_XEN3PAE_DOMU) #2: Mon Aug 14 01:43:53 BST 2023
   textdata bss dec hex filename
6066821 5262648 1622016 12951485 c59fbd netbsd
ERROR: nbctfmerge: Input file adiantum_selftest.o was partially built
from C sources, but no CTF data was present

*** Failed target: netbsd
*** Failed commands:
${SYSTEM_LD_HEAD}
=> @rm -f netbsd
${SYSTEM_LD}
=> echo '#  ' "   link  INSTALL_XEN3PAE_DOMU/netbsd";
--

Chavdar


-- 

Re: Regression in -current

[Chavdar Ivanov]

Well, it turned out to be PEBKAC, I was at some stage thinking to
change the displayed font and the corresponding option was set in
GENERIC.local. For some reason this worked on the desktop system and
on the virtual machines I tested it on, but failed when ran on this
laptop. The issue with the USB stick not showing also turned out to be
connected to the stick in use - it works fine with a 8GB Sony stick,
but fails on a no-name one (which, again. works OK on the desktop
system).

It might be mildly interesting that when I use the "bad" stick to boot
and it is not found to continue the installation, some perhaps timing
issue gets me to the first trace, after about a minute or so, when I
am trying to figure out the disk spec to continue the boot:

breakpoint() at netbsd:breakpoint+0x5
vpanic() at netbsd:vpanic+0x173
panic() at netbsd:panic+0x3c
heartbeat() at netbsd:heartbeat+0x1ec
hardclock() at netbsd:hardclock+0x8b
Xresume_lapic_ltimer() at netbsd:Xresume_lapic_ltimer+0x1e
--- interrupt ---
x86_mwait() at netbsd:x86_mwait+0xd
acpicpu_cstate_idle() at netbsd:acpicpu_cstate_idle+0x19a
idle_loop() at netbsd:idle_loop+0x14c
cpu_hatch() at netbsd:cpu_hatch+0x180

and in some occasions to the second one, I don't know

panic: kernel diagnostic assertion "addr >= 1 && addr <= 127" failed:
file "./src/sys/dev/usb/xhci.c", line 2948 addr 0
cpu3: begin traceback...
vpanic() at netbsd:vpanic+0x173
kern_assert() at netbsd:kern_assert+0x4b
xhci_new_device() at netbsd:xhci_new_device+0x705
uhub_explore() at netbsd:uhub_explore+0x4bd
usb_discover() at netbsd:usb_discover+0x4f
usb_event_thread() at netbsd:usb_event_thread+0x46
cpu3: End traceback...
fatal breakpoint trap in supervisor mode
trap type 1 code 0 rp 0x80235425 cs 0x8 rflags 0x202 cr2 0
ilevel 0 rsp 0xd48446026de0
curlwp 0x812f10282500 pid 0.218 lowest kstack 0xd484460222c0
breakpoint() at netbsd:breakpoint+0x5
.

But otherwise there is no problem with any regression, as far as this
hardware is concerned.

Chavdar

On Wed, 19 Jul 2023 at 22:32, Robert Nestor  wrote:
>
> I’ve been doing some testing running NetBSD 9.x and 10.x in a VM environment 
> and have noticed some differences in booting that might be related.   The 
> testing I’ve done was using a fairly recent version of 10.0_BETA so similar 
> results _might_ be present in -current as well.
>
> #
> # Install differences between 9.3 and 10.0 in a virtual machine setup
> #  installing NetBSD for an amd64. The virtual environment used is KVM
> #  in LinuxMint 21.1 runing on an S600 with an Intel i9-12900H
> #
> 9.3: (using distribution CDROM image attached as SATA CDROM)
> BIOS boot - installs and runs fine
> UEFI boot - installs and runs fine
> 10.0: (using distribution CDROM image - NetBSD-10.0_BETA-amd64.iso)
> CD attached as SATA CDROM:
> BIOS boot - installs and runs fine
> UEFI boot - fails to boot - can't find root device
> CD attached as USB CDROM:
> BIOS boot - fails to boot - no BIOS boot on CD
> UEFI boot - fails to boot - can't find netbsd image
> CD attached as USB R/O disk:
> BIOS boot - fails to boot - no BIOS boot on CD
> UEFI boot - fails to boot - can't find netbsd image on CD
> CD attached as USB R/W disk:
> BIOS boot - fails to boot - no BIOS boot on CD
> UEFI boot - fails to boot - can't find netbsd image on CD
> 10.0: (using installation CDROM image - NetBSD-10.0_BETA-amd64-install.img.gz)
> CD attached as SATA CDROM:
> BIOS boot - fails to boot - no BIOS boot on CD
> UEFI boot - fails to boot - no UEFI boot on CD
> CD attached as USB CDROM:
> BIOS boot - fails to boot - no BIOS boot on CD
> UEFI boot - complains about CD not being writable for 
> /etc/gettytab
> CD attached as USB RO disk:
> BIOS boot - fails to boot - no BIOS boot on CD
> UEFI boot - complains about not being writable for /etc/gettytab
> CD attached as USB RW disk:
> BIOS boot - fails to boot - no BIOS boot on CD
> UEFI boot - boots, installs and runs
>
> So, if wanting to install 10.0 with a BIOS boot setup it's necessary to
> use the amd64 CD.  For installing with a UEFI boot setup it's necessary
> to use the amd64 install image.  I didn't test with the install image
> built for BIOS, so the above observations are not entirely complete.
>
> Notes:
> There doesn't appear to be any way to get into userconf when booting the
> installation images.  Would be nice to have that option during install.
>
> In a KVM virtual environment the keyboard and mouse aren't available until
> the kernel gets loaded, so even with an option in boot.cfg to boot up
> with the "-c" option, there's no way to use it interactively. This may be
> an issue with KVM and not NetBSD as this is the same in both 9.3 and 10.0
> and this 

Re: Regression in -current

[Chavdar Ivanov]

On Wed, 19 Jul 2023 at 13:23, Chavdar Ivanov  wrote:
>
> Hi,
>
> Among others, I have an HP Envy 17 laptop with Intel 530 graphics, as
> well as NVidia GeForce 980M. I have been running NetBSD-current on it
> since I bought it seven years ago, without much trouble. nouveau0 was
> recognized, but never worked, Intel graphics used to work just fine
> with accelerated OpenGL etc., dri2 was fine, mode-switching and font
> loading on bootstrap OK.  It boots in EFI mode, I have to manually
> select the requisite .efi file to do it.
>
> The last kernel I am able to boot on it is from the 12th of July;
> subsequent ones hard-reset immediately after the boot menu. I was able
> to boot the old kernel initially, and, thinking that it is a problem
> with the latest updates to the nouveau driver and I am perhaps missing
> the right firmware files, I added 'userconf=disable nouveau*' to
> /boot.cfg. This didn't make any difference - the system resets
> immediately - but if now I select the kernel which used to boot OK,
> after the initial kernel messages, upon the mode switch, the screen
> gets corrupted - as if it is zoomed out four times and then repeated
> close to the top of the screen. Since then, I am unable to boot NetBSD
> on it (I will repair it using a usb stick later). On top of that, the
> system has a second monitor conected via HDMI, which worked fine
> before, still left as a mirror to the original screen. After the above
> attempt the HDMI port appeared completely out of order and stopped
> working under Windows 11 and Linux... I had to reset the laptop to the
> point of disconnecting the battery, after which the HDMI port started
> to work again.

I was able to boot 10.99.6 from today by using the live system - which
is, for some reason, only BIOS based. It wouldn't boot from the USB
stick, as it does not see USB3 device past the kernel boot, but it
showed me the original disk slice, which booted further without a
problem. So it is some issue related to the EFI boot on this machine.
I will try tomorrow with amd64-install.img, which is EFI, to see if it
will fail the same way.

>
>
> Any ideas as to what may have caused this?
>
>
> Chavdar
>
>
> --
> 



-- 

Regression in -current

[Chavdar Ivanov]

Hi,

Among others, I have an HP Envy 17 laptop with Intel 530 graphics, as
well as NVidia GeForce 980M. I have been running NetBSD-current on it
since I bought it seven years ago, without much trouble. nouveau0 was
recognized, but never worked, Intel graphics used to work just fine
with accelerated OpenGL etc., dri2 was fine, mode-switching and font
loading on bootstrap OK.  It boots in EFI mode, I have to manually
select the requisite .efi file to do it.

The last kernel I am able to boot on it is from the 12th of July;
subsequent ones hard-reset immediately after the boot menu. I was able
to boot the old kernel initially, and, thinking that it is a problem
with the latest updates to the nouveau driver and I am perhaps missing
the right firmware files, I added 'userconf=disable nouveau*' to
/boot.cfg. This didn't make any difference - the system resets
immediately - but if now I select the kernel which used to boot OK,
after the initial kernel messages, upon the mode switch, the screen
gets corrupted - as if it is zoomed out four times and then repeated
close to the top of the screen. Since then, I am unable to boot NetBSD
on it (I will repair it using a usb stick later). On top of that, the
system has a second monitor conected via HDMI, which worked fine
before, still left as a mirror to the original screen. After the above
attempt the HDMI port appeared completely out of order and stopped
working under Windows 11 and Linux... I had to reset the laptop to the
point of disconnecting the battery, after which the HDMI port started
to work again.


Any ideas as to what may have caused this?


Chavdar


-- 

Re: modesetting vs intel in 10.0

[Chavdar Ivanov]

On Wed, 12 Jul 2023 at 02:50, Paul Ripke  wrote:
>
> On Sun, Jul 09, 2023 at 08:13:45AM +0100, Chavdar Ivanov wrote:
> > On Sun, 9 Jul 2023 at 00:55, Lloyd Parkes  
> > wrote:
> > >
> > >
> > >
> > > On 9/07/23 10:06, David Brownlee wrote:
> > > > What would be a good benchmark to stress the system a little?
> > >
> > > A while back someone mentioned pkgsrc/benchmarks/glmark2 and so I
> > > started using that. It seems reasonable.
> >
> > Besides that, I also use cad.onshape.com/check - but using firefox
> > ESR, as the current firefox in pkgsrc is stripped from its WebGL
> > capabilities.
>
> I did note after a rolling update of pkgsrc-2023Q2 that webgl was
> disabled in firefox-114.0.1, but could be re-enabled in about:config
> by setting webgl.disabled=false and/or webgl.force-enabled=true.

I knew about these, I had them set accordingly.

With 'webgl.disabled=true' you get a nice message telling you that
your browser does not support it; otherwise, you get your GL canvas as
a green blob and your error stream is filled with messages like:
...
Crash Annotation GraphicsCriticalError: |[0][GFX1]:
MethodDispatcher<26> not found. Please file a bug! (t=7.7034)
|[4111][GFX1]: DispatchCommand(id: 18) failed. Please file a bug!
(t=12.0513) |[4112][GFX1]: MethodDispatcher<18> not found. Please file
a bug! (t=12.0522) |[4098][GFX1]: MethodDispatcher<18> not found.
Please file a bug! (t=12.0466) |[4099][GFX1]: DispatchCommand(id: 18)
failed. Please file a bug! (t=12.0467) |[4100][GFX1]:
MethodDispatcher<18> not found. Please file a bug! (t=12.0473)
|[4101][GFX1]: DispatchCommand(id: 18) failed. Please file a bug!
(t=12.0474) |[4102][GFX1]: MethodDispatcher<18> not found. Please file
a bug! (t=12.0482) |[4103][GFX1]: DispatchCommand(id: 18) failed.
Please file a bug! (t=12.0485) |[4104][GFX1]: MethodDispatcher<18> not
found. Please file a bug! (t=12.0492) |[4105][GFX1]:
DispatchCommand(id: 18) failed. Please file a bug! (t=12.0492)
|[4106][GFX1]: MethodDispatcher<18> not found. Please file a bug!
(t=12.0499) |[4107][GFX1]: DispatchCommand(id: 18) failed. Please file
a bug! (t=12.0499) |[4108][GFX1]: MethodDispatcher<18> not found.
Please file a bug! (t=12.0506) |[4109][GFX1]: DispatchCommand(id: 18)
failed. Please file a bug! (t=12.0507) |[4110][GFX1]:
MethodDispatcher<18> not found. Please file a bug! (t=12.0513) [GFX1]:
MethodDispatcher<18> not found. Please file a bug!



So no, in my case, both Intel 530 and AMD FirePro W5000, the result is
the same and WebGL is missing.

At the same time, as I mentioned before, the latest firefox-esr
supports it fine, on both systems.


>
> (netbsd-9 on amd64 with i915, fwiw).
>
> --
> Paul Ripke
> "Great minds discuss ideas, average minds discuss events, small minds
>  discuss people."
> -- Disputed: Often attributed to Eleanor Roosevelt. 1948.

Chavdar


-- 

Re: Unable to complete build of aarch64

[Chavdar Ivanov]

On Wed, 12 Jul 2023 at 10:56, RVP  wrote:
>
> On Tue, 11 Jul 2023, Chavdar Ivanov wrote:
>
> > if c++ -stdlib=libc++ -c -fmodules -fcxx-modules
> > -fmodules-cache-path=./module.cache
> > /home/sysbuild/src/tools/llvm/module-test.cpp  3> /dev/null 2>&1; then
> > echo HOST_SUPPORTS_MODULES=yes > support-modules;  else  echo
> > HOST_SUPPORTS_MODULES=no > support-modules;  fi
> > c++: error: unrecognized command-line option '-stdlib=libc++'
> > c++: error: unrecognized command-line option '-fmodules'; did you mean 
> > '-fmoduleinfo'?
> > c++: error: unrecognized command-line option '-fcxx-modules'
> > c++: error: unrecognized command-line option 
> > '-fmodules-cache-path=./module.cache'
> > dependall ===> tools/config
> >
> > ...
> >
> >
> > The same happens with the amd64 build.
> >
> >
> > Any ideas?
> >
>
> All those are Clang-specific options which GCC doesn't understand, but, this
> can't be the reason why your (LLVM-based) build is failing. As you can see
> the test is in an `if' statement, so it shouldn't error-out.
>
> Can you run the build again within script(1) so that the complete text is
> captured, and we can see where the actual error is?


Well, no need. Subsequent cvs update allowed me to build both systems.

Comparing the cvs log between the failed and the succeeded builds
(both were incremental), the only relevant change I see to be

RCS file: /cvsroot/src/tools/gcc/gcc-version.mk,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- gcc-version.mk  23 Jul 2022 19:01:18 -  1.22
+++ gcc-version.mk  11 Jul 2023 18:13:27 -  1.23
@@ -1,11 +1,7 @@
-#  $NetBSD: gcc-version.mk,v 1.22 2022/07/23 19:01:18 mrg Exp $
+#  $NetBSD: gcc-version.mk,v 1.23 2023/07/11 18:13:27 mrg Exp $

 # common location for tools and native build

-.if ${HAVE_GCC} == 8
-NETBSD_GCC_VERSION=nb1 20200311
-.elif ${HAVE_GCC} == 9
-NETBSD_GCC_VERSION=nb1 20200907
-.elif ${HAVE_GCC} == 10
-NETBSD_GCC_VERSION=nb1 20220722
+.if ${HAVE_GCC} == 10
+NETBSD_GCC_VERSION=nb2 20230710
 .endif


There you are.
>
> -RVP



Chavdar

-- 

Re: Unable to complete build of aarch64

[Chavdar Ivanov]

if c++ -stdlib=libc++ -c -fmodules -fcxx-modules
-fmodules-cache-path=./module.cache
/home/sysbuild/src/tools/llvm/module-test.cpp  3> /dev/null 2>&1; then
 echo HOST_SUPPORTS_MODULES=yes > support-modules;  else  echo
HOST_SUPPORTS_MODULES=no > support-modules;  fi
c++: error: unrecognized command-line option '-stdlib=libc++'
c++: error: unrecognized command-line option '-fmodules'; did you mean
'-fmoduleinfo'?
c++: error: unrecognized command-line option '-fcxx-modules'
c++: error: unrecognized command-line option
'-fmodules-cache-path=./module.cache'
dependall ===> tools/config

...


The same happens with the amd64 build.


Any ideas?

On Tue, 11 Jul 2023 at 11:31, Chavdar Ivanov  wrote:
>
> Hi,
>
> After having completely cleaned all previous traces of obj and tools
> directories, having run 'make cleandir' in src and xsrc and cvs
> updated with no problematic logs, I am getting repeatedly the
> following:
> 
> dependall ===> tools/llvm
> rm -rf /dumps/sysbuild/evbarm64/obj/home/sysbuild/src/tools/llvm/module.cache
> printf 'int setupterm(char *, int, int *);\nint main(void){return
> setupterm("", 0, 0);}' > need-terminfo.c
> for lib in tinfo terminfo ncurses curses; do  if cc -o
> need-terminfo.out need-terminfo.c -l$lib > /dev/null 2>&1; then  echo
> -l$lib > need-terminfo;  break;  fi;  done
> mkdir -p config
> printf '#!/bin/sh\necho 2.7.3' > config/python
> chmod 755 config/python
> cd config && /bin/sh
> /home/sysbuild/src/tools/llvm/../../external/apache2/llvm/lib/../autoconf/configure
> --enable-targets=x86,powerpc,sparc,aarch64,arm,mips
> --with-c-include-dirs=/usr/include/clang-13.0:/usr/include
> --disable-timestamps --prefix=/usr --sysconfdir=/etc/llvm
> --with-clang-default-openmp-runtime=libomp
> --with-llvm-srcdir=/home/sysbuild/src/tools/llvm/../../external/apache2/llvm/lib/../dist/llvm
>  
> --with-clang-srcdir=/home/sysbuild/src/tools/llvm/../../external/apache2/llvm/lib/../dist/clang
>  --host=aarch64--netbsd --disable-compiler-version-checks
> --disable-bindings
> llvm_cv_gnu_make_command=/dumps/sysbuild/evbarm64/tools/bin/nbmake
> ac_cv_path_CIRCO="echo circo" ac_cv_path_DOT="echo dot"
> ac_cv_path_DOTTY="echo dotty" ac_cv_path_FDP="echo fdp"
> ac_cv_path_NEATO="echo neato" ac_cv_path_TWOPI="echo twopi"
> ac_cv_path_XDOT="echo xdot"  --enable-optimized CC=cc CXX=c++
> --with-python=/dumps/sysbuild/evbarm64/obj/home/sysbuild/src/tools/llvm/config/python
> &&  cp 
> /home/sysbuild/src/tools/llvm/../../external/apache2/llvm/lib/../include/module.modulemap
> include/llvm/module.modulemap
> checking for aarch64--netbsd-clang... cc
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... no
> 
> checking for _chsize_s... no
> checking whether arc4random is declared... (cached) yes
> checking whether strerror_s is declared... no
> checking for GCC atomic builtins... yes
> yes
> checking for compiler -fvisibility-inlines-hidden option... yes
> configure: creating ./config.status
> config.status: creating include/llvm/Config/Targets.def
> config.status: creating include/llvm/Config/AsmPrinters.def
> config.status: creating include/llvm/Config/AsmParsers.def
> config.status: creating include/llvm/Config/Disassemblers.def
> config.status: creating include/llvm/Config/config.h
> config.status: creating include/llvm/Config/llvm-config.h
> config.status: creating include/llvm/Config/abi-breaking.h
> config.status: creating include/llvm/Support/DataTypes.h
> config.status: creating include/clang/Config/config.h
> printf '#include \nint main(void){void *p; return dladdr(p,
> p);}' > need-dl.c
> if cc -o need-dl.out -D_GNU_SOURCE need-dl.c > /dev/null 2>&1; then
> echo > need-dl;  elif cc -o need-dl.out -D_GNU_SOURCE need-dl.c -ldl >
> /dev/null 2>&1; then  echo -ldl > need-dl;  else  echo > need-dl;  fi
> if c++ -stdlib=libc++ -c -fmodules -fcxx-modules
> -fmodules-cache-path=./module.cache
> /home/sysbuild/src/tools/llvm/module-test.cpp  3> /dev/null 2>&1; then
>  echo HOST_SUPPORTS_MODULES=yes > support-modules;  else  echo
> HOST_SUPPORTS_MODULES=no > support-modules;  fi
> c++: error: unrecognized command-line option '-stdlib=libc++'
> c++: error: unrecognized command-line option '-fmodules'; did you mean
> '-fmoduleinfo'?
> c++: error: unrecognized command-line option '-fcxx-modules'
> c++: error: unrecognized command-line option
> '-fmodules-cache-path=./module.cache'
> dependall ===> tools/config
>
> ...
>
>
> The host is
>
> uname -a
> NetBSD ymir.lorien.lan 10.99.5 NetBSD 10.99.5 (GENERIC) #7: Sun Jul  9
> 10:15:07 BST 2023
> sysbu...@ymir.lorien.lan:/dumps/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC
> amd64
>
> I am going to rebuild the host just in case, but am not able to see
> any particular problem ewlsewhere.
>
>
> Chavdar
>
>
> 



-- 

Unable to complete build of aarch64

[Chavdar Ivanov]

Hi,

After having completely cleaned all previous traces of obj and tools
directories, having run 'make cleandir' in src and xsrc and cvs
updated with no problematic logs, I am getting repeatedly the
following:

dependall ===> tools/llvm
rm -rf /dumps/sysbuild/evbarm64/obj/home/sysbuild/src/tools/llvm/module.cache
printf 'int setupterm(char *, int, int *);\nint main(void){return
setupterm("", 0, 0);}' > need-terminfo.c
for lib in tinfo terminfo ncurses curses; do  if cc -o
need-terminfo.out need-terminfo.c -l$lib > /dev/null 2>&1; then  echo
-l$lib > need-terminfo;  break;  fi;  done
mkdir -p config
printf '#!/bin/sh\necho 2.7.3' > config/python
chmod 755 config/python
cd config && /bin/sh
/home/sysbuild/src/tools/llvm/../../external/apache2/llvm/lib/../autoconf/configure
--enable-targets=x86,powerpc,sparc,aarch64,arm,mips
--with-c-include-dirs=/usr/include/clang-13.0:/usr/include
--disable-timestamps --prefix=/usr --sysconfdir=/etc/llvm
--with-clang-default-openmp-runtime=libomp
--with-llvm-srcdir=/home/sysbuild/src/tools/llvm/../../external/apache2/llvm/lib/../dist/llvm
 
--with-clang-srcdir=/home/sysbuild/src/tools/llvm/../../external/apache2/llvm/lib/../dist/clang
 --host=aarch64--netbsd --disable-compiler-version-checks
--disable-bindings
llvm_cv_gnu_make_command=/dumps/sysbuild/evbarm64/tools/bin/nbmake
ac_cv_path_CIRCO="echo circo" ac_cv_path_DOT="echo dot"
ac_cv_path_DOTTY="echo dotty" ac_cv_path_FDP="echo fdp"
ac_cv_path_NEATO="echo neato" ac_cv_path_TWOPI="echo twopi"
ac_cv_path_XDOT="echo xdot"  --enable-optimized CC=cc CXX=c++
--with-python=/dumps/sysbuild/evbarm64/obj/home/sysbuild/src/tools/llvm/config/python
&&  cp 
/home/sysbuild/src/tools/llvm/../../external/apache2/llvm/lib/../include/module.modulemap
include/llvm/module.modulemap
checking for aarch64--netbsd-clang... cc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no

checking for _chsize_s... no
checking whether arc4random is declared... (cached) yes
checking whether strerror_s is declared... no
checking for GCC atomic builtins... yes
yes
checking for compiler -fvisibility-inlines-hidden option... yes
configure: creating ./config.status
config.status: creating include/llvm/Config/Targets.def
config.status: creating include/llvm/Config/AsmPrinters.def
config.status: creating include/llvm/Config/AsmParsers.def
config.status: creating include/llvm/Config/Disassemblers.def
config.status: creating include/llvm/Config/config.h
config.status: creating include/llvm/Config/llvm-config.h
config.status: creating include/llvm/Config/abi-breaking.h
config.status: creating include/llvm/Support/DataTypes.h
config.status: creating include/clang/Config/config.h
printf '#include \nint main(void){void *p; return dladdr(p,
p);}' > need-dl.c
if cc -o need-dl.out -D_GNU_SOURCE need-dl.c > /dev/null 2>&1; then
echo > need-dl;  elif cc -o need-dl.out -D_GNU_SOURCE need-dl.c -ldl >
/dev/null 2>&1; then  echo -ldl > need-dl;  else  echo > need-dl;  fi
if c++ -stdlib=libc++ -c -fmodules -fcxx-modules
-fmodules-cache-path=./module.cache
/home/sysbuild/src/tools/llvm/module-test.cpp  3> /dev/null 2>&1; then
 echo HOST_SUPPORTS_MODULES=yes > support-modules;  else  echo
HOST_SUPPORTS_MODULES=no > support-modules;  fi
c++: error: unrecognized command-line option '-stdlib=libc++'
c++: error: unrecognized command-line option '-fmodules'; did you mean
'-fmoduleinfo'?
c++: error: unrecognized command-line option '-fcxx-modules'
c++: error: unrecognized command-line option
'-fmodules-cache-path=./module.cache'
dependall ===> tools/config

...


The host is

uname -a
NetBSD ymir.lorien.lan 10.99.5 NetBSD 10.99.5 (GENERIC) #7: Sun Jul  9
10:15:07 BST 2023
sysbu...@ymir.lorien.lan:/dumps/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC
amd64

I am going to rebuild the host just in case, but am not able to see
any particular problem ewlsewhere.


Chavdar

Re: modesetting vs intel in 10.0

[Chavdar Ivanov]

On Sun, 9 Jul 2023 at 00:55, Lloyd Parkes  wrote:
>
>
>
> On 9/07/23 10:06, David Brownlee wrote:
> > What would be a good benchmark to stress the system a little?
>
> A while back someone mentioned pkgsrc/benchmarks/glmark2 and so I
> started using that. It seems reasonable.

Besides that, I also use cad.onshape.com/check - but using firefox
ESR, as the current firefox in pkgsrc is stripped from its WebGL
capabilities.

>
> Cheers,
> Lloyd
>


-- 

Panic on recent i386 -current

[Chavdar Ivanov]

Hi,

I got:
..
➜  crash crash -M netbsd.0.core -N netbsd.0
Crash version 10.99.4, image version 10.99.4.
crash: _kvm_kvatop(0)
Kernel compiled without options LOCKDEBUG.
System panicked: kernel diagnostic assertion "c->c_cpu->cc_lwp ==
curlwp || c->c_cpu->cc_active != c" failed: file
"/home/sysbuild/src/sys/kern/kern_timeout.c", line 381 running callout
0xc2074030: c_func (0xc055cffb) c_flags (0x9) destroyed from
0xc015d1d4
Backtrace from time of crash is available.
crash> bt
_KERNEL_OPT_MEMORY_RBFLAGS(104,0,c1f12300,c1357bc4,c1401258,cd855db8,c0dc2787,104,0,0)
at 0
kern_reboot(104,0,0,0,c17393a0,c2074030,c21f6104,cd855dc8,c0f8cf12,c1401258)
at sys_reboot
vpanic(c1401258,cd855dd4,cd855df8,c0d9a966,c1401258,c12db1db,c1401220,c1401008,17d,c2074030)
at vpanic+0x194
kern_assert(c1401258,c12db1db,c1401220,c1401008,17d,c2074030,c055cffb,9,c015d1d4,c2074020)
at kern_assert+0x23
callout_destroy(c2074030,c21efe00,c1fdf4c4,c0d6bbda,cd855e24,c21efe10,c2074020,c1fdf4c4,c21f6104,cd855e78)
at callout_destroy+0x94
scsipi_put_xs(c2074020,c398ed3c,cd855e40,2,0,0,800,c200e200,c1e34040,0)
at scsipi_put_xs+0x7e
scsipi_complete(6,c055d3db,c2074030,c27449c4,0,800,0,c21e6574,c1fdf4c0,0)
at scsipi_complete+0x2a9
scsipi_done(c2074020,1,1e0,f0,a,0,0,c21f4804,c1fdf4c0,0) at scsipi_done+0x1f1
esiop_checkdone(c1fdf4c0,cdd77000,14,c0d632f3,6,4,2,0,2,f0) at
esiop_checkdone+0x2b1
esiop_intr(c1fdf4c0,4,cd855f6c,c04aff51,c2075e80,c0d9b2b9,1ec,10eba,c16820dc,c20649c0)
at esiop_intr+0x1f
intr_biglock_wrapper(c2064e40,cd9bef14,0,0,0,0,0,0,0,0) at
intr_biglock_wrapper+0x3b
--- switch to interrupt stack ---
Xintr_ioapic_level5() at Xintr_ioapic_level5+0xcc
--- interrupt ---
Xspllower(4,0,0,0,0,0,0,0,0,0) at Xspllower+0xf
crash: _kvm_kvatop(cd9bf000)
crash: kvm_read(0xcd9bf000, 4): invalid translation (invalid PTE)
softint_dispatch(c1f12880,4,0,0,0,0,
...

This is on
uname -a
NetBSD n1386.lorien.lan 10.99.4 NetBSD 10.99.4 (GENERIC) #0: Fri May
26 23:00:33 BST 2023
sysbu...@ymir.lorien.lan:/dumps/sysbuild/i386/obj/home/sysbuild/src/sys/arch/i386/compile/GENERIC
i386

running under Qemu 5.2 (latest Virtualisation Station 4.0.0.212) while
cvs updating pkgsrc.
That could be linked to the message I am getting from esiop0:

[50.639308] esiop0: autoconfiguration error: phase mismatch without command
[50.639308] esiop0: autoconfiguration error: unhandled scsi
interrupt, sist=0x80 sstat1=0x0 DSA=0x20510f1 DSP=0x50
[50.639308] esiop0: scsi bus reset
[50.659293] sd0: async, 8-bit transfers, tagged queueing
[50.659293] esiop0: autoconfiguration error: phase mismatch without command
[50.659293] esiop0: autoconfiguration error: unhandled scsi
interrupt, sist=0x80 sstat1=0x0 DSA=0x1 DSP=0x50
[50.659293] esiop0: scsi bus reset
[50.669289] sd0(esiop0:0:0:0): command with tag id 0 reset



-- 

Re: /usr/bin/ftp crash on -current (10.00.4) aarch64

[Chavdar Ivanov]

Clean build resolved the problem.

Thanks,

Chavdar

On Thu, 18 May 2023 at 15:10, Chavdar Ivanov  wrote:
>
> On Thu, 18 May 2023 at 15:06, Brad Spencer  wrote:
> >
> > Chavdar Ivanov  writes:
> >
> > > On Thu, 18 May 2023 at 11:31, Robert Swindells  wrote:
> > >>
> > >>
> > >> Chavdar Ivanov  wrote:
> > >> > The weird and suspicious thing is that /usr/bin/ftp is linked to both
> > >> > existing libcrypto.so versions:
> > >> >
> > >> > ldd /usr/bin/ftp
> > >> > /usr/bin/ftp:
> > >> >-ledit.3 => /usr/lib/libedit.so.3
> > >> >-lterminfo.2 => /usr/lib/libterminfo.so.2
> > >> >-lc.12 => /usr/lib/libc.so.12
> > >> >-lssl.15 => /usr/lib/libssl.so.15
> > >> >-lcrypto.14 => /usr/lib/libcrypto.so.14
> > >> >-lcrypt.1 => /lib/libcrypt.so.1
> > >> >-lcrypto.15 => /usr/lib/libcrypto.so.15
> > >>
> > >> I'm guessing you did an update build not a clean one. Also, did you use
> > >> the -j flag to build in parallel?
> > >
> > > I indeed usually do update builds; in this case however, I had deleted
> > > the entire obj (it is on a zfs, removing takes a lot of time, so
> > > subsequently I replaced it with a dedicated zfs so that I can just
> > > destroy and recreate it...). I also 'make cleandir' in [x]src in
> > > advance; that usually is enough.
> >
> > 
> > Snapshot the zfs fileset when it is empty and rollback when you want to
> > make it empty again.  Very quick  works best when obj is its own
> > fileset.
>
> It didn't come to my mind... I was doing destroy, create, set
> mountpoint and chown, so the above saves me three commands...
>
> > 
> >
> > >>
> > >> Do a clean build and everything should work.
> > >
> > > That's next.
> >
> >
> >
> > --
> > Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
>
>
>
> --
> 



-- 

Re: /usr/bin/ftp crash on -current (10.00.4) aarch64

[Chavdar Ivanov]

On Thu, 18 May 2023 at 15:06, Brad Spencer  wrote:
>
> Chavdar Ivanov  writes:
>
> > On Thu, 18 May 2023 at 11:31, Robert Swindells  wrote:
> >>
> >>
> >> Chavdar Ivanov  wrote:
> >> > The weird and suspicious thing is that /usr/bin/ftp is linked to both
> >> > existing libcrypto.so versions:
> >> >
> >> > ldd /usr/bin/ftp
> >> > /usr/bin/ftp:
> >> >-ledit.3 => /usr/lib/libedit.so.3
> >> >-lterminfo.2 => /usr/lib/libterminfo.so.2
> >> >-lc.12 => /usr/lib/libc.so.12
> >> >-lssl.15 => /usr/lib/libssl.so.15
> >> >-lcrypto.14 => /usr/lib/libcrypto.so.14
> >> >-lcrypt.1 => /lib/libcrypt.so.1
> >> >-lcrypto.15 => /usr/lib/libcrypto.so.15
> >>
> >> I'm guessing you did an update build not a clean one. Also, did you use
> >> the -j flag to build in parallel?
> >
> > I indeed usually do update builds; in this case however, I had deleted
> > the entire obj (it is on a zfs, removing takes a lot of time, so
> > subsequently I replaced it with a dedicated zfs so that I can just
> > destroy and recreate it...). I also 'make cleandir' in [x]src in
> > advance; that usually is enough.
>
> 
> Snapshot the zfs fileset when it is empty and rollback when you want to
> make it empty again.  Very quick  works best when obj is its own
> fileset.

It didn't come to my mind... I was doing destroy, create, set
mountpoint and chown, so the above saves me three commands...

> 
>
> >>
> >> Do a clean build and everything should work.
> >
> > That's next.
>
>
>
> --
> Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org



-- 

Re: /usr/bin/ftp crash on -current (10.00.4) aarch64

[Chavdar Ivanov]

On Thu, 18 May 2023 at 13:16, RVP  wrote:
>
> On Thu, 18 May 2023, Chavdar Ivanov wrote:
>
> > Yes indeed, with SIGILL passed I get:
> >
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0xf03114c97890 in EC_GROUP_order_bits () from /usr/lib/libcrypto.so.14
> > (gdb) bt
> > #0  0xf03114c97890 in EC_GROUP_order_bits () from 
> > /usr/lib/libcrypto.so.14
> > #1  0xf031154898a4 in engine_unlocked_init () from 
> > /usr/lib/libcrypto.so.15
> > #2  0xf03115489ab0 in ENGINE_init () from /usr/lib/libcrypto.so.15
> > #3  0xf031153d11f0 in ?? () from /usr/lib/libcrypto.so.15
> > #4  0xf03115694c30 in ssl_setup_sig_algs () from /usr/lib/libssl.so.15
> > #5  0xf031156a85c4 in SSL_CTX_new_ex () from /usr/lib/libssl.so.15
> > #6  0x0f1be6d8 in fetch_start_ssl ()
> > #7  0x0f1b0dfc in fetch_url ()
> > #8  0x0f1b3128 in auto_fetch ()
> > #9  0x0f1bf944 in main ()
> >
>
> You can see the cause right in that stack trace:
>
> EC_GROUP_order_bits is from libcrypto.so.14, but,
> engine_unlocked_init etc., are from libcrypto.so.15
>
> This is our old friend: library interpositioning and it happens due to
> this:
>
> $ readelf -d /mnt/usr/bin/ftp | f NEEDED
>   0x0001 NEEDED   Shared library: [libedit.so.3]
>   0x0001 NEEDED   Shared library: [libterminfo.so.2]
>   0x0001 NEEDED   Shared library: [libssl.so.14]
>   0x0001 NEEDED   Shared library: [libcrypto.so.14]
>   0x0001 NEEDED   Shared library: [libc.so.12]
> $ readelf -d /mnt/usr/lib/libssl.so.14 | f NEEDED
>   0x0001 NEEDED   Shared library: [libcrypto.so.14]
>   0x0001 NEEDED   Shared library: [libc.so.12]
>
>
> So, my ftp binary explicitly needs `libcrypto.so.14'. and `libssl' also has
> _the same version_ as a dependency. But, in your case, the ftp binary will
> show `libcrypto.so.15', but libssl will need `libcrypto.so.14'. Ie. the
> compiler linked in the newer version explicitly (cc ... -lcrypto') and the
> other one was brought in implicitly via libssl.

Indeed:

# readelf -d /usr/bin/ftp | grep NEEDED
 0x0001 (NEEDED) Shared library: [libedit.so.3]
 0x0001 (NEEDED) Shared library: [libterminfo.so.2]
 0x0001 (NEEDED) Shared library: [libssl.so.15]
 0x0001 (NEEDED) Shared library: [libcrypto.so.15]
 0x0001 (NEEDED) Shared library: [libc.so.12]
# readelf -d /usr/lib/libssl.so.15.0 | grep NEEDED
 0x0001 (NEEDED) Shared library: [libcrypto.so.14]
 0x0001 (NEEDED) Shared library: [libc.so.12]

Rebuilding clean now.

Thanks,

Chavdar

>
> -RVP
>


-- 

Re: /usr/bin/ftp crash on -current (10.00.4) aarch64

[Chavdar Ivanov]

On Thu, 18 May 2023 at 11:31, Robert Swindells  wrote:
>
>
> Chavdar Ivanov  wrote:
> > The weird and suspicious thing is that /usr/bin/ftp is linked to both
> > existing libcrypto.so versions:
> >
> > ldd /usr/bin/ftp
> > /usr/bin/ftp:
> >-ledit.3 => /usr/lib/libedit.so.3
> >-lterminfo.2 => /usr/lib/libterminfo.so.2
> >-lc.12 => /usr/lib/libc.so.12
> >-lssl.15 => /usr/lib/libssl.so.15
> >-lcrypto.14 => /usr/lib/libcrypto.so.14
> >-lcrypt.1 => /lib/libcrypt.so.1
> >-lcrypto.15 => /usr/lib/libcrypto.so.15
>
> I'm guessing you did an update build not a clean one. Also, did you use
> the -j flag to build in parallel?

I indeed usually do update builds; in this case however, I had deleted
the entire obj (it is on a zfs, removing takes a lot of time, so
subsequently I replaced it with a dedicated zfs so that I can just
destroy and recreate it...). I also 'make cleandir' in [x]src in
advance; that usually is enough.

>
> Do a clean build and everything should work.

That's next.



-- 

Re: /usr/bin/ftp crash on -current (10.00.4) aarch64

[Chavdar Ivanov]

On Thu, 18 May 2023 at 11:33, RVP  wrote:
>
> On Thu, 18 May 2023, Chavdar Ivanov wrote:
>
> > This turned out to be /usr/bin/ftp crashing:
> >
> > #  /usr/bin/ftp -o node-v20.2.0.tar.xz
> > 'https://nodejs.org/dist/v20.2.0/node-v20.2.0.tar.xz'
> > Trying 104.20.23.46:443 ...
> > [1]7100 segmentation fault  /usr/bin/ftp -o node-v20.2.0.tar.xz
> > 
> >
> > If I run it under gdb, I get:
> >
> > (gdb) run -o node-v20.2.0.tar.xz
> > 'https://nodejs.org/dist/v20.2.0/node-v20.2.0.tar.xz'
> > Starting program: /usr/bin/ftp -o node-v20.2.0.tar.xz
> > 'https://nodejs.org/dist/v20.2.0/node-v20.2.0.tar.xz'
> >
> > Program received signal SIGILL, Illegal instruction.
> > 0xf7db5d54be70 in _armv8_sha512_probe () from /usr/lib/libcrypto.so.14
> > (gdb) bt
> > #0  0xf7db5d54be70 in _armv8_sha512_probe () from 
> > /usr/lib/libcrypto.so.14
> > #1  0xf7db5d54c23c in OPENSSL_cpuid_setup () from 
> > /usr/lib/libcrypto.so.14
> > #2  0xef643398 in _rtld_call_init_function () from
> > /usr/libexec/ld.elf_so
> > #3  0xef6436a4 in _rtld_call_init_functions () from
> > /usr/libexec/ld.elf_so
> > #4  0xef643f74 in _rtld () from /usr/libexec/ld.elf_so
> > #5  0xef640b10 in _rtld_start () from /usr/libexec/ld.elf_so
> > Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> >
>
> You should ignore SIGILL when it's in libcrypto on some archs. eg. ARM,
> PPC & Sparc. On x86 systems, libcrypto uses the CPUID instruction to
> determine which optimized assembly routines can be used for speedup. On
> ARM etc, it installs a SIGILL handler and just runs test instructions. The
> handler being called means _those_ instructions are not available.
>
> So, on ARM, you have to tell gdb to pass through SIGILL to the program:
>
> ```
> (gdb) handle SIGILL nostop noprint pass
> ```
>
> > The weird and suspicious thing is that /usr/bin/ftp is linked to both
> > existing libcrypto.so versions:
> >
> > ldd /usr/bin/ftp
> > /usr/bin/ftp:
> >-ledit.3 => /usr/lib/libedit.so.3
> >-lterminfo.2 => /usr/lib/libterminfo.so.2
> >-lc.12 => /usr/lib/libc.so.12
> >-lssl.15 => /usr/lib/libssl.so.15
> >-lcrypto.14 => /usr/lib/libcrypto.so.14
> >-lcrypt.1 => /lib/libcrypt.so.1
> >-lcrypto.15 => /usr/lib/libcrypto.so.15
> >
>
> I would say this is the real reason for the crash (SIGSEGV).

Yes indeed, with SIGILL passed I get:


Program received signal SIGSEGV, Segmentation fault.
0xf03114c97890 in EC_GROUP_order_bits () from /usr/lib/libcrypto.so.14
(gdb) bt
#0  0xf03114c97890 in EC_GROUP_order_bits () from /usr/lib/libcrypto.so.14
#1  0xf031154898a4 in engine_unlocked_init () from /usr/lib/libcrypto.so.15
#2  0xf03115489ab0 in ENGINE_init () from /usr/lib/libcrypto.so.15
#3  0xf031153d11f0 in ?? () from /usr/lib/libcrypto.so.15
#4  0xf03115694c30 in ssl_setup_sig_algs () from /usr/lib/libssl.so.15
#5  0xf031156a85c4 in SSL_CTX_new_ex () from /usr/lib/libssl.so.15
#6  0x0f1be6d8 in fetch_start_ssl ()
#7  0x0f1b0dfc in fetch_url ()
#8  0x0f1b3128 in auto_fetch ()
#9  0x0f1bf944 in main ()


>
> -RVP



-- 

/usr/bin/ftp crash on -current (10.00.4) aarch64

[Chavdar Ivanov]

Hi,

After having upgraded my aarch64 host to

(NetBSD narvi 10.99.4 NetBSD 10.99.4 (GENERIC64) #0: Sun May 14
19:13:18 BST 2023
sysbu...@ymir.lorien.lan:/dumps/sysbuild/evbarm64/obj/home/sysbuild/src/sys/arch/evbarm/compile/GENERIC64
evbarm)

I found out I can no longer fetch some packages:
...
 cd /usr/pkgsrc/lang/nodejs
➜  nodejs make fetch
=> Bootstrap dependency digest>=20211023: found digest-20220214
=> Fetching node-v20.2.0.tar.xz
=> Total size: 41778040 bytes
Trying 104.20.22.46:443 ...
[1]   Segmentation fault  (cd ${fetchdir}; if ${TEST} -n "${resume}"; th...
fetch: Unable to fetch expected file node-v20.2.0.tar.xz
Trying 151.101.61.6:80 ...
...

This turned out to be /usr/bin/ftp crashing:

#  /usr/bin/ftp -o node-v20.2.0.tar.xz
'https://nodejs.org/dist/v20.2.0/node-v20.2.0.tar.xz'
Trying 104.20.23.46:443 ...
[1]7100 segmentation fault  /usr/bin/ftp -o node-v20.2.0.tar.xz


If I run it under gdb, I get:

(gdb) run -o node-v20.2.0.tar.xz
'https://nodejs.org/dist/v20.2.0/node-v20.2.0.tar.xz'
Starting program: /usr/bin/ftp -o node-v20.2.0.tar.xz
'https://nodejs.org/dist/v20.2.0/node-v20.2.0.tar.xz'

Program received signal SIGILL, Illegal instruction.
0xf7db5d54be70 in _armv8_sha512_probe () from /usr/lib/libcrypto.so.14
(gdb) bt
#0  0xf7db5d54be70 in _armv8_sha512_probe () from /usr/lib/libcrypto.so.14
#1  0xf7db5d54c23c in OPENSSL_cpuid_setup () from /usr/lib/libcrypto.so.14
#2  0xef643398 in _rtld_call_init_function () from
/usr/libexec/ld.elf_so
#3  0xef6436a4 in _rtld_call_init_functions () from
/usr/libexec/ld.elf_so
#4  0xef643f74 in _rtld () from /usr/libexec/ld.elf_so
#5  0xef640b10 in _rtld_start () from /usr/libexec/ld.elf_so
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

The weird and suspicious thing is that /usr/bin/ftp is linked to both
existing libcrypto.so versions:

ldd /usr/bin/ftp
/usr/bin/ftp:
-ledit.3 => /usr/lib/libedit.so.3
-lterminfo.2 => /usr/lib/libterminfo.so.2
-lc.12 => /usr/lib/libc.so.12
-lssl.15 => /usr/lib/libssl.so.15
-lcrypto.14 => /usr/lib/libcrypto.so.14
-lcrypt.1 => /lib/libcrypt.so.1
-lcrypto.15 => /usr/lib/libcrypto.so.15

whereas on amd64, built a few hours earlier, I get:
# ldd =ftp
/usr/bin/ftp:
-ledit.3 => /usr/lib/libedit.so.3
-lterminfo.2 => /usr/lib/libterminfo.so.2
-lc.12 => /usr/lib/libc.so.12
-lssl.15 => /usr/lib/libssl.so.15
-lcrypto.15 => /usr/lib/libcrypto.so.15
-lcrypt.1 => /lib/libcrypt.so.1

I will obviously rebuild the aarch64 system just in case, but thought
it worth mentioning.

Chavdar

-- 

lang/elixir build failure post OpenSSL 3.0.8, -current, aarch64

[Chavdar Ivanov]

Hi,

I am getting:
...
===> Building for elixir-1.14.4
ENV:
LANG=C
LC_ALL=en_US.UTF-8
LC_COLLATE=C
LC_CTYPE=C
LC_MESSAGES=C
LC_MONETARY=C
LC_NUMERIC=C
LC_TIME=C
LOCALE:
LANG="C"
LC_CTYPE="en_US.UTF-8"
LC_COLLATE="C"
LC_TIME="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_ALL="en_US.UTF-8"
==> mix (compile)
/usr/lib/openssl/modules/legacy.so: Undefined PLT symbol
"OSSL_LIB_CTX_new_child" (symnum = 100)
gmake: *** [Makefile:117: lib/mix/ebin/Elixir.Mix.beam] Error 1

(erlang built OK).

Chavdar

-- 

Re: Aarch64 build failure

[Chavdar Ivanov]

Hi,
I noticed Christos just updated etc/mtree/NetBSD.dist.aarch64, so it
should be OK now.

On Sun, 14 May 2023 at 17:40, Chavdar Ivanov  wrote:
>
> Hi,
>
> I get:
> 
> /dumps/sysbuild/evbarm64/tools/bin/nbmtree -def
> /dumps/sysbuild/evbarm64/obj/home/sysbuild/src/etc/mtree/NetBSD.dist
> -N /home/sysbuild/src/etc/mtree/..  -p
> /dumps/sysbuild/evbarm64/destdir/ -U -W
> ./lib/eabi missing (created)
> ./usr/lib/eabi missing (created)
> 
>
> And further down:
>
> ===  2 extra files in DESTDIR  =
> Files in DESTDIR but missing from flist.
> File is obsolete or flist is out of date ?
> --
> ./lib/eabi
> ./usr/lib/eabi
> =  end of 2 extra files  ===
>
> I guess this is an incorrect mtree somewhere?
>
> Chavdar
>
>
>
> --
> 



-- 

Aarch64 build failure

[Chavdar Ivanov]

Hi,

I get:

/dumps/sysbuild/evbarm64/tools/bin/nbmtree -def
/dumps/sysbuild/evbarm64/obj/home/sysbuild/src/etc/mtree/NetBSD.dist
-N /home/sysbuild/src/etc/mtree/..  -p
/dumps/sysbuild/evbarm64/destdir/ -U -W
./lib/eabi missing (created)
./usr/lib/eabi missing (created)


And further down:

===  2 extra files in DESTDIR  =
Files in DESTDIR but missing from flist.
File is obsolete or flist is out of date ?
--
./lib/eabi
./usr/lib/eabi
=  end of 2 extra files  ===

I guess this is an incorrect mtree somewhere?

Chavdar



-- 

Build failure on -current

[Chavdar Ivanov]

Does anybody see:
...
#  link  ec/h_ectest
/dumps/sysbuild/amd64/tools/bin/x86_64--netbsd-gcc
--sysroot=/dumps/sysbuild/amd64/destdir   -pie  -shared-libgcc
-Wl,--warn-shared-textrel -Wl,-z,relro -o h_ectest  ectest.o
-Wl,-rpath-link,/dumps/sysbuild/amd64/destdir/lib  -L=/lib -lcrypt
/dumps/sysbuild/amd64/obj/home/sysbuild/src/crypto/external/bsd/openssl/lib/libcryptotest/libcryptotest.a
/dumps/sysbuild/amd64/obj/home/sysbuild/src/crypto/external/bsd/openssl/lib/libcrypto/libcrypto.a
/dumps/sysbuild/amd64/tools/lib/gcc/x86_64--netbsd/10.4.0/../../../../x86_64--netbsd/bin/ld:
ectest.o:(.data.rel.ro+0x0): undefined reference to
`EC_GFp_nistp224_method'
/dumps/sysbuild/amd64/tools/lib/gcc/x86_64--netbsd/10.4.0/../../../../x86_64--netbsd/bin/ld:
ectest.o:(.data.rel.ro+0x58): undefined reference to
`EC_GFp_nistp256_method'
/dumps/sysbuild/amd64/tools/lib/gcc/x86_64--netbsd/10.4.0/../../../../x86_64--netbsd/bin/ld:
ectest.o:(.data.rel.ro+0xb0): undefined reference to
`EC_GFp_nistp521_method'
collect2: error: ld returned 1 exit status
*** Failed target: h_ectest
*** Failed commands:
${_MKTARGET_LINK}
=> @echo '#  ' "   link " ec/h_ectest
${_CCLINK.${:Uh_ectest}}  ${_LDFLAGS.${:Uh_ectest}}
${_LDSTATIC.${:Uh_ectest}} -o ${.TARGET}  ${OBJS.${:Uh_ectest}}
${_PROGLDOPTS} ${_LDADD.${:Uh_ectest}}
=> /dumps/sysbuild/amd64/tools/bin/x86_64--netbsd-gcc
--sysroot=/dumps/sysbuild/amd64/destdir   -pie  -shared-libgcc
-Wl,--warn-shared-textrel -Wl,-z,relro -o h_ectest  ectest.o
-Wl,-rpath-link,/dumps/sysbuild/amd64/destdir/lib  -L=/lib -lcrypt
/dumps/sysbuild/amd64/obj/home/sysbuild/src/crypto/external/bsd/openssl/lib/libcryptotest/libcryptotest.a
/dumps/sysbuild/amd64/obj/home/sysbuild/src/crypto/external/bsd/openssl/lib/libcrypto/libcrypto.a
${CTFMERGE} ${CTFMFLAGS} -o ${.TARGET} ${OBJS.${:Uh_ectest}}
=> /dumps/sysbuild/amd64/tools/bin/nbctfmerge -t -g -L VERSION
-o h_ectest ectest.o
...

now?

Chavdar


-- 

Re: Build failure - current

[Chavdar Ivanov]

On Sat, 29 Apr 2023 at 23:14, Robert Elz  wrote:
>
> Date:Sat, 29 Apr 2023 20:18:13 +0100
> From:    Chavdar Ivanov 
> Message-ID:  
> 
>
>
>   | KDTRACE_HOOKS undefined, SDT_PROBE2 and 4 define to _nothing, the
>   | abovementioned variables are used in the invocations of these
>   | macros...
>
> Working on it now.

It's fine now:

$ uname -a
NetBSD narvi 10.99.4 NetBSD 10.99.4 (GENERIC64) #2: Sun Apr 30
16:53:29 BST 2023
sysbu...@ymir.lorien.lan:/dumps/sysbuild/evbarm64/obj/home/sysbuild/src/sys/arch/evbarm/compile/GENERIC64
evbarm

>
> kre
>

Thanks



-- 

Re: Build failure - current

[Chavdar Ivanov]

On Sat, 29 Apr 2023 at 19:39, Chavdar Ivanov  wrote:
>
> Hi,
>
> I am getting:
> .
>
> #   compile  librumpvfs/vfs_subr.pico
> /dumps/sysbuild/evbarm64/tools/bin/aarch64--netbsd-gcc -O2
> -fno-delete-null-pointer-checks  -ffreestanding -fno-strict-aliasing
> -std=gnu99-Wall -Wstric
> t-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare
> -Wsystem-headers   -Wno-traditional   -Wa,--fatal-warnings
> -Wreturn-type -Wswitch -Wshad
> ow -Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter
> -Wno-sign-compare -Werror -Wno-format-zero-length -Wno-pointer-sign
> -fPIE   -I/home/sysbuild/sr
> c/lib/librumpvfs/../../sys/rump/include
> --sysroot=/dumps/sysbuild/evbarm64/destdir -D_RUMPKERNEL
> -I/home/sysbuild/src/lib/librumpvfs/../../sys/rump/librump/r
> umpkern -DCOMPAT_50 -DCOMPAT_60 -DCOMPAT_70 -DCOMPAT_80 -DCOMPAT_90
> -nostdinc -I/home/sysbuild/src/lib/librumpvfs -I.
> -I/home/sysbuild/src/lib/librumpvfs/../.
> ./sys/rump/../../common/include
> -I/home/sysbuild/src/lib/librumpvfs/../../sys/rump/include
> -I/home/sysbuild/src/lib/librumpvfs/../../sys/rump/include/opt -I/h
> ome/sysbuild/src/lib/librumpvfs/../../sys/rump/../arch
> -I/home/sysbuild/src/lib/librumpvfs/../../sys/rump/.. -DDIAGNOSTIC
> -DKTRACE  -imacros /home/sysbuild/sr
> c/lib/librumpvfs/../../sys/rump/include/opt/opt_rumpkernel.h  -c
> -fPIC   /home/sysbuild/src/lib/librumpvfs/../../sys/rump/../kern/vfs_subr.c
> -o vfs_subr.pi
> co
> /home/sysbuild/src/lib/librumpvfs/../../sys/rump/../kern/vfs_subr.c:
> In function 'vn_syncer_add_to_worklist':
> /home/sysbuild/src/lib/librumpvfs/../../sys/rump/../kern/vfs_subr.c:717:16:
> error: unused variable 'vip' [-Werror=unused-variable]
>   717 |  vnode_impl_t *vip = VNODE_TO_VIMPL(vp);
>   |^~~
> /home/sysbuild/src/lib/librumpvfs/../../sys/rump/../kern/vfs_subr.c:
> In function 'sched_sync':
> /home/sysbuild/src/lib/librumpvfs/../../sys/rump/../kern/vfs_subr.c:845:6:
> error: variable 'error' set but not used
> [-Werror=unused-but-set-variable]
>   845 |  int error;
>   |  ^
> /home/sysbuild/src/lib/librumpvfs/../../sys/rump/../kern/vfs_subr.c:843:14:
> error: variable 'oslot' set but not used
> [-Werror=unused-but-set-variable]
>   843 |  int vdelay, oslot, nslot, delayx;
>   |  ^
> cc1: all warnings being treated as errors
> *** Failed target: vfs_subr.pico

KDTRACE_HOOKS undefined, SDT_PROBE2 and 4 define to _nothing, the
abovementioned variables are used in the invocations of these
macros...

(at a cursory glance).

>
> 
>
> while building aarch64 -current.
>
> Chavdar
>
>
> --
> 



-- 

Build failure - current

[Chavdar Ivanov]

Hi,

I am getting:
.

#   compile  librumpvfs/vfs_subr.pico
/dumps/sysbuild/evbarm64/tools/bin/aarch64--netbsd-gcc -O2
-fno-delete-null-pointer-checks  -ffreestanding -fno-strict-aliasing
-std=gnu99-Wall -Wstric
t-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare
-Wsystem-headers   -Wno-traditional   -Wa,--fatal-warnings
-Wreturn-type -Wswitch -Wshad
ow -Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter
-Wno-sign-compare -Werror -Wno-format-zero-length -Wno-pointer-sign
-fPIE   -I/home/sysbuild/sr
c/lib/librumpvfs/../../sys/rump/include
--sysroot=/dumps/sysbuild/evbarm64/destdir -D_RUMPKERNEL
-I/home/sysbuild/src/lib/librumpvfs/../../sys/rump/librump/r
umpkern -DCOMPAT_50 -DCOMPAT_60 -DCOMPAT_70 -DCOMPAT_80 -DCOMPAT_90
-nostdinc -I/home/sysbuild/src/lib/librumpvfs -I.
-I/home/sysbuild/src/lib/librumpvfs/../.
./sys/rump/../../common/include
-I/home/sysbuild/src/lib/librumpvfs/../../sys/rump/include
-I/home/sysbuild/src/lib/librumpvfs/../../sys/rump/include/opt -I/h
ome/sysbuild/src/lib/librumpvfs/../../sys/rump/../arch
-I/home/sysbuild/src/lib/librumpvfs/../../sys/rump/.. -DDIAGNOSTIC
-DKTRACE  -imacros /home/sysbuild/sr
c/lib/librumpvfs/../../sys/rump/include/opt/opt_rumpkernel.h  -c
-fPIC   /home/sysbuild/src/lib/librumpvfs/../../sys/rump/../kern/vfs_subr.c
-o vfs_subr.pi
co
/home/sysbuild/src/lib/librumpvfs/../../sys/rump/../kern/vfs_subr.c:
In function 'vn_syncer_add_to_worklist':
/home/sysbuild/src/lib/librumpvfs/../../sys/rump/../kern/vfs_subr.c:717:16:
error: unused variable 'vip' [-Werror=unused-variable]
  717 |  vnode_impl_t *vip = VNODE_TO_VIMPL(vp);
  |^~~
/home/sysbuild/src/lib/librumpvfs/../../sys/rump/../kern/vfs_subr.c:
In function 'sched_sync':
/home/sysbuild/src/lib/librumpvfs/../../sys/rump/../kern/vfs_subr.c:845:6:
error: variable 'error' set but not used
[-Werror=unused-but-set-variable]
  845 |  int error;
  |  ^
/home/sysbuild/src/lib/librumpvfs/../../sys/rump/../kern/vfs_subr.c:843:14:
error: variable 'oslot' set but not used
[-Werror=unused-but-set-variable]
  843 |  int vdelay, oslot, nslot, delayx;
  |  ^
cc1: all warnings being treated as errors
*** Failed target: vfs_subr.pico



while building aarch64 -current.

Chavdar


-- 

Another exciting panic on today's --current amd64...

[Chavdar Ivanov]

Hi,

I got today:

Reader / writer lock error: rw_vector_exit,453: assertion failed:
RW_COUNT(rw) != 0

lock address : f040f988fa80
current cpu  :  2
current lwp  : 0xf040ea7ba780
owner/count  : 00 flags: 00

panic: lock error: Reader / writer lock: rw_vector_exit,453: assertion
failed: RW_COUNT(rw) != 0: lock 0xf040f988fa80 cpu 2 lwp
0xf040ea7ba780
cpu2: Begin traceback...
vpanic() at netbsd:vpanic+0x173
panic() at netbsd:panic+0x3c
lockdebug_abort() at netbsd:lockdebug_abort+0x114
rw_vector_exit() at netbsd:rw_vector_exit+0xcf
zfs_netbsd_getpages() at zfs:zfs_netbsd_getpages+0x364
VOP_GETPAGES() at netbsd:VOP_GETPAGES+0x58
uvm_fault_internal() at netbsd:uvm_fault_internal+0x18d9
trap() at netbsd:trap+0x480
--- trap (number 6) ---
7c2d2a20ce24:
cpu2: End traceback...


The last few panics I've had on this host were always around the
2.5GB/s Realtek adapter, but this is different apparently.

I doubt it is insufficient memory, it is a 16GB machine, but it was
building pkgsrc bits at the time.

Chavdar

-- 

Re: Panic on yesterday's -current amd64

[Chavdar Ivanov]

On Wed, 19 Apr 2023 at 12:37, Chavdar Ivanov  wrote:
>
> On Fri, 14 Apr 2023 at 10:09, Chavdar Ivanov  wrote:
> >
> > Hi,
> >
> > I got:
> > ..
> > Apr 14 00:28:34 ymir syslogd[2516]: restart
> >  [ 19830.9541169] panic: kernel diagnostic assertion "offset <
> > map->dm_mapsize" failed: file
> > "/home/sysbuild/src/sys/arch/x86/x86/bus_dma.c", line 826 bad offset
> > 0x0 >= 0x0
> >  [ 19830.9541169] cpu0: Begin traceback...
> >  [ 19830.9541169] vpanic() at netbsd:vpanic+0x173
> >  [ 19830.9541169] kern_assert() at netbsd:kern_assert+0x4b
> >  [ 19830.9541169] bus_dmamap_sync() at netbsd:bus_dmamap_sync+0x326
> >  [ 19830.9541169] rge_rxeof() at netbsd:rge_rxeof+0x179
> >  [ 19830.9541169] rge_intr() at netbsd:rge_intr+0x16f
> >  [ 19830.9541169] intr_biglock_wrapper() at netbsd:intr_biglock_wrapper+0x41
> >  [ 19830.9541169] Xhandle_ioapic_edge21() at 
> > netbsd:Xhandle_ioapic_edge21+0x75
> >  [ 19830.9641164] --- interrupt ---
> >  [ 19830.9641164] x86_mwait() at netbsd:x86_mwait+0xd
> >  [ 19830.9641164] acpicpu_cstate_idle() at netbsd:acpicpu_cstate_idle+0x19a
> >  [ 19830.9641164] idle_loop() at netbsd:idle_loop+0x14c
> >  [ 19830.9641164] cpu0: End traceback...
> >
> >  [ 19830.9641164] dumping to dev 168,2 (offset=8, size=4189743):
> >  [ 19830.9641164] dump [   1.000] Copyright (c) 1996, 1997, 1998,
> > 1999, 2000, 2001, 2002, 2003,
> > ...
> >
> > rge is a 2.5gb/s network adapter:
> > ...
> >  rge0 at pci7 dev 0 function 0: Realtek Semiconductor 8125
> > 10/100/1G/2.5G Ethernet (rev. 0x00)
> > rge0: interrupting at msix5 vec 0
> > rge0: Ethernet address 00:8e:25:79:05:3c
> > ...
> > which should not have been busy at the time; the system was close to
> > completing a full build of aarch64 -current.
> >
> > Chavdar
> >
> > --
> > 
>
> I am getting the same when I installed the image from releng -
>
> panic: kernel diagnostic assertion "offset < map->dm_mapsize" failed:
> file "/usr/src/sys/arch/x86/x86/bus_dma.c", line 826 bad offset 0x0 >=
> 0x0
> cpu0: Begin traceback...
> vpanic() at netbsd:vpanic+0x173
> kern_assert() at netbsd:kern_assert+0x4b
> bus_dmamap_sync() at netbsd:bus_dmamap_sync+0x326
> rge_rxeof() at netbsd:rge_rxeof+0x179
> rge_intr() at netbsd:rge_intr+0x16f
> intr_biglock_wrapper() at netbsd:intr_biglock_wrapper+0x41
> Xhandle_ioapic_edge21() at netbsd:Xhandle_ioapic_edge21+0x75
> --- interrupt ---
> x86_mwait() at netbsd:x86_mwait+0xd
> acpicpu_cstate_idle() at netbsd:acpicpu_cstate_idle+0x19a
> idle_loop() at netbsd:idle_loop+0x14c
> cpu0: End traceback...
>
> dumping to dev 168,2 (offset=8, size=4189743):
>
>
> # uname -a
> NetBSD ymir.lorien.lan 10.99.3 NetBSD 10.99.3 (GENERIC) #0: Mon Apr 17
> 20:37:43 UTC 2023
> mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
> amd64
>
> so it does not appear to be a problem with my own builds only.
>
> Chavdar
>
> --
> 
Another one this morning:
...
audio1(hdafg1): DIAGNOSTIC: hdafg1 raised stray interrupt
panic: kernel diagnostic assertion "offset < map->dm_mapsize" failed:
file "/home/sysbuild/src/sys/arch/x86/x86/bus_dma.c", line 826 bad
offset 0x0 >= 0x0
cpu0: Begin traceback...
vpanic() at netbsd:vpanic+0x173
kern_assert() at netbsd:kern_assert+0x4b
bus_dmamap_sync() at netbsd:bus_dmamap_sync+0x326
rge_rxeof() at netbsd:rge_rxeof+0x179
rge_intr() at netbsd:rge_intr+0x16f
intr_biglock_wrapper() at netbsd:intr_biglock_wrapper+0x41
Xhandle_ioapic_edge21() at netbsd:Xhandle_ioapic_edge21+0x75
--- interrupt ---
x86_mwait() at netbsd:x86_mwait+0xd
acpicpu_cstate_idle() at netbsd:acpicpu_cstate_idle+0x19a
idle_loop() at netbsd:idle_loop+0x14c
cpu0: End traceback...

dumping to dev 168,2 (offset=8, size=4189743):
...

They look the same, second time there was the hdafg1 warning, which
may not be relevant.

rge0 is

rge0 at pci7 dev 0 function 0: Realtek Semiconductor 8125
10/100/1G/2.5G Ethernet (rev. 0x00)


-- 

Re: Total sysupgrade failure - 10.99.3 -> 10.99.3, 4 days difference

[Chavdar Ivanov]

On Wed, 19 Apr 2023 at 14:47, Christos Zoulas  wrote:
>
> In article 
> ,
> Chavdar Ivanov   wrote:
> >On Tue, 18 Apr 2023 at 22:16, Chavdar Ivanov  wrote:
> >>
> >> Hi,
...
> >> 
>
> Yup, that was my fault. It was broken for a few hours and you caught it
> during that time. If it makes you feel any better I got bitten the same
> way, but thanks for /rescue :-)

No problem; -current is actually rather stable for a system in
constant development. It never came to my mind in the heat of the
moment that I have /rescue... although I have used it in the past; I
could have restored the base set and the kernel from my saved copy of
10.99.2. Anyway, the iso from releng was good and now I am rebuilding
again. The hardest thing was to remember which key activated the boot
menu choice of my system...

>
> christos
>


-- 

Re: Panic on yesterday's -current amd64

[Chavdar Ivanov]

On Fri, 14 Apr 2023 at 10:09, Chavdar Ivanov  wrote:
>
> Hi,
>
> I got:
> ..
> Apr 14 00:28:34 ymir syslogd[2516]: restart
>  [ 19830.9541169] panic: kernel diagnostic assertion "offset <
> map->dm_mapsize" failed: file
> "/home/sysbuild/src/sys/arch/x86/x86/bus_dma.c", line 826 bad offset
> 0x0 >= 0x0
>  [ 19830.9541169] cpu0: Begin traceback...
>  [ 19830.9541169] vpanic() at netbsd:vpanic+0x173
>  [ 19830.9541169] kern_assert() at netbsd:kern_assert+0x4b
>  [ 19830.9541169] bus_dmamap_sync() at netbsd:bus_dmamap_sync+0x326
>  [ 19830.9541169] rge_rxeof() at netbsd:rge_rxeof+0x179
>  [ 19830.9541169] rge_intr() at netbsd:rge_intr+0x16f
>  [ 19830.9541169] intr_biglock_wrapper() at netbsd:intr_biglock_wrapper+0x41
>  [ 19830.9541169] Xhandle_ioapic_edge21() at netbsd:Xhandle_ioapic_edge21+0x75
>  [ 19830.9641164] --- interrupt ---
>  [ 19830.9641164] x86_mwait() at netbsd:x86_mwait+0xd
>  [ 19830.9641164] acpicpu_cstate_idle() at netbsd:acpicpu_cstate_idle+0x19a
>  [ 19830.9641164] idle_loop() at netbsd:idle_loop+0x14c
>  [ 19830.9641164] cpu0: End traceback...
>
>  [ 19830.9641164] dumping to dev 168,2 (offset=8, size=4189743):
>  [ 19830.9641164] dump [   1.000] Copyright (c) 1996, 1997, 1998,
> 1999, 2000, 2001, 2002, 2003,
> ...
>
> rge is a 2.5gb/s network adapter:
> ...
>  rge0 at pci7 dev 0 function 0: Realtek Semiconductor 8125
> 10/100/1G/2.5G Ethernet (rev. 0x00)
> rge0: interrupting at msix5 vec 0
> rge0: Ethernet address 00:8e:25:79:05:3c
> ...
> which should not have been busy at the time; the system was close to
> completing a full build of aarch64 -current.
>
> Chavdar
>
> --
> 

I am getting the same when I installed the image from releng -

panic: kernel diagnostic assertion "offset < map->dm_mapsize" failed:
file "/usr/src/sys/arch/x86/x86/bus_dma.c", line 826 bad offset 0x0 >=
0x0
cpu0: Begin traceback...
vpanic() at netbsd:vpanic+0x173
kern_assert() at netbsd:kern_assert+0x4b
bus_dmamap_sync() at netbsd:bus_dmamap_sync+0x326
rge_rxeof() at netbsd:rge_rxeof+0x179
rge_intr() at netbsd:rge_intr+0x16f
intr_biglock_wrapper() at netbsd:intr_biglock_wrapper+0x41
Xhandle_ioapic_edge21() at netbsd:Xhandle_ioapic_edge21+0x75
--- interrupt ---
x86_mwait() at netbsd:x86_mwait+0xd
acpicpu_cstate_idle() at netbsd:acpicpu_cstate_idle+0x19a
idle_loop() at netbsd:idle_loop+0x14c
cpu0: End traceback...

dumping to dev 168,2 (offset=8, size=4189743):


# uname -a
NetBSD ymir.lorien.lan 10.99.3 NetBSD 10.99.3 (GENERIC) #0: Mon Apr 17
20:37:43 UTC 2023
mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
amd64

so it does not appear to be a problem with my own builds only.

Chavdar

-- 

Re: Total sysupgrade failure - 10.99.3 -> 10.99.3, 4 days difference

[Chavdar Ivanov]

On Tue, 18 Apr 2023 at 22:16, Chavdar Ivanov  wrote:
>
> Hi,
>
> I do my builds with sysbuild and my upgrades with sysupgrade, many
> years now, basically since these two tools were made available. I
> haven't had much problems with them so far.
>
> My previous build was from 14th of April and worked just fine. Today I
> did another one, after completing a two day pkg-rolling-replace, and
> got:
> 
> 100% 
> |*|
> 43015 KiB8.57 MiB/s00:00 ETA
> sysupgrade: I: Extracting comp into /
> /usr/lib/libc.so.12: Undefined symbol "_libc_init" (symnum = 3700)
> sysupgrade: I: Extracting games into /
> ...
> /usr/lib/libc.so.12: Undefined symbol "_libc_init" (symnum = 3700)
> sysupgrade: I: Extracting xserver into /
> /usr/lib/libc.so.12: Undefined symbol "_libc_init" (symnum = 3700)
> sysupgrade: I: Upgrading /etc interactively
> /bin/sh: Undefined symbol "optreset" (symnum = 16)
> sysupgrade: I: Performing postinstall checks
> /bin/sh: Undefined symbol "optreset" (symnum = 16)
> /bin/sh: Undefined symbol "optreset" (symnum = 16)
> sysupgrade: E: Some postinstall(8) checks have failed
> ..
> # sh
>
>sh: Undefined symbol "optreset" (symnum = 16)
> # /sbin/zpool status
>
> /sbin/zpool: Undefined symbol "suboptarg" (symnum = 17)
> # /sbin/reboot
>
>  /lib/libutil.so.7: Undefined symbol "ifm_type_descriptions" (symnum =
> 6)
> 
>
> and basically nothing works. This was my second build of the day, the
> first one failed as the destination directory still contained the
> remnants of lua 5.3, so I deleted them and repeated the build, with
> iso, live and install system, which completed to end.
>
>
> Any ideas? Or should I wipe the root disk and start afresh?
>
> Chavdar
>
> --
> 

I was able to easily recover using the image from releng and restoring
only the kernel and base; I then further tested the bad installation
and indeed, the cd boot also panics, so I might have caught the update
in a wrong place.

I guess I should first test the newly created ISO on a virtual machine
before attempting sysupgrade...


-- 

Total sysupgrade failure - 10.99.3 -> 10.99.3, 4 days difference

[Chavdar Ivanov]

Hi,

I do my builds with sysbuild and my upgrades with sysupgrade, many
years now, basically since these two tools were made available. I
haven't had much problems with them so far.

My previous build was from 14th of April and worked just fine. Today I
did another one, after completing a two day pkg-rolling-replace, and
got:

100% 
|*|
43015 KiB8.57 MiB/s00:00 ETA
sysupgrade: I: Extracting comp into /
/usr/lib/libc.so.12: Undefined symbol "_libc_init" (symnum = 3700)
sysupgrade: I: Extracting games into /
...
/usr/lib/libc.so.12: Undefined symbol "_libc_init" (symnum = 3700)
sysupgrade: I: Extracting xserver into /
/usr/lib/libc.so.12: Undefined symbol "_libc_init" (symnum = 3700)
sysupgrade: I: Upgrading /etc interactively
/bin/sh: Undefined symbol "optreset" (symnum = 16)
sysupgrade: I: Performing postinstall checks
/bin/sh: Undefined symbol "optreset" (symnum = 16)
/bin/sh: Undefined symbol "optreset" (symnum = 16)
sysupgrade: E: Some postinstall(8) checks have failed
..
# sh

   sh: Undefined symbol "optreset" (symnum = 16)
# /sbin/zpool status

/sbin/zpool: Undefined symbol "suboptarg" (symnum = 17)
# /sbin/reboot

 /lib/libutil.so.7: Undefined symbol "ifm_type_descriptions" (symnum =
6)


and basically nothing works. This was my second build of the day, the
first one failed as the destination directory still contained the
remnants of lua 5.3, so I deleted them and repeated the build, with
iso, live and install system, which completed to end.


Any ideas? Or should I wipe the root disk and start afresh?

Chavdar

-- 

Re: shells/fish non-functional under -current amd64

[Chavdar Ivanov]

On Mon, 17 Apr 2023 at 06:30, RVP  wrote:
>
> On Mon, 17 Apr 2023, Chavdar Ivanov wrote:
>
> > I am getting consistently:
> > ...
> > Reading symbols from /usr/pkg/bin/fish...
> > (No debugging symbols found in /usr/pkg/bin/fish)
> > [New process 22165]
> > [New process 17293]
> > [New process 512]
> > Core was generated by `fish'.
> > Program terminated with signal SIGSEGV, Segmentation fault.
> > #0  0x778907cc4f13 in _ti_parm_analyse () from /usr/lib/libterminfo.so.2
> > [Current thread is 1 (process 22165)]
> > (gdb) bt
> > #0  0x778907cc4f13 in _ti_parm_analyse () from /usr/lib/libterminfo.so.2
> >
>
> Can you try this patch? Not sure that the ARM failure has the same
> underlying cause.
>
> ```
> diff -urN fish-3.6.1.orig/cmake/ConfigureChecks.cmake 
> fish-3.6.1/cmake/ConfigureChecks.cmake
> --- fish-3.6.1.orig/cmake/ConfigureChecks.cmake 2023-03-25 06:50:41.0 
> +
> +++ fish-3.6.1/cmake/ConfigureChecks.cmake  2023-04-17 05:24:06.879329819 
> +
> @@ -76,7 +76,7 @@
>   # Fix undefined reference to tparm on RHEL 6 and potentially others
>   # If curses is found via CMake, it also links against tinfo if it exists. 
> But if we use our
>   # fallback pkg-config logic above, we need to do this manually.
> -find_library(CURSES_TINFO tinfo)
> +find_library(CURSES_TINFO NAMES tinfo terminfo)
>   if (CURSES_TINFO)
>   set(CURSES_LIBRARY ${CURSES_LIBRARY} ${CURSES_TINFO})
>   endif()
> ```
>
> -RVP

It didn't make any difference on both architectures.

I suspect it would not be news if I say that pkgsrc build of fish
under Ubuntu aarch64 works just fine.

Chavdar




-- 

shells/fish non-functional under -current amd64

[Chavdar Ivanov]

Hi,

I am getting consistently:
...
Reading symbols from /usr/pkg/bin/fish...
(No debugging symbols found in /usr/pkg/bin/fish)
[New process 22165]
[New process 17293]
[New process 512]
Core was generated by `fish'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x778907cc4f13 in _ti_parm_analyse () from /usr/lib/libterminfo.so.2
[Current thread is 1 (process 22165)]
(gdb) bt
#0  0x778907cc4f13 in _ti_parm_analyse () from /usr/lib/libterminfo.so.2
#1  0x778907cc504d in ?? () from /usr/lib/libterminfo.so.2
#2  0x778907cc5da4 in ?? () from /usr/lib/libterminfo.so.2
#3  0x010a75d0 in ?? ()
#4  0x010a4244 in ?? ()
#5  0x010a5191 in ?? ()
#6  0x01150732 in ?? ()
#7  0x0101063d in ?? ()
#8  0x7f7ff7198860 in ?? () from /usr/libexec/ld.elf_so
#9  0x0001 in ?? ()
#10 0x7f7fff478540 in ?? ()
#11 0x in ?? ()
..

on shells/fish immediately after starting it, on -current amd64 from a
couple of days ago.

It also crashes under -current aarch64, the trace looks like this:


Reading symbols from /usr/pkg/bin/fish...
(No debugging symbols found in /usr/pkg/bin/fish)
[New process 3768]
Core was generated by `fish'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0xfd5647dbdd9c in strlen () from /usr/lib/libc.so.12
(gdb) bt
#0  0xfd5647dbdd9c in strlen () from /usr/lib/libc.so.12
#1  0x0e262214 in ?? ()
#2  0x0e18433c in ?? ()
#3  0x0e151d74 in ?? ()
#4  0x0e252fec in ?? ()
#5  0x0e133a38 in ?? ()
#6  0xef2e0b10 in _rtld_start () from /usr/libexec/ld.elf_so
Backtrace stopped: previous frame identical to this frame (corrupt stack?)


At least it is consistent...

Both systems are from the 13th of April:

$ uname -a
NetBSD ymir.lorien.lan 10.99.3 NetBSD 10.99.3 (GENERIC) #3: Thu Apr 13
14:24:47 BST 2023
sysbu...@ymir.lorien.lan:/dumps/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC
amd64
...
 uname -a
NetBSD narvi 10.99.3 NetBSD 10.99.3 (GENERIC64) #1: Thu Apr 13
23:29:03 BST 2023
sysbu...@ymir.lorien.lan:/dumps/sysbuild/evbarm64/obj/home/sysbuild/src/sys/arch/evbarm/compile/GENERIC64
evbarm
...

Chavdar



-- 

Panic on yesterday's -current amd64

[Chavdar Ivanov]

Hi,

I got:
..
Apr 14 00:28:34 ymir syslogd[2516]: restart
 [ 19830.9541169] panic: kernel diagnostic assertion "offset <
map->dm_mapsize" failed: file
"/home/sysbuild/src/sys/arch/x86/x86/bus_dma.c", line 826 bad offset
0x0 >= 0x0
 [ 19830.9541169] cpu0: Begin traceback...
 [ 19830.9541169] vpanic() at netbsd:vpanic+0x173
 [ 19830.9541169] kern_assert() at netbsd:kern_assert+0x4b
 [ 19830.9541169] bus_dmamap_sync() at netbsd:bus_dmamap_sync+0x326
 [ 19830.9541169] rge_rxeof() at netbsd:rge_rxeof+0x179
 [ 19830.9541169] rge_intr() at netbsd:rge_intr+0x16f
 [ 19830.9541169] intr_biglock_wrapper() at netbsd:intr_biglock_wrapper+0x41
 [ 19830.9541169] Xhandle_ioapic_edge21() at netbsd:Xhandle_ioapic_edge21+0x75
 [ 19830.9641164] --- interrupt ---
 [ 19830.9641164] x86_mwait() at netbsd:x86_mwait+0xd
 [ 19830.9641164] acpicpu_cstate_idle() at netbsd:acpicpu_cstate_idle+0x19a
 [ 19830.9641164] idle_loop() at netbsd:idle_loop+0x14c
 [ 19830.9641164] cpu0: End traceback...

 [ 19830.9641164] dumping to dev 168,2 (offset=8, size=4189743):
 [ 19830.9641164] dump [   1.000] Copyright (c) 1996, 1997, 1998,
1999, 2000, 2001, 2002, 2003,
...

rge is a 2.5gb/s network adapter:
...
 rge0 at pci7 dev 0 function 0: Realtek Semiconductor 8125
10/100/1G/2.5G Ethernet (rev. 0x00)
rge0: interrupting at msix5 vec 0
rge0: Ethernet address 00:8e:25:79:05:3c
...
which should not have been busy at the time; the system was close to
completing a full build of aarch64 -current.

Chavdar

-- 

Re: Panic on today's -current aarch64 on Qemu (Oracle OCI VM)

[Chavdar Ivanov]

With the last few updates by yamaguchi@ and mlelstv@ it again works.

Thanks for the quick response,

Chavdar

On Sat, 25 Mar 2023 at 08:15, Shoichi Yamaguchi  wrote:
>
> Sorry, it is my mistake and thank you for your report.
> I think the problem has been fixed because I added a change.
>
>
> On Sat, Mar 25, 2023 at 7:54 AM Chavdar Ivanov  wrote:
> >
> > kern/57292: GENERIC64 virtio panic on aarch64
> >
> >  - in case somebody is interested.
> >
> > I'll try to reproduce it locally under Qemu.
> >
> > On Fri, 24 Mar 2023 at 22:39, Chavdar Ivanov  wrote:
> > >
> > > I am talking to myself again...
> > >
> > > I did my "bisection" - the kernel from
> > > http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/202303221210Z/ works
> > > fine,
> > > the kernel from
> > > http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/202303231250Z/ -
> > > crashes.
> > >
> > > I should file a pr.
> > >
> > > On Fri, 24 Mar 2023 at 22:10, Chavdar Ivanov  wrote:
> > > >
> > > > On Fri, 24 Mar 2023 at 20:54, Chavdar Ivanov  wrote:
> > > > >
> > > > > On Fri, 24 Mar 2023 at 19:09, Chavdar Ivanov  wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > My OCI NetBSD aarch64 instance did a doobie today after carrying a
> > > > > > clean build as follows:
> > > > > > .
> > > > > > shutdown: [pid 11239]
> > > > > >
> > > > > >   \\-__,--,___.
> > > > > >\\__,---`  NetBSD/evbarm efiboot (arm64)
> > > > > > \\   `---,_.  Revision 2.13 (Thu Jan 19 05:06:49 UTC 2023)
> > > > > >  \\-,_,.---`
> > > > > >   \\
> > > > > >\\
> > > > > > \\
> > > > > >
> > > > > > Press return to boot now, any other key for boot prompt
> > > > > > booting netbsd - starting in 0 seconds.
> > > > > > 8547120+3683568+4183008+1742616 [56+1183824+708887]=0x16053c8
> > > > > > GOP: PixelBltOnly pixel format not supported
> > > > > > GOP: PixelBltOnly pixel format not supported
> > > > > > [   1.000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 
> > > > > > 2002, 2003,
> > > > > > [   1.000] 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 
> > > > > > 2012, 2013,
> > > > > > [   1.000] 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 
> > > > > > 2022, 2023
> > > > > > [   1.000] The NetBSD Foundation, Inc.  All rights reserved.
> > > > > > [   1.000] Copyright (c) 1982, 1986, 1989, 1991, 1993
> > > > > > [   1.000] The Regents of the University of California.  All
> > > > > > rights reserved.
> > > > > >
> > > > > > [   1.000] NetBSD 10.99.2 (GENERIC64) #0: Fri Mar 24 17:22:56 
> > > > > > GMT 2023
> > > > > > [   1.000]
> > > > > > sysbu...@ymir.lorien.lan:/home/sysbuild/sysbuild/evbarm64/obj/home/sysbuild/src/sys/arch/evbarm/compile/GENERIC64
> > > > > > [   1.000] total memory = 12261 MB
> > > > > > [   1.000] avail memory = 11820 MB
> > > > > > [   1.000] armfdt0 (root)
> > > > > > [   1.000] armfdt0: using EFI runtime services for RTC
> > > > > > [   1.000] simplebus0 at armfdt0: QEMU KVM Virtual Machine
> > > > > > [   1.000] simplebus1 at simplebus0
> > > > > > [   1.000] acpifdt0 at simplebus0
> > > > > > [   1.000] acpifdt0: SMBIOS rev. 3.0.0 @ 0x33bec
> > > > > > [   1.000] ACPI: RSDP 0x0003385F0018 24 (v02 BOCHS )
> > > > > > [   1.000] ACPI: XSDT 0x0003385FFE98 5C (v01 BOCHS
> > > > > > BXPCFACP 0001  0113)
> > > > > > [   1.000] ACPI: FACP 0x0003385FFA98 00010C (v05 BOCHS
> > > > > > BXPCFACP 0001 BXPC 0001)
> > > > > > [   1.000] ACPI: DSDT 0x0003385F7518 004842 (v02 BOCHS
> > > > > > BXPCDSDT 0001 BXPC 0001)
> > > > > > [   1.000] ACPI: APIC 0x0003385FFC18 000100 (v03 BOCHS
> > > > > > BXPCAPIC 0001 BXPC 0001)
> > > 

Re: Panic on today's -current aarch64 on Qemu (Oracle OCI VM)

[Chavdar Ivanov]

kern/57292: GENERIC64 virtio panic on aarch64

 - in case somebody is interested.

I'll try to reproduce it locally under Qemu.

On Fri, 24 Mar 2023 at 22:39, Chavdar Ivanov  wrote:
>
> I am talking to myself again...
>
> I did my "bisection" - the kernel from
> http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/202303221210Z/ works
> fine,
> the kernel from
> http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/202303231250Z/ -
> crashes.
>
> I should file a pr.
>
> On Fri, 24 Mar 2023 at 22:10, Chavdar Ivanov  wrote:
> >
> > On Fri, 24 Mar 2023 at 20:54, Chavdar Ivanov  wrote:
> > >
> > > On Fri, 24 Mar 2023 at 19:09, Chavdar Ivanov  wrote:
> > > >
> > > > Hi,
> > > >
> > > > My OCI NetBSD aarch64 instance did a doobie today after carrying a
> > > > clean build as follows:
> > > > .
> > > > shutdown: [pid 11239]
> > > >
> > > >   \\-__,--,___.
> > > >\\__,---`  NetBSD/evbarm efiboot (arm64)
> > > > \\   `---,_.  Revision 2.13 (Thu Jan 19 05:06:49 UTC 2023)
> > > >  \\-,_,.---`
> > > >   \\
> > > >\\
> > > > \\
> > > >
> > > > Press return to boot now, any other key for boot prompt
> > > > booting netbsd - starting in 0 seconds.
> > > > 8547120+3683568+4183008+1742616 [56+1183824+708887]=0x16053c8
> > > > GOP: PixelBltOnly pixel format not supported
> > > > GOP: PixelBltOnly pixel format not supported
> > > > [   1.000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 
> > > > 2003,
> > > > [   1.000] 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 
> > > > 2012, 2013,
> > > > [   1.000] 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 
> > > > 2022, 2023
> > > > [   1.000] The NetBSD Foundation, Inc.  All rights reserved.
> > > > [   1.000] Copyright (c) 1982, 1986, 1989, 1991, 1993
> > > > [   1.000] The Regents of the University of California.  All
> > > > rights reserved.
> > > >
> > > > [   1.000] NetBSD 10.99.2 (GENERIC64) #0: Fri Mar 24 17:22:56 GMT 
> > > > 2023
> > > > [   1.000]
> > > > sysbu...@ymir.lorien.lan:/home/sysbuild/sysbuild/evbarm64/obj/home/sysbuild/src/sys/arch/evbarm/compile/GENERIC64
> > > > [   1.000] total memory = 12261 MB
> > > > [   1.000] avail memory = 11820 MB
> > > > [   1.000] armfdt0 (root)
> > > > [   1.000] armfdt0: using EFI runtime services for RTC
> > > > [   1.000] simplebus0 at armfdt0: QEMU KVM Virtual Machine
> > > > [   1.000] simplebus1 at simplebus0
> > > > [   1.000] acpifdt0 at simplebus0
> > > > [   1.000] acpifdt0: SMBIOS rev. 3.0.0 @ 0x33bec
> > > > [   1.000] ACPI: RSDP 0x0003385F0018 24 (v02 BOCHS )
> > > > [   1.000] ACPI: XSDT 0x0003385FFE98 5C (v01 BOCHS
> > > > BXPCFACP 0001  0113)
> > > > [   1.000] ACPI: FACP 0x0003385FFA98 00010C (v05 BOCHS
> > > > BXPCFACP 0001 BXPC 0001)
> > > > [   1.000] ACPI: DSDT 0x0003385F7518 004842 (v02 BOCHS
> > > > BXPCDSDT 0001 BXPC 0001)
> > > > [   1.000] ACPI: APIC 0x0003385FFC18 000100 (v03 BOCHS
> > > > BXPCAPIC 0001 BXPC 0001)
> > > > [   1.000] ACPI: GTDT 0x0003385FFD98 60 (v02 BOCHS
> > > > BXPCGTDT 0001 BXPC 0001)
> > > > [   1.000] ACPI: MCFG 0x0003385FFF98 3C (v01 BOCHS
> > > > BXPCMCFG 0001 BXPC 0001)
> > > > [   1.000] ACPI: SPCR 0x0003385FE998 50 (v02 BOCHS
> > > > BXPCSPCR 0001 BXPC 0001)
> > > > [   1.000] ACPI: IORT 0x0003385FF898 7C (v00 BOCHS
> > > > BXPCIORT 0001 BXPC 0001)
> > > > [   1.000] ACPI: BGRT 0x0003385FF998 38 (v01 INTEL  EDK2
> > > >   0002  0113)
> > > > [   1.000] ACPI: 1 ACPI AML tables successfully acquired and loaded
> > > > [   1.000] acpi0 at acpifdt0: Intel ACPICA 20221020
> > > > [   1.000] cpu0 at acpi0: Arm Neoverse N1 r3p1 (v8.2-A+), id 0x0
> > > > [   1.000] cpu0: package 0, core 0, smt 0
> > > > [   1.000] cpu1 at acpi0: Arm Neoverse N1 r3p1 (v8.2-A+), id 0x1
> > > > [   1.000] cpu1: package 0, core 1, smt 0
> > > > [   

Re: Panic on today's -current aarch64 on Qemu (Oracle OCI VM)

[Chavdar Ivanov]

I am talking to myself again...

I did my "bisection" - the kernel from
http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/202303221210Z/ works
fine,
the kernel from
http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/202303231250Z/ -
crashes.

I should file a pr.

On Fri, 24 Mar 2023 at 22:10, Chavdar Ivanov  wrote:
>
> On Fri, 24 Mar 2023 at 20:54, Chavdar Ivanov  wrote:
> >
> > On Fri, 24 Mar 2023 at 19:09, Chavdar Ivanov  wrote:
> > >
> > > Hi,
> > >
> > > My OCI NetBSD aarch64 instance did a doobie today after carrying a
> > > clean build as follows:
> > > .
> > > shutdown: [pid 11239]
> > >
> > >   \\-__,--,___.
> > >\\__,---`  NetBSD/evbarm efiboot (arm64)
> > > \\   `---,_.  Revision 2.13 (Thu Jan 19 05:06:49 UTC 2023)
> > >  \\-,_,.---`
> > >   \\
> > >\\
> > > \\
> > >
> > > Press return to boot now, any other key for boot prompt
> > > booting netbsd - starting in 0 seconds.
> > > 8547120+3683568+4183008+1742616 [56+1183824+708887]=0x16053c8
> > > GOP: PixelBltOnly pixel format not supported
> > > GOP: PixelBltOnly pixel format not supported
> > > [   1.000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 
> > > 2003,
> > > [   1.000] 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 
> > > 2013,
> > > [   1.000] 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022, 
> > > 2023
> > > [   1.000] The NetBSD Foundation, Inc.  All rights reserved.
> > > [   1.000] Copyright (c) 1982, 1986, 1989, 1991, 1993
> > > [   1.000] The Regents of the University of California.  All
> > > rights reserved.
> > >
> > > [   1.000] NetBSD 10.99.2 (GENERIC64) #0: Fri Mar 24 17:22:56 GMT 2023
> > > [   1.000]
> > > sysbu...@ymir.lorien.lan:/home/sysbuild/sysbuild/evbarm64/obj/home/sysbuild/src/sys/arch/evbarm/compile/GENERIC64
> > > [   1.000] total memory = 12261 MB
> > > [   1.000] avail memory = 11820 MB
> > > [   1.000] armfdt0 (root)
> > > [   1.000] armfdt0: using EFI runtime services for RTC
> > > [   1.000] simplebus0 at armfdt0: QEMU KVM Virtual Machine
> > > [   1.000] simplebus1 at simplebus0
> > > [   1.000] acpifdt0 at simplebus0
> > > [   1.000] acpifdt0: SMBIOS rev. 3.0.0 @ 0x33bec
> > > [   1.000] ACPI: RSDP 0x0003385F0018 24 (v02 BOCHS )
> > > [   1.000] ACPI: XSDT 0x0003385FFE98 5C (v01 BOCHS
> > > BXPCFACP 0001  0113)
> > > [   1.000] ACPI: FACP 0x0003385FFA98 00010C (v05 BOCHS
> > > BXPCFACP 0001 BXPC 0001)
> > > [   1.000] ACPI: DSDT 0x0003385F7518 004842 (v02 BOCHS
> > > BXPCDSDT 0001 BXPC 0001)
> > > [   1.000] ACPI: APIC 0x0003385FFC18 000100 (v03 BOCHS
> > > BXPCAPIC 0001 BXPC 0001)
> > > [   1.000] ACPI: GTDT 0x0003385FFD98 60 (v02 BOCHS
> > > BXPCGTDT 0001 BXPC 0001)
> > > [   1.000] ACPI: MCFG 0x0003385FFF98 3C (v01 BOCHS
> > > BXPCMCFG 0001 BXPC 0001)
> > > [   1.000] ACPI: SPCR 0x0003385FE998 50 (v02 BOCHS
> > > BXPCSPCR 0001 BXPC 0001)
> > > [   1.000] ACPI: IORT 0x0003385FF898 7C (v00 BOCHS
> > > BXPCIORT 0001 BXPC 0001)
> > > [   1.000] ACPI: BGRT 0x0003385FF998 38 (v01 INTEL  EDK2
> > >   0002  0113)
> > > [   1.000] ACPI: 1 ACPI AML tables successfully acquired and loaded
> > > [   1.000] acpi0 at acpifdt0: Intel ACPICA 20221020
> > > [   1.000] cpu0 at acpi0: Arm Neoverse N1 r3p1 (v8.2-A+), id 0x0
> > > [   1.000] cpu0: package 0, core 0, smt 0
> > > [   1.000] cpu1 at acpi0: Arm Neoverse N1 r3p1 (v8.2-A+), id 0x1
> > > [   1.000] cpu1: package 0, core 1, smt 0
> > > [   1.000] gicvthree0 at acpi0: GICv3
> > > [   1.000] gicvthree0: ITS #0 at 0x808
> > > [   1.000] gicvthree0: ITS [#0] Devices table @
> > > 0x5a0b/0x8, Cacheable WA WB, Inner shareable
> > > [   1.000] gicvthree0: ITS [#1] Collections table @
> > > 0x5a13/0x1, Cacheable WA WB, Inner shareable
> > > [   1.000] gtmr0 at acpi0: irq 27
> > > [   1.000] armgtmr0 at gtmr0: Generic Timer (25000 kHz, virtual)
> > > [   1.040] C000 (ACPI0007) at acpi0 not configured
> > > [   1.040] C001 (ACPI0007) at a

Re: Panic on today's -current aarch64 on Qemu (Oracle OCI VM)

[Chavdar Ivanov]

On Fri, 24 Mar 2023 at 20:54, Chavdar Ivanov  wrote:
>
> On Fri, 24 Mar 2023 at 19:09, Chavdar Ivanov  wrote:
> >
> > Hi,
> >
> > My OCI NetBSD aarch64 instance did a doobie today after carrying a
> > clean build as follows:
> > .
> > shutdown: [pid 11239]
> >
> >   \\-__,--,___.
> >\\__,---`  NetBSD/evbarm efiboot (arm64)
> > \\   `---,_.  Revision 2.13 (Thu Jan 19 05:06:49 UTC 2023)
> >  \\-,_,.---`
> >   \\
> >\\
> > \\
> >
> > Press return to boot now, any other key for boot prompt
> > booting netbsd - starting in 0 seconds.
> > 8547120+3683568+4183008+1742616 [56+1183824+708887]=0x16053c8
> > GOP: PixelBltOnly pixel format not supported
> > GOP: PixelBltOnly pixel format not supported
> > [   1.000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003,
> > [   1.000] 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 
> > 2013,
> > [   1.000] 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022, 
> > 2023
> > [   1.000] The NetBSD Foundation, Inc.  All rights reserved.
> > [   1.000] Copyright (c) 1982, 1986, 1989, 1991, 1993
> > [   1.000] The Regents of the University of California.  All
> > rights reserved.
> >
> > [   1.000] NetBSD 10.99.2 (GENERIC64) #0: Fri Mar 24 17:22:56 GMT 2023
> > [   1.000]
> > sysbu...@ymir.lorien.lan:/home/sysbuild/sysbuild/evbarm64/obj/home/sysbuild/src/sys/arch/evbarm/compile/GENERIC64
> > [   1.000] total memory = 12261 MB
> > [   1.000] avail memory = 11820 MB
> > [   1.000] armfdt0 (root)
> > [   1.000] armfdt0: using EFI runtime services for RTC
> > [   1.000] simplebus0 at armfdt0: QEMU KVM Virtual Machine
> > [   1.000] simplebus1 at simplebus0
> > [   1.000] acpifdt0 at simplebus0
> > [   1.000] acpifdt0: SMBIOS rev. 3.0.0 @ 0x33bec
> > [   1.000] ACPI: RSDP 0x0003385F0018 24 (v02 BOCHS )
> > [   1.000] ACPI: XSDT 0x0003385FFE98 5C (v01 BOCHS
> > BXPCFACP 0001  0113)
> > [   1.000] ACPI: FACP 0x0003385FFA98 00010C (v05 BOCHS
> > BXPCFACP 0001 BXPC 0001)
> > [   1.000] ACPI: DSDT 0x0003385F7518 004842 (v02 BOCHS
> > BXPCDSDT 0001 BXPC 0001)
> > [   1.000] ACPI: APIC 0x0003385FFC18 000100 (v03 BOCHS
> > BXPCAPIC 0001 BXPC 0001)
> > [   1.000] ACPI: GTDT 0x0003385FFD98 60 (v02 BOCHS
> > BXPCGTDT 0001 BXPC 0001)
> > [   1.000] ACPI: MCFG 0x0003385FFF98 3C (v01 BOCHS
> > BXPCMCFG 0001 BXPC 0001)
> > [   1.000] ACPI: SPCR 0x0003385FE998 50 (v02 BOCHS
> > BXPCSPCR 0001 BXPC 0001)
> > [   1.000] ACPI: IORT 0x0003385FF898 7C (v00 BOCHS
> > BXPCIORT 0001 BXPC 0001)
> > [   1.000] ACPI: BGRT 0x0003385FF998 38 (v01 INTEL  EDK2
> >   0002  0113)
> > [   1.000] ACPI: 1 ACPI AML tables successfully acquired and loaded
> > [   1.000] acpi0 at acpifdt0: Intel ACPICA 20221020
> > [   1.000] cpu0 at acpi0: Arm Neoverse N1 r3p1 (v8.2-A+), id 0x0
> > [   1.000] cpu0: package 0, core 0, smt 0
> > [   1.000] cpu1 at acpi0: Arm Neoverse N1 r3p1 (v8.2-A+), id 0x1
> > [   1.000] cpu1: package 0, core 1, smt 0
> > [   1.000] gicvthree0 at acpi0: GICv3
> > [   1.000] gicvthree0: ITS #0 at 0x808
> > [   1.000] gicvthree0: ITS [#0] Devices table @
> > 0x5a0b/0x8, Cacheable WA WB, Inner shareable
> > [   1.000] gicvthree0: ITS [#1] Collections table @
> > 0x5a13/0x1, Cacheable WA WB, Inner shareable
> > [   1.000] gtmr0 at acpi0: irq 27
> > [   1.000] armgtmr0 at gtmr0: Generic Timer (25000 kHz, virtual)
> > [   1.040] C000 (ACPI0007) at acpi0 not configured
> > [   1.040] C001 (ACPI0007) at acpi0 not configured
> > [   1.040] plcom0 at acpi0 (COM0, ARMH0011-0): mem
> > 0x900-0x9000fff irq 33
> > [   1.040] plcom0: txfifo 16 bytes
> > [   1.040] plcom0: console
> > [   1.040] FLS0 (LNRO0015) at acpi0 not configured
> > [   1.040] FLS1 (LNRO0015) at acpi0 not configured
> > [   1.040] qemufwcfg0 at acpi0 (FWCF, QEMU0002): mem 0x902-0x9020017
> > [   1.040] virtio0 at acpi0 (VR00, LNRO0005-0): mem
> > 0xa00-0xa0001ff irq 48
> > [   1.040] virtio1 at acpi0 (VR01, LNRO0005-1): mem
> > 0xa000200-0xa0003ff irq 49
> > [   1.040] virtio2 at acpi0 (VR02, LNRO0005-2): mem
> > 0xa000400-0xa0005ff irq 50

Re: Panic on today's -current aarch64 on Qemu (Oracle OCI VM)

[Chavdar Ivanov]

On Fri, 24 Mar 2023 at 19:09, Chavdar Ivanov  wrote:
>
> Hi,
>
> My OCI NetBSD aarch64 instance did a doobie today after carrying a
> clean build as follows:
> .
> shutdown: [pid 11239]
>
>   \\-__,--,___.
>\\__,---`  NetBSD/evbarm efiboot (arm64)
> \\   `---,_.  Revision 2.13 (Thu Jan 19 05:06:49 UTC 2023)
>  \\-,_,.---`
>   \\
>\\
> \\
>
> Press return to boot now, any other key for boot prompt
> booting netbsd - starting in 0 seconds.
> 8547120+3683568+4183008+1742616 [56+1183824+708887]=0x16053c8
> GOP: PixelBltOnly pixel format not supported
> GOP: PixelBltOnly pixel format not supported
> [   1.000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003,
> [   1.000] 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013,
> [   1.000] 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022, 2023
> [   1.000] The NetBSD Foundation, Inc.  All rights reserved.
> [   1.000] Copyright (c) 1982, 1986, 1989, 1991, 1993
> [   1.000] The Regents of the University of California.  All
> rights reserved.
>
> [   1.000] NetBSD 10.99.2 (GENERIC64) #0: Fri Mar 24 17:22:56 GMT 2023
> [   1.000]
> sysbu...@ymir.lorien.lan:/home/sysbuild/sysbuild/evbarm64/obj/home/sysbuild/src/sys/arch/evbarm/compile/GENERIC64
> [   1.000] total memory = 12261 MB
> [   1.000] avail memory = 11820 MB
> [   1.000] armfdt0 (root)
> [   1.000] armfdt0: using EFI runtime services for RTC
> [   1.000] simplebus0 at armfdt0: QEMU KVM Virtual Machine
> [   1.000] simplebus1 at simplebus0
> [   1.000] acpifdt0 at simplebus0
> [   1.000] acpifdt0: SMBIOS rev. 3.0.0 @ 0x33bec
> [   1.000] ACPI: RSDP 0x0003385F0018 24 (v02 BOCHS )
> [   1.000] ACPI: XSDT 0x0003385FFE98 5C (v01 BOCHS
> BXPCFACP 0001  0113)
> [   1.000] ACPI: FACP 0x0003385FFA98 00010C (v05 BOCHS
> BXPCFACP 0001 BXPC 0001)
> [   1.000] ACPI: DSDT 0x0003385F7518 004842 (v02 BOCHS
> BXPCDSDT 0001 BXPC 0001)
> [   1.000] ACPI: APIC 0x0003385FFC18 000100 (v03 BOCHS
> BXPCAPIC 0001 BXPC 0001)
> [   1.000] ACPI: GTDT 0x0003385FFD98 60 (v02 BOCHS
> BXPCGTDT 0001 BXPC 0001)
> [   1.000] ACPI: MCFG 0x0003385FFF98 3C (v01 BOCHS
> BXPCMCFG 0001 BXPC 0001)
> [   1.000] ACPI: SPCR 0x0003385FE998 50 (v02 BOCHS
> BXPCSPCR 0001 BXPC 0001)
> [   1.000] ACPI: IORT 0x0003385FF898 7C (v00 BOCHS
> BXPCIORT 0001 BXPC 0001)
> [   1.000] ACPI: BGRT 0x0003385FF998 38 (v01 INTEL  EDK2
>   0002  0113)
> [   1.000] ACPI: 1 ACPI AML tables successfully acquired and loaded
> [   1.000] acpi0 at acpifdt0: Intel ACPICA 20221020
> [   1.000] cpu0 at acpi0: Arm Neoverse N1 r3p1 (v8.2-A+), id 0x0
> [   1.000] cpu0: package 0, core 0, smt 0
> [   1.000] cpu1 at acpi0: Arm Neoverse N1 r3p1 (v8.2-A+), id 0x1
> [   1.000] cpu1: package 0, core 1, smt 0
> [   1.000] gicvthree0 at acpi0: GICv3
> [   1.000] gicvthree0: ITS #0 at 0x808
> [   1.000] gicvthree0: ITS [#0] Devices table @
> 0x5a0b/0x8, Cacheable WA WB, Inner shareable
> [   1.000] gicvthree0: ITS [#1] Collections table @
> 0x5a13/0x1, Cacheable WA WB, Inner shareable
> [   1.000] gtmr0 at acpi0: irq 27
> [   1.000] armgtmr0 at gtmr0: Generic Timer (25000 kHz, virtual)
> [   1.040] C000 (ACPI0007) at acpi0 not configured
> [   1.040] C001 (ACPI0007) at acpi0 not configured
> [   1.040] plcom0 at acpi0 (COM0, ARMH0011-0): mem
> 0x900-0x9000fff irq 33
> [   1.040] plcom0: txfifo 16 bytes
> [   1.040] plcom0: console
> [   1.040] FLS0 (LNRO0015) at acpi0 not configured
> [   1.040] FLS1 (LNRO0015) at acpi0 not configured
> [   1.040] qemufwcfg0 at acpi0 (FWCF, QEMU0002): mem 0x902-0x9020017
> [   1.040] virtio0 at acpi0 (VR00, LNRO0005-0): mem
> 0xa00-0xa0001ff irq 48
> [   1.040] virtio1 at acpi0 (VR01, LNRO0005-1): mem
> 0xa000200-0xa0003ff irq 49
> [   1.040] virtio2 at acpi0 (VR02, LNRO0005-2): mem
> 0xa000400-0xa0005ff irq 50
> [   1.040] virtio3 at acpi0 (VR03, LNRO0005-3): mem
> 0xa000600-0xa0007ff irq 51
> [   1.040] virtio4 at acpi0 (VR04, LNRO0005-4): mem
> 0xa000800-0xa0009ff irq 52
> [   1.040] virtio5 at acpi0 (VR05, LNRO0005-5): mem
> 0xa000a00-0xa000bff irq 53
> [   1.040] virtio6 at acpi0 (VR06, LNRO0005-6): mem
> 0xa000c00-0xa000dff irq 54
> [   1.040] virtio7 at acpi0 (VR07, LNRO0005-7): mem
> 0xa000e00-0xa000fff irq 55
> [   1.040] virtio8 at acpi0 (VR08, LNRO0005-8): 

Panic on today's -current aarch64 on Qemu (Oracle OCI VM)

[Chavdar Ivanov]

Hi,

My OCI NetBSD aarch64 instance did a doobie today after carrying a
clean build as follows:
.
shutdown: [pid 11239]

  \\-__,--,___.
   \\__,---`  NetBSD/evbarm efiboot (arm64)
\\   `---,_.  Revision 2.13 (Thu Jan 19 05:06:49 UTC 2023)
 \\-,_,.---`
  \\
   \\
\\

Press return to boot now, any other key for boot prompt
booting netbsd - starting in 0 seconds.
8547120+3683568+4183008+1742616 [56+1183824+708887]=0x16053c8
GOP: PixelBltOnly pixel format not supported
GOP: PixelBltOnly pixel format not supported
[   1.000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003,
[   1.000] 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013,
[   1.000] 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022, 2023
[   1.000] The NetBSD Foundation, Inc.  All rights reserved.
[   1.000] Copyright (c) 1982, 1986, 1989, 1991, 1993
[   1.000] The Regents of the University of California.  All
rights reserved.

[   1.000] NetBSD 10.99.2 (GENERIC64) #0: Fri Mar 24 17:22:56 GMT 2023
[   1.000]
sysbu...@ymir.lorien.lan:/home/sysbuild/sysbuild/evbarm64/obj/home/sysbuild/src/sys/arch/evbarm/compile/GENERIC64
[   1.000] total memory = 12261 MB
[   1.000] avail memory = 11820 MB
[   1.000] armfdt0 (root)
[   1.000] armfdt0: using EFI runtime services for RTC
[   1.000] simplebus0 at armfdt0: QEMU KVM Virtual Machine
[   1.000] simplebus1 at simplebus0
[   1.000] acpifdt0 at simplebus0
[   1.000] acpifdt0: SMBIOS rev. 3.0.0 @ 0x33bec
[   1.000] ACPI: RSDP 0x0003385F0018 24 (v02 BOCHS )
[   1.000] ACPI: XSDT 0x0003385FFE98 5C (v01 BOCHS
BXPCFACP 0001  0113)
[   1.000] ACPI: FACP 0x0003385FFA98 00010C (v05 BOCHS
BXPCFACP 0001 BXPC 0001)
[   1.000] ACPI: DSDT 0x0003385F7518 004842 (v02 BOCHS
BXPCDSDT 0001 BXPC 0001)
[   1.000] ACPI: APIC 0x0003385FFC18 000100 (v03 BOCHS
BXPCAPIC 0001 BXPC 0001)
[   1.000] ACPI: GTDT 0x0003385FFD98 60 (v02 BOCHS
BXPCGTDT 0001 BXPC 0001)
[   1.000] ACPI: MCFG 0x0003385FFF98 3C (v01 BOCHS
BXPCMCFG 0001 BXPC 0001)
[   1.000] ACPI: SPCR 0x0003385FE998 50 (v02 BOCHS
BXPCSPCR 0001 BXPC 0001)
[   1.000] ACPI: IORT 0x0003385FF898 7C (v00 BOCHS
BXPCIORT 0001 BXPC 0001)
[   1.000] ACPI: BGRT 0x0003385FF998 38 (v01 INTEL  EDK2
  0002  0113)
[   1.000] ACPI: 1 ACPI AML tables successfully acquired and loaded
[   1.000] acpi0 at acpifdt0: Intel ACPICA 20221020
[   1.000] cpu0 at acpi0: Arm Neoverse N1 r3p1 (v8.2-A+), id 0x0
[   1.000] cpu0: package 0, core 0, smt 0
[   1.000] cpu1 at acpi0: Arm Neoverse N1 r3p1 (v8.2-A+), id 0x1
[   1.000] cpu1: package 0, core 1, smt 0
[   1.000] gicvthree0 at acpi0: GICv3
[   1.000] gicvthree0: ITS #0 at 0x808
[   1.000] gicvthree0: ITS [#0] Devices table @
0x5a0b/0x8, Cacheable WA WB, Inner shareable
[   1.000] gicvthree0: ITS [#1] Collections table @
0x5a13/0x1, Cacheable WA WB, Inner shareable
[   1.000] gtmr0 at acpi0: irq 27
[   1.000] armgtmr0 at gtmr0: Generic Timer (25000 kHz, virtual)
[   1.040] C000 (ACPI0007) at acpi0 not configured
[   1.040] C001 (ACPI0007) at acpi0 not configured
[   1.040] plcom0 at acpi0 (COM0, ARMH0011-0): mem
0x900-0x9000fff irq 33
[   1.040] plcom0: txfifo 16 bytes
[   1.040] plcom0: console
[   1.040] FLS0 (LNRO0015) at acpi0 not configured
[   1.040] FLS1 (LNRO0015) at acpi0 not configured
[   1.040] qemufwcfg0 at acpi0 (FWCF, QEMU0002): mem 0x902-0x9020017
[   1.040] virtio0 at acpi0 (VR00, LNRO0005-0): mem
0xa00-0xa0001ff irq 48
[   1.040] virtio1 at acpi0 (VR01, LNRO0005-1): mem
0xa000200-0xa0003ff irq 49
[   1.040] virtio2 at acpi0 (VR02, LNRO0005-2): mem
0xa000400-0xa0005ff irq 50
[   1.040] virtio3 at acpi0 (VR03, LNRO0005-3): mem
0xa000600-0xa0007ff irq 51
[   1.040] virtio4 at acpi0 (VR04, LNRO0005-4): mem
0xa000800-0xa0009ff irq 52
[   1.040] virtio5 at acpi0 (VR05, LNRO0005-5): mem
0xa000a00-0xa000bff irq 53
[   1.040] virtio6 at acpi0 (VR06, LNRO0005-6): mem
0xa000c00-0xa000dff irq 54
[   1.040] virtio7 at acpi0 (VR07, LNRO0005-7): mem
0xa000e00-0xa000fff irq 55
[   1.040] virtio8 at acpi0 (VR08, LNRO0005-8): mem
0xa001000-0xa0011ff irq 56
[   1.040] virtio9 at acpi0 (VR09, LNRO0005-9): mem
0xa001200-0xa0013ff irq 57
[   1.040] virtio10 at acpi0 (VR10, LNRO0005-10): mem
0xa001400-0xa0015ff irq 58
[   1.040] virtio11 at acpi0 (VR11, LNRO0005-11): mem
0xa001600-0xa0017ff irq 59
[   1.040] virtio12 at acpi0 (VR12, LNRO0005-12): mem
0xa001800-0xa0019ff irq 60
[   1.040] virtio13 at acpi0 (VR13, LNRO0005-13): mem
0xa001a00-0xa001bff irq 61
[   1.040] virtio14 at acpi0 (VR14, LNRO0005-14): mem
0xa001c00-0xa001dff irq 62
[   

Re: GENERIC64 aarch64 failure to autoboot

[Chavdar Ivanov]

On Sun, 5 Mar 2023 at 22:03, Michael van Elst  wrote:
>
> On Sun, Mar 05, 2023 at 10:56:31PM +0100, Michael van Elst wrote:
> > On Mon, Mar 06, 2023 at 07:44:20AM +1030, Brett Lymn wrote:
> > > On Sun, Mar 05, 2023 at 03:01:02PM -, Michael van Elst wrote:
> > > >
> > > > - if (guid != NULL && len == 16)
> > > > + if (guid == NULL || len == 16)
> > > > +
> > >
> > > Shouldn't that be "len != 16"?
> >
> > Yes, and another error. The wedge device is 'dv' not 'dev'.
> >
> > Here is a patch that works for me:
>
> The first hunk was another local change. Please ignore.


I used the previous patch with the first hunk, it worked for me.

Thanks for the quick response.

Chavdar

> Here is without:
>
>
> Index: sys/arch/evbarm/fdt/fdt_machdep.c
> ===
> RCS file: /cvsroot/src/sys/arch/evbarm/fdt/fdt_machdep.c,v
> retrieving revision 1.100
> diff -p -u -r1.100 fdt_machdep.c
> --- sys/arch/evbarm/fdt/fdt_machdep.c   5 Feb 2023 22:42:39 -   1.100
> +++ sys/arch/evbarm/fdt/fdt_machdep.c   5 Mar 2023 21:59:49 -
> @@ -743,9 +743,6 @@ fdt_detect_root_device(device_t dev)
>  {
> int error, len;
>
> -   if (booted_device)
> -   return;
> -
> const int chosen = OF_finddevice("/chosen");
> if (chosen < 0)
> return;
> @@ -801,8 +798,15 @@ fdt_detect_root_device(device_t dev)
> const struct uuid *guid =
> fdtbus_get_prop(chosen, "netbsd,gpt-guid", );
>
> -   if (guid != NULL && len == 16)
> -   booted_device = dev;
> +   if (guid == NULL || len != 16)
> +   return;
> +
> +   char guidstr[UUID_STR_LEN];
> +   uuid_snprintf(guidstr, sizeof(guidstr), guid);
> +
> +   device_t dv = dkwedge_find_by_wname(guidstr);
> +   if (dv != NULL)
> +   booted_device = dv;
>
> return;
> }
> @@ -895,8 +899,7 @@ fdt_cpu_rootconf(void)
> if (device_class(dev) != DV_DISK)
> continue;
>
> -   if (device_is_a(dev, "ld") || device_is_a(dev, "sd") || 
> device_is_a(dev, "wd"))
> -   fdt_detect_root_device(dev);
> +   fdt_detect_root_device(dev);
>
> if (booted_device != NULL)
> break;



-- 

Re: GENERIC64 aarch64 failure to autoboot

[Chavdar Ivanov]

On Sun, 5 Mar 2023 at 15:01, Michael van Elst  wrote:
>
> mlel...@serpens.de (Michael van Elst) writes:
>
> >On Sun, Mar 05, 2023 at 12:56:29PM +, Chavdar Ivanov wrote:
> >[   1.3797015] dk0 at sd0: "EFI system", 262144 blocks at 2048, type:
> >msdos
> >[   1.3897890] dk1 at sd0: "cc8f4a89-edc0-48d1-b9ce-b40d227a4a07",
> >> netbsd,gpt-guid 894a8fcc c0edd148 b9ceb40d 227a4a07   
> >> .J.H"zJ.
>
> >Means, the bootloader passes dk1 as the boot device.
> >But the code only checks "ld", "sd" and "wd" devices:
>
>
> This might help (compile tested only):


It didn't, unfortunately. Copy/paste from the mail message didn't work
as a patch, I guess the usual tabs vs. spaces, so I applied it
manually and rebuilt, getting the same:

[   1.7028470] sd0: fabricating a geometry
[   1.7028470] sd0: 47694 MB, 47694 cyl, 64 head, 32 sec, 512
bytes/sect x 97677312 sectors
[   1.7228509] sd0: fabricating a geometry
[   1.7329004] dk0 at sd0: "EFI system", 262144 blocks at 2048, type: msdos
[   1.7429382] dk1 at sd0: "cc8f4a89-edc0-48d1-b9ce-b40d227a4a07",
97411072 blocks at 264192, type: ffs
[   1.7629942] sd0: async, 8-bit transfers, tagged queueing
[   2.1331596] uhidev0 at uhub1 port 1 configuration 1 interface 0
[   2.1432296] uhidev0: QEMU (0x0627) QEMU USB Keyboard (0x0001), rev
2.00/0.00, addr 1, iclass 3/1
[   2.1633250] ukbd0 at uhidev0
[   2.1633250] wskbd0 at ukbd0 mux 1
[   2.5836221] uhidev1 at uhub1 port 2 configuration 1 interface 0
[   2.5937434] uhidev1: QEMU (0x0627) QEMU USB Mouse (0x0001), rev
2.00/0.00, addr 2, iclass 3/1
[   2.6137849] ums0 at uhidev1: 3 buttons and Z dir
[   2.6137849] wsmouse0 at ums0 mux 0
[   3.0340582] uhidev2 at uhub1 port 3 configuration 1 interface 0
[   3.0441520] uhidev2: QEMU (0x0627) QEMU USB Tablet (0x0001), rev
2.00/0.00, addr 3, iclass 3/0
[   3.0541618] ums1 at uhidev2: 3 buttons and Z dir
[   3.0657830] wsmouse1 at ums1 mux 0
[   3.0657830] swwdog0: software watchdog initialized
[   3.0743900] WARNING: 1 error while detecting hardware; check system log.
[   3.0884404] boot device: 
[   3.0884404] root device: dk1< manually entered, as before.
[   4.8980356] dump device:
[   5.0748269] file system (default generic):
[   5.9316952] root on dk1
[   5.9316952] root file system type: ffs
[   5.9316952] kern.module.path=/stand/evbarm/10.99.2/modules
[   5.9416986] init path (default /sbin/init):
[   6.9224038] init: trying /sbin/init
...

>
>
> Index: sys/arch/evbarm/fdt/fdt_machdep.c
> ===
> RCS file: /cvsroot/src/sys/arch/evbarm/fdt/fdt_machdep.c,v
> retrieving revision 1.100
> diff -p -u -r1.100 fdt_machdep.c
> --- sys/arch/evbarm/fdt/fdt_machdep.c   5 Feb 2023 22:42:39 -   1.100
> +++ sys/arch/evbarm/fdt/fdt_machdep.c   5 Mar 2023 14:55:41 -
> @@ -743,9 +743,6 @@ fdt_detect_root_device(device_t dev)
>  {
> int error, len;
>
> -   if (booted_device)
> -   return;
> -
> const int chosen = OF_finddevice("/chosen");
> if (chosen < 0)
> return;
> @@ -801,7 +798,14 @@ fdt_detect_root_device(device_t dev)
> const struct uuid *guid =
> fdtbus_get_prop(chosen, "netbsd,gpt-guid", );
>
> -   if (guid != NULL && len == 16)
> +   if (guid == NULL || len == 16)
> +   return;
> +
> +   char guidstr[UUID_STR_LEN];
> +   uuid_snprintf(guidstr, sizeof(guidstr), guid);
> +
> +   device_t dv = dkwedge_find_by_wname(guidstr);
> +   if (dv != NULL)
> booted_device = dev;
>
> return;
> @@ -895,8 +899,7 @@ fdt_cpu_rootconf(void)
> if (device_class(dev) != DV_DISK)
> continue;
>
> -   if (device_is_a(dev, "ld") || device_is_a(dev, "sd") || 
> device_is_a(dev, "wd"))
> -   fdt_detect_root_device(dev);
> +   fdt_detect_root_device(dev);
>
> if (booted_device != NULL)
> break;
>
>


-- 

Re: GENERIC64 aarch64 failure to autoboot

[Chavdar Ivanov]

On Sun, 5 Mar 2023 at 12:24, matthew green  wrote:
>
> Chavdar Ivanov writes:
> > On Sat, 4 Mar 2023 at 23:30, Michael van Elst  wrote:
> > >
> > > ci4...@gmail.com (Chavdar Ivanov) writes:
> > >
> > > >Since my last aarch64 build yesterday, 03/03/2023, my machine no
> > > >longer boots automatically,
> > >
> > > sys/arch/evbarm/fdt/fdt_machdep.c 1.100
> > >
> > > changed how the boot disk is determined. Apparently it now fails for you.
> >
> > That's right, I rebuilt it with 1.99 and it now boots as before.
> >
> > I guess I'll file a pr.
>
> on the system that didn't auto-boot properly, can you answer the ask
> root prompt dk1 like it should, and once it is booted up, show the
> result of "drvctl -p dk1" and also "ofctl -p /chosen"?

Yes, here they are:

# drvctl -p dk1
Properties for device `dk1':

http://www.apple.com/DTDs/PropertyList-1.0.dtd;>


device-driver
dk
device-unit
0x1
disk-info

geometry

cylinders-per-unit
0xb9cc
sector-size
0x200
sectors-per-track
0x20
sectors-per-unit
0x5ce6000
tracks-per-cylinder
0x40






[Caching 3 nodes and 18 properties]
name63686f73 656e00..     "chosen"
netbsd,acpi-root-table  0003 385f0018     8_..
netbsd,gpt-guid 894a8fcc c0edd148 b9ceb40d 227a4a07   .J.H"zJ.
netbsd,smbios-table 0003 3bed     ;...
netbsd,uefi-memmap  0007  4000    @...
0010:   002f60ac  0008 0002   ./`.
0020:   0003 360ac000  2438   6.$8
0030:    0008 0001 0003   
0040:   384e4000  002d    8N@-
0050:   0008 0003 0003 38511000   8Q..
0060:    00df  0008   
0070:   0009 0003 385f    8_..
0080:   0010  0008 0007   
0090:   0003 3860  0006   8`..
00a0:    0008 0003 0003   
00b0:   38606000  00aa    8``.
00c0:   0008 0006 0003 386b   8k..
00d0:    0050 8000 0008   ...P
00e0:   0005 0003 3870    8p..
00f0:   0050 8000 0008 0006   ...P
0100:   0003 3875  0050   8u.P
0110:   8000 0008 0005 0003   
0120:   387a  0050 8000   8z.P
0130:   0008 0006 0003 387f   8...
0140:    00c0 8000 0008   
0150:   0005 0003 388b    8...
0160:   0060 8000 0008 0006   ...`
0170:   0003 3891  00a0   8...
0180:   8000 0008 0005 0003   
0190:   389b  0050 8000   8..P
01a0:   0008 0006 0003 38a0   8...
01b0:    0050 8000 0008   ...P
01c0:   0005 0003 38a5    8...
01d0:   00f0 8000 0008 0007   
01e0:   0003 38b4  0002   8...
01f0:    0008 0002 0003   
0200:   38b42000  0002    8. .
0210:   0008 0007 0003 38b44000   8.@.
0220:    1730  0008   ...0
0230:   0004 0003 3a274000    :'@.
0240:   077e  0008 0007   ...~
0250:   0003 3a9f2000  0001   :. .
0260:    0008 0004 0003   
0270:   3a

Re: GENERIC64 aarch64 failure to autoboot

[Chavdar Ivanov]

On Sat, 4 Mar 2023 at 23:30, Michael van Elst  wrote:
>
> ci4...@gmail.com (Chavdar Ivanov) writes:
>
> >Since my last aarch64 build yesterday, 03/03/2023, my machine no
> >longer boots automatically,
>
> sys/arch/evbarm/fdt/fdt_machdep.c 1.100
>
> changed how the boot disk is determined. Apparently it now fails for you.

That's right, I rebuilt it with 1.99 and it now boots as before.

I guess I'll file a pr.

>
>
>

Thanks,

Chavdar

-- 

GENERIC64 aarch64 failure to autoboot

[Chavdar Ivanov]

Hi,

I may have mentioned in some earlier mail to the list that I am
running a (free) instance on Oracle OCI of aarch64 NetBSD-current
machine. As there is no foreign OS support for the free instances
there, following a suggestion elsewhere on this list, I was able to
overwrite the boot disk of a Ubuntu guest with the live-image of an
aarch64 NetBSD-current guest. All went well; I proceeded with pkgsrc
etc. and have done several sysupgrades - using sysutil/sysupgrade on
manually transferred kernel and sets directories,all this without a
problem, actually very much recommended to anyone who wants to have a
decent AARCH64 QEMU free instance in the cloud - up to 24GB/4cores is
actually free, no problem with networking etc.

Since my last aarch64 build yesterday, 03/03/2023, my machine no
longer boots automatically, it cannot see its root disk and I have to
connect to the serial console one gets on OCI and select the boot disk
manually. There is no change on the cloud side, as I can still boot
onetbsd and it proceeds as before. The interesting diffs in the
process follow:

 -kernel from 30/01/2023--
[   1.3495762] sd0: fabricating a geometry
[   1.3654912] sd0: 47694 MB, 47694 cyl, 64 head, 32 sec, 512
bytes/sect x 97677312 sectors
[   1.3696969] sd0: fabricating a geometry
[   1.3797015] dk0 at sd0: "EFI system", 262144 blocks at 2048, type: msdos
[   1.3897890] dk1 at sd0: "cc8f4a89-edc0-48d1-b9ce-b40d227a4a07",
97411072 blocks at 264192, type: ffs
[   1.4097270] sd0: async, 8-bit transfers, tagged queueing
..
[   3.2743726] boot device: 
[   3.2743726] root on dk1
[   3.2743726] root file system type: ffs
[   3.2843774] kern.module.path=/stand/evbarm/10.99.2/modules
Sat Mar  4 12:41:17 UTC 2023
Starting root file system check:
/dev/rdk1: file system is clean; not checking
Not resizing / (NAME=cc8f4a89-edc0-48d1-b9ce-b40d227a4a07): already correct size
Setting sysctl variables:
ddb.onpanic: 1 -> 0

kernel from 03/03/2023-
[   1.7012844] sd0 at scsibus0 target 0 lun 1:  disk fixed
[   1.7235943] sd0: fabricating a geometry
[   1.7235943] sd0: 47694 MB, 47694 cyl, 64 head, 32 sec, 512
bytes/sect x 97677312 sectors
[   1.7330480] sd0: fabricating a geometry
[   1.7330480] dk0 at sd0: "EFI system", 262144 blocks at 2048, type: msdos
[   1.7330480] dk1 at sd0: "cc8f4a89-edc0-48d1-b9ce-b40d227a4a07",
97411072 blocks at 264192, type: ffs
[   1.7431542] sd0: async, 8-bit transfers, tagged queueing
...
[   3.0014644] boot device: sd0
[   3.0014644] root on sd0a dumps on sd0b
[   3.0121746] vfs_mountroot: can't open root device
[   3.0226157] cannot mount root, error = 16
[   3.0226157] root device (default sd0a): list
[   8.0440822] use one of: dk0 dk1 vioif0 sd0[a-p] wedge:EFI system
wedge:cc8f4a89-edc0-48d1-b9ce-b40d227a4a07 ddb halt reboot
[   8.0440822] root device (default sd0a): dk1
[  10.0516176] dump device:
[  10.1093156] file system (default generic):
[  10.7765265] root on dk1
[  10.7765265] root file system type: ffs
[  10.7865339] kern.module.path=/stand/evbarm/10.99.2/modules
[  10.7886598] init path (default /sbin/init):
[  12.7982026] init: trying /sbin/init
Sat Mar  4 12:50:15 UTC 2023
Starting root file system check:



GENERIC64 diffs:

 cvs diff -u -r 1.207 -r 1.210 GENERIC64
Index: GENERIC64
===
RCS file: /cvsroot/src/sys/arch/evbarm/conf/GENERIC64,v
retrieving revision 1.207
retrieving revision 1.210
diff -u -r1.207 -r1.210
--- GENERIC64   24 Dec 2022 15:46:50 -  1.207
+++ GENERIC64   25 Feb 2023 08:19:35 -  1.210
@@ -1,5 +1,5 @@
 #
-#  $NetBSD: GENERIC64,v 1.207 2022/12/24 15:46:50 nia Exp $
+#  $NetBSD: GENERIC64,v 1.210 2023/02/25 08:19:35 skrll Exp $
 #
 #  GENERIC ARM (aarch64) kernel
 #
@@ -47,7 +47,9 @@
 #options   EARLYCONS=sunxi, CONSADDR=0x01c28000
 #options   EARLYCONS=tegra, CONSADDR=0x70006000
 #options   EARLYCONS=thunderx, CONSADDR=0x87e02400
-#options   EARLYCONS=virt, CONSADDR=0x0900
+
+# The QEMU virt machine
+#options   EARLYCONS=plcom, CONSADDR=0x0900

 # Hardware management of the Access flag and dirty state (HAFDBS).
 optionsARMV81_HAFDBS
@@ -412,6 +414,7 @@
 ahcisata*  at fdt? # AHCI SATA
 ahcisata*  at acpi?
 ahcisata*  at pci? dev ? function ?
+siisata*   at pci? dev ? function ?
 atabus*at ata?
 atapibus*  at atapi?
 wd*at atabus? drive ?
@@ -561,4 +564,5 @@
 scsibus*   at scsi?
 sd*at scsibus? target ? lun ?  # SCSI disk drives

-cinclude "arch/evbarm/conf/GENERIC64.local"
+# Pull in optional local configuration - always at end
+cinclude   "arch/evbarm/conf/GENERIC64.local"

So the kernel that boots OK says that the boot device is unknown,
whereas the new one incorrectly identifies sd0 as the boot device - it
should be dk1, or whatever the NAME is (the fstab has NAME=...
identifying dk1).

Re: AMDGPU Driver patches/bugs

[Chavdar Ivanov]

FYI I tried amdgpu driver today on a fresh -current amd64 post the
above mentioned patches, using FirePro W5000; Xorg (system) started
fine and looked to be working well, but firefox 109.1 froze the
machine when I tried the benchmark from http://cad.onshape.com/check -
no crash, dark screen, no respond to ping. With the radeon driver this
hardware performs next to perfect for me - this test gives some 60
million triangles and lines per second. The radeon driver also returns
some 5000 points on glmark2; I didn't do a second attempt with the
amdgpu though - it probably would have froze again.

On Tue, 21 Feb 2023 at 22:23, Taylor R Campbell  wrote:
>
> > Date: Tue, 21 Feb 2023 13:20:13 -0800
> > From: Jeff Frasca 
> >
> > I was going to try the radeon driver again, because I want to see if
> > my wayland compositor works better against it than the AMDGPU driver
> > (I'm getting some weird corruption problems with my compositor that
> > do not happen under Linux, but that's probably my code).
>
> We have seen other weird minor graphics corruption problems with X,
> even with xcompmgr or picom running.  I probably made another stupid
> bug, maybe in cacheability attributes or something, buried somewhere
> in the megabytes of diffs...
>
> > I'll send the FP stuff to tech-kern and CC you.  For the PRs, that's
> > the sendpr.cgi on netbsd.org, right?
>
> Sure, https://gnats.NetBSD.org -> report a new bug, which goes to some
> sendpr.cgi URL, or send-pr(1) if you like to do things from a local
> mailer (but it requires a working local mailer which can make outgoing
> SMTP connections, often blocked on residential networks).



-- 

OpenJDK 1[17] on 11.99.2 aarch64

[Chavdar Ivanov]

Hi, 



Is that combination supposed to work? There is no apparent block in 
-current pkgsrc, but I am getting - on any attempt to run the bootstrap 
java as follows:





 ./work/bootstrap/bin/java --version
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xf543dca31350, pid=10935, tid=269671831519232
#
# JRE version:  (17.0.3) (build )
# Java VM: OpenJDK 64-Bit Server VM 
(17.0.3-internal+0-adhoc.pkgsrc.jdk17u-jdk-17.0.3-7-1, mixed mode, tiered, 
compressed oops, compressed class ptrs, g1 gc, bsd-aarch64)

# Problematic frame:
# V  [libjvm.so+0x951350]  JVM_RaiseSignal+0x1b61a8
#
# No core dump will be written. Core dumps have been disabled. To enable 
core dumping, try "ulimit -c unlimited" before starting Java again

#
# An error report file with more information is saved as:
# /usr/pkgsrc/lang/openjdk17/hs_err_pid10935.log
#


  


The mentioned .log file starts with:

...



#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xf543dca31350, pid=10935, tid=269671831519232
#
# JRE version:  (17.0.3) (build )
# Java VM: OpenJDK 64-Bit Server VM 
(17.0.3-internal+0-adhoc.pkgsrc.jdk17u-jdk-17.0.3-7-1, mixed mode, tiered, 
compressed oops, compressed class ptrs, g1 gc, bsd-aarch64)

# Problematic frame:
# V  [libjvm.so+0x951350]  JVM_RaiseSignal+0x1b61a8
#
# No core dump will be written. Core dumps have been disabled. To enable 
core dumping, try "ulimit -c unlimited" before starting Java again

#
#

---  S U M M A R Y 

Command Line:

Host: netbsd,generic-acpi evbarm, 2 cores, 11G, NetBSD 10.99.2
Time: Fri Jan 27 19:28:26 2023 UTC elapsed time: 0.043550 seconds (0d 0h 0m 
0s)


---  T H R E A D  ---

Current thread (0xf543dda4f000):  JavaThread "Unknown thread" 
[_thread_in_vm, id=17666, stack(0xf543dbee,0xf543dc0e)]


Stack: [0xf543dbee,0xf543dc0e],  sp=0xf543dc0df780,  
free space=2045k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
code)

V  [libjvm.so+0x951350]  JVM_RaiseSignal+0x1b61a8
V  [libjvm.so+0x9538b8]  JVM_RaiseSignal+0x1b8710
V  [libjvm.so+0x9541d4]  JVM_RaiseSignal+0x1b902c
V  [libjvm.so+0xad0928]  JVM_RaiseSignal+0x335780
V  [libjvm.so+0xac8f44]  JVM_RaiseSignal+0x32dd9c
V  [libjvm.so+0x6b9f0c]  AsyncGetCallTrace+0xddcbc
V  [libjvm.so+0xbba760]  JVM_handle_bsd_signal+0x95588
V  [libjvm.so+0x7657b4]  JNI_CreateJavaVM+0x94
C  [libjli.so+0x46d0]  JLI_AddArgsFromEnvVar+0x1290
C  [libjli.so+0x7ecc]  JLI_Launch+0x1d64
C  [libpthread.so.1+0xdc14]  __libc_thr_exit+0x160


siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 
0x


 

(I tried to bootstrap sbcl using clisp, which turned out broken on aarch64 
as the Makefiles suggests, then I remeberred that I previously did its 
bootstrap using pkgsrc abcl under aarch64 ubuntu, so I tried to build abcl 
under the NetBSD combination, sans success). 

  
--


Chavdar Ivanov

Re: Kernel config options for drm [ Was Re: No HDMI output... ]

[Chavdar Ivanov]

On 06 January 2023 19:16:56 (+00:00), Chavdar Ivanov wrote:

> 
> 
> On 06 January 2023 16:51:09 (+00:00), Mayuresh wrote:
> 
> > > It works as close to perfect as one can desire. 
cad.onshape.com/check

> > > returns some tens of millions tri/sec under the latest firefox. No
> > > graphics artifacts whatsoever.
> > > Can you tell a bit more about cad.onshape.com? I can see it in 
"Measuring
> > performance" state for long. Not sure what it is supposed to be 
reporting

> > and after how long.
> 
> See https://youtu.be/ycVPG1jl-uY  (I just uploaded it, I will publish 
the same test using different graphics hardware, browser and OS).


After a brief hiatus following the changes in the run-time loader my laptop 
can again run X under yesterday's build. I was able to take a few 
benchmarks and demos using obs, which I've published here - 
https://youtube.com/playlist?list=PLTBH64F3FJLo9OlR5hQBk68OcOmdYU2UE . They 
are not particularly interesting, but basically demonstrate that NetBSD can 
be successfully used as a graphics workstation, when utilising one of the 
supported graphics hardware. 

The only - unrelated - problem I am having with it is with the Synaptics 
touchpad - it works fine, with the exception that when a button is pressed, 
it stops sending any position information to the server, unless one is 
using the same finger used for the press (it doesn't have physical 
buttons), so to drag a window, I have to press with one finger, keep it 
pressed and move it around... Normally one would press with the finger of 
the left hand and move it around using a finger from the right hand (I am 
right-handed). I tried with both the mouse and the ws driver, it is the 
same; perhaps there is a workaround I don't know about.
  

> It takes less than a minute. 

> > 


--

Chavdar Ivanov

Re: Very recent NetBSD-current Xorg panic

[Chavdar Ivanov]

On 08 January 2023 12:15:12 (+00:00), Martin Husemann wrote:

> On Sun, Jan 08, 2023 at 11:28:18AM +0000, Chavdar Ivanov wrote:
> > This morning I upgraded the instance to my yesterday's build - as of
> > 07/01/2023. Now Xorg dumps core as follows:
> 
> Can you show the output of
> 
>   readelf -l /usr/X11R7/lib/modules/dri/i965_dri.so
> 
> for the new build? It probably has 4 LOAD sections now, while the old

> one only had 2.

Correct:



# readelf -l /usr/X11R7/lib/modules/dri/i965_dri.so

Elf file type is DYN (Shared object file)
Entry point 0x0
There are 9 program headers, starting at offset 64

Program Headers:
  Type   Offset VirtAddr   PhysAddr
 FileSizMemSiz  Flags  Align
  PHDR   0x0040 0x0040 0x0040
 0x01f8 0x01f8  R  0x8
  LOAD   0x 0x 0x
 0x0007ec68 0x0007ec68  R  0x1000
  LOAD   0x0007f000 0x0007f000 0x0007f000
 0x007c04be 0x007c04be  R E0x1000
  LOAD   0x0084 0x0084 0x0084
 0x001c9c72 0x001c9c72  R  0x1000
  LOAD   0x00a0a090 0x00a0a090 0x00a0a090
 0x000aa8e8 0x001f6078  RW 0x1000
  DYNAMIC0x00a7ecb8 0x00a7ecb8 0x00a7ecb8
 0x0280 0x0280  RW 0x8
  NOTE   0x0238 0x0238 0x0238
 0x0050 0x0050  R  0x4
  GNU_EH_FRAME   0x009684d8 0x009684d8 0x009684d8
 0x0001c8c4 0x0001c8c4  R  0x4
  GNU_RELRO  0x00a0a090 0x00a0a090 0x00a0a090
 0x00074f70 0x00074f70  R  0x1

 Section to Segment mapping:
  Segment Sections...
   00
   01 .note.gnu.build-id .note.netbsd.ident .note.netbsd.pax .hash 
.dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt

   02 .init .plt .plt.got .text .fini
   03 .rodata .eh_frame_hdr .eh_frame .gcc_except_table
   04 .init_array .fini_array .ctors .dtors .jcr .data.rel.ro .dynamic 
.got .got.plt .data .bss

   05 .dynamic
   06 .note.gnu.build-id .note.netbsd.ident .note.netbsd.pax
   07 .eh_frame_hdr
   08 .init_array .fini_array .ctors .dtors .jcr .data.rel.ro .dynamic 
.got
> 


> Martin

> 

I downgraded the system to the version from 03/01, it works fine; it might 
be interesting to mention that multimedia/obs, compiled on the version from 
07/01, does not work on the version from 03/01, even if it reports the same 
10.99.2:




$ uname -a
NetBSD tarkus.lorien.lan 10.99.2 NetBSD 10.99.2 (GENERIC) #4: Tue Jan  3 
20:39:31 GMT 2023  
sysbu...@ymir.lorien.lan:/home/sysbuild/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC 
amd64

$ file /usr/pkg/bin/obs
/usr/pkg/bin/obs: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /usr/libexec/ld.elf_so, for NetBSD 10.99.2, 
stripped

$ ldd /usr/pkg/bin/obs
ldd: /usr/pkg/bin/obs: invalid ELF class 2; expected 1
$ /usr/pkg/bin/obs
/usr/pkg/bin/obs: Shared object "libobs-frontend-api.so.0" not found

As far as I understand it, there was a change with the dynamic loader at 
this time? 

BTW, I tried backing out sys/dev/ic/igpioreg.h, as mentioned above, it 
didn't make any difference. 


--

Chavdar Ivanov

Very recent NetBSD-current Xorg panic

[Chavdar Ivanov]

gpioreg.h,v 1.2 2022/03/26 19:35:35 riastradh Exp $ */
+/* $NetBSD: igpioreg.h,v 1.3 2023/01/07 00:39:20 msaitoh Exp $ */

 /*
  * Copyright (c) 2021 Emmanuel Dreyfus
@@ -180,9 +180,9 @@

/* Lewisburg */
{ "INT3536",0,   0,   7, 0x100, 0x110 },
-   { "INT3536",1,  72,  13, 0x100, 0x110 },
-   { "INT3536",3, 133,  14, 0x100, 0x110 },
-   { "INT3536",4, 144,  17, 0x100, 0x110 },
+   { "INT3536",1,  72, 132, 0x100, 0x110 },
+   { "INT3536",3, 133, 143, 0x100, 0x110 },
+   { "INT3536",4, 144, 178, 0x100, 0x110 },
{ "INT3536",5, 179, 246, 0x100, 0x110 },

/* Emmitsburg */

I don't yet know if this is related, I'll back this out and try to rebuild.

--

Chavdar Ivanov

Re: Kernel config options for drm [ Was Re: No HDMI output... ]

[Chavdar Ivanov]

On 06 January 2023 16:51:09 (+00:00), Mayuresh wrote:

> > It works as close to perfect as one can desire. cad.onshape.com/check
> > returns some tens of millions tri/sec under the latest firefox. No
> > graphics artifacts whatsoever.
> 
> Can you tell a bit more about cad.onshape.com? I can see it in 
"Measuring
> performance" state for long. Not sure what it is supposed to be 
reporting

> and after how long.

See https://youtu.be/ycVPG1jl-uY  (I just uploaded it, I will publish the 
same test using different graphics hardware, browser and OS). 

It takes less than a minute. 

> 


--

Chavdar Ivanov

Re: binutils still failing on amd64

[Chavdar Ivanov]

On 31 December 2022 19:44:05 (+00:00), Paul Goyette wrote:

> Sources updated to 2022-12-31 at 13:42:04 UTC and all output dirs (obj,
> release, dist, tools) were cleaned.
> 
> ``build.sh tools'' fails trying to build bfdver.texi - see attachment

> for log details




 Summary of results:
 build.sh command:./build.sh 
-D/home/sysbuild/sysbuild/amd64/destdir -M/home/sysbuild/sysbuild/amd64/obj 
-N2 -R/home/sysbuild/sysbuild/release -T/home/sysbuild/sysbuild/amd64/tools 
-U -X/usr/xsrc -j1 -mamd64 -u -x release iso-image

 build.sh started:Sat Dec 31 15:46:53 GMT 2022
 NetBSD version:  10.99.2
 MACHINE: amd64
 MACHINE_ARCH:x86_64
 Build platform:  NetBSD 10.99.2 amd64
 HOST_SH: /bin/sh
 MAKECONF file:   /etc/mk.conf
 TOOLDIR path:/home/sysbuild/sysbuild/amd64/tools
 DESTDIR path:/home/sysbuild/sysbuild/amd64/destdir
 RELEASEDIR path: /home/sysbuild/sysbuild/release
 Updated makewrapper: 
/home/sysbuild/sysbuild/amd64/tools/bin/nbmake-amd64

 Successful make release
 Successful make iso-image
 build.sh ended:  Sat Dec 31 18:33:19 GMT 2022


> 


> ++--+--+

> | Paul Goyette   | PGP Key fingerprint: | E-mail addresses:|

> | (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com|

> | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org  |

> | & Network Engineer |  | pgoyett...@gmail.com |

> ++--+------+

--

Chavdar Ivanov

Re: -current build failure?

[Chavdar Ivanov]

On 30 December 2022 14:26:09 (+00:00), Martin Husemann wrote:

> On Fri, Dec 30, 2022 at 01:04:46PM +0000, Chavdar Ivanov wrote:
> > Hi,
> > 
> > I am getting again a failure in binutils.old, after having cleaned 
four days

> > ago the entire obj:
> 
> binutils.old is the wrong directory, your build should use binutils now.

> You need to clean the tools/binutils obj dir.
Thanks. 


There appear to be some missing merges?

...


sysbuild: I: Running 'cvs -danon...@anoncvs.netbsd.org:/cvsroot -q update 
-d -P' in /home/sysbuild/src

M external/gpl3/binutils/dist/bfd/doc/bfd.info
M external/gpl3/binutils/dist/gas/config/m68k-parse.c

...

> 


> Martin

> 


--

Chavdar Ivanov

-current build failure?

[Chavdar Ivanov]

Hi, 

I am getting again a failure in binutils.old, after having cleaned four 
days ago the entire obj:

...


  CC   archive.lo
In file included from 
/home/sysbuild/src/tools/binutils/../../external/gpl3/binutils.old/dist/bfd/archive.c:134:


/home/sysbuild/src/tools/binutils/../../external/gpl3/binutils.old/dist/bfd/sysdep.h:127:1: 
warning: function declaration isn't a prototype [-Wstrict-prototypes]

  127 | extern void free ();
  | ^~
/home/sysbuild/src/tools/binutils/../../external/gpl3/binutils.old/dist/bfd/sysdep.h:131:1: 
warning: function declaration isn't a prototype [-Wstrict-prototypes]

  131 | extern char *getenv ();
  | ^~
/home/sysbuild/src/tools/binutils/../../external/gpl3/binutils.old/dist/bfd/sysdep.h:135:8: 
error: unknown type name 'PTR'

  135 | extern PTR malloc ();
  |^~~
/home/sysbuild/src/tools/binutils/../../external/gpl3/binutils.old/dist/bfd/sysdep.h:135:1: 
warning: function declaration isn't a prototype [-Wstrict-prototypes]

  135 | extern PTR malloc ();
  | ^~
/home/sysbuild/src/tools/binutils/../../external/gpl3/binutils.old/dist/bfd/sysdep.h:135:12: 
error: conflicting types for 'malloc'

  135 | extern PTR malloc ();
  |^~
In file included from 
/home/sysbuild/src/tools/binutils/../../external/gpl3/binutils.old/dist/bfd/sysdep.h:60,
 
from 
/home/sysbuild/src/tools/binutils/../../external/gpl3/binutils.old/dist/bfd/archive.c:134:


/usr/include/stdlib.h:117:7: note: previous declaration of 'malloc' was 
here

  117 | void *malloc(size_t);
  |   ^~


--

Chavdar Ivanov

Re: Kernel config options for drm [ Was Re: No HDMI output... ]

[Chavdar Ivanov]

On 27 December 2022 15:01:40 (+00:00), Mayuresh wrote:

> On Tue, Dec 27, 2022 at 02:56:07PM +0000, Chavdar Ivanov wrote:
> > > > Had it worked on 9.99.x / 10.0 BETA as well?
> > 
> > Yes.
> 
> Sounds great. Was it with the GENERIC (default) kernel or did you have 
to

> tweak anything?
>

GENERIC. It's been many years since I had to build a custom kernel for any 
reason.   


--

Chavdar Ivanov

Re: Kernel config options for drm [ Was Re: No HDMI output... ]

[Chavdar Ivanov]

On 27 December 2022 14:51:29 (+00:00), Mayuresh wrote:

> On Tue, Dec 27, 2022 at 02:33:27PM +0000, Chavdar Ivanov wrote:
> > > #i915drm*   at drm? # Intel i915, i945 DRM driver
> > > #mach64drm* at drm? # mach64 (3D Rage Pro, Rage) DRM
> > driver
> > > #mgadrm*at drm? # Matrox G[24]00, G[45]50 DRM 
driver

> > > #r128drm*   at drm? # ATI Rage 128 DRM driver
> > > #radeondrm* at drm? # ATI Radeon DRM driver
> > > #savagedrm* at drm? # S3 Savage DRM driver
> > > #sisdrm*at drm? # SiS DRM driver
> > > #tdfxdrm*   at drm? # 3dfx (voodoo) DRM driver
> > > i915drmkms* at pci? dev ? function ?
> > > radeondrmkmsfb* at radeonfbbus?
> > > #viadrmums* at drm?
> > 
> > That's the default...
> 
> Right. But do I need to tinker with the defaults to get it working? Also

> the nomenclature i915drm vs i915drmkms or radeondrm vs radeondrmkmsfb
> isn't clear to me - which one is which?
> 
> > Just in case someone is interested, this is what I get now (on 10.99.2 
from
> > yesterday, but it has been like that since I installed this graphics 
card):
> 
> Had it worked on 9.99.x / 10.0 BETA as well?


Yes. I installed NetBSD on this system sometimes around mid-September, it 
has generally worked like that since then. Well, perhaps a little later - 
it had initially  an NVidia Quadro 600, which I swapped with the FirePro 
W5000 shortly after. 
 
> 


--

Chavdar Ivanov

Re: Kernel config options for drm [ Was Re: No HDMI output... ]

[Chavdar Ivanov]

6540 0x6540 0x6544 0x6544 0x6548 0x6548 0x654c 0x654c
[drm]   Encoders:
[drm] DFP2: INTERNAL_UNIPHY2
[drm] Connector 2:
[drm]   DVI-I-1
[drm]   HPD6
[drm]   DDC: 0x6560 0x6560 0x6564 0x6564 0x6568 0x6568 0x656c 0x656c
[drm]   Encoders:
[drm] DFP3: INTERNAL_UNIPHY
[drm] CRT1: INTERNAL_KLDSCP_DAC1
radeondrmkmsfb0 at radeon0
[drm] Initialized radeon 2.50.0 20080528 for radeon0 on minor 0
radeondrmkmsfb0: framebuffer at 0xe05d8000, size 1280x1024, depth 32, 
stride 5120
wsdisplay0 at radeondrmkmsfb0 kbdmux 1: console (default, vt100 emulation), 
using wskbd0
radeon0 at pci1 dev 0 function 0: ATI Technologies FirePro W5000 (rev. 
0x00)
[drm] initializing kernel modesetting (PITCAIRN 0x1002:0x6809 0x1002:0x0B06 
0x00).

[drm] register mmio base: 0xf050
[drm] register mmio size: 262144
radeon0: VRAM: 2048M 0x - 0x7FFF (2048M used)
radeon0: GTT: 2048M 0x8000 - 0x
[drm] Detected VRAM RAM=800M, BAR=256M
[drm] RAM width 256bits DDR
[drm] radeon: 2048M of VRAM memory ready
[drm] radeon: 2048M of GTT memory ready.
[drm] Loading pitcairn Microcode
[drm] Internal thermal controller with fan control
[drm] radeon: dpm initialized
[drm] Found VCE firmware/feedback version 50.0.1 / 17!
[drm] GART: num cpu pages 524288, num gpu pages 524288
[drm] PCIE gen 2 link speeds already enabled
[drm] PCIE GART of 2048M enabled (table at 0x001D6000).
radeon0: WB enabled
radeon0: fence driver on ring 0 use gpu addr 0x8c00 and cpu 
addr 0x0xfc20b3a57c00
radeon0: fence driver on ring 1 use gpu addr 0x8c04 and cpu 
addr 0x0xfc20b3a57c04
radeon0: fence driver on ring 2 use gpu addr 0x8c08 and cpu 
addr 0x0xfc20b3a57c08
radeon0: fence driver on ring 3 use gpu addr 0x8c0c and cpu 
addr 0x0xfc20b3a57c0c
radeon0: fence driver on ring 4 use gpu addr 0x8c10 and cpu 
addr 0x0xfc20b3a57c10
radeon0: fence driver on ring 5 use gpu addr 0x00075a18 and cpu 
addr 0x0xca044f405a18
radeon0: fence driver on ring 6 use gpu addr 0x8c18 and cpu 
addr 0x0xfc20b3a57c18
radeon0: fence driver on ring 7 use gpu addr 0x8c1c and cpu 
addr 0x0xfc20b3a57c1c

[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
radeon0: radeon: MSI limited to 32-bit
radeon0: radeon: using MSI.
radeon0: interrupting at msi9 vec 0 (radeon0)
[drm] radeon: irq initialized.
[drm] ring test on 0 succeeded in 3 usecs
[drm] ring test on 1 succeeded in 1 usecs
[drm] ring test on 2 succeeded in 1 usecs
[drm] ring test on 3 succeeded in 7 usecs
[drm] ring test on 4 succeeded in 7 usecs
[drm] ring test on 5 succeeded in 2 usecs
[drm] UVD initialized successfully.
[drm] ring test on 6 succeeded in 23 usecs
[drm] ring test on 7 succeeded in 3 usecs
[drm] VCE initialized successfully.
[drm] ib test on ring 0 succeeded in 0 usecs
[drm] ib test on ring 1 succeeded in 0 usecs
[drm] ib test on ring 2 succeeded in 0 usecs
[drm] ib test on ring 3 succeeded in 0 usecs
[drm] ib test on ring 4 succeeded in 0 usecs
[drm] ib test on ring 5 succeeded
[drm] ib test on ring 6 succeeded
[drm] ib test on ring 7 succeeded
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   DP-1
[drm]   HPD4
[drm]   DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 0x653c
[drm]   Encoders:
[drm] DFP1: INTERNAL_UNIPHY2
[drm] Connector 1:
[drm]   DP-2
[drm]   HPD5
[drm]   DDC: 0x6540 0x6540 0x6544 0x6544 0x6548 0x6548 0x654c 0x654c
[drm]   Encoders:
[drm] DFP2: INTERNAL_UNIPHY2
[drm] Connector 2:
[drm]   DVI-I-1
[drm]   HPD6
[drm]   DDC: 0x6560 0x6560 0x6564 0x6564 0x6568 0x6568 0x656c 0x656c
[drm]   Encoders:
[drm] DFP3: INTERNAL_UNIPHY
[drm] CRT1: INTERNAL_KLDSCP_DAC1
radeondrmkmsfb0 at radeon0
[drm] Initialized radeon 2.50.0 20080528 for radeon0 on minor 0
radeondrmkmsfb0: framebuffer at 0xe05d8000, size 1280x1024, depth 32, 
stride 5120
wsdisplay0 at radeondrmkmsfb0 kbdmux 1: console (default, vt100 emulation), 
using wskbd0


 

It works as close to perfect as one can desire. cad.onshape.com/check 
returns some tens of millions tri/sec under the latest firefox. No graphics 
artifacts whatsoever. 

While here, my laptop under the same build as above, having an Intel 530 
graphics (and a GeForce 950m, non-functional) works again perfectly well 
using 'driver Intel', whereas 'driver modesetting' is absolutely unusable. 

 

> 

> 

> 


--

Chavdar Ivanov

Re: tools build failure

[Chavdar Ivanov]

On 25 December 2022 18:01:11 (+00:00), Martin Husemann wrote:

> You may need to clean the binutils objdir, as the binutils vs. 
binutils.old

> switch happened recently.
> 
> Martin
> 

I had to clear the entire obj tree; it then succeeded (there were no cvs 
changes whatsoever since the previous failure).


--

Chavdar Ivanov

Re: tools build failure

[Chavdar Ivanov]

On 25 December 2022 16:26:29 (+00:00), Paul Goyette wrote:

> on amd64 host and with amd64 target I am seeing
> 
> ...
> /build/netbsd-current/tools/x86_64/amd64/bin/nbyacc: f - cannot open 
"/build/netbsd-current/src_ro/tools/binutils/../../external/gpl3/binutils.old/dist/gas/config/m68k-parse.c"


*** Failed target: 

/build/netbsd-current/src_ro/tools/binutils/../../external/gpl3/binutils.old/dist/gas/config/m68k-parse.c


*** Failed commands:

> ${_MKTARGET_YACC}
> => @echo '#  ' "   yacc " 
binutils//build/netbsd-current/src_ro/tools/binutils/../../external/gpl3/binutils.old/dist/gas/config/m68k-parse.c



${YACC.y} -o ${.TARGET} ${.IMPSRC}


I am getting:


Making all in po
nbmake[11]: nbmake[11]: don't know how to make 
/home/sysbuild/src/tools/binutils/../../external/gpl3/binutils/dist/bfd/i386netbsd.c. 
Stop
nbmake[11]: stopped in 
/home/sysbuild/sysbuild/amd64/obj/home/sysbuild/src/tools/binutils/build/bfd


nbmake[10]: stopped in 
/home/sysbuild/sysbuild/amd64/obj/home/sysbuild/src/tools/binutils/build/bfd


nbmake[9]: stopped in 
/home/sysbuild/sysbuild/amd64/obj/home/sysbuild/src/tools/binutils/build/bfd


*** Failed target:  all-bfd
*** Failed command: r=`${PWDCMD-pwd}`;  (the command is two screens or 
so long...) 
 
> ...


> 


> Wondering why amd64 builds are referencing m68k stuff?  :-)

> 

> 


> ++--+--+

> | Paul Goyette   | PGP Key fingerprint: | E-mail addresses:|

> | (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com|

> | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org  |

> | & Network Engineer |  | pgoyett...@gmail.com |

> +----+--+--+

> 


--

Chavdar Ivanov

10.99.1 panic

[Chavdar Ivanov]

Hi,


I just got a panic while shutting down a VirtualBox guest:



Crash version 10.99.1, image version 10.99.1.
crash: _kvm_kvatop(0)
Kernel compiled without options LOCKDEBUG.
System panicked: reboot forced via kernel debugger
Backtrace from time of crash is available.
crash> bt
rtstrFormatRt.cold() at 0
kern_reboot() at sys_reboot
db_reboot_cmd() at db_fncall
db_command() at db_command+0x123
db_command_loop() at db_command_loop+0xa4
db_trap() at db_trap+0xe9
kdb_trap() at kdb_trap+0x106
trap() at trap+0x2f4
--- trap (number 1) ---
breakpoint() at breakpoint+0x5
vpanic() at vpanic+0x183
kern_assert() at __x86_indirect_thunk_rax
eventfd_fop_close() at eventfd_fop_close+0xe7
closef() at closef+0x60
fd_free() at fd_free+0x10b
exit1() at exit1+0x126
sigexit() at sigexit+0x2e7
postsig() at sendsig
lwp_userret() at lwp_userret+0x20a
mi_userret() at mi_userret+0x234
trap() at trap+0x12d
--- trap (number 6) ---
774de3e39ffe:


-- 
----
Chavdar Ivanov

Rather decent accelerated graphics

[Chavdar Ivanov]

] (==) RADEON(0): Backing store enabled
[44.747] (II) RADEON(0): Direct rendering enabled
[44.782] (II) RADEON(0): Use GLAMOR acceleration.
[44.782] (II) RADEON(0): Acceleration enabled
[44.782] (==) RADEON(0): DPMS enabled
[44.782] (==) RADEON(0): Silken mouse enabled
[44.783] (II) RADEON(0): Set up textured video (glamor)
[44.783] (II) RADEON(0): [XvMC] Associated with GLAMOR Textured Video.
[44.783] (II) RADEON(0): [XvMC] Extension initialized.
[44.791] (II) Initializing extension Generic Event Extension
[44.792] (II) Initializing extension SHAPE
[44.792] (II) Initializing extension MIT-SHM
[44.792] (II) Initializing extension XInputExtension
[44.793] (II) Initializing extension XTEST
[44.793] (II) Initializing extension BIG-REQUESTS
[44.793] (II) Initializing extension SYNC
[44.794] (II) Initializing extension XKEYBOARD
[44.794] (II) Initializing extension XC-MISC
[44.794] (II) Initializing extension SECURITY
[44.795] (II) Initializing extension XFIXES
[44.796] (II) Initializing extension XFree86-Bigfont
[44.796] (II) Initializing extension RENDER
[44.796] (II) Initializing extension RANDR
[44.796] (II) Initializing extension COMPOSITE
[44.797] (II) Initializing extension DAMAGE
[44.797] (II) Initializing extension MIT-SCREEN-SAVER
[44.797] (II) Initializing extension DOUBLE-BUFFER
[44.797] (II) Initializing extension RECORD
[44.797] (II) Initializing extension DPMS
[44.798] (II) Initializing extension Present
[44.798] (II) Initializing extension DRI3


GLmark2 results:
...
vblank=0 glmark2
=== 
   
glmark2 2020.04

===
OpenGL Information
GL_VENDOR: X.Org
GL_RENDERER:   AMD PITCAIRN (DRM 2.50.0, 9.99.104, LLVM 13.0.0)
GL_VERSION:4.5 (Compatibility Profile) Mesa 19.1.17
===
...
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 6601 
FrameTime: 0.151 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 7174 
FrameTime: 0.139 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 7180 
FrameTime: 0.139 ms

===
  glmark2 Score: 4938
===

Also cad.onshape.com/check returns some 28-30 million triangles/sec using 
firefox 105.0.3, which is completely usable.



No need for xorg.conf file. 


--

Chavdar Ivanov

Re: weird less(1) CTRL-Z behaviour

[Chavdar Ivanov]

On 12 October 2022 12:29:34 (+01:00), Robert Elz wrote:

> Date: Wed, 12 Oct 2022 11:12:31 +
> From: Chavdar Ivanov 
> Message-ID: <1665573114107.3142740811.698765...@gmail.com>
>
>
> | Funny enough, even under zsh, the following works just fine:
> |
> | dir() { (/bin/ls -al "$@" | less;) }
>
> That's an entirely different thing, that the two behave differently
> is not a surprise, if that one didn't work, zsh would be unusable (on 
NetBSD).
Sure, it is another process; I meant, wiz@ could avoid the problem for the 
moment this way...


Mind you, there was a new version of zsh relatively recently, mine is from 
28th of September. 


>
> And while here, when I tested this with my current development sh
> (where, for several reasons, though this example was not one of them,
> at least, not previously) it works there too - I have made several
> changes to the way jobs, and pipelines, are handled internally, and
> it seems that the problem that was discovered with this test (not the
> same one as zsh has) has been fixed, just by the general cleanup.
>
> Those fixes are still a while away from being committed, there is more
> to do (though the ATF tests are all working now) - not least of which is
> separating out several different changes so they can be committed 
separately.

>
> kre
>
>

--

Chavdar Ivanov

Re: weird less(1) CTRL-Z behaviour

[Chavdar Ivanov]

On 12 October 2022 12:08:26 (+01:00), Robert Elz wrote:

> Date: Wed, 12 Oct 2022 12:13:05 +0200
> From: Thomas Klausner 
> Message-ID: 
>
> | dir() { ls -al "$@" | less; }
> |
> | On -current (9.99.100 kernel from Oct 9, Userland from Sep 21, zsh
> | from May), when I CTRL-Z the less(1) and then want to go back in, it
> | doesn't work and I see the following:
>
> As Chavdar said, this seems to be specific to zsh (the sh problem
> is different, an in an area I have been working on in the past few
> days, so just ignore that one for this purpose).
>
> I tested a bunch of shells, zsh is the only one I saw fail this way.
Funny enough, even under zsh, the following works just fine:

 dir() { (/bin/ls -al "$@" | less;) }


>
> The issue will be related to process group control, zsh must be
> doing something different to other shells, and some recent
> kernel change might have altered how that works - perhaps just
> the timing.
>
> That might be serpgrp() or TIOCSPGRP (or whatever equiv is being
> used to change tge terminal's pgrp).
>
> Perhaps this enough for someone to recognise a change they might
> have made which could cause this.
>
> kre
>

-- 

Chavdar Ivanov

Re: weird less(1) CTRL-Z behaviour

[Chavdar Ivanov]

On 12 October 2022 11:36:04 (+01:00), Chavdar Ivanov wrote:

>
>
> On 12 October 2022 11:13:05 (+01:00), Thomas Klausner wrote:
>
> > Hi!
> >
> > I've been using the following shell function for ages:
> >
> > dir() { ls -al "$@" | less; }
> >
> > On -current (9.99.100 kernel from Oct 9, Userland from Sep 21, zsh
> > from May), when I CTRL-Z the less(1) and then want to go back in, it
> > doesn't work and I see the following:
> >
> > > dir
> > zsh: done ls -al "$@" |
> > zsh: suspended
> > > fg
> > [1] + done ls -al "$@" |
> > continued
> > zsh: done ls -al "$@" |
> > zsh: suspended (tty output)
> > zsh: done ls -al "$@" |
> > zsh: suspended (tty output)
> >
> > That happens every time I try to 'fg' it.
> Seems specific to the shell. I get the same with zsh, with /bin/sh I get:
> 
> $ exec /bin/sh
> $ dir() { ls -al "$@" | less; }
> $ dir
> [1] + Done ls -al "${@}" |
> Suspended less
> $ fg
> ls -al "${@}" | less
> fg: Cannot continue job (No such process)
> $ jobs
> [1] + Done ls -al "${@}" |
> Suspended less
> $ fg
> ls -al "${@}" | less
> fg: Cannot continue job (No such process)
> $
> 
>
> However, with /usr/pkg/bin/ksh93 from the latest pkgsrc package, it works as 
> expected:
>
> ...
> ➜ ~ exec ksh93
> [xci@ymir ~]; dir() { /bin/ls -al "$@" | less; }
> [xci@ymir ~]; dir
> [1] + Stopped dir
> [xci@ymir ~]; fg  it gets me back into less, which I exit
> dir
> [xci@ymir ~]; fg
> ksh93: fg: no such job
> [xci@ymir ~];
> 
>
It also works as expected with bash.
  
> >
> > This was working fine not so long ago, but I don't remember exactly
> > when it started happening.
> > Thomas
> >
>
>

-- 

Chavdar Ivanov

Re: weird less(1) CTRL-Z behaviour

[Chavdar Ivanov]

On 12 October 2022 11:13:05 (+01:00), Thomas Klausner wrote:

> Hi!
>
> I've been using the following shell function for ages:
>
> dir() { ls -al "$@" | less; }
>
> On -current (9.99.100 kernel from Oct 9, Userland from Sep 21, zsh
> from May), when I CTRL-Z the less(1) and then want to go back in, it
> doesn't work and I see the following:
>
> > dir
> zsh: done ls -al "$@" |
> zsh: suspended
> > fg
> [1] + done ls -al "$@" |
> continued
> zsh: done ls -al "$@" |
> zsh: suspended (tty output)
> zsh: done ls -al "$@" |
> zsh: suspended (tty output)
>
> That happens every time I try to 'fg' it.
Seems specific to the shell. I get the same with zsh, with /bin/sh I get:

$ exec /bin/sh
$ dir() { ls -al "$@" | less; }
$ dir
[1] + Donels -al "${@}" |
  Suspended   less
$ fg
ls -al "${@}" | less
fg: Cannot continue job (No such process)
$ jobs
[1] + Donels -al "${@}" |
  Suspended   less
$ fg
ls -al "${@}" | less
fg: Cannot continue job (No such process)
$


However, with /usr/pkg/bin/ksh93 from the latest pkgsrc package, it works as 
expected:

...
➜ ~ exec ksh93
[xci@ymir ~]; dir() { /bin/ls -al "$@" | less; }
[xci@ymir ~]; dir
[1] + Stopped  dir
[xci@ymir ~]; fg  it gets me back into less, which I 
exit
dir
[xci@ymir ~]; fg
ksh93: fg: no such job
[xci@ymir ~];


>
> This was working fine not so long ago, but I don't remember exactly
> when it started happening.
> Thomas
>


-- 

Chavdar Ivanov

Re: 9.99.99 build failure

[Chavdar Ivanov]

On 14 September 2022 09:07:21 (+01:00), RVP wrote:

> On Wed, 14 Sep 2022, Chavdar Ivanov wrote:
>
> > 
/home/sysbuild/src/external/apache2/llvm/librt/libLLVMOrc/../../lib/../dist/llvm/lib/ExecutionEngine/Orc/LLJIT.cpp 
-o LLJIT.pico
> > 
/home/sysbuild/src/external/apache2/llvm/librt/libLLVMOrc/../../lib/../dist/llvm/lib/ExecutionEngine/Orc/LLJIT.cpp:551:3: 
internal compiler error: Segmentation fault

> > 551 | }
> > | ^
> >
>
> Might not be an actual compiler error. Try restarting the build, if it
> carries on, see the Sig11 FAQ[1].
>
I did, and got (third time in a row, after a clean cvs update, 'make 
cleandir', removed destdir and obj, thw followng:

...
# grep error: ../sysbuild/log/sysbuild4cron.20220914153020.log | wc -l
 106
...

:1: error: invalid preprocessing directive #X
   
  :2: error: invalid preprocessing directive #See   
   
 :8: error: invalid 
preprocessing directive #in 

collect2: fatal error: ld terminated with signal 13 [Broken pipe]   
   
  /home/sysbuild/amd64/tools/bin/x86_64--netbsd-ld: 
bootia32.efi.so.tmp: error: PHDR segment not covered by LOAD segment
/home/sysbuild/amd64/tools/bin/x86_64--netbsd-ld: bootx64.efi.so.tmp: 
error: PHDR segment not covered by LOAD segment
:1: error: macro names must be identifiers
   
  
:2: error: macro names must be identifiers
   
  
:3: error: macro names must be identifiers 
...

:25: error: macro names must be identifiers
/home/sysbuild/src/sys/arch/amd64/amd64/machdep.c:388:44: error: invalid 
use of undefined type 'struct bootspace'
/home/sysbuild/src/sys/arch/amd64/amd64/machdep.c:389:15: error: invalid 
use of undefined type 'struct bootspace'
/home/sysbuild/src/sys/arch/amd64/amd64/machdep.c:486:2: error: implicit 
declaration of function 'xen_set_ldt' 
[-Werror=implicit-function-declaration]
/home/sysbuild/src/sys/arch/amd64/amd64/machdep.c:542:15: error: implicit 
declaration of function 'pmap_pdirpa' 
[-Werror=implicit-function-declaration]
/home/sysbuild/src/sys/arch/amd64/amd64/machdep.c:1103:20: error: 
'PDPpaddr' undeclared (first use in this function)
/home/sysbuild/src/sys/arch/amd64/amd64/machdep.c:1122:1: error: no 
previous prototype for 'reserve_dumppages' [-Werror=missing-prototypes]
/home/sysbuild/src/sys/arch/amd64/amd64/machdep.c:1403:2: error: implicit 
declaration of function 'pmap_changeprot_local' 
[-Werror=implicit-function-declaration]
/home/sysbuild/src/sys/arch/amd64/amd64/machdep.c:1539:30: error: invalid 
application of 'sizeof' to incomplete type 'struct bootspace'
/home/sysbuild/src/sys/arch/amd64/amd64/machdep.c:1541:11: error: invalid 
use of undefined type 'struct bootspace'  

/home/sysbuild/src/sys/arch/amd64/amd64/machdep.c:2197:33: error: 
'BTSEG_RODATA' undeclared (first use in this function)
/home/sysbuild/src/sys/arch/amd64/amd64/machdep.c:2205:17: error: invalid 
use of undefined type 'struct bootspace'
/home/sysbuild/src/sys/arch/amd64/amd64/machdep.c:2206:27: error: invalid 
use of undefined type 'struct bootspace'
/home/sysbuild/src/sys/arch/amd64/amd64/machdep.c:2212:20: error: invalid 
use of undefined type 'struct bootspace'
/home/sysbuild/src/sys/arch/amd64/amd64/machdep.c:2212:45: error: invalid 
use of undefined type 'struct bootspace'


(all in machdep.c in the last section). 

I'll repeat after moving away /etc/mk.conf in case something interferes. 


> -RVP
>
> [1]: https://www.bitwizard.nl/sig11/
>


Chavdar 


--
Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com

9.99.99 build failure

[Chavdar Ivanov]

Hi, 
Anybody seen this:

...
#   compile  libLLVMOrc/LLJIT.pico
/home/sysbuild/amd64/tools/bin/x86_64--netbsd-c++ -frandom-seed=f8e69fdd 
-O2 -Werror -Wno-error=init-list-lifetime -fPIE  -std=c++14 -fno-rtti 
-fno-exceptions  -fno-strict-aliasing  -ffunction-sections -fdata-sections  
--sysroot=/home/sysbuild/amd64/destdir -I. 
-I/home/sysbuild/src/external/apache2/llvm/librt/libLLVMOrc/../../lib/../dist/clang/include 
-I/home/sysbuild/src/external/apache2/llvm/librt/libLLVMOrc/../../lib/../dist/llvm/include 
-I/home/sysbuild/amd64/obj/home/sysbuild/src/external/apache2/llvm/include 
-I/home/sysbuild/src/external/apache2/llvm/librt/libLLVMOrc/../../lib/../config  
-I/home/sysbuild/src/external/apache2/llvm/librt/libLLVMOrc/../../lib/../config  
-c-fPIC   
/home/sysbuild/src/external/apache2/llvm/librt/libLLVMOrc/../../lib/../dist/llvm/lib/ExecutionEngine/Orc/LLJIT.cpp 
-o LLJIT.pico
/home/sysbuild/src/external/apache2/llvm/librt/libLLVMOrc/../../lib/../dist/llvm/lib/ExecutionEngine/Orc/LLJIT.cpp:551:3: 
internal compiler error: Segmentation fault

  551 |   }
  |   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
*** Failed target: LLJIT.pico
*** Failed commands:
${_MKTARGET_COMPILE}
=> @echo '#  ' "compile " libLLVMOrc/LLJIT.pico
${COMPILE.cc} ${COPTS.${.IMPSRC:T}} ${CPUFLAGS.${.IMPSRC:T}} 
${CPPFLAGS.${.IMPSRC:T}} ${CSHLIBFLAGS} ${.IMPSRC} -o ${.TARGET}
=> /home/sysbuild/amd64/tools/bin/x86_64--netbsd-c++ 
-frandom-seed=f8e69fdd -O2 -Werror -Wno-error=init-list-lifetime -fPIE  
-std=c++14 -fno-rtti -fno-exceptions  -fno-strict-aliasing  
-ffunction-sections -fdata-sections   
--sysroot=/home/sysbuild/amd64/destdir -I. 
-I/home/sysbuild/src/external/apache2/llvm/librt/libLLVMOrc/../../lib/../dist/clang/include 
-I/home/sysbuild/src/external/apache2/llvm/librt/libLLVMOrc/../../lib/../dist/llvm/include 
-I/home/sysbuild/amd64/obj/home/sysbuild/src/external/apache2/llvm/include 
-I/home/sysbuild/src/external/apache2/llvm/librt/libLLVMOrc/../../lib/../config  
-I/home/sysbuild/src/external/apache2/llvm/librt/libLLVMOrc/../../lib/../config  
-c-fPIC   
/home/sysbuild/src/external/apache2/llvm/librt/libLLVMOrc/../../lib/../dist/llvm/lib/ExecutionEngine/Orc/LLJIT.cpp 
-o LLJIT.pico${OBJCOPY} ${OBJCOPYLIBFLAGS} ${.TARGET}


*** Failed target:  dependall-../external/apache2/llvm/librt
...


--
Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com

Re: How to BIOS-boot from NVMe device?

[Chavdar Ivanov]

On 08 September 2022 17:36:46 (+01:00), Brad Spencer wrote:

> Paul Goyette  writes:
>
> > On Thu, 8 Sep 2022, Paul Goyette wrote:
> >
> >> Would be nice to get my menu back and have it default to the NetBSD
> >> system partition, but at least it boots!
> >
> > I got my menu back. Just had to put it at /efi/boot.cfg (ie, at the
> > root of the EFI partition).
> >
> >
> > 
++--+--+

> > | Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
> > | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
> > | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org 
|

> > | & Network Engineer | | pgoyett...@gmail.com |
> > 
++--+--+

>
>
> This is a clear indication of a UEFI boot. There is confusion in the
> docs about where the boot.cfg file should be located. I have also found
> that the desired behavior works if it is in the root of the EFI
> filesystem.
>
> If anyone wants to play with UEFI booting and has access to a recent Xen
> DOM0 system you can install the pkgsrc/sysutils/ovmf package and point a
pkgsrc/sysutils/ovmf does not build on -current at least - and hasn't been 
building for a long while. 

I checkout the source and build it manually under Debian; obviously the 
resulting firmware files are the same. 


> Xen HVM guest at that for its bios and get a more or less working UEFI
> setup without physical hardware (you will have to compile a custom
> kernel without PVM or PVHVM support). I posted a note on port-xen a bit
> ago about what works and what had trouble. You can probably do the same
> thing with qemu and/or nvmm but I have not messed with those.
>
>
>

--
Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com

Re: iscsi target on a zfs zvol?

[Chavdar Ivanov]

On 10 July 2022 20:40:56 (+01:00), Michael van Elst wrote:

> ha...@espresso.rhein-neckar.de (Hauke Fath) writes:
>
> >I would like to set up an iscsi target backed by a zfs zvol, to 
serve=20

> >as a Mac time machine volume.
I have been using iSCSI target backed by a zvol for quite some time. 
Initially I tried the built-in target (always on -current, whatever was the 
version at the time), but found it to be less reliable than the pkgsrc 
version. 
>

> Independent of your problem you should use 'istgt' from pkgsrc.
>
>
> 

863:/u/sources/netbsd-developer/src/external/bsd/iscsi/lib/../dist/src/lib/=



>disk.c:720:=20

> >***ERROR*** error reading "target0"
> ># hexdump -C -n 512 /dev/zvol/rdsk/tank/time_machine_1=20
> > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =20
> >at which point
> >DISK: LUN 0: 2097152 MB disk storage for "target0"

I would check the permissions of /dev/zvol/rdsk...  (that is from elsewhere 
- I also use zvol-backed disks for my NVMM virtual machines, the default 
wouldn't work if I start the VM as a user).



I can't verify the exact setup unfortunately - the laptop I was using for 
all that finally packed yesterday after some 9 years of faithful work and I 
will have to look for another suitable hardware to get my daily NetBSD 
fix... 
  
>

>
> >Looks like an initialization issue on behalf of iscsi-target. Does 
that=20

> >ring a bell for anyone?
>
> Probably unrelated to ZFS, this reminds me of:
>
> # stat -s /dev/rvnd0a
> st_dev=43010 st_ino=65103 st_mode=020640 st_nlink=1 st_uid=0 st_gid=5 
st_rdev=10496 st_size=0 st_atime=1590051866 st_mtime=1590051866 
st_ctime=1590051866 st_birthtime=1590051866 st_blksize=65536 st_blocks=0 
st_flags=0

>
> # hexdump -C /dev/rvnd0a | head -1
>  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |
>
> # stat -s /dev/rvnd0a
> st_dev=43010 st_ino=65103 st_mode=020640 st_nlink=1 st_uid=0 st_gid=5 
st_rdev=10496 st_size=10485760 st_atime=1657481715 st_mtime=1590051866 
st_ctime=1590051866 st_birthtime=1590051866 st_blksize=65536 st_blocks=0 
st_flags=0

>
> Before opening the device with hexdump, the st_size field is 0.
>
> The size is cached in the vnode, but only determined when you open the
> device. The information gets lost again when the vnode is expired,
> which only happens when there is a memory shortage.
>
>

--
Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com

Re: 9.99.98: spontaneous reboots

[Chavdar Ivanov]

On 21 June 2022 22:04:03 (+01:00), Thomas Klausner wrote:

> Hi!
>
> I've been running a 9.99.97 kernel from June 1 and it was stable,
> including bulk builds. Today I upgraded to 9.99.98 and started a fresh
> bulk build, and it rebooted after a couple hours, nothing in dmesg or
> syslog, no crashdump.
>
> I restarted the bulk build and it rebooted again after about 5 minutes
> and one finished package. I think it was building nodejs and
> webkit-gtk at the time (and some third package I don't know).
>
> Has anyone else seen stability issues with today's current?
I rebuilt 9.99.98 today around 15:00 and have been building rather large 
packages since; right now I am through pkg_rolling-replace and haven't seen 
any problem yet. 


> Thomas
>

Chavdar 
--

Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com

Re: Archive of .iso images for -current

[Chavdar Ivanov]

On 15 June 2022 01:05:43 (+01:00), Chavdar Ivanov wrote:

>
>
> On 14 June 2022 23:06:56 (+01:00), Roland Illig wrote:
>
> > Hi,
> >
> > NetBSD-current fails for me in a VirtualBox with more than 1 CPU.
> >
> > https://gnats.netbsd.org/56883
> > https://gnats.netbsd.org/56884
> > https://gnats.netbsd.org/56885
> >
> > NetBSD 9.2 from 2020-02-14 works fine.
> > NetBSD 9.99.97 from 2022-06-14 doesn't work.
> It works just fine for me:
>
> # dmesg | grep -i box
> [ 1.03] ACPI: RSDP 0x000E 24 (v02 VBOX )
> [ 1.03] ACPI: XSDT 0xDBFF0040 4C (v01 VBOX VBOXXSDT 
0001 ASL 0061)
> [ 1.03] ACPI: FACP 0xDBFF0110 F4 (v04 VBOX VBOXFACP 
0001 ASL 0061)
> [ 1.03] ACPI: DSDT 0xDBFF0540 002325 (v02 VBOX VBOXBIOS 
0002 INTL 20100528)
> [ 1.03] ACPI: APIC 0xDBFF0280 6C (v02 VBOX VBOXAPIC 
0001 ASL 0061)
> [ 1.03] ACPI: HPET 0xDBFF02F0 38 (v01 VBOX VBOXHPET 
0001 ASL 0061)
> [ 1.03] ACPI: MCFG 0xDBFF0330 3C (v01 VBOX VBOXMCFG 
0001 ASL 0061)
> [ 1.03] ACPI: SSDT 0xDBFF0370 0001CC (v01 VBOX VBOXCPUT 
0002 INTL 20100528)
> [ 1.03] acpi0: X/RSDT: OemId , AslId ,0061>
> [ 1.013905] vga0 at pci0 dev 2 function 0: VirtualBox Graphics (rev. 
0x00)
> [ 1.013905] VirtualBox Guest Service (miscellaneous system) at pci0 dev 
4 function 0 not configured

> [ 1.040897] acpibat0: innotek VBOX rechargeable battery
> [ 1.519620] wd0: 
> [ 1.558634] cd0 at atapibus0 drive 0:  
cdrom removable
> [ 3.389645] sd0 at scsibus0 target 1 lun 0:  disk 
fixed
> [ 3.419818] sd1 at scsibus0 target 2 lun 0:  disk 
fixed

> [ 16.859249] vboxguest0 at pci0 dev 4 function 0: VirtualBox Guest
> [ 16.859249] vboxguest0: interrupting at ioapic0 pin 20
> [ 16.859249] wsmouse1 at vboxguest0 mux 0
> [ 16.859249] vboxguest0: WARNING: power management not supported
> # cpuctl list
> Num HwId Unbound LWPs Interrupts Last change #Intr
>    --  -
> 0 0 online intr Tue Jun 14 22:28:57 2022 11
> 1 1 online intr Tue Jun 14 22:28:57 2022 0
> 2 2 online intr Tue Jun 14 22:28:57 2022 0
> 3 3 online intr Tue Jun 14 22:28:57 2022 0
> # uname -a
> NetBSD marge.lorien.lan 9.99.97 NetBSD 9.99.97 (GENERIC) #10: Mon Jun 13 
11:45:33 BST 2022 
sysbuild@ymir:/home/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC 
amd64

>
> I have been having problems running it under VirtualBOX with the 
GENERIC_KASLR kernel, I've reported it previously, still have no idea what 
is the problem.
> But otherwise on my hardware (6-year old HP Envy laptop, Intel(R) 
Core(TM) i7-6700HQ CPU @ 2.60GHz) it works fine. I always build the 
VirtualBox additions for every minor version of -current.

> >
> > There's more than 2 years of active development in between. To narrow
> > this down further, I'd like to bisect this without having to build the
> > whole release myself each time.
> >
> > Is there a monthly archive of NetBSD-current somewhere? I looked on
> > https://cdn.netbsd.org/pub/ and https://archive.netbsd.org/ but 
couldn't

> > find anything. In particular, I'm interested in amd64/boot.iso.
> >
> > Any other ideas?
>
> Virtual machine settings?
> I have several of them, some using EFI, some BIOS; some using VMware 
graphics, some - still VboxSVGA. Generally they work ok, the additions 
functionality with -current is not complete, but still useful.
> I build -current 2-3 times a week and regularly test sysinst with 
various configurations under VirtualBox.

> >
> > Roland
> >
>
> Chavdar
>


Here is another one, a bit old, still on 9.99.93, using EFI, I just booted 
it with three CPUs:





ntest5# cpuctl list
Num  HwId Unbound LWPs Interrupts Last change  #Intr
   --  -
00online   intr   Wed Jun 15 01:12:55 2022 12
11online   intr   Wed Jun 15 01:12:55 2022 0
22online   intr   Wed Jun 15 01:12:55 2022 0
ntest5# uname -a
NetBSD ntest5.lorien.lan 9.99.93 NetBSD 9.99.93 (GENERIC) #0: Fri Feb 18 
02:21:34 GMT 2022  
sysbuild@ymir:/home/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC 
amd64

ntest5# dmesg | grep -i box
[ 1.03] ACPI: RSDP 0x3EFFA014 24 (v02 VBOX  )
[ 1.03] ACPI: XSDT 0x3EFF90E8 44 (v01 VBOX   VBOXFACP 
0001  0113)
[ 1.03] ACPI: FACP 0x3EFF7000 F4 (v04 VBOX   VBOXFACP 
0001 ASL  0061)
[ 1.03] ACPI: DSDT 0x3EFF4000 002325 (v02 VBOX   VBOXBIOS 
0002 INTL 20100528)
[ 1.03] ACPI: APIC 0x3EFF8000 64 (v02 VBO

Re: Archive of .iso images for -current

[Chavdar Ivanov]

On 14 June 2022 23:06:56 (+01:00), Roland Illig wrote:

> Hi,
>
> NetBSD-current fails for me in a VirtualBox with more than 1 CPU.
>
> https://gnats.netbsd.org/56883
> https://gnats.netbsd.org/56884
> https://gnats.netbsd.org/56885
>
> NetBSD 9.2 from 2020-02-14 works fine.
> NetBSD 9.99.97 from 2022-06-14 doesn't work.
It works just fine for me:

# dmesg | grep -i box
[ 1.03] ACPI: RSDP 0x000E 24 (v02 VBOX  )
[ 1.03] ACPI: XSDT 0xDBFF0040 4C (v01 VBOX   VBOXXSDT 
0001 ASL  0061)
[ 1.03] ACPI: FACP 0xDBFF0110 F4 (v04 VBOX   VBOXFACP 
0001 ASL  0061)
[ 1.03] ACPI: DSDT 0xDBFF0540 002325 (v02 VBOX   VBOXBIOS 
0002 INTL 20100528)
[ 1.03] ACPI: APIC 0xDBFF0280 6C (v02 VBOX   VBOXAPIC 
0001 ASL  0061)
[ 1.03] ACPI: HPET 0xDBFF02F0 38 (v01 VBOX   VBOXHPET 
0001 ASL  0061)
[ 1.03] ACPI: MCFG 0xDBFF0330 3C (v01 VBOX   VBOXMCFG 
0001 ASL  0061)
[ 1.03] ACPI: SSDT 0xDBFF0370 0001CC (v01 VBOX   VBOXCPUT 
0002 INTL 20100528)
[ 1.03] acpi0: X/RSDT: OemId , AslId ,0061>
[ 1.013905] vga0 at pci0 dev 2 function 0: VirtualBox Graphics (rev. 
0x00)
[ 1.013905] VirtualBox Guest Service (miscellaneous system) at pci0 dev 
4 function 0 not configured

[ 1.040897] acpibat0: innotek VBOX rechargeable battery
[ 1.519620] wd0: 
[ 1.558634] cd0 at atapibus0 drive 0:  
cdrom removable
[ 3.389645] sd0 at scsibus0 target 1 lun 0:  disk 
fixed
[ 3.419818] sd1 at scsibus0 target 2 lun 0:  disk 
fixed

[16.859249] vboxguest0 at pci0 dev 4 function 0: VirtualBox Guest
[16.859249] vboxguest0: interrupting at ioapic0 pin 20
[16.859249] wsmouse1 at vboxguest0 mux 0
[16.859249] vboxguest0: WARNING: power management not supported
# cpuctl list
Num  HwId Unbound LWPs Interrupts Last change  #Intr
   --  -
00online   intr   Tue Jun 14 22:28:57 2022 11
11online   intr   Tue Jun 14 22:28:57 2022 0
22online   intr   Tue Jun 14 22:28:57 2022 0
33online   intr   Tue Jun 14 22:28:57 2022 0
# uname -a
NetBSD marge.lorien.lan 9.99.97 NetBSD 9.99.97 (GENERIC) #10: Mon Jun 13 
11:45:33 BST 2022  
sysbuild@ymir:/home/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC 
amd64


I have been having problems running it under VirtualBOX with the 
GENERIC_KASLR kernel, I've reported it previously, still have no idea what 
is the problem. 

But otherwise on my hardware (6-year old HP Envy laptop, Intel(R) Core(TM) 
i7-6700HQ CPU @ 2.60GHz) it works fine. I always build the VirtualBox 
additions for every minor version of -current. 


>
> There's more than 2 years of active development in between. To narrow
> this down further, I'd like to bisect this without having to build the
> whole release myself each time.
>
> Is there a monthly archive of NetBSD-current somewhere? I looked on
> https://cdn.netbsd.org/pub/ and https://archive.netbsd.org/ but couldn't
> find anything. In particular, I'm interested in amd64/boot.iso.
>
> Any other ideas?

Virtual machine settings? 

I have several of them, some using EFI, some BIOS; some using VMware 
graphics, some - still VboxSVGA. Generally they work ok, the additions 
functionality with -current is not complete, but still useful. 

I build -current 2-3 times a week and regularly test sysinst with various 
configurations under VirtualBox.  


>
> Roland
>

Chavdar 



--
Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com