Re: NFS issues since upgrading to 13-RELEASE
I have the same issue, using Ubuntu 20.10 with Linux 5.8 kernel. The Linux NFS client will get unresponsive and it does not recover in my case, even if I restart NFS on FreeBSD. I upgraded from FreeBSD 12.1-RELEASE though. On Thu, Apr 15, 2021 at 8:36 PM Allan Jude wrote: > On 4/15/2021 9:22 AM, Chris Roose wrote: > > I posted this in -questions and someone suggested I post here as well. > > > > I'm having NFS availability issues between my Proxmox client and FreeBSD > server (10G link) since upgrading to 13-RELEASE. And unfortunately I > upgraded my ZFS pool to v2.0.0 before I noticed the issue, so I'm kind of > stuck. > > > > Periodically, the NFS server (I've tried both v3 and v4.2 clients) will > go unresponsive for several minutes. I never had this problem on 12.2, and > as far as I can tell it's not a disk or network I/O issue. I'll get several > "nfs: server not responding, still trying" messages on the client and a few > minutes later it usually recovers. It's not clear to me yet what's causing > the block. Restarting nfsd on the server will resolve the issue if it > doesn't clear itself. > > > > Any pointers for troubleshooting this? I've been looking through vmstat, > gstat, top, etc. when the problem occurs, but I haven't been able to > pinpoint the issue. I can get pcap, but it would be from the hosts, because > I don't have a 10G tap or managed switch. > > > > run `nfsstat -d 1` and try to capture a few lines from before, during, > and after the stall, and that may provide some insight. > > Specifically, does the queue length grow, suggesting it is waiting on > the I/O subsystem, or does it just stop getting traffic all together. > > > -- > Allan Jude > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > -- Kind Regards / Med Vennlig Hilsen Olav Grønås Gjerde BackupBay Gjerde Madlaforen 35 4042 HAFRSFJORD Norway Phone: +47 918 000 59 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Trying to build Current
On Thu, Apr 15, 2021 at 4:19 AM Willem Jan Withagen via freebsd-current < freebsd-current@freebsd.org> wrote: > On 15-4-2021 12:44, Yuri Pankov wrote: > > Willem Jan Withagen via freebsd-current wrote: > >> On 15-4-2021 11:47, Gary Jennejohn wrote: > >>> On Thu, 15 Apr 2021 10:51:39 +0200 > >>> Willem Jan Withagen via freebsd-current > >>> wrote: > >>> > Hi, > > I actually went completely back to the basic setup with directories > /usr/src and /usr/obj > But even then I do not manage to buildworld. > The process keeps bumping into missing bsm/audit. > > First case was when it tried to build the 64bit libc. > I copied the bsm directory into > __ /usr/obj/usr/src/amd64.amd64/tmp/usr/include/sys/ > > Which allowed it to continue. > But then a bit further on it halts again in 32bit libc. > Whcih I could fix the same way. > > --- fts.o --- > In file included from /usr/src/lib/libc/gen/fts.c:40: > In file included from > /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/mount.h:38: > > /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/ucred.h:42:10: > > fatal error: 'bsm/audit.h' file not found > #include > ^ > > Even defining HISTORICAL_MAKE_WORLD did not help, but then I'm not > doing > 'make world' > > So why is this include file missing? > > >>> Try running make includes first. This step is missing because you are > NOT > >>> doing a buildworld. > >>> > >> Well actual the commands were: > >> > >> rm -rf /usr/src /usr/obj > >> mkdir -p /usr/src /usr/obj > >> cd /usr/src > >> git clone https://git.freebsd.org/src.git . > >> make -j16 buildworld > >> > >> But I'll give it a shot anyways. > > Anything in /etc/make.conf and /etc/src.conf? > I had the same idea, but only after I asked the question > There was quite a lot of old cruft there > Removed it all, and I'm trying fresh again. > But Clang building, even with ccache takes quite some time. > > --WjW > --WjW > You can greatly reduce buildworld time by adding "WITHOUT_LLVM_TARGET_ALL=YES" to /etc/src.conf. This will not build all of the back-ends for other platforms. Of course, it means that you can't cross-compile for them, but I would assume that installing the full llvm11 port would take care of this, so I don't understand why building them is default. This may be shortened to "I don't understand", of course. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: NFS issues since upgrading to 13-RELEASE
> On 15 Apr 2021, at 23:09, Juraj Lutter wrote: > > The machine it’s running on is definitely a slow or weak one (it’s dell > r740xd with 2x CPU, 256GB RAM, 22xNVMe data zpool). Is definitely *NOT* a slow or weak one :-) otis ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: NFS issues since upgrading to 13-RELEASE
> On 15 Apr 2021, at 22:47, Rick Macklem wrote: > > Allan Jude wrote: >> On 4/15/2021 9:22 AM, Chris Roose wrote: >>> I posted this in -questions and someone suggested I post here as well. >>> >>> I'm having NFS availability issues between my Proxmox client and FreeBSD >>> server (10G link) since upgrading to 13->RELEASE. And unfortunately I >>> upgraded my ZFS pool to v2.0.0 before I noticed the issue, so I'm kind of >>> stuck. >>> >>> Periodically, the NFS server (I've tried both v3 and v4.2 clients) will go >>> unresponsive for several minutes. I never had >this problem on 12.2, and as >>> far as I can tell it's not a disk or network I/O issue. I'll get several >>> "nfs: server not >responding, still trying" messages on the client and a >>> few minutes later it usually recovers. It's not clear to me yet >what's >>> causing the block. Restarting nfsd on the server will resolve the issue if >>> it doesn't clear itself. >> > otis@ has run into a problem that sounds similar. > He sees a growing Recv-Q size on the server for the TCP connection from the > client > when "netstat -a" is done on the server when the "hang" occurs. > In his case, he is using a Linux client and it does not recover, however > other client > mounts continue to function. Correct. > I suspect the recovery after a few minutes is the client establishing a new > TCP > connection. > > He has been running for almost a week with r367492 reverted and has not > reported > seeing the problem again (he had reported that it has taken up to a week to > recur, so > reverting r367492 *might* have fixed the problem and I'd guess we'll know in > another > week?). We are now running 4 days without interruption. Before r367492 was reverted, it was unpredictable when it will lock up. The best result we achieved was 7 days. The machine it’s running on is definitely a slow or weak one (it’s dell r740xd with 2x CPU, 256GB RAM, 22xNVMe data zpool). otis ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: NFS issues since upgrading to 13-RELEASE
Stupid Outlook... I wrote: [stuff snipped] >- Alternately you can try rscheff@'s alternate proposed patch that is at > https://reviews.freebsd.og/D29690. Oops, that's https:/reviews.freebsd.org/D29690 But you can figure out the link;-), rick rick I have not yet had time to test this one, but since I cannot reproduce the hang, I can only do testing of it to see that it is "no worse" than reverting r367492 for my setup. Please let us know which you choose and whether or not it fixes your problem. >> Any pointers for troubleshooting this? I've been looking through vmstat, >> gstat, top, etc. when the problem occurs, but I haven't been able to >> pinpoint the issue. I can get pcap, but it would be from the hosts, because >> I don't have a 10G tap or managed switch. >> > >run `nfsstat -d 1` and try to capture a few lines from before, during, >and after the stall, and that may provide some insight. > >Specifically, does the queue length grow, suggesting it is waiting on >the I/O subsystem, or does it just stop getting traffic all together. If the revert of r367492 does not fix the problem, monitor the TCP connection(s) via "netstat -a" and, if possible, capture packets via tcpdump -s 0 -w hang.pcap host or similar, run on the server. Ideally the tcpdump would be started before the "hang" occurs, but running one while the hang is occurring (until after it recovers) could also be useful. Thanks for reporting this, rick -- Allan Jude ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: NFS issues since upgrading to 13-RELEASE
I wrote: [stuff snipped] >- Alternately you can try rscheff@'s alternate proposed patch that is at > https://reviews.freebsd.og/D29690. Oops, that's https:/reviews.freebsd.org/D29690 rick I have not yet had time to test this one, but since I cannot reproduce the hang, I can only do testing of it to see that it is "no worse" than reverting r367492 for my setup. Please let us know which you choose and whether or not it fixes your problem. >> Any pointers for troubleshooting this? I've been looking through vmstat, >> gstat, top, etc. when the problem occurs, but I haven't been able to >> pinpoint the issue. I can get pcap, but it would be from the hosts, because >> I don't have a 10G tap or managed switch. >> > >run `nfsstat -d 1` and try to capture a few lines from before, during, >and after the stall, and that may provide some insight. > >Specifically, does the queue length grow, suggesting it is waiting on >the I/O subsystem, or does it just stop getting traffic all together. If the revert of r367492 does not fix the problem, monitor the TCP connection(s) via "netstat -a" and, if possible, capture packets via tcpdump -s 0 -w hang.pcap host or similar, run on the server. Ideally the tcpdump would be started before the "hang" occurs, but running one while the hang is occurring (until after it recovers) could also be useful. Thanks for reporting this, rick -- Allan Jude ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: NFS issues since upgrading to 13-RELEASE
Allan Jude wrote: >On 4/15/2021 9:22 AM, Chris Roose wrote: >> I posted this in -questions and someone suggested I post here as well. >> >> I'm having NFS availability issues between my Proxmox client and FreeBSD >> server (10G link) since upgrading to 13->RELEASE. And unfortunately I >> upgraded my ZFS pool to v2.0.0 before I noticed the issue, so I'm kind of >> stuck. >> >> Periodically, the NFS server (I've tried both v3 and v4.2 clients) will go >> unresponsive for several minutes. I never had >this problem on 12.2, and as >> far as I can tell it's not a disk or network I/O issue. I'll get several >> "nfs: server not >responding, still trying" messages on the client and a few >> minutes later it usually recovers. It's not clear to me yet >what's causing >> the block. Restarting nfsd on the server will resolve the issue if it >> doesn't clear itself. > otis@ has run into a problem that sounds similar. He sees a growing Recv-Q size on the server for the TCP connection from the client when "netstat -a" is done on the server when the "hang" occurs. In his case, he is using a Linux client and it does not recover, however other client mounts continue to function. I suspect the recovery after a few minutes is the client establishing a new TCP connection. He has been running for almost a week with r367492 reverted and has not reported seeing the problem again (he had reported that it has taken up to a week to recur, so reverting r367492 *might* have fixed the problem and I'd guess we'll know in another week?). - If using svn to revert the patch is inconvenient, I've attached a patch that can be applied to revert it. - Alternately you can try rscheff@'s alternate proposed patch that is at https://reviews.freebsd.og/D29690. I have not yet had time to test this one, but since I cannot reproduce the hang, I can only do testing of it to see that it is "no worse" than reverting r367492 for my setup. Please let us know which you choose and whether or not it fixes your problem. >> Any pointers for troubleshooting this? I've been looking through vmstat, >> gstat, top, etc. when the problem occurs, but I haven't been able to >> pinpoint the issue. I can get pcap, but it would be from the hosts, because >> I don't have a 10G tap or managed switch. >> > >run `nfsstat -d 1` and try to capture a few lines from before, during, >and after the stall, and that may provide some insight. > >Specifically, does the queue length grow, suggesting it is waiting on >the I/O subsystem, or does it just stop getting traffic all together. If the revert of r367492 does not fix the problem, monitor the TCP connection(s) via "netstat -a" and, if possible, capture packets via tcpdump -s 0 -w hang.pcap host or similar, run on the server. Ideally the tcpdump would be started before the "hang" occurs, but running one while the hang is occurring (until after it recovers) could also be useful. Thanks for reporting this, rick -- Allan Jude ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" r367492-revert.patch Description: r367492-revert.patch ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD-14.0-CURRENT-amd64-20210408-15dc713ceb5-245885-memstick.img fails to boot on Haswell-based laptop.
On 15.04.2021 21:41, Dmitry Chagin wrote: calltrap() --- trap 0x9 run_interrupt_driven_config_hooks() boot_run_interrupt_driven_config_hooks() mi_startup() It is 100% reproducible, and I cannot issue commands to kernel debugger, keyboard is dead. Enabling verbose boot helps, with verbose boot it boots to installer. Looks like some race condition. Is it known problem? try to boot verbose It is funny, but boot-verbose helps on battery and doesn't help with AC. I think, it is because with AC plugged in CPU is set to "performance" mode and delay from printing verbose information is not enough! -- // Lev Serebryakov ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD-14.0-CURRENT-amd64-20210408-15dc713ceb5-245885-memstick.img fails to boot on Haswell-based laptop.
On 15.04.2021 21:41, Dmitry Chagin wrote: Enabling verbose boot helps, with verbose boot it boots to installer. Looks like some race condition. try to boot verbose It helps. Sometimes. And soemtimes even verbose boot gives same Fatal Trap with same stacktrace. It is why I think it is some race condition. -- // Lev Serebryakov ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD-14.0-CURRENT-amd64-20210408-15dc713ceb5-245885-memstick.img fails to boot on Haswell-based laptop.
On Thu, Apr 15, 2021 at 06:04:55PM +0300, Lev Serebryakov wrote: > > I'm trying to install CURRENT > (FreeBSD-14.0-CURRENT-amd64-20210408-15dc713ceb5-245885-memstick.img) > snapshot onto Lenovo Thinkpad T540p, i7-4700 based laptop. > > Kernel traps on boot with "Fatal trap 9" and this stack trace (hand-copied): > > calltrap() > --- trap 0x9 > run_interrupt_driven_config_hooks() > boot_run_interrupt_driven_config_hooks() > mi_startup() > > It is 100% reproducible, and I cannot issue commands to kernel debugger, > keyboard is dead. > > Enabling verbose boot helps, with verbose boot it boots to installer. > > Looks like some race condition. > > Is it known problem? try to boot verbose > > -- > // Lev Serebryakov > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: NFS issues since upgrading to 13-RELEASE
On 4/15/2021 9:22 AM, Chris Roose wrote: > I posted this in -questions and someone suggested I post here as well. > > I'm having NFS availability issues between my Proxmox client and FreeBSD > server (10G link) since upgrading to 13-RELEASE. And unfortunately I upgraded > my ZFS pool to v2.0.0 before I noticed the issue, so I'm kind of stuck. > > Periodically, the NFS server (I've tried both v3 and v4.2 clients) will go > unresponsive for several minutes. I never had this problem on 12.2, and as > far as I can tell it's not a disk or network I/O issue. I'll get several > "nfs: server not responding, still trying" messages on the client and a few > minutes later it usually recovers. It's not clear to me yet what's causing > the block. Restarting nfsd on the server will resolve the issue if it doesn't > clear itself. > > Any pointers for troubleshooting this? I've been looking through vmstat, > gstat, top, etc. when the problem occurs, but I haven't been able to pinpoint > the issue. I can get pcap, but it would be from the hosts, because I don't > have a 10G tap or managed switch. > run `nfsstat -d 1` and try to capture a few lines from before, during, and after the stall, and that may provide some insight. Specifically, does the queue length grow, suggesting it is waiting on the I/O subsystem, or does it just stop getting traffic all together. -- Allan Jude ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
NFS issues since upgrading to 13-RELEASE
I posted this in -questions and someone suggested I post here as well. I'm having NFS availability issues between my Proxmox client and FreeBSD server (10G link) since upgrading to 13-RELEASE. And unfortunately I upgraded my ZFS pool to v2.0.0 before I noticed the issue, so I'm kind of stuck. Periodically, the NFS server (I've tried both v3 and v4.2 clients) will go unresponsive for several minutes. I never had this problem on 12.2, and as far as I can tell it's not a disk or network I/O issue. I'll get several "nfs: server not responding, still trying" messages on the client and a few minutes later it usually recovers. It's not clear to me yet what's causing the block. Restarting nfsd on the server will resolve the issue if it doesn't clear itself. Any pointers for troubleshooting this? I've been looking through vmstat, gstat, top, etc. when the problem occurs, but I haven't been able to pinpoint the issue. I can get pcap, but it would be from the hosts, because I don't have a 10G tap or managed switch. -- Chris ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Trying to build Current
Willem Jan Withagen via freebsd-current wrote: > On 15-4-2021 11:47, Gary Jennejohn wrote: >> On Thu, 15 Apr 2021 10:51:39 +0200 >> Willem Jan Withagen via freebsd-current >> wrote: >> >>> Hi, >>> >>> I actually went completely back to the basic setup with directories >>> /usr/src and /usr/obj >>> But even then I do not manage to buildworld. >>> The process keeps bumping into missing bsm/audit. >>> >>> First case was when it tried to build the 64bit libc. >>> I copied the bsm directory into >>> __ /usr/obj/usr/src/amd64.amd64/tmp/usr/include/sys/ >>> >>> Which allowed it to continue. >>> But then a bit further on it halts again in 32bit libc. >>> Whcih I could fix the same way. >>> >>> --- fts.o --- >>> In file included from /usr/src/lib/libc/gen/fts.c:40: >>> In file included from >>> /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/mount.h:38: >>> /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/ucred.h:42:10: >>> >>> fatal error: 'bsm/audit.h' file not found >>> #include >>> ^ >>> >>> Even defining HISTORICAL_MAKE_WORLD did not help, but then I'm not doing >>> 'make world' >>> >>> So why is this include file missing? >>> >> Try running make includes first. This step is missing because you are NOT >> doing a buildworld. >> > Well actual the commands were: > > rm -rf /usr/src /usr/obj > mkdir -p /usr/src /usr/obj > cd /usr/src > git clone https://git.freebsd.org/src.git . > make -j16 buildworld > > But I'll give it a shot anyways. Anything in /etc/make.conf and /etc/src.conf? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
panic: general protection fault
I just got this one: 0210415 17:01:45 all (458/755): callout_reset_on.sh kernel trap 9 with interrupts disabled Fatal trap 9: general protection fault while in kernel mode cpuid = 10; apic id = 0a instruction pointer = 0x20:0x80c7c286 stack pointer = 0x0:0xfe00e49b0730 frame pointer = 0x0:0xfe00e49b0770 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 12 (swi1: netisr 0) trap number = 9 panic: general protection fault cpuid = 10 time = 1618498958 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00e49b0440 vpanic() at vpanic+0x181/frame 0xfe00e49b0490 panic() at panic+0x43/frame 0xfe00e49b04f0 trap_fatal() at trap_fatal+0x387/frame 0xfe00e49b0550 trap() at trap+0xa4/frame 0xfe00e49b0660 calltrap() at calltrap+0x8/frame 0xfe00e49b0660 --- trap 0x9, rip = 0x80c7c286, rsp = 0xfe00e49b0730, rbp = 0xfe00e49b0770 --- turnstile_wait() at turnstile_wait+0x46/frame 0xfe00e49b0770 __rw_wlock_hard() at __rw_wlock_hard+0x464/frame 0xfe00e49b0820 _rw_wlock_cookie() at _rw_wlock_cookie+0xb7/frame 0xfe00e49b0860 in_pcblookup_hash() at in_pcblookup_hash+0x76/frame 0xfe00e49b0890 in_pcblookup_mbuf() at in_pcblookup_mbuf+0x24/frame 0xfe00e49b08b0 tcp_input() at tcp_input+0x6e8/frame 0xfe00e49b0a10 ip_input() at ip_input+0x194/frame 0xfe00e49b0aa0 swi_net() at swi_net+0x1a1/frame 0xfe00e49b0b20 ithread_loop() at ithread_loop+0x279/frame 0xfe00e49b0bb0 fork_exit() at fork_exit+0x80/frame 0xfe00e49b0bf0 https://people.freebsd.org/~pho/stress/log/log0092.txt - Peter ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD-14.0-CURRENT-amd64-20210408-15dc713ceb5-245885-memstick.img fails to boot on Haswell-based laptop.
I'm trying to install CURRENT (FreeBSD-14.0-CURRENT-amd64-20210408-15dc713ceb5-245885-memstick.img) snapshot onto Lenovo Thinkpad T540p, i7-4700 based laptop. Kernel traps on boot with "Fatal trap 9" and this stack trace (hand-copied): calltrap() --- trap 0x9 run_interrupt_driven_config_hooks() boot_run_interrupt_driven_config_hooks() mi_startup() It is 100% reproducible, and I cannot issue commands to kernel debugger, keyboard is dead. Enabling verbose boot helps, with verbose boot it boots to installer. Looks like some race condition. Is it known problem? -- // Lev Serebryakov ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Trying to build Current
On 15-4-2021 14:20, Emmanuel Vadot wrote: On Thu, 15 Apr 2021 10:51:39 +0200 Willem Jan Withagen via freebsd-current wrote: Hi, I actually went completely back to the basic setup with directories /usr/src and /usr/obj But even then I do not manage to buildworld. The process keeps bumping into missing bsm/audit. First case was when it tried to build the 64bit libc. I copied the bsm directory into /usr/obj/usr/src/amd64.amd64/tmp/usr/include/sys/ Which allowed it to continue. But then a bit further on it halts again in 32bit libc. Whcih I could fix the same way. --- fts.o --- In file included from /usr/src/lib/libc/gen/fts.c:40: In file included from /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/mount.h:38: /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/ucred.h:42:10: fatal error: 'bsm/audit.h' file not found #include ^ Even defining HISTORICAL_MAKE_WORLD did not help, but then I'm not doing 'make world' So why is this include file missing? Try with https://cgit.freebsd.org/src/commit/?id=f41efc453ab5563cde214cb19273d87e6e4aa2d4 applied. You probably have WITHOUT_AUDIT=yes in src.conf I'm pretty sure that was one of the settings in src.conf. But the fan in the powersupply of my builder has crashed, and leaving my office smelling of melted plastic. ;( So I first need to find a replacement PSU. --WjW ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Trying to build Current
On Thu, 15 Apr 2021 10:51:39 +0200 Willem Jan Withagen via freebsd-current wrote: > Hi, > > I actually went completely back to the basic setup with directories > /usr/src and /usr/obj > But even then I do not manage to buildworld. > The process keeps bumping into missing bsm/audit. > > First case was when it tried to build the 64bit libc. > I copied the bsm directory into > /usr/obj/usr/src/amd64.amd64/tmp/usr/include/sys/ > > Which allowed it to continue. > But then a bit further on it halts again in 32bit libc. > Whcih I could fix the same way. > > --- fts.o --- > In file included from /usr/src/lib/libc/gen/fts.c:40: > In file included from > /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/mount.h:38: > /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/ucred.h:42:10: > fatal error: 'bsm/audit.h' file not found > #include > ^ > > Even defining HISTORICAL_MAKE_WORLD did not help, but then I'm not doing > 'make world' > > So why is this include file missing? > > --WjW > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" Try with https://cgit.freebsd.org/src/commit/?id=f41efc453ab5563cde214cb19273d87e6e4aa2d4 applied. You probably have WITHOUT_AUDIT=yes in src.conf -- Emmanuel Vadot ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Trying to build Current
On 15-4-2021 12:44, Yuri Pankov wrote: Willem Jan Withagen via freebsd-current wrote: On 15-4-2021 11:47, Gary Jennejohn wrote: On Thu, 15 Apr 2021 10:51:39 +0200 Willem Jan Withagen via freebsd-current wrote: Hi, I actually went completely back to the basic setup with directories /usr/src and /usr/obj But even then I do not manage to buildworld. The process keeps bumping into missing bsm/audit. First case was when it tried to build the 64bit libc. I copied the bsm directory into __ /usr/obj/usr/src/amd64.amd64/tmp/usr/include/sys/ Which allowed it to continue. But then a bit further on it halts again in 32bit libc. Whcih I could fix the same way. --- fts.o --- In file included from /usr/src/lib/libc/gen/fts.c:40: In file included from /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/mount.h:38: /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/ucred.h:42:10: fatal error: 'bsm/audit.h' file not found #include ^ Even defining HISTORICAL_MAKE_WORLD did not help, but then I'm not doing 'make world' So why is this include file missing? Try running make includes first. This step is missing because you are NOT doing a buildworld. Well actual the commands were: rm -rf /usr/src /usr/obj mkdir -p /usr/src /usr/obj cd /usr/src git clone https://git.freebsd.org/src.git . make -j16 buildworld But I'll give it a shot anyways. Anything in /etc/make.conf and /etc/src.conf? I had the same idea, but only after I asked the question There was quite a lot of old cruft there Removed it all, and I'm trying fresh again. But Clang building, even with ccache takes quite some time. --WjW --WjW ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Trying to build Current
On 15-4-2021 11:47, Gary Jennejohn wrote: On Thu, 15 Apr 2021 10:51:39 +0200 Willem Jan Withagen via freebsd-current wrote: Hi, I actually went completely back to the basic setup with directories /usr/src and /usr/obj But even then I do not manage to buildworld. The process keeps bumping into missing bsm/audit. First case was when it tried to build the 64bit libc. I copied the bsm directory into __ /usr/obj/usr/src/amd64.amd64/tmp/usr/include/sys/ Which allowed it to continue. But then a bit further on it halts again in 32bit libc. Whcih I could fix the same way. --- fts.o --- In file included from /usr/src/lib/libc/gen/fts.c:40: In file included from /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/mount.h:38: /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/ucred.h:42:10: fatal error: 'bsm/audit.h' file not found #include ^ Even defining HISTORICAL_MAKE_WORLD did not help, but then I'm not doing 'make world' So why is this include file missing? Try running make includes first. This step is missing because you are NOT doing a buildworld. Well actual the commands were: rm -rf /usr/src /usr/obj mkdir -p /usr/src /usr/obj cd /usr/src git clone https://git.freebsd.org/src.git . make -j16 buildworld But I'll give it a shot anyways. --WjW ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Trying to build Current
On Thu, 15 Apr 2021 10:51:39 +0200 Willem Jan Withagen via freebsd-current wrote: > Hi, > > I actually went completely back to the basic setup with directories > /usr/src and /usr/obj > But even then I do not manage to buildworld. > The process keeps bumping into missing bsm/audit. > > First case was when it tried to build the 64bit libc. > I copied the bsm directory into > __ /usr/obj/usr/src/amd64.amd64/tmp/usr/include/sys/ > > Which allowed it to continue. > But then a bit further on it halts again in 32bit libc. > Whcih I could fix the same way. > > --- fts.o --- > In file included from /usr/src/lib/libc/gen/fts.c:40: > In file included from > /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/mount.h:38: > /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/ucred.h:42:10: > fatal error: 'bsm/audit.h' file not found > #include > ^ > > Even defining HISTORICAL_MAKE_WORLD did not help, but then I'm not doing > 'make world' > > So why is this include file missing? > Try running make includes first. This step is missing because you are NOT doing a buildworld. -- Gary Jennejohn ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Trying to build Current
Hi, I actually went completely back to the basic setup with directories /usr/src and /usr/obj But even then I do not manage to buildworld. The process keeps bumping into missing bsm/audit. First case was when it tried to build the 64bit libc. I copied the bsm directory into /usr/obj/usr/src/amd64.amd64/tmp/usr/include/sys/ Which allowed it to continue. But then a bit further on it halts again in 32bit libc. Whcih I could fix the same way. --- fts.o --- In file included from /usr/src/lib/libc/gen/fts.c:40: In file included from /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/mount.h:38: /usr/obj/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/ucred.h:42:10: fatal error: 'bsm/audit.h' file not found #include ^ Even defining HISTORICAL_MAKE_WORLD did not help, but then I'm not doing 'make world' So why is this include file missing? --WjW ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
