Re: r358252 causes intermittent hangs where processes are stuck sleeping on btalloc
On Wed, May 20, 2020 at 6:04 PM Rick Macklem wrote: > > Hi, > > Since I hadn't upgraded a kernel through the winter, it took me a while > to bisect this, but r358252 seems to be the culprit. > > If I do a kernel build over NFS using my not so big Pentium 4 (single core, > 1.25Gbytes RAM, i386), about every second attempt will hang. > When I do a "ps" in the debugger, I see processes sleeping on btalloc. > If I revert to r358251, I cannot reproduce this. > > Any ideas? > > I can easily test any change you might suggest to see if it fixes the > problem. > > If you want more debug info, let me know, since I can easily > reproduce it. > > Thanks, rick Nothing obvious to me. I can maybe try a repro on a VM... ddb ps, acttrace, alltrace, show all vmem, show page would be welcome. "btalloc" is "We're either out of address space or lost a fill race." ___ 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: r358252 causes intermittent hangs where processes are stuck sleeping on btalloc
On Wed, May 20, 2020 at 11:58:50PM -0700, Ryan Libby wrote: > On Wed, May 20, 2020 at 6:04 PM Rick Macklem wrote: > > > > Hi, > > > > Since I hadn't upgraded a kernel through the winter, it took me a while > > to bisect this, but r358252 seems to be the culprit. > > > > If I do a kernel build over NFS using my not so big Pentium 4 (single core, > > 1.25Gbytes RAM, i386), about every second attempt will hang. > > When I do a "ps" in the debugger, I see processes sleeping on btalloc. > > If I revert to r358251, I cannot reproduce this. > > > > Any ideas? > > > > I can easily test any change you might suggest to see if it fixes the > > problem. > > > > If you want more debug info, let me know, since I can easily > > reproduce it. > > > > Thanks, rick > > Nothing obvious to me. I can maybe try a repro on a VM... > > ddb ps, acttrace, alltrace, show all vmem, show page would be welcome. > > "btalloc" is "We're either out of address space or lost a fill race." Yes, I would be not surprised to be out of something on 1G i386 machine. Please also add 'show alllocks'. ___ 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"
RFC: merging nfs-over-tls changes into head/sys
Hi, I have now completed changes to the code in projects/nfs-over-tls, which implements TLS encryption of NFS RPC messages. (This roughly conforms to the internet draft "Towards Remote Procedure Call Encryption By Default", which should soon become an RFC. For now, TLS1.2 is used instead of TLS1.3, since FreeBSD's KERN_TLS does not yet implement TLS1.3.) I'd like to start merging some of the kernel changes into head/sys. The first of these would be creation of the syscall used by the daemons. (The code in projects/nfs-over-tls cheats and uses the syscall for the gssd, but it needs to have its own syscall so that the gssd daemon can run concurrently with it. I didn't want testers to need to build userland just to get a syscall stub in libc.) After this, there are a bunch of changes to the NFS code to add support for ext_pgs mbufs (these are significant patches, but should not affect the non-ext_pgs mbuf case, since they'll be conditional on ND_EXTPGS/M_EXTPGS). Does this sound ok to do? Please let me know if you see problems with me doing this? Thanks, rick ___ 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 Wed, Feb 05, 2020 at 02:45:50PM +0100, Andreas Nilsson wrote: Ok I am going to respond to this old email from February.. > Hello, > > I upgraded to a newer version, git 87d669d3863-c266265, and I do not > experience the random hang anymore. The machine still hangs on boot on > "hwpstate_intel0: on cpu0" unless I set > 'hint.hwpstate_intel.0.disabled="1"' in loader.conf. > As a few others know on IRC I ran into exactly this same problem on a brand new Lenovo Carbon. I missed this thread somehow. I also had to bisect the commit. Would it be possible to put a note into UPDATING and default to disabled=1 for now? ;) ... > > Best regards > Andreas > > On Sat, Feb 1, 2020 at 11:26 PM Andreas Nilsson wrote: > > > Hello Conrad, > > > > thank you Andrey for bisecting! I'll try with that hint and see how it > > works for me. > > > > Best regards > > Andreas > > > > On Sat, Feb 1, 2020, 18:18 Conrad Meyer wrote: > > > >> Hi Andrey, > >> > >> Please try 'hint.hwpstate_intel.0.disabled="1"' as a workaround for now. > >> > >> I think I have identified at least one problematic piece of code, > >> although I don't know if it's the root cause. I will go ahead and fix > >> that, which may not fix the hang, and also add some debug printfs that > >> can be enabled to help identify the real issue. > >> > >> Thanks for the report and bisect. > >> > >> Best, > >> Conrad > >> > >> On Sat, Feb 1, 2020 at 6:06 AM Andrey V. Elsukov > >> wrote: > >> > > >> > 31.01.2020 18:11, Andrey V. Elsukov пишет: > >> > > On 24.01.2020 19:52, Andreas Nilsson wrote: > >> > >> It hangs during kernel boot and the last message printed on console > >> is: > >> > >> hwpstate_intel0: on cpu0 > >> > > > >> > > Hi, > >> > > > >> > > Did you find the cause of this hang? > >> > > I also tried to update today from r350816 to r357330. But my Lenovo X1 > >> > > Carbon 4th hangs on the same message. > >> > > > >> > > >> > Hi, > >> > > >> > I have bisected the bad commit, it is r357002. Yep. I also had to bisect this from what is now some 5 months ago :-( Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ 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"
