Re: gnucash coredump on startup
On Sat, Jan 07, 2023 at 03:42:00PM -, Christos Zoulas wrote: > In article , > Thomas Klausner wrote: > >Hi! > > > >I've just replaced my 10.99.2/20221231 userland (kernel slightly > >older, but also 10.99.2) with a 10.99.2/20230107 kernel+userland. > > > >Now gnucash dumps core on startup: > > Could be rtld related. Can you try with the older ld_elf.so? I can't go back with just that one, but I did the following test: Downgraded my whole userland to 20221231: gnucash works install ld_elf.so from 20230107: gnucash dumps core install ld_elf.so from 20221231: gnucash works So yes, definitely an issue in ld_elf.so :) Thomas
Re: ldscripts not cleaned up
In article , Thomas Klausner wrote: >On Sun, Jan 08, 2023 at 08:48:24PM -, Christos Zoulas wrote: >> In article , >> Thomas Klausner wrote: >> >Hi! >> > >> >NetBSD after the switch to binutils 2.39 does not install the >> >following files any longer, but they are not marked as obsolete >> >either: >> > >> >/usr/libdata/ldscripts/elf_k1om.x >> >/usr/libdata/ldscripts/elf_k1om.xbn >> >/usr/libdata/ldscripts/elf_k1om.xc >> >/usr/libdata/ldscripts/elf_k1om.xd >> >/usr/libdata/ldscripts/elf_k1om.xdc >> >/usr/libdata/ldscripts/elf_k1om.xdw >> >/usr/libdata/ldscripts/elf_k1om.xn >> >/usr/libdata/ldscripts/elf_k1om.xr >> >/usr/libdata/ldscripts/elf_k1om.xs >> >/usr/libdata/ldscripts/elf_k1om.xsc >> >/usr/libdata/ldscripts/elf_k1om.xsw >> >/usr/libdata/ldscripts/elf_k1om.xu >> >/usr/libdata/ldscripts/elf_k1om.xw >> >/usr/libdata/ldscripts/elf_l1om.x >> >/usr/libdata/ldscripts/elf_l1om.xbn >> >/usr/libdata/ldscripts/elf_l1om.xc >> >/usr/libdata/ldscripts/elf_l1om.xd >> >/usr/libdata/ldscripts/elf_l1om.xdc >> >/usr/libdata/ldscripts/elf_l1om.xdw >> >/usr/libdata/ldscripts/elf_l1om.xn >> >/usr/libdata/ldscripts/elf_l1om.xr >> >/usr/libdata/ldscripts/elf_l1om.xs >> >/usr/libdata/ldscripts/elf_l1om.xsc >> >/usr/libdata/ldscripts/elf_l1om.xsw >> >/usr/libdata/ldscripts/elf_l1om.xu >> >/usr/libdata/ldscripts/elf_l1om.xw >> > >> >Should new binutils install them, or should they be marked as obsolete? >> > >> They should be marked as obsolete... > >Done! > Thanks, well, only for the platform that has 239 christos
Re: ldscripts not cleaned up
On Sun, Jan 08, 2023 at 08:48:24PM -, Christos Zoulas wrote: > In article , > Thomas Klausner wrote: > >Hi! > > > >NetBSD after the switch to binutils 2.39 does not install the > >following files any longer, but they are not marked as obsolete > >either: > > > >/usr/libdata/ldscripts/elf_k1om.x > >/usr/libdata/ldscripts/elf_k1om.xbn > >/usr/libdata/ldscripts/elf_k1om.xc > >/usr/libdata/ldscripts/elf_k1om.xd > >/usr/libdata/ldscripts/elf_k1om.xdc > >/usr/libdata/ldscripts/elf_k1om.xdw > >/usr/libdata/ldscripts/elf_k1om.xn > >/usr/libdata/ldscripts/elf_k1om.xr > >/usr/libdata/ldscripts/elf_k1om.xs > >/usr/libdata/ldscripts/elf_k1om.xsc > >/usr/libdata/ldscripts/elf_k1om.xsw > >/usr/libdata/ldscripts/elf_k1om.xu > >/usr/libdata/ldscripts/elf_k1om.xw > >/usr/libdata/ldscripts/elf_l1om.x > >/usr/libdata/ldscripts/elf_l1om.xbn > >/usr/libdata/ldscripts/elf_l1om.xc > >/usr/libdata/ldscripts/elf_l1om.xd > >/usr/libdata/ldscripts/elf_l1om.xdc > >/usr/libdata/ldscripts/elf_l1om.xdw > >/usr/libdata/ldscripts/elf_l1om.xn > >/usr/libdata/ldscripts/elf_l1om.xr > >/usr/libdata/ldscripts/elf_l1om.xs > >/usr/libdata/ldscripts/elf_l1om.xsc > >/usr/libdata/ldscripts/elf_l1om.xsw > >/usr/libdata/ldscripts/elf_l1om.xu > >/usr/libdata/ldscripts/elf_l1om.xw > > > >Should new binutils install them, or should they be marked as obsolete? > > > They should be marked as obsolete... Done! Thomas
Re: ldscripts not cleaned up
In article , Thomas Klausner wrote: >Hi! > >NetBSD after the switch to binutils 2.39 does not install the >following files any longer, but they are not marked as obsolete >either: > >/usr/libdata/ldscripts/elf_k1om.x >/usr/libdata/ldscripts/elf_k1om.xbn >/usr/libdata/ldscripts/elf_k1om.xc >/usr/libdata/ldscripts/elf_k1om.xd >/usr/libdata/ldscripts/elf_k1om.xdc >/usr/libdata/ldscripts/elf_k1om.xdw >/usr/libdata/ldscripts/elf_k1om.xn >/usr/libdata/ldscripts/elf_k1om.xr >/usr/libdata/ldscripts/elf_k1om.xs >/usr/libdata/ldscripts/elf_k1om.xsc >/usr/libdata/ldscripts/elf_k1om.xsw >/usr/libdata/ldscripts/elf_k1om.xu >/usr/libdata/ldscripts/elf_k1om.xw >/usr/libdata/ldscripts/elf_l1om.x >/usr/libdata/ldscripts/elf_l1om.xbn >/usr/libdata/ldscripts/elf_l1om.xc >/usr/libdata/ldscripts/elf_l1om.xd >/usr/libdata/ldscripts/elf_l1om.xdc >/usr/libdata/ldscripts/elf_l1om.xdw >/usr/libdata/ldscripts/elf_l1om.xn >/usr/libdata/ldscripts/elf_l1om.xr >/usr/libdata/ldscripts/elf_l1om.xs >/usr/libdata/ldscripts/elf_l1om.xsc >/usr/libdata/ldscripts/elf_l1om.xsw >/usr/libdata/ldscripts/elf_l1om.xu >/usr/libdata/ldscripts/elf_l1om.xw > >Should new binutils install them, or should they be marked as obsolete? > They should be marked as obsolete... christos
Re: NetBSD 10.0_BETA envstat hangs
On 7/01/23 03:47, Mayuresh wrote: On Thu, Jan 05, 2023 at 10:12:27AM +1300, Lloyd Parkes wrote: 2) For the the fact that the device appears to be getting attached to sysmon_envsys(9) even though device configuration failed. I filed for the other two, but did not find the word sysmon_envsys in dmesg. What observation shall I report in the PR? The sysmon_envsys subsystem is an internal kernel API, which is why its manual page is in section 9 of the manual. sysmon_envsys probably doesn't log much (if anything) to the console and so you have to know what's going on behind the scenes before you can have an idea of what to expect, which is an important part of the PR. Sorry. Every device driver has an attach function that is responsible for configuring all the I/O needed to access the hardware and then registering that device with the kernel in some way so that NetBSD can then use the hardware. If the I/O can't be configured, then there is no point trying to register the device with the kernel because the device driver can't access the hardware. With many drivers I would expect that if the dmesg output says "autoconfiguration error", then the device would not be registered with the kernel. You can verify that acpibat0 has been registered with sysmon_envsys by running "envstat -D", which hopefully won't hang your system. In summary. When I see an "autoconfiguration error" for a device in dmesg, I expect that device to be unavailable. i.e. it won't be reported in "envstat -D". My expectations may be wrong, this wouldn't be the first time. Cheers, Lloyd
lang/guile30 crash in build even without lto [was Re: lang/guile30 build issue: lto support missing in ar/ranlib]
On Sun, Jan 08, 2023 at 12:38:05PM -0500, Greg Troxel wrote: > Thomas Klausner writes: > > > On 10.99.2 after the load sections 2->4 change I see the following > > when building lang/guile30: > > > > ar: libguile_3.0_la-alist.o: plugin needed to handle lto object > > ranlib: .libs/libguile-3.0.a(libguile_3.0_la-alist.o): plugin needed to > > handle lto object > > CCLD guile > > > > and the resulting binary segfaults when run (which also happens during > > the build), backtrace below. > > > > Is there a flag to turn off lto, or can we please get ar/ranlib > > support for lto? > > > > To reproduce, just try building 'lang/guile30'. > > It fails to even build on i386. I have a local patch, pending figuring > it out, to just disable lto. I was unsure if that belonged on only some > arches, but seems best to mass disable and theni figure it out. Ok, I tried that out - the warning is gone, but guile is still crashing. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x799bb2aff3a6 in scm_sloppy_assq () from /scratch/lang/guile30/work/guile-3.0.8/libguile/.libs/libguile-3.0.so.1 (gdb) bt #0 0x799bb2aff3a6 in scm_sloppy_assq () from /scratch/lang/guile30/work/guile-3.0.8/libguile/.libs/libguile-3.0.so.1 #1 0x799bb2b27c28 in scm_hash_fn_ref () from /scratch/lang/guile30/work/guile-3.0.8/libguile/.libs/libguile-3.0.so.1 #2 0x799bb2b15f18 in expand () from /scratch/lang/guile30/work/guile-3.0.8/libguile/.libs/libguile-3.0.so.1 #3 0x799bb2b160c4 in expand_and () from /scratch/lang/guile30/work/guile-3.0.8/libguile/.libs/libguile-3.0.so.1 #4 0x799bb2b16e49 in expand_cond_clauses () from /scratch/lang/guile30/work/guile-3.0.8/libguile/.libs/libguile-3.0.so.1 #5 0x799bb2b16e06 in expand_cond_clauses () from /scratch/lang/guile30/work/guile-3.0.8/libguile/.libs/libguile-3.0.so.1 #6 0x799bb2b15dda in expand () from /scratch/lang/guile30/work/guile-3.0.8/libguile/.libs/libguile-3.0.so.1 #7 0x799bb2b18f7f in expand_letrec_helper () from /scratch/lang/guile30/work/guile-3.0.8/libguile/.libs/libguile-3.0.so.1 #8 0x799bb2b17492 in expand_lambda_star_case () from /scratch/lang/guile30/work/guile-3.0.8/libguile/.libs/libguile-3.0.so.1 #9 0x799bb2b179a9 in expand_lambda_star () from /scratch/lang/guile30/work/guile-3.0.8/libguile/.libs/libguile-3.0.so.1 #10 0x799bb2b1688a in expand_set_x () from /scratch/lang/guile30/work/guile-3.0.8/libguile/.libs/libguile-3.0.so.1 #11 0x799bb2b1618b in expand_sequence () from /scratch/lang/guile30/work/guile-3.0.8/libguile/.libs/libguile-3.0.so.1 #12 0x799bb2b1617c in expand_sequence () from /scratch/lang/guile30/work/guile-3.0.8/libguile/.libs/libguile-3.0.so.1 #13 0x799bb2b1617c in expand_sequence () from /scratch/lang/guile30/work/guile-3.0.8/libguile/.libs/libguile-3.0.so.1 #14 0x799bb2b1617c in expand_sequence () from /scratch/lang/guile30/work/guile-3.0.8/libguile/.libs/libguile-3.0.so.1 #15 0x799bb2b1617c in expand_sequence () from /scratch/lang/guile30/work/guile-3.0.8/libguile/.libs/libguile-3.0.so.1 #16 0x799bb2b1617c in expand_sequence () from /scratch/lang/guile30/work/guile-3.0.8/libguile/.libs/libguile-3.0.so.1 #17 0x799bb2b1617c in expand_sequence () from /scratch/lang/guile30/work/guile-3.0.8/libguile/.libs/libguile-3.0.so.1 #18 0x799bb2b1617c in expand_sequence () from /scratch/lang/guile30/work/guile-3.0.8/libguile/.libs/libguile-3.0.so.1 #19 0x799bb2b1617c in expand_sequence () from /scratch/lang/guile30/work/guile-3.0.8/libguile/.libs/libguile-3.0.so.1 #20 0x799bb2b1617c in expand_sequence () from /scratch/lang/guile30/work/guile-3.0.8/libguile/.libs/libguile-3.0.so.1 #21 0x799bb2b1617c in expand_sequence () from /scratch/lang/guile30/work/guile-3.0.8/libguile/.libs/libguile-3.0.so.1 #22 0x799bb2b1617c in expand_sequence () from /scratch/lang/guile30/work/guile-3.0.8/libguile/.libs/libguile-3.0.so.1 #23 0x799bb2b1617c in expand_sequence () from /scratch/lang/guile30/work/guile-3.0.8/libguile/.libs/libguile-3.0.so.1 #24 0x799bb2b1617c in expand_sequence () from /scratch/lang/guile30/work/guile-3.0.8/libguile/.libs/libguile-3.0.so.1 #25 0x799bb2b1617c in expand_sequence () from /scratch/lang/guile30/work/guile-3.0.8/libguile/.libs/libguile-3.0.so.1 #26 0x799bb2b1617c in expand_sequence () from /scratch/lang/guile30/work/guile-3.0.8/libguile/.libs/libguile-3.0.so.1 #27 0x799bb2b1617c in expand_sequence () from /scratch/lang/guile30/work/guile-3.0.8/libguile/.libs/libguile-3.0.so.1 #28 0x799bb2b1617c in expand_sequence () from /scratch/lang/guile30/work/guile-3.0.8/libguile/.libs/libguile-3.0.so.1 #29 0x799bb2b1617c in expand_sequence () from /scratch/lang/guile30/work/guile-3.0.8/libguile/.libs/libguile-3.0.so.1 #30 0x799bb2b1617c in expand_sequence () from /scratch/lang/guile30/work/guile-3.0.8/libguile/.libs/libguile-3.0.so.1 #31 0x799bb2b1617c in expand_sequence () from
Re: lang/guile30 build issue: lto support missing in ar/ranlib
Thomas Klausner writes:
> On 10.99.2 after the load sections 2->4 change I see the following
> when building lang/guile30:
>
> ar: libguile_3.0_la-alist.o: plugin needed to handle lto object
> ranlib: .libs/libguile-3.0.a(libguile_3.0_la-alist.o): plugin needed to
> handle lto object
> CCLD guile
>
> and the resulting binary segfaults when run (which also happens during
> the build), backtrace below.
>
> Is there a flag to turn off lto, or can we please get ar/ranlib
> support for lto?
>
> To reproduce, just try building 'lang/guile30'.
It fails to even build on i386. I have a local patch, pending figuring
it out, to just disable lto. I was unsure if that belonged on only some
arches, but seems best to mass disable and theni figure it out.
Index: Makefile
===
RCS file: /cvsroot/pkgsrc/lang/guile30/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- Makefile26 Oct 2022 10:31:04 - 1.5
+++ Makefile8 Jan 2023 17:37:16 -
@@ -23,6 +23,8 @@ LDFLAGS.SunOS+= -lsocket -lnsl
MAKE_ENV+= PAXCTL=echo
MAKE_ENV.NetBSD+= PAXCTL=/usr/sbin/paxctl
+CONFIGURE_ARGS+= --disable-lto
+
.if !empty(GUILE_SUBDIR)
# Installation prefix is non-default.
GUILE_PREFIX= ${PREFIX}/${GUILE_SUBDIR}
ldscripts not cleaned up
Hi! NetBSD after the switch to binutils 2.39 does not install the following files any longer, but they are not marked as obsolete either: /usr/libdata/ldscripts/elf_k1om.x /usr/libdata/ldscripts/elf_k1om.xbn /usr/libdata/ldscripts/elf_k1om.xc /usr/libdata/ldscripts/elf_k1om.xd /usr/libdata/ldscripts/elf_k1om.xdc /usr/libdata/ldscripts/elf_k1om.xdw /usr/libdata/ldscripts/elf_k1om.xn /usr/libdata/ldscripts/elf_k1om.xr /usr/libdata/ldscripts/elf_k1om.xs /usr/libdata/ldscripts/elf_k1om.xsc /usr/libdata/ldscripts/elf_k1om.xsw /usr/libdata/ldscripts/elf_k1om.xu /usr/libdata/ldscripts/elf_k1om.xw /usr/libdata/ldscripts/elf_l1om.x /usr/libdata/ldscripts/elf_l1om.xbn /usr/libdata/ldscripts/elf_l1om.xc /usr/libdata/ldscripts/elf_l1om.xd /usr/libdata/ldscripts/elf_l1om.xdc /usr/libdata/ldscripts/elf_l1om.xdw /usr/libdata/ldscripts/elf_l1om.xn /usr/libdata/ldscripts/elf_l1om.xr /usr/libdata/ldscripts/elf_l1om.xs /usr/libdata/ldscripts/elf_l1om.xsc /usr/libdata/ldscripts/elf_l1om.xsw /usr/libdata/ldscripts/elf_l1om.xu /usr/libdata/ldscripts/elf_l1om.xw Should new binutils install them, or should they be marked as obsolete? Thomas
lang/guile30 build issue: lto support missing in ar/ranlib
Hi! On 10.99.2 after the load sections 2->4 change I see the following when building lang/guile30: ar: libguile_3.0_la-alist.o: plugin needed to handle lto object ranlib: .libs/libguile-3.0.a(libguile_3.0_la-alist.o): plugin needed to handle lto object CCLD guile and the resulting binary segfaults when run (which also happens during the build), backtrace below. Is there a flag to turn off lto, or can we please get ar/ranlib support for lto? To reproduce, just try building 'lang/guile30'. Thanks, Thomas [New process 4469] Core was generated by `guile'. Program terminated with signal SIGSEGV, Segmentation fault. #0 weak_set_lookup.constprop.0 (set=set@entry=0x7902a5065150, hash=581991487143039215, hash@entry=290995743571519607, pred=pred@entry=0x7902a58f6f1b , closure=closure@entry=0x7f7fff302a50, dflt=) at weak-set.c:483 483 other_hash = entries[k].hash; (gdb) bt #0 weak_set_lookup.constprop.0 (set=set@entry=0x7902a5065150, hash=581991487143039215, hash@entry=290995743571519607, pred=pred@entry=0x7902a58f6f1b , closure=closure@entry=0x7f7fff302a50, dflt=) at weak-set.c:483 #1 0x7902a58f56b8 in scm_c_weak_set_lookup (dflt=0x4, closure=0x7f7fff302a50, pred=0x7902a58f6f1b , raw_hash=290995743571519607, set=) at weak-set.c:763 #2 lookup_interned_symbol (raw_hash=290995743571519607, name=0x7902a500ef80) at symbols.c:112 #3 scm_i_str2symbol (str=0x7902a500ef80) at symbols.c:244 #4 0x7902a58f92a6 in scm_string_to_symbol (string=) at symbols.c:360 #5 0x7902a58fe437 in scm_gensym (prefix=0x7902a4ed30e0) at symbols.c:408 #6 0x7902a5872cb1 in transform_bindings (bindings=bindings@entry=0x7902a5028cb0, expr=expr@entry=0x7902a5028d50, names=names@entry=0x7f7fff302c20, vars=vars@entry=0x7f7fff302c18, initptr=initptr@entry=0x7f7fff302c10) at expand.c:948 #7 0x7902a5872e49 in expand_let (expr=0x7902a5028d50, env=0x7902a5070ff0) at expand.c:1012 #8 0x7902a5871157 in expand_if (expr=0x7902a501d120, env=0x7902a5070ff0) at expand.c:586 #9 0x7902a587266c in expand_letstar_clause (bindings=0x7902a501d140, body=0x7902a502cdf0, env=0x7902a5065150) at expand.c:1074 #10 0x7902a587266c in expand_letstar_clause (bindings=0x7902a501d1e0, body=0x7902a502cdf0, env=0x7902a5065200) at expand.c:1074 #11 0x7902a5871157 in expand_if (expr=0x7902a501d5c0, env=0x7902a5065200) at expand.c:586 #12 0x7902a5871359 in expand_lambda_case (clause=0x7902a501d5d0, alternate=alternate@entry=0x4, env=) at expand.c:662 #13 0x7902a587162e in expand_lambda (expr=0x7902a501d610, env=) at expand.c:676 #14 0x7902a58732ce in expand_exprs (env=0x7902a5062a40, forms=0x7902a5062ad0) at expand.c:393 #15 expand_letrec_helper (expr=, env=0x7902a5062a40, in_order_p=0x404) at expand.c:1040 #16 0x7902a5871359 in expand_lambda_case (clause=0x7902a501dd80, alternate=alternate@entry=0x4, env=) at expand.c:662 #17 0x7902a587162e in expand_lambda (expr=0x7902a501ddc0, env=) at expand.c:676 #18 0x7902a58732ce in expand_exprs (env=0x7902a5059560, forms=0x7902a5059c20) at expand.c:393 #19 expand_letrec_helper (expr=, env=0x7902a5059560, in_order_p=0x404) at expand.c:1040 #20 0x7902a58703d8 in expand (exp=0x7902a501de50, env=0x7902a5055020) at expand.c:361 #21 0x7902a5870703 in expand_sequence (forms=0x7902a5034160, env=0x7902a5055020) at expand.c:405 #22 0x7902a58706f4 in expand_sequence (forms=0x7902a501de60, env=0x7902a5055020) at expand.c:405 #23 0x7902a58706f4 in expand_sequence (forms=0x7902a501df10, env=0x7902a5055020) at expand.c:405 #24 0x7902a58706f4 in expand_sequence (forms=0x7902a501dfc0, env=0x7902a5055020) at expand.c:405 #25 0x7902a58706f4 in expand_sequence (forms=0x7902a501a070, env=0x7902a5055020) at expand.c:405 #26 0x7902a58706f4 in expand_sequence (forms=0x7902a501a120, env=0x7902a5055020) at expand.c:405 #27 0x7902a58706f4 in expand_sequence (forms=0x7902a501a1d0, env=0x7902a5055020) at expand.c:405 #28 0x7902a58706f4 in expand_sequence (forms=0x7902a501a900, env=0x7902a5055020) at expand.c:405 #29 0x7902a58706f4 in expand_sequence (forms=0x7902a5014230, env=0x7902a5055020) at expand.c:405 #30 0x7902a58706f4 in expand_sequence (forms=0x7902a5014860, env=0x7902a5055020) at expand.c:405 #31 0x7902a58706f4 in expand_sequence (forms=0x7902a500c1f0, env=0x7902a5055020) at expand.c:405 #32 0x7902a58706f4 in expand_sequence (forms=0x7902a500cc50, env=0x7902a5055020) at expand.c:405 #33 0x7902a58706f4 in expand_sequence (forms=0x7902a50096b0, env=0x7902a5055020) at expand.c:405 #34 0x7902a58706f4 in expand_sequence (forms=0x7902a50056e0, env=0x7902a5055020) at expand.c:405 #35 0x7902a58706f4 in expand_sequence (forms=0x7902a50010d0, env=0x7902a5055020) at expand.c:405 #36 0x7902a58706f4 in expand_sequence (forms=0x7902a5001cc0, env=0x7902a5055020) at expand.c:405 #37 0x7902a58706f4 in expand_sequence (forms=0x7902a4ffc8b0, env=0x7902a5055020) at
Re: Very recent NetBSD-current Xorg panic
On Sun, Jan 08, 2023 at 01:15:01PM +, Chavdar Ivanov wrote: > As far as I understand it, there was a change with the dynamic loader at > this time? Yes, and after the ld.elf_so change the default linker options were adjusted, which makes testing this now a bit tricky (you can't just downgrad ld.elf_so). Martin
Re: Very recent NetBSD-current Xorg panic
On 08 January 2023 12:15:12 (+00:00), Martin Husemann wrote: > On Sun, Jan 08, 2023 at 11:28:18AM +, 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
Re: Very recent NetBSD-current Xorg panic
On Sun, Jan 08, 2023 at 11:28:18AM +, 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. Martin
Re: Automated report: NetBSD-current/i386 build failure
Date:Sat, 7 Jan 2023 20:41:01 + (UTC) From:NetBSD Test Fixture Message-ID: <167312406178.23291.2878684022518773...@babylon5.netbsd.org> | The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host, | using sources from CVS date 2023.01.07.19.41.30. This i386 build failure was fixed by: cvs rdiff -u -r1.56 -r1.57 src/sbin/fsck_ffs/pass5.c cvs rdiff -u -r1.105 -r1.106 src/sbin/fsck_ffs/setup.c by chs@ but b5 seems to have confused itself, and doesn't seem to have sent the normal "is working again" message, perhaps because it sent that other one, while the build was still broken due to this one. kre
Very recent NetBSD-current Xorg panic
Hi, My laptop, an HP Envy 17, has been running NetBSD (among others) -current since I've had it, almost seven years ago. It has an Intel 530 graphics, as well as NVidia GeForce GTX 950m, the latter has never worked for me under NetBSD, to get Xorg running, I usually run 'Xorg -configure' and get rid of all the configured options - screen, device, monitor - relating to the NVidia card. Up until 10.99.2 as of 03/01/2023, all was fine, more or less; Xorg ran using DRI2, everything was accelerated as expected, I didn't even have some of the graphics glitches which appeared previously. This morning I upgraded the instance to my yesterday's build - as of 07/01/2023. Now Xorg dumps core as follows: - Reading symbols from /usr/X11R7/bin/Xorg... (No debugging symbols found in /usr/X11R7/bin/Xorg) [New process 3404] [New process 3397] [New process 3229] [New process 3555] Core was generated by `Xorg'. Program terminated with signal SIGABRT, Aborted. #0 0x6fa66dcb845a in _lwp_kill () from /usr/lib/libc.so.12 [Current thread is 1 (process 3404)] (gdb) bt #0 0x6fa66dcb845a in _lwp_kill () from /usr/lib/libc.so.12 #1 0x6fa66dcb895a in abort () from /usr/lib/libc.so.12 #2 0x00aa3854 in OsAbort () #3 0x00a9eb6e in AbortServer () #4 0x00a9f7de in FatalError () #5 0x00aa44d2 in ?? () #6 #7 0x6fa6665dec79 in _mesa_sha1_format () from /usr/X11R7/lib/modules/dri/i965_dri.so #8 0x6fa6665d9161 in brw_disk_cache_init () from /usr/X11R7/lib/modules/dri/i965_dri.so #9 0x6fa6664baa93 in ?? () from /usr/X11R7/lib/modules/dri/i965_dri.so #10 0x6fa6668fdc03 in ?? () from /usr/X11R7/lib/modules/dri/i965_dri.so #11 0x00aaefeb in ?? () #12 0x00ab834f in ?? () #13 0x0098d3a0 in _CallCallbacks () #14 0x00ab0201 in GlxExtensionInit () #15 0x009d7841 in InitExtensions () #16 0x0094bca7 in dix_main () #17 0x0094ba1d in ___start () #18 0x7f7ff7681820 in ?? () from /usr/libexec/ld.elf_so #19 0x0001 in ?? () #20 0x7f7fff7a6fd0 in ?? () #21 0x in ?? () (gdb) quit startx results in (I guess the same): X.Org X Server 1.21.1.5 X Protocol Version 11, Revision 0 Current Operating System: NetBSD tarkus.lorien.lan 10.99.2 NetBSD 10.99.2 (GENERIC) #5: Sat Jan 7 01:31:38 GMT 2023 sysbu...@ymir.lorien.lan:/home/sysbuild/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC amd64 Current version of pixman: 0.38.4 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Sun Jan 8 10:44:14 2023 (==) Using config file: "/etc/X11/xorg.conf" (EE) (EE) Backtrace: (EE) 0: /usr/X11R7/bin/X (xorg_backtrace+0x44) [0xa5c6c5] (EE) 1: /usr/X11R7/bin/X (os_move_fd+0x79) [0xa58465] (EE) 2: /usr/lib/libc.so.12 (__sigtramp_siginfo_2+0x0) [0x7d363a2b8510] (EE) 3: /usr/X11R7/lib/modules/dri/i965_dri.so (__driDriverGetExtensions_i965+0x122e6f) [0x7d3632fdec79] (EE) 4: /usr/X11R7/lib/modules/dri/i965_dri.so (__driDriverGetExtensions_i965+0x11d357) [0x7d3632fd9161] (EE) 5: /usr/X11R7/lib/modules/dri/i965_dri.so (__driDriverGetExtensions_r200+0x24fbb3) [0x7d3632ebaa93] (EE) 6: /usr/X11R7/lib/modules/dri/i965_dri.so (__driDriverGetExtensions_i915+0x44978) [0x7d36332fdc03] (EE) 7: /usr/X11R7/bin/X (_XSERVTransConvertAddress+0xb4a) [0xa62feb] (EE) 8: /usr/X11R7/bin/X (glxProbeDriver+0x6c5) [0xa6c34f] (EE) 9: /usr/X11R7/bin/X (_CallCallbacks+0x35) [0x9413a0] (EE) 10: /usr/X11R7/bin/X (GlxExtensionInit+0x146) [0xa64201] (EE) 11: /usr/X11R7/bin/X (InitExtensions+0x85) [0x98b841] (EE) 12: /usr/X11R7/bin/X (dix_main+0x1a7) [0x8ffca7] (EE) (EE) Segmentation fault at address 0x10 (EE) Fatal server error: (EE) Caught signal 11 (Segmentation fault). Server aborting (EE) The same build appears to be working fine on the build machine using .. radeon0 at pci1 dev 0 function 0: ATI Technologies FirePro W5000 (rev. 0x00) .. (again, decent DRI2 performance here). I tried the kernel from the previous build - which was working OK - but obviously it didn't work, as the problem appears to be in /usr/X11R7/lib/modules/dri/i965_dri.so . I examined the cvs changes between 03/01 and 07/01 and could not find anything directly related to Intel graphics, with the possible exception of: cvs diff -u -r 1.2 -r 1.3 igpioreg.h Index: igpioreg.h === RCS file: /cvsroot/src/sys/dev/ic/igpioreg.h,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- igpioreg.h 26 Mar 2022 19:35:35 - 1.2 +++ igpioreg.h 7 Jan 2023 00:39:20 - 1.3 @@ -1,4 +1,4 @@ -/* $NetBSD: igpioreg.h,v 1.2
