Re: Curious new panic

[Markus Kilbinger]

See kern/58301

Am Do., 30. Mai 2024 um 14:59 Uhr schrieb Jason Thorpe :
>
>
>
> > On May 30, 2024, at 1:17 AM, Chavdar Ivanov  wrote:
> >
> > Hi,
> >
> > On my amd64-current system from yesterday:
> >
> > NetBSD ymir.lorien.lan 10.99.10 NetBSD 10.99.10 (GENERIC) #6: Wed May
> > 29 17:55:25 BST 2024
> > sysbu...@ymir.lorien.lan:/dumps/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC
> > amd64
> >
> > I got an overnight panic, as follows:
> > ...
> > nvmm0: attached, using backend x86-vmx
> > panic: kernel diagnostic assertion "lle->la_numheld == 0" failed:
> >   file "/home/sysbuild/src/sys/net/if_llatbl.c",
> >   line 333 la_numheld 1 > 0, pkts_dropped 0
> > cpu4: Begin traceback...
>
> Riastradh recently made a change in this area.  Can you please file a bug 
> report?
>
> -- thorpej
>

Re: weird hangs in current (ghc, gnucash)

[Markus Kilbinger]

... 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

Re: kerberos issues with 10.0_BETA post openssl update

[Markus Kilbinger]

In a preexisting krb-installation on an aarch64 machine (odroid c2)
kadmin still dumps core when trying to add a new principal (even after
recent source changes):

# kadmin -l add -r host/test
Max ticket life [1 day]:
Max renewable life [1 week]:
Principal expiration time [never]:
Password expiration time [never]:
Attributes []:
Policy [default]:
Memory fault (core dumped)

# gdb /usr/sbin/kadmin kadmin.core
GNU gdb (GDB) 13.2
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "aarch64--netbsd".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/kadmin...
(No debugging symbols found in /usr/sbin/kadmin)
[New process 591]
Core was generated by `kadmin'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0xf37a50b81320 in ?? () from /usr/lib/libkrb5.so.28
#2  0xf37a50b803a8 in krb5_string_to_key_data_salt_opaque () from
/usr/lib/libkrb5.so.28
#3  0xf37a50b8045c in krb5_string_to_key_data_salt () from
/usr/lib/libkrb5.so.28
#4  0xf37a50b805dc in krb5_string_to_key_salt () from /usr/lib/libkrb5.so.28
#5  0xf37a50c61fe0 in hdb_generate_key_set_password_with_ks_tuple
() from /usr/lib/libhdb.so.16
#6  0xf37a50cae978 in _kadm5_set_keys () from /usr/lib/libkadm5srv.so.16
#7  0xf37a50ca9e40 in kadm5_s_create_principal () from
/usr/lib/libkadm5srv.so.16
#8  0x0fdf85c4 in add_one_principal ()
#9  0x0fdf8930 in add_new_key ()
#10 0x0fdf7944 in add_wrap ()
#11 0x0fdff0b8 in main ()

Am Di., 5. Sept. 2023 um 00:10 Uhr schrieb Mark Davies :
>
>
>
> On 4/09/23 22:30, Taylor R Campbell wrote:
> > Can you share `ldd /usr/libexec/kadmind' on the machine where it's
> > crashing?  Wondering whether it's mixing shlib versions in one address
> > space, like https://gnats.netbsd.org/57603 (though that's not the same
> > issue because you're only using things in base).
>
>
> /usr/libexec/kadmind:
>  -lgssapi.11 => /usr/lib/libgssapi.so.11
>  -lkrb5.27 => /usr/lib/libkrb5.so.27
>  -lhx509.6 => /usr/lib/libhx509.so.6
>  -lasn1.10 => /usr/lib/libasn1.so.10
>  -lcom_err.8 => /usr/lib/libcom_err.so.8
>  -lc.12 => /usr/lib/libc.so.12
>  -lroken.20 => /usr/lib/libroken.so.20
>  -lutil.7 => /usr/lib/libutil.so.7
>  -lcrypt.1 => /usr/lib/libcrypt.so.1
>  -lcrypto.15 => /usr/lib/libcrypto.so.15
>  -lwind.1 => /usr/lib/libwind.so.1
>  -lheimbase.2 => /usr/lib/libheimbase.so.2
>  -lsqlite3.1 => /usr/lib/libsqlite3.so.1
>  -lm.0 => /usr/lib/libm.so.0
>  -lheimntlm.5 => /usr/lib/libheimntlm.so.5
>  -lkadm5srv.15 => /usr/lib/libkadm5srv.so.15
>  -lhdb.15 => /usr/lib/libhdb.so.15
>
> > Can you install the debug set on one of the affected systems where you
> > can reproduce a problem to get more information out of the stack
> > traces?
>
> I'll rebuild a tree with MKDEBUG and MKDEBUGLIB set now, and see what I see.
>
> cheers
> mark
>

Re: Hints for Bananapi and -current

[Markus Kilbinger]

Am Mi., 8. Mai 2019 um 00:51 Uhr schrieb Jason Thorpe :
>
> > On May 7, 2019, at 2:37 PM, Jared McNeill  wrote:
> >
> > On Tue, 7 May 2019, Markus Kilbinger wrote:
> >
> >> - I was not able to bootarm.efi this kernel from its local ffs2 (!)
> >> netbsd partition on the sdcrad. Is bootarm.efi limited to ffs1?
> >
> > It uses ffs support from libsa, so I would expect it to work (but can't say 
> > that I have tried it on armv7).
>
> ...and it looks like ffsv2 is in the fs ops table in efiboot, so... *boggle*

boogled:

1. I had to disklabel(8) my sdcard (was just fdisk-ed before) to make
bootarm.efi successfully find the kernel on its ffsv2 partition.
W/should be gpt-ing it sufficient, too?

2. Played with bootarm.efi (stored on sdcard) on my cubietruck and a
connected gpt-ed sata disk: u-boot seems to detect it as scsi disk, I
had to "scsi scan" before it and its partitions would be correctly
detected for / by bootarm.efi.
I managed to make bootarm.efi boot from the recognised sata disk by
setting manually "dev hd0b" at its boot prompt (defaults to the sdcard
"hd1a").
After tons of
  CACHE: Misaligned operation at range [bf4cdb70, bf4d1b70]
 messages it finally loaded the kernel from the harddisks ffsv2
partition ("hd0b" aka "dk1") and booted successfully into NetBSD :-).
2.1 How to get rid of the "CACHE..." messages?
2.2 How to instruct bootarm.efi to boot automatically from a
non-standard / -default device / partition?

Regards, Markus.

Re: Hints for Bananapi and -current

[Markus Kilbinger]

Am Di., 7. Mai 2019 um 12:17 Uhr schrieb Jared McNeill :
> [...]
> Now on to the modern boot method..
>
> Using U-Boot 2018.11 or later, setup a FAT partition with the following files 
> on it:
>
>   EFI/BOOT/bootarm.efi
>   your-fdt-file.dtb
>
> U-Boot will automatically launch the UEFI bootloader and you will be 
> presented with a countdown timer. bootarm will load a native ELF kernel (by 
> default /netbsd) from the first FFS partition on the same drive that the 
> loader came from. In addition, bootarm passes information about where to find 
> the root device to the kernel automatically, so you shouldn’t need to specify 
> a root= option. GENERIC and GENERIC64 kernels are setup to automatically use 
> fb when available, so console=fb is also no longer required.

Great news!
It tried / played with that on my bananapro with some limited success:

- I just managed to boot successfully a netbsd elf kernel via network
/ pxe. (How to disable / reorder pxe booting?)

- I was not able to bootarm.efi this kernel from its local ffs2 (!)
netbsd partition on the sdcrad. Is bootarm.efi limited to ffs1?

- In case of a connected sata disk: Is it possible to directly boot
from that via bootarm.efi (or specify explicitly a boot device)?

Once the kernel is found and loaded everything seems to run fine!

Regards, Markus.

Re: New jemalloc problem on evbarm earmv7hf / cubietruck

[Markus Kilbinger]

Am Sa., 30. März 2019 um 23:49 Uhr schrieb Christos Zoulas
:
>
> Markus Kilbinger   wrote:
> >
> >If not already known, with new jemalloc all binaries (e. g. from
> >http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/201903291930Z/evbarm-earmv7hf/binary/sets/)
> >produce following error message on my cubietruck:
> >
> >  : Unsupported system page size
> >  Abort (core dumped)
>
> Should be fixed now.

Confirmed fixed in new userland!

Thanks, Markus.

npf blocks ipv6 fragmented packets (?)

[Markus Kilbinger]

Hi!

While playing with npf I noticed that some (fragmented) ipv6 packets
would not be passed.

Tracking it down (a bit) i've found that simply activating npf without any rule

  ntpctl start

'blocks' a

  ping6 -s 2048 testhost

which worked w/o npf aktivated flawlessly.
BTW: ipv4 fragmented packets seems to be handled correctly under npf
('ping -s 2048' works).
This happens under HEAD and netbsd-7.

Is this a known limitation of npf? Or a bug?
Send-pr?

Regards, Markus.

base.tgz no longer contains './bin/[' (in HEAD and netbsd-7)

[Markus Kilbinger]

Hi!

While looking for old / outdated binaries in userland I noticed that
'./bin/[' is no longer updated / part of base.tgz (or any other *.tgz
file) in HEAD and netbsd-7, though it still seems to be listed in
'src/distrib/sets/lists/base/mi'.

Is this a known bug?

Otherwise I can send-pr ...

Regards,

Markus.