Re: r356776 breaks kernel for powerpc64 users
Dennis Clarke dclarke at blastwave.org wrote on Mon Jan 27 02:25:15 UTC 2020 : > On 2020-01-26 19:27, Mark Millard wrote: > > Piotr Kubaj listy at anongoth.pl wrote on > > Thu Jan 16 19:56:11 UTC 2020 : > > > >> revision 356776 breaks booting for powerpc64 users. It reportedly works > >> fine on POWER8, but I get kernel panic on POWER9 (Talos II) right after > >> the usual warning: WITNESS enabled. Kernel panic is uploaded to > >> https://pastebin.com/s8ZaUNS2. > >> > >> > >> @jeff > >> Since you commited this patch, can you fix this issue or revert this > >> commit? > >> > > > > Is this still a problem for powerpc64? I've not seen > > anything looking like a direct response or like a > > status update for this. > > > > I do see arm report(s) of problems that they also > > attributed to head -r356776 . But I've no clue how > > good the evidence is generally. An example message > > is: > > > > https://lists.freebsd.org/pipermail/freebsd-arm/2020-January/021069.html > > > > But one part of that is for specifically for going > > from -r356767 to the next check-in to head: -r356776 . > > That problem likely has good evidence for the > > attribution to -r356776 . > > > > I will give current a try and report back. However I am hesitant to do > so as I have a working G5 right now. > > For science ... I will do the experiment. If Piotr has a context that fairly reliably gives the problem still, you might want to wait until it starts working. Especially if you can not keep a bootable copy of your working environment. I've not heard one way or the other for any PowerMacs. Piotr indicated some POWER8 contexts did not get the problem that he got on POWER9. Also, unfortunately, head -r356899 eliminated the old binutils as program but powerpc64 can still require it for an (empty!) crtsavres.s assembly. powerpc64 probably needs to be changed to avoid using an external assembler for anything, even indirectly via system-clang reaching into /usr/local/ if it does so. (Otherwise an external toolchain is still required.) Of course, if one is not building from source, this is not an issue. Another issue is that the "epoch" usage changes seem to have lead to a fair number of crash problems as the various places gradually are updated to use it the new way but do not fully work prior to their updates. (It is just an impression of what I've read but not dealt with: I might have summarized incorrectly.) These and -r536776 related material have overlapping time frames, so it may be things are odd until all 3 areas have been taken care of sufficiently. I'm still holding at head -r356426 as the base version for my activities. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ 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: r356776 breaks kernel for powerpc64 users
On 2020-01-26 19:27, Mark Millard wrote: Piotr Kubaj listy at anongoth.pl wrote on Thu Jan 16 19:56:11 UTC 2020 : revision 356776 breaks booting for powerpc64 users. It reportedly works fine on POWER8, but I get kernel panic on POWER9 (Talos II) right after the usual warning: WITNESS enabled. Kernel panic is uploaded to https://pastebin.com/s8ZaUNS2. @jeff Since you commited this patch, can you fix this issue or revert this commit? Is this still a problem for powerpc64? I've not seen anything looking like a direct response or like a status update for this. I do see arm report(s) of problems that they also attributed to head -r356776 . But I've no clue how good the evidence is generally. An example message is: https://lists.freebsd.org/pipermail/freebsd-arm/2020-January/021069.html But one part of that is for specifically for going from -r356767 to the next check-in to head: -r356776 . That problem likely has good evidence for the attribution to -r356776 . I will give current a try and report back. However I am hesitant to do so as I have a working G5 right now. For science ... I will do the experiment. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ 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: r356776 breaks kernel for powerpc64 users
Piotr Kubaj listy at anongoth.pl wrote on Thu Jan 16 19:56:11 UTC 2020 : > revision 356776 breaks booting for powerpc64 users. It reportedly works fine > on POWER8, but I get kernel panic on POWER9 (Talos II) right after the usual > warning: WITNESS enabled. Kernel panic is uploaded to > https://pastebin.com/s8ZaUNS2. > > > @jeff > Since you commited this patch, can you fix this issue or revert this commit? > Is this still a problem for powerpc64? I've not seen anything looking like a direct response or like a status update for this. I do see arm report(s) of problems that they also attributed to head -r356776 . But I've no clue how good the evidence is generally. An example message is: https://lists.freebsd.org/pipermail/freebsd-arm/2020-January/021069.html But one part of that is for specifically for going from -r356767 to the next check-in to head: -r356776 . That problem likely has good evidence for the attribution to -r356776 . === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ 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: how to use the ktls
John Baldwin wrote:
[stuff snipped]
>Hmmm, this might be a fair bit of work indeed.
>
>Right now KTLS only works for transmit (though I have some WIP for receive).
>
>KTLS does assumes that the initial handshake and key negotiation is handled by
>OpenSSL. OpenSSL uses custom setockopt() calls to tell the kernel which
>session keys to use.
>
>I think what you would want to do is use something like OpenSSL_connect() in
>userspace, and then check to see if KTLS "worked". If it did, you can tell
>the kernel it can write to the socket directly, otherwise you will have to
>bounce data back out to userspace to run it through SSL_write() and have
>userspace do SSL_read() and then feed data into the kernel.
>
>The pseudo-code might look something like:
>
>SSL *s;
>
>s = SSL_new(...);
>
>/* fd is the existing TCP socket */
>SSL_set_fd(s, fd);
>OpenSSL_connect(s);
>if (BIO_get_ktls_send(SSL_get_wbio(s)) {
> /* Can use KTLS for transmit. */
>}
>if (BIO_get_ktls_recv(SSL_get_rbio(s)) {
> /* Can use KTLS for receive. */
>}
So, I've been making some progress. The first stab at the daemons that do the
handshake are now on svn in base/projects/nfs-over-tls/usr.sbin/rpctlscd and
rpctlssd.
A couple of questions...
1 - I haven't found BIO_get_ktls_send() or BIO_get_ktls_recv(). Are they in some
different library?
2 - After a successful SSL_connect(), the receive queue for the socket has
478bytes
of stuff in it. SSL_read() seems to know how to skip over it, but I haven't
figured out a good way to do this. (I currently just do a recv(..478,0) on
the
socket.)
Any idea what to do with this? (Or will the receive side of the ktls
figure out
how to skip over it?)
I'm currently testing with a kernel that doesn't have options KERN_TLS and
(so long as I get rid of the 478 bytes), it then just does unencrypted RPCs.
So, I guess the big question is can I get access to your WIP code for KTLS
receive? (I have no idea if I can make progress on it, but I can't do a lot more
before I have that.)
Oh, and for anyone out there...
What is the easiest freebie way to test signed certificates?
(I currently am using a self-signed certificate, but I need to test the "real"
version
at some point soon.)
Thanks, rick
--
John Baldwin
___
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: After update to r357104 build of poudriere jail fails with 'out of swap space'
> In message <20200125233116.ga49...@troutmask.apl.washington.edu>, Steve > Kargl w > rites: > > On Sat, Jan 25, 2020 at 02:09:29PM -0800, Cy Schubert wrote: > > > On January 25, 2020 1:52:03 PM PST, Steve Kargl > > > > on.edu> wrote: > > > >On Sat, Jan 25, 2020 at 01:41:16PM -0800, Cy Schubert wrote: > > > >> > > > >> It's not just poudeiere. Standard port builds of chromium, rust > > > >> and thunderbird also fail on my machines with less than 8 GB. > > > >> > > > > > > > >Interesting. I routinely build chromium, rust, firefox, > > > >llvm and few other resource-hunger ports on a i386-freebsd > > > >laptop with 3.4 GB available memory. This is done with > > > >chrome running with a few tabs swallowing a 1-1.5 GB of > > > >memory. No issues. > > > > > > Number of threads makes a difference too. How many core/threads does your > > > l > > aptop have? > > > > 2 cores. > > This is why. > > > > > > Reducing number of concurrent threads allowed my builds to complete > > > on the 5 GB machine. My build machines have 4 cores, 1 thread per > > > core. Reducing concurrent threads circumvented the issue. > > > > I use portmaster, and AFIACT, it uses 'make -j 2' for the build. > > Laptop isn't doing too much, but an update and browsing. It does > > take a long time especially if building llvm is required. > > I use portmaster as well (for quick incidental builds). It uses > MAKE_JOBS_NUMBER=4 (which is equivalent to make -j 4). I suppose machines > with not enough memory to support their cores with certain builds might > have a better chance of having this problem. > > MAKE_JOBS_NUMBER_LIMIT to limit a 4 core machine with less than 2 GB per > core might be an option. Looking at it this way, instead of an extra 3 GB, > the extra 60% more memory in the other machine makes a big difference. A > rule of thumb would probably be, have ~ 2 GB RAM for every core or thread > when doing large parallel builds. Perhaps we need to redo some boot time calculations, for one the ZFS arch cache, IMHO, is just silly at a fixed percent of total memory. A high percentage at that. One idea based on what you just said might be: percore_memory_reserve = 2G (Your number, I personally would use 1G here) arc_max = MAX(memory size - (Cores * percore_memory_reserve), 512mb) I think that simple change would go a long ways to cutting down the number of OOM reports we see. ALSO IMHO there should be a way for sub systems to easily tell zfs they are memory pigs too and need to share the space. Ie, bhyve is horrible if you do not tune zfs arc based on how much memory your using up for VM's. Another formulation might be percore_memory_reserve = alpha * memory_zire / cores Alpha most likely falling in the 0.25 to 0.5 range, I think this one would have better scalability, would need to run some numbers. Probably needs to become non linear above some core count. > Cy Schubert -- Rod Grimes rgri...@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: hwpstate_intel hangs kernel
On Fri, Jan 24, 2020 at 5:52 PM Andreas Nilsson wrote: > Hello, > > I updated my sources from 20200113 to 20200124 and after that my laptop > hangs during boot. > > The machine is a Lenovo Thinkpad X1 yoga with a core i7-6500U cpu and 8Gb > ram. > > It hangs during kernel boot and the last message printed on console is: > hwpstate_intel0: on cpu0 > > I reverted commits > 1c59e40a6928d0e50272f3653cc3be27a94d8ea3 > 0a0670f4aee197f46e40fda8b1c58f15fa882043 > a4e3b5b685179d1576933ac5e67719dfe96efdea > and recompiled the kernel, which then boots just fine. > > Interestingly, the hwpstate_intel code worked fine on my workstation, with > a Intel i7-7700 cpu. > > I set debug.hwpstate_verbose=1 in loader.conf in hopes of getting more > info, but I could not see any additional information. > > Best regards > Andreas > There seems to be further problems: My workstation has since hung, I'm on my way to the office to check it out now. My laptop with the hwpstate patches reverted has also hung, so that issue might be due to another commit. Best regards Andreas ___ 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: ip_divert.c:374:7: error: use of undeclared identifier
25.01.2020, 19:14, "AN" : > FYI Should be fixed by r357144. Thanks for the report! > > FreeBSD Free_BSD_13 13.0-CURRENT FreeBSD 13.0-CURRENT #22 r356360: Sat Jan > 4 20:10:21 EST 2020 > root@Free_BSD_13:/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL amd64 1300074 > > --- all_subdir_dtrace --- > --- prototype.o --- > cc -target x86_64-unknown-freebsd13.0 > --sysroot=/usr/obj/usr/src/amd64.amd64/tmp > -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe > -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -DKLD_TIED -nostdinc > -I/usr/src/sys/cddl/compat/opensolaris > -I/usr/src/sys/cddl/contrib/opensolaris/uts/common -I/usr/src/sys > -DHAVE_KERNEL_OPTION_HEADERS -include > /usr/obj/usr/src/amd64.amd64/sys/MYKERNEL/opt_global.h -I. -I/usr/src/sys > -I/usr/src/sys/contrib/ck/include -fno-common -g -fno-omit-frame-pointer > -mno-omit-leaf-frame-pointer > -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include > -fdebug-prefix-map=./x86=/usr/src/sys/x86/include > -I/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL -MD > -MF.depend.prototype.o -MTprototype.o -mcmodel=kernel -mno-red-zone > -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables > -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ > -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas > -Wno-error-tautological-compare -Wno-error-empty-body > -Wno-error-parentheses-equality -Wno-error-unused-function > -Wno-error-pointer-sign -Wno-error-shift-negative-value > -Wno-address-of-packed-member -Wno-format-zero-length -mno-aes -mno-avx > -std=iso9899:1999 -include > /usr/src/sys/cddl/compat/opensolaris/sys/debug_compat.h -c > /usr/src/sys/cddl/dev/prototype.c -o prototype.o > --- all_subdir_iir --- > --- iir.ko.debug --- > objcopy --only-keep-debug iir.ko.full iir.ko.debug > --- iir.ko --- > objcopy --strip-debug --add-gnu-debuglink=iir.ko.debug iir.ko.full iir.ko > --- all_subdir_ipdivert --- > /usr/src/sys/netinet/ip_divert.c:374:7: error: use of undeclared > identifier 'IPV6_VERSION' > case IPV6_VERSION >> 4: > ^ > --- all_subdir_ipfilter --- > ===> ipfilter (all) > [Creating objdir > /usr/obj/usr/src/amd64.amd64/sys/MYKERNEL/modules/usr/src/sys/modules/ipfilter...] > --- all_subdir_ipdivert --- > 1 error generated. > *** [ip_divert.o] Error code 1 > > make[4]: stopped in /usr/src/sys/modules/ipdivert > 1 error > > make[4]: stopped in /usr/src/sys/modules/ipdivert > *** [all_subdir_ipdivert] Error code 2 > > ___ > 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"
