Re: core dump in ld during buildworld
On 19 Feb 2023, at 06:15, Steve Kargl wrote: > > On Sat, Feb 18, 2023 at 04:57:45PM -0800, Steve Kargl wrote: >>> >>> At that point it is still using the system compiler and linker, and it >>> seems that the latter is lld. Do you know which version it is? >>> >> >> Good question. Unfortunate ident(1) is useless in a git world. >> >> % ll /usr/bin/ld.lld >> -r-xr-xr-x 1 root wheel - 41754432 Jan 15 12:03 /usr/bin/ld.lld >> >> This was built from source from Jan 15 2023. >> >> % /usr/bin/ld.lld --version >> LLD 14.0.5 (FreeBSD llvmorg-14.0.5-0-gc12386ae247c-144) (compatible with >> GNU linkers) >> > > So, is there some way to rebild only ld.lld and install a new loader? > > % cd /usr/src/usr.bin/clang/lld > % make depend > llvm-tblgen -gen-opt-parser-defs -I > /usr/src/contrib/llvm-project/llvm/include -d Options.inc.d -o Options.inc > /usr/src/contrib/llvm-project/lld/ELF/Options.td > make: exec(llvm-tblgen) failed (No such file or directory) > *** Error code 1 > > How to I fix this? Assuming llvm-tblgen has already been built (it's a bootstrap-tool), and you have a regular setup, it should be in: /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/usr.bin/clang/llvm-tblgen/llvm-tblgen You could try setting LLVM_TBLGEN to that path, then first build libllvm just to be sure, then usr.bin/clang/lld: export LLVM_TBLGEN=/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/usr.bin/clang/llvm-tblgen/llvm-tblgen make -C /usr/src/lib/clang/libllvm make -C /usr/src/usr.bin/clang/lld If that works, you can run make install from usr.bin/clang/lld. -Dimitry signature.asc Description: Message signed with OpenPGP
Re: FreeBSD 13.2-stable crash in /usr/src/sys/amd64/include/pcpu_aux.h:55
I'll see if I can find something. - James On 2023-02-19 04:57, Mateusz Guzik wrote: looks like a jail problem, maintainer cc'ed On 2/19/23, Michael Jung wrote: After upgrading from FreeBSD firewall.mikej.com 13.1-STABLE FreeBSD 13.1-STABLE #21 stable/13-n253337-16603f60156e:Wed Dec 28 08:22:48 EST 2022 mi...@firewall.mikej.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 TO FreeBSD firewall.mikej.com 13.2-STABLE FreeBSD 13.2-STABLE #3 stable/13-n254483-e0c3f2a1e296: Tue Feb 14 19:25:51 EST 2023 mi...@firewall.mikej.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 I had a kernel crash which can be found here. http://mail.mikej.com/core.txt.0 It has not happened again, but I'm putting it though it's normal paces. The only thing that was occurring which is not a normal thing for me to is I was moving TB's worth of data between directly attached two zpools. Regards, Michael Jung
Re: CURRENT: Crash in multiuser mode while shutdown
Am Sun, 19 Feb 2023 06:19:04 -0800 Rick Macklem schrieb: > I committed a patch that would cause crashes if > the system was using jails on Feb. 11, but it was > fixed the next day. It bogusly had a prison_cleanup() > method in it. > > But if you kernel wasn't from main on about Feb. 11 > or you aren't running jails, I don't think this is it. Sources are most recent. > > It is too bad you don't have a backtrace? I need the box today, the other one is a poudriere host and can't be interrupted on short notice, I will enable debugging as I finish my work. The I hope I can provide you with a backtrace. cpu-data has been updated recently, I use this on these two IvyBridge methusalem riggs, I may disable this first and see what happens ... Regards oh > > rick > > On Sun, Feb 19, 2023 at 1:38 AM FreeBSD User wrote: > > > > Hello, > > > > most recent CURRENT crashes on shutdown from multiuser mode (singleuser > > mode, used after > > repairing failed FFS filesystems, is all right). The crashes go on since > > roughly a 1/2 week > > from now. The boxes involved are all cumtomized kernels (in most cases hard > > linked modules > > into kernel). Is there a known issue? > > > > Otherwise I have to reconfigure all systems for debugging an d will report > > aftwards more. > > > > > > Regards and thanks in advance > > Oliver > > -- > > O. Hartmann > > -- O. Hartmann
Re: FreeBSD 13.2-stable crash in /usr/src/sys/amd64/include/pcpu_aux.h:55
looks like a jail problem, maintainer cc'ed On 2/19/23, Michael Jung wrote: > After upgrading from > > FreeBSD firewall.mikej.com 13.1-STABLE FreeBSD 13.1-STABLE #21 > stable/13-n253337-16603f60156e:Wed Dec 28 08:22:48 EST 2022 > mi...@firewall.mikej.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 > > TO > > FreeBSD firewall.mikej.com 13.2-STABLE FreeBSD 13.2-STABLE #3 > stable/13-n254483-e0c3f2a1e296: Tue Feb 14 19:25:51 EST 2023 > mi...@firewall.mikej.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 > > I had a kernel crash which can be found here. > > http://mail.mikej.com/core.txt.0 > > It has not happened again, but I'm putting it though it's normal paces. > > The only thing that was occurring which is not a normal thing for me to > is I was moving TB's worth of data between directly attached two zpools. > > Regards, > > Michael Jung > > > > > -- Mateusz Guzik
Re: IPFW: IPv6 and NPTv6 issues: multiple IPv6 addresses confuses IPFW
Am Sun, 19 Feb 2023 13:30:13 +0300 "Andrey V. Elsukov" schrieb: > 18.02.2023 18:42, FreeBSD User пишет: > > On a 24 hour basis, the ISP changes the IPv4 and IPv6 on the WAN > > interface. We use NPTv6 to translate ULA addresses for the inner > > IPv6 networks. We use IPv6 privacy on the tun0 interface. The > > router/firewall is operating after a reboot or restart of mpd5 > > correctly, IPv6 and IPv4 networks have conection to the internet. > > When the ISP rotates it IPs, the IPv6 address is configured using > > SLAAC and mpd5 seems to act weird: > > > > - the IPv4 address is always set correct, IPFW and in-kernel NAT > > route/filter traffic correctly - sometimes old IPv6 address is dumped > > and only a new IPv6 address - in such a case, the old IPv6 is gone, > > the new pair (temporary and MACified address are the only IPv6 > > addresses attached to the interface. - sometimes the old IPv6 address > > set (= temporary) are marked "deprecated" and/or "detached" and a new > > set is attached to the interface tun0, in some rare occassion also an > > IPv6 address WITHOUT its "temoprary" sibbling is attached. > > > > In any of the cases above, IPFW's NPTv6 gets confused, routing isn't > > working properly anymore. > > > > In any cases of a change of the IPv6 address, IPFW has to be > > restartet! > > Hi, > > I assume you are using ext_if option in your NPTv6 instance configuration. That is correct. > > I think there might be several problems that lead to your situation: > > 1. NPTv6 tracks IPv6 addresses deletion, but since an old IPv6 address > that was used as external prefix kept on the interface, it ignores > appearance of new IPv6 address. > > 2. Then, even if you delete old IPv6 address by hand, NPTv6 won't try to > peak another one until there won't appear new address. > > 3. There should be some logic that takes into account presence of > temporary and deprecated addresses on the interface. > -- O. Hartmann pgpGnCla7RwGj.pgp Description: OpenPGP digital signature
FreeBSD 13.2-stable crash in /usr/src/sys/amd64/include/pcpu_aux.h:55
After upgrading from FreeBSD firewall.mikej.com 13.1-STABLE FreeBSD 13.1-STABLE #21 stable/13-n253337-16603f60156e:Wed Dec 28 08:22:48 EST 2022 mi...@firewall.mikej.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 TO FreeBSD firewall.mikej.com 13.2-STABLE FreeBSD 13.2-STABLE #3 stable/13-n254483-e0c3f2a1e296: Tue Feb 14 19:25:51 EST 2023 mi...@firewall.mikej.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 I had a kernel crash which can be found here. http://mail.mikej.com/core.txt.0 It has not happened again, but I'm putting it though it's normal paces. The only thing that was occurring which is not a normal thing for me to is I was moving TB's worth of data between directly attached two zpools. Regards, Michael Jung
Re: IPFW: IPv6 and NPTv6 issues: multiple IPv6 addresses confuses IPFW
18.02.2023 18:42, FreeBSD User пишет: On a 24 hour basis, the ISP changes the IPv4 and IPv6 on the WAN interface. We use NPTv6 to translate ULA addresses for the inner IPv6 networks. We use IPv6 privacy on the tun0 interface. The router/firewall is operating after a reboot or restart of mpd5 correctly, IPv6 and IPv4 networks have conection to the internet. When the ISP rotates it IPs, the IPv6 address is configured using SLAAC and mpd5 seems to act weird: - the IPv4 address is always set correct, IPFW and in-kernel NAT route/filter traffic correctly - sometimes old IPv6 address is dumped and only a new IPv6 address - in such a case, the old IPv6 is gone, the new pair (temporary and MACified address are the only IPv6 addresses attached to the interface. - sometimes the old IPv6 address set (= temporary) are marked "deprecated" and/or "detached" and a new set is attached to the interface tun0, in some rare occassion also an IPv6 address WITHOUT its "temoprary" sibbling is attached. In any of the cases above, IPFW's NPTv6 gets confused, routing isn't working properly anymore. In any cases of a change of the IPv6 address, IPFW has to be restartet! Hi, I assume you are using ext_if option in your NPTv6 instance configuration. I think there might be several problems that lead to your situation: 1. NPTv6 tracks IPv6 addresses deletion, but since an old IPv6 address that was used as external prefix kept on the interface, it ignores appearance of new IPv6 address. 2. Then, even if you delete old IPv6 address by hand, NPTv6 won't try to peak another one until there won't appear new address. 3. There should be some logic that takes into account presence of temporary and deprecated addresses on the interface. -- WBR, Andrey V. Elsukov OpenPGP_signature Description: OpenPGP digital signature
CURRENT: Crash in multiuser mode while shutdown
Hello, most recent CURRENT crashes on shutdown from multiuser mode (singleuser mode, used after repairing failed FFS filesystems, is all right). The crashes go on since roughly a 1/2 week from now. The boxes involved are all cumtomized kernels (in most cases hard linked modules into kernel). Is there a known issue? Otherwise I have to reconfigure all systems for debugging an d will report aftwards more. Regards and thanks in advance Oliver -- O. Hartmann
