Re: update UPDATING after malloc code change
On Sun, 8 Nov 2020 00:22:26 +0100 Guido Falsi wrote: > On 07/11/20 17:20, Gary Jennejohn wrote: > > It seems like an entry should be added to /usr/src/UPDATING, since the > > change made > > to the malloc code causes panics with KMODs from ports if they haven't been > > re-compiled. My nvidia-driver also caused a panic with a new kernel. > > > > A reminder/warning would be useful. > > > > Why? Rebuilding kmods every time you update the kernel sources is > already required by default. > No, it's not. It's an option which can be used, not a requirement. -- 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"
Re: CURRENT failing at contrib/unbound/util/config_file.c:122:20
On 11/7/20 3:56 PM, Cy Schubert wrote: In message , Pete Wright w rites: wondering if anyone else is having this error building CURRENT today: --- config_file.o --- /usr/home/pete/git/freebsd/contrib/unbound/util/config_file.c:122:20: error: use of undeclared identifier 'UNBOUND_DNS_OVER_HTTPS_PORT'        cfg->https_port = UNBOUND_DNS_OVER_HTTPS_PORT;                          ^ 1 error generated. --- all_subdir_lib/ncurses --- my last commit from the github mirror is: commit efb48d58bee75fdb221adece8ef5a13cede99e8c (HEAD -> master, origin/master, origin/HEAD) Author: tuexen Date:  Sat Nov 7 21:17:49 2020 +    The ioctl() calls using FIONREAD, FIONWRITE, FIONSPACE, and SIOCATMAR K    access the socket send or receive buffer. This is not possible for    listening sockets since r319722.    Because send()/recv() calls fail on listening sockets, fail also ioctl()    indicating EINVAL. so not sure if it's been found or if this is a real issue. No such problem here. What do you see on line 1397 of /usr/src/usr.sbin/unbound/config.h? Also, uname -a, please. And, git status usr.sbin/unbound, looking for local mods. Your cwd will need to be the root of your git tree. Thanks Cy for the confirmation that it is working on your end. I think my git checkout must be in a bad state locally. Even after a make clean and purge of my obj directory it was still failing. I then did a fresh checkout using the cgit-beta server and it is building fine now by the looks of it. I should have done that before spam'ing the list - d'oh. -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ 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: update UPDATING after malloc code change
On 07/11/20 17:20, Gary Jennejohn wrote: It seems like an entry should be added to /usr/src/UPDATING, since the change made to the malloc code causes panics with KMODs from ports if they haven't been re-compiled. My nvidia-driver also caused a panic with a new kernel. A reminder/warning would be useful. Why? Rebuilding kmods every time you update the kernel sources is already required by default. You should be surprised when the old kmods still work, not the other way around. -- Guido Falsi ___ 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: update UPDATING after malloc code change
On Sat, Nov 7, 2020 at 5:43 PM Tomoaki AOKI wrote: > On Sun, 8 Nov 2020 00:22:26 +0100 > Guido Falsi wrote: > > > On 07/11/20 17:20, Gary Jennejohn wrote: > > > It seems like an entry should be added to /usr/src/UPDATING, since the > change made > > > to the malloc code causes panics with KMODs from ports if they haven't > been > > > re-compiled. My nvidia-driver also caused a panic with a new kernel. > > > > > > A reminder/warning would be useful. > > > > > > > Why? Rebuilding kmods every time you update the kernel sources is > > already required by default. > > IIRC, there's no official documentation for it. > There is a warning to disable to old modules, which is close... > Adding new NOTE for it into UPDATING (before the first dated entry) > would be a good idea, as someone encounterd problem would read it > to confirm any cautions. > https://svnweb.freebsd.org/base?view=revision=367474 has my take on that. Please let me know what you think. Warner > > You should be surprised when the old kmods still work, not the other way > > around. > > +1. > > > > > -- > > Guido Falsi > > ___ > > 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" > > > -- > Tomoaki AOKI > ___ > 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: update UPDATING after malloc code change
On Sun, 8 Nov 2020 00:22:26 +0100 Guido Falsi wrote: > On 07/11/20 17:20, Gary Jennejohn wrote: > > It seems like an entry should be added to /usr/src/UPDATING, since the > > change made > > to the malloc code causes panics with KMODs from ports if they haven't been > > re-compiled. My nvidia-driver also caused a panic with a new kernel. > > > > A reminder/warning would be useful. > > > > Why? Rebuilding kmods every time you update the kernel sources is > already required by default. IIRC, there's no official documentation for it. Adding new NOTE for it into UPDATING (before the first dated entry) would be a good idea, as someone encounterd problem would read it to confirm any cautions. > You should be surprised when the old kmods still work, not the other way > around. +1. > > -- > Guido Falsi > ___ > 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" -- Tomoaki AOKI ___ 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: CURRENT failing at contrib/unbound/util/config_file.c:122:20
In message , Pete Wright w rites: > wondering if anyone else is having this error building CURRENT today: > > > --- config_file.o --- > /usr/home/pete/git/freebsd/contrib/unbound/util/config_file.c:122:20: > error: use of undeclared identifier 'UNBOUND_DNS_OVER_HTTPS_PORT' > Â Â Â Â Â Â Â cfg->https_port = UNBOUND_DNS_OVER_HTTPS_PORT; > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ^ > 1 error generated. > --- all_subdir_lib/ncurses --- > > > my last commit from the github mirror is: > > commit efb48d58bee75fdb221adece8ef5a13cede99e8c (HEAD -> master, > origin/master, origin/HEAD) > Author: tuexen > Date:Â Â Sat Nov 7 21:17:49 2020 + > > Â Â Â The ioctl() calls using FIONREAD, FIONWRITE, FIONSPACE, and SIOCATMAR > K > Â Â Â access the socket send or receive buffer. This is not possible for > Â Â Â listening sockets since r319722. > Â Â Â Because send()/recv() calls fail on listening sockets, fail also > ioctl() > Â Â Â indicating EINVAL. > > so not sure if it's been found or if this is a real issue. No such problem here. What do you see on line 1397 of /usr/src/usr.sbin/unbound/config.h? Also, uname -a, please. And, git status usr.sbin/unbound, looking for local mods. Your cwd will need to be the root of your git tree. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. ___ 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"
Darwin-XNU
Hi, I'm trying to build Darwin-XNU and XQuartz on freebsd and suggestions? The XQuartz submodules are broken Thank You, Jonathan Moore ___ 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"
CURRENT failing at contrib/unbound/util/config_file.c:122:20
wondering if anyone else is having this error building CURRENT today: --- config_file.o --- /usr/home/pete/git/freebsd/contrib/unbound/util/config_file.c:122:20: error: use of undeclared identifier 'UNBOUND_DNS_OVER_HTTPS_PORT' cfg->https_port = UNBOUND_DNS_OVER_HTTPS_PORT; ^ 1 error generated. --- all_subdir_lib/ncurses --- my last commit from the github mirror is: commit efb48d58bee75fdb221adece8ef5a13cede99e8c (HEAD -> master, origin/master, origin/HEAD) Author: tuexen Date: Sat Nov 7 21:17:49 2020 + The ioctl() calls using FIONREAD, FIONWRITE, FIONSPACE, and SIOCATMARK access the socket send or receive buffer. This is not possible for listening sockets since r319722. Because send()/recv() calls fail on listening sockets, fail also ioctl() indicating EINVAL. so not sure if it's been found or if this is a real issue. thx! -p -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ 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: panic: VERIFY(ZFS_TEARDOWN_READ_HELD(zfsvfs)) failed
Fixed as of r367454 (also see r367453). On 11/6/20, Mateusz Guzik wrote: > I think I have an idea how to keep this. In the meantime you can just > comment it out. > > On 11/6/20, Mateusz Guzik wrote: >> On 11/6/20, Andriy Gapon wrote: >>> On 06/11/2020 22:58, Mateusz Guzik wrote: Note the underlying primitive was recently replaced. One immediate thing to check would be exact state of the lock. READ_HELD checks for reading only, fails if you have this write-locked, which is a plausible explanation if you are coming in from less likely codepath. iow what's the backtrace and can you print both rms->readers and rms->owner (+ curthread) >>> >>> Unfortunately, I do not have a vmcore, only a picture of the screen. >>> >>> ZFS code looks correct, the lock should be held in read mode, so indeed >>> I >>> suspect that the problem is with rms. >>> >>> It looks like rms_rlock() does not change rmslock::readers, but >>> rms_rowned() >>> checks it? >>> >>> That's just from a first, super-quick look at the code. >>> >> >> Heh, now that you mention it, I remember wanting to just remove the >> arguably spurious assert. Linux is never doing it for reading. The >> only state asserts made are for writing which works fine. >> >> As for reading assertions, there is no performant way to make it work >> and I don't think it is worth it as it is. >> >> As such, I vote for just removing these 2 asserts. They really don't >> buy anything to begin with. >> >> -- >> Mateusz Guzik >> > > > -- > Mateusz Guzik > -- Mateusz Guzik ___ 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"
update UPDATING after malloc code change
It seems like an entry should be added to /usr/src/UPDATING, since the change made to the malloc code causes panics with KMODs from ports if they haven't been re-compiled. My nvidia-driver also caused a panic with a new kernel. A reminder/warning would be useful. -- 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"
