Re: ffmpeg6 and SSP?

[pin]

On Tuesday, November 14th, 2023 at 8:48 AM, Vitaly Shevtsov  
wrote:


> Hello!
> 
> What if you put -D_FORTIFY_SOURCE=0 into Makefile, will it help?

Won't know until I try :)
Will have to wait a bit, though ... currently building firefox.

If someone else can try before tomorrow, it would be great.
Else, I can test it.

Re: ffmpeg6 and SSP?

[pin]

Hi all,

I've reported off-list to wiz@ that building ffmpeg6 on current from Saturday 
Nov. 11 2023 failed for me.

The error is/was the same as reported here, 
https://mail-index.netbsd.org/pkgsrc-users/2023/11/13/msg038461.html

I can now confirm that downgrading userland to Nov. 8 2023 allows the build to 
complete successfully.
It's highly likely the issue is related to the changes introduced to ssp on 
Nov. 10 2023

Regards,

Excessive sleep time

[pin]

Hi,

On current since amd64 since August 28, I get the following at boot,

[ 1.037893] ACPI Warning: Firmware issue: Excessive sleep time 
(0x0064 ms > 10 ms) in ACPI Control Method (20220331/exsystem-239)
[ 1.037893] ACPI Warning: Firmware issue: Excessive sleep time 
(0x0064 ms > 10 ms) in ACPI Control Method (20220331/exsystem-239)
[ 1.037893] ACPI Warning: Firmware issue: Excessive sleep time 
(0x0064 ms > 10 ms) in ACPI Control Method (20220331/exsystem-239)
[ 1.037893] ACPI Warning: Firmware issue: Excessive sleep time 
(0x0064 ms > 10 ms) in ACPI Control Method (20220331/exsystem-239)
[ 1.037893] ACPI Warning: Firmware issue: Excessive sleep time 
(0x005A ms > 10 ms) in ACPI Control Method (20220331/exsystem-239)
[ 1.037893] ACPI Warning: Firmware issue: Excessive sleep time 
(0x005A ms > 10 ms) in ACPI Control Method (20220331/exsystem-239)
[ 1.037893] ACPI Warning: Firmware issue: Excessive sleep time 
(0x005A ms > 10 ms) in ACPI Control Method (20220331/exsystem-239)
[ 1.037893] ACPI Warning: Firmware issue: Excessive sleep time 
(0x005A ms > 10 ms) in ACPI Control Method (20220331/exsystem-239)
[ 1.037893] ACPI Warning: Firmware issue: Excessive sleep time 
(0x005A ms > 10 ms) in ACPI Control Method (20220331/exsystem-239)
[ 1.037893] ACPI Warning: Firmware issue: Excessive sleep time 
(0x005A ms > 10 ms) in ACPI Control Method (20220331/exsystem-239)
[ 1.037893] ACPI Warning: Firmware issue: Excessive sleep time 
(0x005A ms > 10 ms) in ACPI Control Method (20220331/exsystem-239)
[ 1.037893] ACPI Warning: Firmware issue: Excessive sleep time 
(0x005A ms > 10 ms) in ACPI Control Method (20220331/exsystem-239)
[ 1.037893] ACPI Warning: Firmware issue: Excessive sleep time 
(0x005A ms > 10 ms) in ACPI Control Method (20220331/exsystem-239)

The system works fine but, these were not there before. I usually upgrade the 
base system once a week.
Right now,

~ > uname -v
NetBSD 9.99.99 (GENERIC) #0: Fri Sep  2 06:51:24 UTC 2022  
mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC

Any clues?
Thanks!

Sent with Proton Mail secure email.

Spotify issues

[pin]

Hi all,

Since a week or so ago, I have been having issues playing any tracks using 
spotify-player.
The issue has been confirmed/reproduced on ncspot by Leot, thanks!

The problem is actually at Spotify's end (channel errors).
If you are interested in the details read about it here, 
https://github.com/librespot-org/librespot/issues/972

The situation for NetBSD users on the available players
-audio/librespot
-audio/ncspot
-audio/spotify-player
-audio/spotify-qt

is the following,

-Users on 2022Q2 using any of the available players are affected
-Users on pkgsrc-current are affected if using ncspot and/or spotify-player

Current users using librespot or spotify-qt should be fine.
I've merged librespot 0.4.2 a few days ago which, fixes the issue.

Going forward:
-I've been in touch with spotify-player upstream and they are preparing a new 
release bumping librespot to 0.4.2
-ncspot-0.10.1 already has librespot-0.4.2, unfortunately I can not merge the 
update as it requires Rust-1.62.1 to build.

Work around:
Add the following line to /etc/hosts

104.199.65.124  ap-gew4.spotify.com

will allow you to stream Spotify as usual.
Remember to remove the line once you have a player using librespot-0.4.2 
installed.

Regards,
pin

core-dump on 9.99.96

[pin]

Hi,

First of all, the system is much more stable then back in January, thanks to 
@riastradh

Now I get a core-dump maybe once a week.
Today I got one an thought it would be good to report.

$ uname -a
NetBSD mybox 9.99.96 NetBSD 9.99.96 (GENERIC) #0: Mon May  9 21:41:49 UTC 2022  
mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64

$ sysctl hw.machine_arch hw.model hw.ncpu
hw.machine_arch = x86_64
hw.model = Intel 686-class
hw.ncpu = 4

pin:var/crash/ $ ls
.rw--- root wheel   2 B  Wed May 11 20:55:28 2022   bounds
.rw--- root wheel  93 MB Wed May 11 20:55:58 2022   netbsd.0.core.gz
.rw--- root wheel 840 KB Wed May 11 20:55:59 2022   netbsd.0.gz
pin:var/crash/ $ su
Password:
pin:var/crash/ # gunzip -d *.gz
pin:var/crash/ # gdb --eval-command="file /netbsd" --eval-command="target kvm 
netbsd.0.core" --eval-command "bt"
GNU gdb (GDB) 11.0.50.20200914-git
Copyright (C) 2020 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 "x86_64--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 /netbsd...
Reading symbols from /usr/libdata/debug//netbsd-GENERIC.debug...
0x802261f5 in cpu_reboot (howto=howto@entry=260, 
bootstr=bootstr@entry=0x0) at /usr/src/sys/arch/amd64/amd64/machdep.c:720
720 /usr/src/sys/arch/amd64/amd64/machdep.c: No such file or directory.
#0  0x802261f5 in cpu_reboot (howto=howto@entry=260, 
bootstr=bootstr@entry=0x0) at /usr/src/sys/arch/amd64/amd64/machdep.c:720
#1  0x80da58a4 in kern_reboot (howto=howto@entry=260, 
bootstr=bootstr@entry=0x0) at /usr/src/sys/kern/kern_reboot.c:73
#2  0x80deb7bd in vpanic (fmt=0x81393f88 "kernel %sassertion 
\"%s\" failed: file \"%s\", line %d ", ap=ap@entry=0xa280c93d8eb8) at 
/usr/src/sys/kern/subr_prf.c:293
#3  0x80fad72f in kern_assert (fmt=fmt@entry=0x81393f88 "kernel 
%sassertion \"%s\" failed: file \"%s\", line %d ") at 
/usr/src/sys/lib/libkern/kern_assert.c:51
#4  0x80d718e2 in cv_broadcast (cv=0xa280db7b2c50) at 
/usr/src/sys/kern/kern_condvar.c:511
#5  0x80f3ee3f in linux___dma_fence_signal_wake 
(fence=0xe1f3f61da340, timestamp=) at 
/usr/src/sys/external/bsd/drm2/linux/linux_dma_fence.c:1176
#6  0x807a510f in signal_irq_work (work=0xa280128691e8) at 
/usr/src/sys/external/bsd/drm2/dist/drm/i915/gt/intel_breadcrumbs.c:218
#7  0x80f43a38 in irq_work_intr (cookie=) at 
/usr/src/sys/external/bsd/drm2/linux/linux_irq_work.c:74
#8  0x80db49c2 in softint_execute (s=5, l=0xe1f57bb1c4c0) at 
/usr/src/sys/kern/kern_softint.c:565
#9  softint_dispatch (pinned=, s=5) at 
/usr/src/sys/kern/kern_softint.c:818
#10 0x80220e3f in Xsoftintr ()
#11 0x653f27eb12da58b1 in ?? ()
#12 0xf347c8997f24105f in ?? ()
#13 0x05ba5d38acb62eec in ?? ()
#14 0x390d9c24d676c2d3 in ?? ()
#15 0xeb56dadab8c27ff3 in ?? ()
#16 0x66e9e74123dc0b24 in ?? ()
#17 0xa2c6a286a2c6a2c6 in ?? ()
#18 0xbb4197f5b69f7d3b in ?? ()
#19 0xdb8920536683a17b in ?? ()
#20 0xb6c7d59f13ee9d8d in ?? ()
#21 0x9a9c634158953b33 in ?? ()
#22 0x4ce88ad906ba1e7c in ?? ()
#23 0x199230d8724cc765 in ?? ()
#24 0x6ab9d258afb07cad in ?? ()
#25 0x6983698fe9c36983 in ?? ()
#26 0xeaf94a9ac027fd8a in ?? ()
#27 0xe37827082bbab3ec in ?? ()
--Type  for more, q to quit, c to continue without paging--

Re: NetBSD-9.99.93 crashes regularly when using web browsers

[pin]

--- Original Message ---

On Tuesday, February 15th, 2022 at 10:24 AM, Mandacarú Cascavel 
 wrote:

> The same happens in my machine, a Lenovo ideapad (amd64). vimb and
>
> epiphany make the system freeze and reboot. I suspect something similar
>
> is happening to mate and xfce4 sessions.
>
> Thanks
>
> Cascavel


Thank you both for confirming this.
It would be nice if everyone seeing this, could also provide debug information.

Anything that can narrow down the issue and help the people working with the 
kernel.

Thanks!

Re: NetBSD-9.99.93 crashes regularly when using web browsers

[pin]

Yet another,

Reading symbols from /netbsd...
Reading symbols from /usr/libdata/debug//netbsd-GENERIC.debug...
0x802261f5 in cpu_reboot (howto=howto@entry=260, 
bootstr=bootstr@entry=0x0) at /usr/src/sys/arch/amd64/amd64/machdep.c:720
720 /usr/src/sys/arch/amd64/amd64/machdep.c: No such file or directory.
#0  0x802261f5 in cpu_reboot (howto=howto@entry=260, 
bootstr=bootstr@entry=0x0) at /usr/src/sys/arch/amd64/amd64/machdep.c:720
#1  0x80dc6944 in kern_reboot (howto=howto@entry=260, 
bootstr=bootstr@entry=0x0) at /usr/src/sys/kern/kern_reboot.c:73
#2  0x80e09862 in vpanic (fmt=fmt@entry=0x81391870 "trap", 
ap=ap@entry=0xdd00da923c78) at /usr/src/sys/kern/subr_prf.c:290
#3  0x80e09927 in panic (fmt=fmt@entry=0x81391870 "trap") at 
/usr/src/sys/kern/subr_prf.c:209
#4  0x80229017 in trap (frame=0xdd00da923dc0) at 
/usr/src/sys/arch/amd64/amd64/trap.c:326
#5  0x802210e3 in alltraps ()
#6  0x in ?? ()
#7  0x8a3705c04d00 in ?? ()
#8  0x in ?? ()

--- Original Message ---

On Monday, February 14th, 2022 at 9:53 AM, pin  wrote:
...

NetBSD-9.99.93 crashes regularly when using web browsers

[pin]

 in genfs_getpages (v=0xc500dbef2638) at 
/usr/src/sys/miscfs/genfs/genfs_io.c:373
#13 0x80e84cc2 in VOP_GETPAGES (vp=vp@entry=0x8508e0ee7300, 
offset=offset@entry=31457280, m=m@entry=0xc500dbef27d0, 
count=count@entry=0xc500dbef27c4,
centeridx=centeridx@entry=0, access_type=, 
advice=advice@entry=0, flags=flags@entry=7718) at 
/usr/src/sys/kern/vnode_if.c:1874
#14 0x80d820d3 in uvn_get (uobj=0x8508e0ee7300, offset=31457280, 
pps=0xc500dbef27d0, npagesp=0xc500dbef27c4, centeridx=0, 
access_type=, advice=0,
flags=7718) at /usr/src/sys/uvm/uvm_vnode.c:189
#15 0x80d5dffc in ubc_alloc_direct (uobj=uobj@entry=0x8508e0ee7300, 
offset=offset@entry=31457280, lenp=lenp@entry=0xc500dbef27c8, 
advice=advice@entry=0,
flags=flags@entry=6, pgs=pgs@entry=0xc500dbef27d0, 
npages=npages@entry=0xc500dbef27c4) at /usr/src/sys/uvm/uvm_bio.c:880
#16 0x80d5e421 in ubc_uiomove_direct (uobj=0x8508e0ee7300, 
uobj@entry=0xc500dbef29e0, uio=0xc500dbef29e0, uio@entry=0xdbef29e0, 
todo=16384, advice=advice@entry=0,
flags=6) at /usr/src/sys/uvm/uvm_bio.c:995
#17 0x80d5ff87 in ubc_uiomove (uobj=0xc500dbef29e0, 
uobj@entry=0x8508e0ee7300, uio=0xdbef29e0, uio@entry=0xc500dbef29e0, 
todo=, advice=advice@entry=0,
flags=) at /usr/src/sys/uvm/uvm_bio.c:765
#18 0x80d16a59 in ffs_write (v=) at 
/usr/src/sys/ufs/ufs/ufs_readwrite.c:409
#19 0x80e836cf in VOP_WRITE (vp=vp@entry=0x8508e0ee7300, 
uio=uio@entry=0xc500dbef29e0, ioflag=ioflag@entry=144, 
cred=cred@entry=0x8508c3de4580) at /usr/src/sys/kern/vnode_if.c:776
#20 0x80e7b0d3 in vn_rdwr (rw=rw@entry=UIO_WRITE, 
vp=0x8508e0ee7300, base=base@entry=0x7653a602b000, len=len@entry=880640, 
offset=, segflg=,
ioflg=ioflg@entry=144, cred=0x8508c3de4580, aresid=0x0, 
l=0x8508dff85300) at /usr/src/sys/kern/vfs_vnops.c:549
#21 0x80d94cd7 in coredump_write (io=0xc500dbef2c80, 
segflg=, data=0x7653a602b000, len=880640) at 
/usr/src/sys/kern/kern_core.c:341
#22 0x80d85967 in real_coredump_elf64 (l=, 
cookie=0xc500dbef2c80) at /usr/src/sys/kern/core_elf32.c:286
#23 0x80dd3098 in coredump_elf64 (l=0x8508dff85300, 
iocookie=0xc500dbef2c80) at /usr/src/sys/kern/kern_sig.c:2392
#24 0x80d95324 in coredump (l=0x8508dff85300, pattern=) at /usr/src/sys/kern/kern_core.c:280
#25 0x80dd29c0 in sigexit (l=l@entry=0x8508dff85300, 
signo=signo@entry=11) at /usr/src/sys/kern/kern_sig.c:2320
#26 0x80dd2e9a in postsig (signo=11) at 
/usr/src/sys/kern/kern_sig.c:2142
#27 0x80db5199 in lwp_userret (l=l@entry=0x8508dff85300) at 
/usr/src/sys/kern/kern_lwp.c:1633
#28 0x80228328 in mi_userret (l=l@entry=0x8508dff85300) at 
/usr/src/sys/sys/userret.h:96
#29 0x8022861d in userret (l=0x8508dff85300) at 
./machine/userret.h:81
#30 trap (frame=0xc500dbef3000) at /usr/src/sys/arch/amd64/amd64/trap.c:664
#31 0x802210e3 in alltraps ()
#32 0x7653a41b6268 in ?? ()
#33 0x33223b0ff2c0 in ?? ()
#34 0x0001 in ?? ()
#35 0x7f7fffc4ebe8 in ?? ()
#36 0x7f7fffc4eb08 in ?? ()
#37 0xfff98000 in ?? ()
#38 0x in ?? ()

Thanks!
/pin

Re: Recent install images do not install netbsd.gdb

[pin]

‐‐‐ Original Message ‐‐‐

On Saturday, January 15th, 2022 at 17:03, Martin Husemann  
wrote:

> On Sat, Jan 15, 2022 at 03:54:43PM +0000, pin wrote:
>
> > But, just so to clarify. The debug set is not pulled by sysinst and
> >
> > it used to be.
>
> I think it never was unless you manually select it in the sets menu.

Honestly, I don't remember doing anything different on my installation on very 
late December. But, maybe I forgot.


> The debug set does not strictly add functionality, so even a "full"
>
> install does not use it by default. Yes, this is confusing (and I think
>
> there even is a PR about it). Better names welcome.

I think it's fine. Usually, I don't need the debug set. Unfortunately, I do now.

> Maybe we should add a "Full with debug" meta-choice or even rename "Full"
>
> to "Full but no debug".
>
> Also many images come w/o the debug sets (to save space on the media
>
> and for the dowload, and sometimes allow the result to be put on CD
>
> instead of DVD).


It makes sense. I always use usb these days. I don't even have a CD drive on my 
laptop.

>
> Martin

Thanks.

Re: Recent install images do not install netbsd.gdb

[pin]

Thank you both.

I've fetched the debug sets now and unpack them into place.
So, I can try to get a backtrace next time I get a coredump.

But, just so to clarify. The debug set is not pulled by sysinst and it used to 
be.

Re: Recent install images do not install netbsd.gdb

[pin]

> You did not update that recently, did you?
>
> This is with the latest download form nycdn:
>
> https://nycdn.NetBSD.org/pub/NetBSD-daily/HEAD/latest/amd64/binary/sets/debug.tar.xz
>
> > tar tvzf debug.tar.xz | fgrep netbsd-
>
> -r--r--r-- 0 root bin 179990264 Jan 15 00:56 
> ./usr/libdata/debug/netbsd-GENERIC.debug
>
> -r--r--r-- 0 root bin 42711 Jan 15 00:56 
> ./usr/libdata/debug/netbsd-GENERIC_KASLR.debug
>
> -r--r--r-- 0 root bin 96391120 Jan 15 00:56 
> ./usr/libdata/debug/netbsd-INSTALL.debug
>
> -r--r--r-- 0 root bin 42729512 Jan 15 00:56 
> ./usr/libdata/debug/netbsd-INSTALL_XEN3_DOMU.debug
>
> -r--r--r-- 0 root bin 94179320 Jan 15 00:56 
> ./usr/libdata/debug/netbsd-XEN3_DOM0.debug
>
> -r--r--r-- 0 root bin 42722960 Jan 15 00:56 
> ./usr/libdata/debug/netbsd-XEN3_DOMU.debug
>
> [...]
>
> Martin

Thanks for checking.
This is weird, though.
I've just downloaded the most recent image from nycdn, booted it and let 
sysinst ugrade the whole system.
Yes, full installation from the image.

Rebooted and those are not installed.
I can fetch them using ftp and unpack them into place of course.

Re: Recent install images do not install netbsd.gdb

[pin]

> The kernel debug symbols are installed in 
> /usr/libdata/netbsd-.debug and

Now I'm feeling stupid. These is the default content of /usr/libdata directory,

$ ls -la
total 24
drwxr-xr-x   6 root  wheel   512 Jan  8 18:25 .
drwxr-xr-x  16 root  wheel   512 Jan 13 11:01 ..
drwxr-xr-x   8 root  wheel   512 Jan  8 18:25 debug
drwxr-xr-x   3 root  wheel   512 Jan  8 18:25 firmware
drwxr-xr-x   2 root  wheel  1536 Jan 12 10:03 ldscripts
drwxr-xr-x   3 root  wheel   512 Jan  8 18:25 lint
$ cd debug/
$ ls -la
total 32
drwxr-xr-x   8 root  wheel  512 Jan  8 18:25 .
drwxr-xr-x   6 root  wheel  512 Jan  8 18:25 ..
drwxr-xr-x   2 root  wheel  512 Jan  8 18:25 bin
drwxr-xr-x   4 root  wheel  512 Jan  8 18:25 lib
drwxr-xr-x   2 root  wheel  512 Jan  8 18:25 libexec
drwxr-xr-x   2 root  wheel  512 Jan  8 18:25 sbin
drwxr-xr-x   2 root  wheel  512 Jan  8 18:25 stand
drwxr-xr-x  10 root  wheel  512 Jan 12 10:04 usr

Re: Recent install images do not install netbsd.gdb

[pin]

>> What should I run now instead?

> If you have MKDEBUG set in your build or have installed the debug sets:

Thanks!
I don't think I follow, though. Sorry.

I didn't build this kernel, the system was installed from a daily-build image.

> # gdb --eval-command="file /netbsd" --eval-command="target kvm

Do you mean the debug symbols are baked into the kernel now?

> Now, there should be also be a netbsd.gdb in the sets if you have 
> MKDEBUGKERNEL
> defined.

I did run
# find / -name netbds.gdb

and it returned nothing.

> christos

Re: Recent install images do not install netbsd.gdb

[pin]

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐

On Friday, January 14th, 2022 at 12:15 PM, Martin Husemann  
wrote:


> The debug information moved, it is now stored in an external debug file
>
> in /usr/libdata/debug.
>
> Martin

Thank you!
But, where is netbsd.gdb located? I can't find it.
I used to run

# gdb --eval-command="file /netbsd.gdb" --eval-command="target kvm 
netbsd.0.core" --eval-command "bt"

What should I run now instead?

Thanks!

Recent install images do not install netbsd.gdb

[pin]

Hi,

As the title says, why is this the case?
I had an install done from an image a day or two into January 2022 and it 
included /netbsd.gdb

Unfortunately, my system is still unstable and several crashes and core dumps 
later, I got fs corruption.
So, I did a clean install.

$ uname -v
NetBSD 9.99.93 (GENERIC) #0: Sat Jan 8 17:25:19 UTC 2022 
mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC

and /netbsd.gdb is missing.
Just got a crash and was about to try to get a backtrace but, it seems that if 
I want to have /netbsd.gdb I need to compile the kernel from source.

I'll do this now but, thought I'd point-out this differnce.

Regards,
pin

Re: Serious crashes on 9.99.93

[pin]

‐‐‐ Original Message ‐‐‐

On Thursday, December 30th, 2021 at 11:21 AM, Yorick Hardy 
 wrote:

> Dear current-users,
>
> I tried to reproduce the problems that pin is seeing. I seldom got
>
> as far as the web browser, but did get the following backtraces:
>
> Crash version 9.99.42, image version 9.99.93.
>
> WARNING: versions differ, you may not be able to examine this image.
>
> System panicked: pr_phinpage_check: [i915_request] item 0x939b82a4f840 
> not part of pool
>
> Backtrace from time of crash is available.
>
> _KERNEL_OPT_GENFB_GLYPHCACHE() at 0
>
> _KERNEL_OPT_GENFB_GLYPHCACHE() at 0
>
> sys_reboot() at sys_reboot
>
> vpanic() at vpanic+0x160
>
> device_printf() at device_printf
>
> pool_cache_put_paddr() at pool_cache_put_paddr+0x14f
>
> linux_dma_resv_fini() at linux_dma_resv_fini+0x55
>
> __i915_gem_free_object_rcu() at __i915_gem_free_object_rcu+0x45
>
> gc_thread() at gc_thread+0x92
>
> Crash version 9.99.42, image version 9.99.93.
>
> WARNING: versions differ, you may not be able to examine this image.
>
> System panicked: trap
>
> Backtrace from time of crash is available.
>
> _KERNEL_OPT_GENFB_GLYPHCACHE() at 0
>
> ?() at bf014f2a
>
> sys_reboot() at sys_reboot
>
> vpanic() at vpanic+0x160
>
> device_printf() at device_printf
>
> startlwp() at startlwp
>
> calltrap() at calltrap+0x19
>
> ffs_sync() at ffs_sync+0x75
>
> VFS_SYNC() at VFS_SYNC+0x22
>
> sched_sync() at sched_sync+0x90
>
> Could the first backtrace be a clue? Changes were made in this area after the 
> 15th,
>
> which is when pin still had a stable kernel.


Taylor suggested off-list that my issues looked like faulty memory.
Initially, I found it hard to believe as the crash only took place when 
launching the web browser.
Also, I had no issues the day before while running 9.99.92 from the 15th of 
December.

Moreover, I did a few memory tests and they all passed. Did also check if there 
were any available
updates to my BIOS and performed an SSD test on my drive. All good.

Taylor still insisted on faulty memory and to compile a kernel with some 
non-default options enabled.

It was although easier to open the lid of my laptop and replace the 2x4Gb RAM 
chips with a 8Gb one
I had in a box.

Surprise, no crashes until now. I used the browser for about 15 min, so not 
that extensive.
I wish to keep this thread alive until I have had the time to test this further 
and because Yorick
still experiences crashes.

That said, it will be a few days until I can do this. I did a clean re-install 
and need to set-up
my system as I like. It means building rust and leftwm-git and it's new year 
soon.

Btw, Happy New Year to all of you and thanks for all the support.

Regards,
pin

Re: Serious crashes on 9.99.93

[pin]

‐‐‐ Original Message ‐‐‐

Unfortunately, I had to wipe my disk due to a corrupted file system.
I did a fresh install using the 9.99.93 image from today 28-Dec-2021 08:57

The same crash happened the first time I launched the web browser.
This time I got a stack backtrace, as follows:


pin@mybox # pwd
/var/crash
pin@mybox # ls -l
total 797032
-rw---  1 root  wheel  2 Dec 28 20:41 bounds
-rw---  1 root  wheel  5 Dec 28 00:19 minfree
-rw---  1 root  wheel2332254 Dec 28 20:41 netbsd.0
-rw---  1 root  wheel  405485080 Dec 28 20:41 netbsd.0.core
pin@mybox # gdb --eval-command="file /netbsd.gdb"
GNU gdb (GDB) 11.0.50.20200914-git
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
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 "x86_64--netbsd".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
Reading symbols from /netbsd.gdb...
(gdb) target kvm netbsd.0.core
0x802261f5 in cpu_reboot (howto=howto@entry=260, 
bootstr=bootstr@entry=0x0) at /usr/src/sys/arch/amd64/amd64/machdep.c:720
720 /usr/src/sys/arch/amd64/amd64/machdep.c: No such file or directory.
(gdb) bt
#0  0x802261f5 in cpu_reboot (howto=howto@entry=260, 
bootstr=bootstr@entry=0x0) at /usr/src/sys/arch/amd64/amd64/machdep.c:720
#1  0x80dbcd54 in kern_reboot (howto=howto@entry=260, 
bootstr=bootstr@entry=0x0) at /usr/src/sys/kern/kern_reboot.c:73
#2  0x80dffcf2 in vpanic (fmt=fmt@entry=0x81390370 "trap", 
ap=ap@entry=0x8580b77ebab8) at /usr/src/sys/kern/subr_prf.c:290
#3  0x80dffdb7 in panic (fmt=fmt@entry=0x81390370 "trap") at 
/usr/src/sys/kern/subr_prf.c:209
#4  0x80229017 in trap (frame=0x8580b77ebc00) at 
/usr/src/sys/arch/amd64/amd64/trap.c:326
#5  0x802210e3 in alltraps ()
#6  0xff404040ff404040 in ?? ()
#7  0x0019 in ?? ()
#8  0x80f752dea000 in ?? ()
#9  0x in ?? ()
(gdb)



This did not happen before on 9.99.92 up to the 15th of December.
Hope that this is useful.

Best Regards

Re: Serious crashes on 9.99.93

[pin]

‐‐‐ Original Message ‐‐‐

On Tuesday, December 28th, 2021 at 17:31, Yorick Hardy  
wrote:

> Dear pin,
>
> On 2021-12-28, pin wrote:
>
> > Sent with ProtonMail Secure Email.
> >
> > ‐‐‐ Original Message ‐‐‐
> >
> > On Tuesday, December 28th, 2021 at 16:29, Yorick Hardy 
> > yorickha...@gmail.com wrote:
> >
> > > Dear pin,
> > >
> > > On 2021-12-27, pin wrote:
> > >
> > > > Hi all,
> > > >
> > > > I've upgraded my amd64 machine to NetBSD-9.99.93 yesterday and I'm 
> > > > experience serious crashes which were not happening on 9.99.92.
> > > >
> > > > dmesg, https://pastebin.com/8WJeUJDj
> > > >
> > > > Xorg-log, https://pastebin.com/xTAmUZPU
> > > >
> > > > The backtraces from the coredumps aren't really useful, 
> > > > https://pastebin.com/eaXYEC0Z
> > > >
> > > > I've managed to reproduce the crashes by launching lariza or badwolf 
> > > > web browsers.
> > > >
> > > > The system runs without issues if I don't use a web browser.
> > > >
> > > > Also, I've noticed the following while booting after a crash
> > > >
> > > > panic: kernel diagnostic assertion "solocked2(so, so2)" failed: file 
> > > > "/usr/src/sys/kern/uipc_usrreq.c", line 525
> > > >
> > > > Finally, unsure if related, console resolution doesn't scale after 
> > > > loading i915drmkms0, it used to in 9.99.92.
> > > >
> > > > Although, resolution after startx is correct.
> > > >
> > > > I've hosted the core-dumps in case,
> > > >
> > > > netbsd.2.core.gz, https://ufile.io/d00lfx4f
> > > >
> > > > netbsd.2.gz, https://ufile.io/4yvklq5w
> > > >
> > > > Thank you for any hints.
> > > >
> > > > Best,
> > > >
> > > > pin
> > > >
> > > > Sent with ProtonMail Secure Email.
> > >
> > > Somehow I managed to get a backtrace (it seems to be correct):
> > >
> > > Crash version 9.99.82, image version 9.99.93.
> > >
> > > WARNING: versions differ, you may not be able to examine this image.
> > >
> > > crash: _kvm_kvatop(0)
> > >
> > > Kernel compiled without options LOCKDEBUG.
> > >
> > > System panicked: kernel diagnostic assertion "solocked2(so, so2)" failed: 
> > > file "/usr/src/sys/kern/uipc_usrreq.c", line 525
> > >
> > > Backtrace from time of crash is available.
> > >
> > > crash> bt
> > >
> > > _KERNEL_OPT_GENFB_GLYPHCACHE() at 0
> > >
> > > _KERNEL_OPT_GENFB_GLYPHCACHE() at 0
> > >
> > > sys_reboot() at sys_reboot
> > >
> > > vpanic() at vpanic+0x160
> > >
> > > __x86_indirect_thunk_rax() at __x86_indirect_thunk_rax
> > >
> > > unp_send() at unp_send+0xa15
> > >
> > > sosend() at sosend+0x845
> > >
> > > soo_write() at soo_write+0x2f
> > >
> > > do_filewritev.part.0() at do_filewritev.part.0+0x25d
> > >
> > > syscall() at syscall+0x196
> > >
> > > --- syscall (number 121) ---
> > >
> > > syscall+0x196:
> > >
> > > crash>
> > >
> > > the last change I could find which might be relevant was in 
> > > sys/kern/sys_generic.c 1.133, but that
> > >
> > > was before 9.99.93, so I am not sure where to look.
> > >
> > > Kind regards,
> > >
> > > Yorick Hardy
> >
> > Thanks!
> >
> > Was this change made in 9.99.92 after the 15th of December?
> >
> > Until the above date this did not happen.
> >
> > Regards
>
> 11 September, so: long before! But thanks, I will continue to look
>
> for any changes after 15 December (I am sure someone more knowledgeable
>
> will find it, but I will have a go in the mean time).
>
> -
>
> Kind regards,
>
> Yorick Hardy

Thank you!

I've managed to get out netbsd.gdb from the system, https://ufile.io/httct5ef

Re-installing now, got a corrupted fs.

Best Regards

Re: Serious crashes on 9.99.93

[pin]

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐

On Tuesday, December 28th, 2021 at 16:29, Yorick Hardy  
wrote:

> Dear pin,
>
> On 2021-12-27, pin wrote:
>
> > Hi all,
> >
> > I've upgraded my amd64 machine to NetBSD-9.99.93 yesterday and I'm 
> > experience serious crashes which were not happening on 9.99.92.
> >
> > dmesg, https://pastebin.com/8WJeUJDj
> >
> > Xorg-log, https://pastebin.com/xTAmUZPU
> >
> > The backtraces from the coredumps aren't really useful, 
> > https://pastebin.com/eaXYEC0Z
> >
> > I've managed to reproduce the crashes by launching lariza or badwolf web 
> > browsers.
> >
> > The system runs without issues if I don't use a web browser.
> >
> > Also, I've noticed the following while booting after a crash
> >
> > panic: kernel diagnostic assertion "solocked2(so, so2)" failed: file 
> > "/usr/src/sys/kern/uipc_usrreq.c", line 525
> >
> > Finally, unsure if related, console resolution doesn't scale after loading 
> > i915drmkms0, it used to in 9.99.92.
> >
> > Although, resolution after startx is correct.
> >
> > I've hosted the core-dumps in case,
> >
> > netbsd.2.core.gz, https://ufile.io/d00lfx4f
> >
> > netbsd.2.gz, https://ufile.io/4yvklq5w
> >
> > Thank you for any hints.
> >
> > Best,
> >
> > pin
> >
> > Sent with ProtonMail Secure Email.
>
> Somehow I managed to get a backtrace (it seems to be correct):
>
> Crash version 9.99.82, image version 9.99.93.
>
> WARNING: versions differ, you may not be able to examine this image.
>
> crash: _kvm_kvatop(0)
>
> Kernel compiled without options LOCKDEBUG.
>
> System panicked: kernel diagnostic assertion "solocked2(so, so2)" failed: 
> file "/usr/src/sys/kern/uipc_usrreq.c", line 525
>
> Backtrace from time of crash is available.
>
> crash> bt
>
> _KERNEL_OPT_GENFB_GLYPHCACHE() at 0
>
> _KERNEL_OPT_GENFB_GLYPHCACHE() at 0
>
> sys_reboot() at sys_reboot
>
> vpanic() at vpanic+0x160
>
> __x86_indirect_thunk_rax() at __x86_indirect_thunk_rax
>
> unp_send() at unp_send+0xa15
>
> sosend() at sosend+0x845
>
> soo_write() at soo_write+0x2f
>
> do_filewritev.part.0() at do_filewritev.part.0+0x25d
>
> syscall() at syscall+0x196
>
> --- syscall (number 121) ---
>
> syscall+0x196:
>
> crash>
>
> the last change I could find which might be relevant was in 
> sys/kern/sys_generic.c 1.133, but that
>
> was before 9.99.93, so I am not sure where to look.
>
> --
>
> Kind regards,
>
> Yorick Hardy

Thanks!

Was this change made in 9.99.92 after the 15th of December?

Until the above date this did not happen.

Regards

Serious crashes on 9.99.93

[pin]

Hi all,
I've upgraded my amd64 machine to NetBSD-9.99.93 yesterday and I'm experience 
serious crashes which were not happening on 9.99.92.
dmesg, https://pastebin.com/8WJeUJDj
Xorg-log, https://pastebin.com/xTAmUZPU

The backtraces from the coredumps aren't really useful, 
https://pastebin.com/eaXYEC0Z

I've managed to reproduce the crashes by launching lariza or badwolf web 
browsers.
The system runs without issues if I don't use a web browser.
Also, I've noticed the following while booting after a crash

panic: kernel diagnostic assertion "solocked2(so, so2)" failed: file 
"/usr/src/sys/kern/uipc_usrreq.c", line 525

Finally, unsure if related, console resolution doesn't scale after loading 
i915drmkms0, it used to in 9.99.92.
Although, resolution after startx is correct.

I've hosted the core-dumps in case,
netbsd.2.core.gz, https://ufile.io/d00lfx4f
netbsd.2.gz, https://ufile.io/4yvklq5w

Thank you for any hints.
Best,
pin

Sent with ProtonMail Secure Email.