/var/log/messages: "should not happen" "see local kernel hacker"
Hello, I thought I'd finally ask about these messages that appear on boot on my machine. It's a Lenovo A485, with an AMD Ryzen laptop running CURRENT as of 8 hours ago, in case that's relevant. Are some of these actionable/would it make sense to take a deeper look or are they about something needing further debugging with the "right" hardware? 1. "this should not happen": FTR: - I switched the wireless chip for an Intel AC 8265. - I'm used to having wireless be wlan0, so I rename iwm0 in rc.conf - This was connecting to a mobile hotspot, but I've seen the message on "normal" networks. And this is what I am seeing in /var/log/messages: Jan 14 06:33:50 kernel: iwm0: 8265> mem 0xc0a0-0xc0a01fff at device 0.0 on pci2 Jan 14 06:33:50 kernel: iwm0: hw rev 0x230, fw ver 22.361476.0, address XX Jan 14 06:33:50 kernel: wlan0: Ethernet address: XX Jan 14 06:33:50 kernel: wlan0: link state changed to UP Jan 14 06:33:50 kernel: iwm0: frame 3/122 b82c UNHANDLED (this should not happen) Jan 14 06:33:50 kernel: iwm0: frame 4/192 b82c UNHANDLED (this should not happen) Jan 14 06:33:50 kernel: iwm0: frame 5/233 b82c UNHANDLED (this should not happen) 2. There is also this "driver bug": Jan 14 06:33:50 kernel: AMD-Vi: IVRS Info VAsize = 64 PAsize = 48 GVAsize = 2 flags:0 Jan 14 06:33:50 kernel: driver bug: Unable to set devclass (class: ppc devname: (unknown)) 3. And "see your local kernel hacker" has been around on my system for about a year, suspend and resume work just fine. Jan 14 06:33:52 kernel: __pm_runtime_resume not implemented -- see your local kernel hacker Jan 14 06:33:52 kernel: pm_runtime_mark_last_busy not implemented -- see your local kernel hacker Jan 14 06:33:52 kernel: __pm_runtime_suspend not implemented -- see your local kernel hacker Jan 14 06:33:52 kernel: __pm_runtime_resume not implemented -- see your local kernel hacker Jan 14 06:33:52 kernel: pm_runtime_mark_last_busy not implemented -- see your local kernel hacker Jan 14 06:33:52 kernel: __pm_runtime_suspend not implemented -- see your local kernel hacker 4. Then 'Giant locked and may be deleted': Jan 14 06:33:50 kernel: WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0. Jan 14 06:33:50 kernel: WARNING: Device "psm" is Giant locked and may be deleted before FreeBSD 13.0. Jan 14 06:33:50 kernel: WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 13.0. I am guessing number 4 has to do with recent changes, and shouldn't really affect the system if the devices are deleted? Is there a way I can test if its deletion would leave the system unusable? Thank you, -- Evilham ___ 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: >On 1/12/20 8:23 PM, Benjamin Kaduk wrote: >> On Thu, Jan 09, 2020 at 10:53:38PM +, Rick Macklem wrote: >>> John Baldwin wrote: On 1/7/20 3:02 PM, Rick Macklem wrote: > Hi, > > Now that I've completed NFSv4.2 I'm on to the next project, which is > making NFS > work over TLS. > Of course, I know absolutely nothing about TLS, which will make this an > interesting > exercise for me. > I did find simple server code in the OpenSSL doc. which at least gives me > a starting > point for the initialization stuff. > As I understand it, this initialization must be done in userspace? > > Then somehow, the ktls takes over and does the encryption of the > data being sent on the socket via sosend_generic(). Does that sound right? > > So, how does the kernel know the stuff that the initialization phase > (handshake) > figures out, or is it magic I don't have to worry about? > > Don't waste much time replying to this. A few quick hints will keep me > going for > now. (From what I've seen sofar, this TLS stuff isn't simple. And I > thought Kerberos > was a pain.;-) > > Thanks in advance for any hints, rick Hmmm, this might be a fair bit of work indeed. >>> If it was easy, it wouldn't be fun;-) FreeBSD13 is a ways off and if it >>> doesn't make that, oh well.. >>> Right now KTLS only works for transmit (though I have some WIP for receive). >>> Hopefully your WIP will make progress someday, or I might be able to work >>> on it. >>> 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. >>> Yea, I figured I'd need a daemon like the gssd for this. The krpc makes it >>> a little >>> more fun, since it handles TCP connections in the kernel. >>> I think what you would want to do is use something like OpenSSL_connect() in userspace, and then check to see if KTLS "worked". >>> Thanks (and for the code below). I found the simple server code in the >>> OpenSSL doc, >>> but the client code gets a web page and is quite involved. >>> 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. >>> I don't think bouncing the data up/down to/from userland would work well. >>> I'd say "if it can't be done in the kernel, too bad". The above could be >>> used for >>> a NULL RPC to see it is working, for the client. >> >> So you're saying that we'd only support rpc-over-tls as an NFS client and >> not as a server, at least until the WIP for ktls read appears? Actually, I'd say that neither NFS client nor server will work over tls until the receive side works, since NFS RPCs result in bi-directional traffic. >To be clear, I have KTLS RX working with TOE right now. I have a design in my >head for KTLS RX that would use software and co-processor engines via OCF such >as aesni(4) and ccr(4) that I hope to implement in the next few months, so KTLS >RX isn't too far off. OpenSSL already supports KTLS RX on Linux and the >FreeBSD >patches I already have use the same API. (Each received TLS frame is read via >recvmsg() with the TLS header fields in a cmsg.) Sounds good. It will be a while before I get to the stage where I need it. I'm currently working on how to give userland access to a socket created in the kernel, so that a daemon can use it. Have fun with it, 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: FreeBSD-head-amd64-test - Build #13912 (r356671) - Failure
Thanks and all tests are good now: https://ci.freebsd.org/job/FreeBSD-head-i386-test/8056/ https://ci.freebsd.org/job/FreeBSD-head-amd64-test/13917/ On Mon, Jan 13, 2020 at 10:36 PM Mateusz Guzik wrote: > > Fixed in r356683. > > On 1/13/20, Mateusz Guzik wrote: > > On 1/13/20, Li-Wen Hsu wrote: > >> On Mon, Jan 13, 2020 at 1:10 PM wrote: > >>> > >>> FreeBSD-head-amd64-test - Build #13912 (r356671) - Failure > >>> > >>> Build information: > >>> https://ci.freebsd.org/job/FreeBSD-head-amd64-test/13912/ > >>> Full change log: > >>> https://ci.freebsd.org/job/FreeBSD-head-amd64-test/13912/changes > >>> Full build log: > >>> https://ci.freebsd.org/job/FreeBSD-head-amd64-test/13912/console > >>> > >>> Status explanation: > >>> "Failure" - the build is suspected being broken by the following changes > >>> "Still Failing" - the build has not been fixed by the following changes > >>> and > >>> this is a notification to note that these changes have > >>> not been fully tested by the CI system > >>> > >>> Change summaries: > >>> (Those commits are likely but not certainly responsible) > >>> > >>> 356671 by mjg: > >>> ufs: use lazy list instead of active list for syncer > >>> > >>> Quota code is temporarily regressed to do a full vnode scan. > >>> > >>> Reviewed by:jeff > >>> Tested by: pho (in a larger patch, previous version) > >>> Differential Revision: https://reviews.freebsd.org/D22996 > >>> > >>> 356670 by mjg: > >>> vfs: add per-mount vnode lazy list and use it for deferred inactive + > >>> msync > >>> > >>> This obviates the need to scan the entire active list looking for vnodes > >>> of interest. > >>> > >>> msync is handled by adding all vnodes with write count to the lazy list. > >>> > >>> deferred inactive directly adds vnodes as it sets the VI_DEFINACT flag. > >>> > >>> Vnodes get dequeued from the list when their hold count reaches 0. > >>> > >>> Newly added MNT_VNODE_FOREACH_LAZY* macros support filtering so that > >>> spurious locking is avoided in the common case. > >>> > >>> Reviewed by:jeff > >>> Tested by: pho (in a larger patch, previous version) > >>> Differential Revision: https://reviews.freebsd.org/D22995 > >>> > >>> 356669 by mjg: > >>> ufs: add a setter for inode i_flag field > >>> > >>> This will be used later to add vnodes to the lazy list. > >>> > >>> Reviewed by:kib (previous version), jeff > >>> Tested by: pho (in a larger patch) > >>> Differential Revision: https://reviews.freebsd.org/D22994 > >> > >> Hi Mateusz, > >> > >> I suspect these changes might have something to do about panic of i386 > >> and amd64 in testing: > > > > I'm on it. > > > >> > >> root@:/usr/tests # cd /usr/tests/usr.sbin/makefs/ > >> root@:/usr/tests/usr.sbin/makefs # kyua debug > >> makefs_cd9660_tests:o_flag_rockridge_dev_nodes > >> VNASSERT failed > >> 0xf8000f24a1e8: type VCHR > >> usecount 1, writecount 0, refcount 1 rdev 0 > >> flags () > >> VI_LOCKedlock type ufs: SHARED (count 1) > >> nlink=1, effnlink=1, size=0, extsize 0 > >> generation=73c32c64, uid=0, gid=0, flags=0x0 > >> ino 117778, on dev gpt/rootfs > >> panic: ffs_unlock_debug: modified vnode (420) not on lazy list > >> cpuid = 1 > >> time = 1578910603 > >> KDB: stack backtrace: > >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > >> 0xfe0038a70fd0 > >> vpanic() at vpanic+0x185/frame 0xfe0038a71030 > >> panic() at panic+0x43/frame 0xfe0038a71090 > >> ffs_unlock_debug() at ffs_unlock_debug+0xa5/frame 0xfe0038a710c0 > >> lookup() at lookup+0xd26/frame 0xfe0038a71160 > >> namei() at namei+0x4d8/frame 0xfe0038a71250 > >> kern_fchmodat() at kern_fchmodat+0x92/frame 0xfe0038a71380 > >> amd64_syscall() at amd64_syscall+0x2d6/frame 0xfe0038a714b0 > >> fast_syscall_common() at fast_syscall_common+0x101/frame > >> 0xfe0038a714b0 > >> --- syscall (15, FreeBSD ELF64, sys_chmod), rip = 0x8003ba95a, rsp = > >> 0x7fffe758, rbp = 0x7fffe7e0 --- > >> KDB: enter: panic > >> [ thread pid 1393 tid 100092 ] > >> Stopped at kdb_enter+0x37: movq$0,0x1084396(%rip) > >> db:0:kdb.enter.panic> show pcpu > >> cpuid= 1 > >> dynamic pcpu = 0xfe00887a7d80 > >> curthread= 0xf8000f25a000: pid 1393 tid 100092 critnest 1 > >> "bsdtar" > >> curpcb = 0xf8000f25a4f0 > >> fpcurthread = 0xf8000f25a000: pid 1393 "bsdtar" > >> idlethread = 0xf800033976e0: tid 14 "idle: cpu1" > >> self = 0x82211000 > >> curpmap = 0xf80003e35120 > >> tssp = 0x82211384 > >> rsp0 = 0xfe0038a71580 > >> kcr3 = 0x8f2ab405 > >> ucr3 = 0x8f287c05 > >> scr3 = 0xf287c05 > >> gs32p= 0x82211404 > >> ldt = 0x82211444 > >> tss = 0x82211434 > >> tlb gen = 889 > >> curvnet = 0 > >> spin locks held: > >> db:0:kdb.enter.panic> > >> > >> full log: > >>
spurious(?) userland malloc/mmap failure
While running head r356494, my buildworld just failed due to an apparently spurious userland malloc/mmap failure. ===> usr.bin/finger (all) objcopy: elf_update() failed: I/O error: Cannot allocate memory --- all_subdir_usr.bin/finger --- *** [all_subdir_usr.bin/finger] Error code 2 I ran 'make' in usr.bin/finger, and objcopy succeeded. I then ran "make buildenv" followed by "make clean" and "make" in usr.bin/finger, which also worked. buildworld was running with -j8, and a few C++ things were building concurrently, such as googletest and usr.bin/clang/llvm-objdump, so maybe the machine was under memory pressure. It's a bhyve VM with 8 CPUs and 8 GB RAM. The full build log is: https://people.freebsd.org/~vangyzen/2010-01-13-buildworld.txt Eric ___ 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
On 1/12/20 8:23 PM, Benjamin Kaduk wrote: > On Thu, Jan 09, 2020 at 10:53:38PM +, Rick Macklem wrote: >> John Baldwin wrote: >>> On 1/7/20 3:02 PM, Rick Macklem wrote: Hi, Now that I've completed NFSv4.2 I'm on to the next project, which is making NFS work over TLS. Of course, I know absolutely nothing about TLS, which will make this an interesting exercise for me. I did find simple server code in the OpenSSL doc. which at least gives me a starting point for the initialization stuff. As I understand it, this initialization must be done in userspace? Then somehow, the ktls takes over and does the encryption of the data being sent on the socket via sosend_generic(). Does that sound right? So, how does the kernel know the stuff that the initialization phase (handshake) figures out, or is it magic I don't have to worry about? Don't waste much time replying to this. A few quick hints will keep me going for now. (From what I've seen sofar, this TLS stuff isn't simple. And I thought Kerberos was a pain.;-) Thanks in advance for any hints, rick >>> >>> Hmmm, this might be a fair bit of work indeed. >> If it was easy, it wouldn't be fun;-) FreeBSD13 is a ways off and if it >> doesn't make that, oh well.. >> >>> Right now KTLS only works for transmit (though I have some WIP for receive). >> Hopefully your WIP will make progress someday, or I might be able to work on >> it. >> >>> 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. >> Yea, I figured I'd need a daemon like the gssd for this. The krpc makes it a >> little >> more fun, since it handles TCP connections in the kernel. >> >>> I think what you would want to do is use something like OpenSSL_connect() in >>> userspace, and then check to see if KTLS "worked". >> Thanks (and for the code below). I found the simple server code in the >> OpenSSL doc, >> but the client code gets a web page and is quite involved. >> >>> 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. >> I don't think bouncing the data up/down to/from userland would work well. >> I'd say "if it can't be done in the kernel, too bad". The above could be >> used for >> a NULL RPC to see it is working, for the client. > > So you're saying that we'd only support rpc-over-tls as an NFS client and > not as a server, at least until the WIP for ktls read appears? To be clear, I have KTLS RX working with TOE right now. I have a design in my head for KTLS RX that would use software and co-processor engines via OCF such as aesni(4) and ccr(4) that I hope to implement in the next few months, so KTLS RX isn't too far off. OpenSSL already supports KTLS RX on Linux and the FreeBSD patches I already have use the same API. (Each received TLS frame is read via recvmsg() with the TLS header fields in a cmsg.) -- 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"
Fast sigblock
https://reviews.freebsd.org/D12773 I intend to commit this in approximately week timeline. The overview of the feature is provided in the review summary above. Short story is, userspace can mask all maskable asynchronous signals with a single memory write, which allows to greatly speed up rtld for single-threaded processes. For small utilities like ls(1), the number of syscalls issued is cut by 1.5-2 times. I believe that a similar feature existed in Solaris, and I saw a mention of it added to DragonFlyBSD. This patch sit in my local repo for many years, I decided to commit it finally. See the following interesting comparision of the startup and runtime cost in term of syscalls https://drewdevault.com/2020/01/04/Slow.html Unpatched we are close to glibc, with the patch applied most of the syscalls issued are mmap(2)s from rtld private allocator and jemalloc(3). ___ 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-head-amd64-test - Build #13912 (r356671) - Failure
Fixed in r356683. On 1/13/20, Mateusz Guzik wrote: > On 1/13/20, Li-Wen Hsu wrote: >> On Mon, Jan 13, 2020 at 1:10 PM wrote: >>> >>> FreeBSD-head-amd64-test - Build #13912 (r356671) - Failure >>> >>> Build information: >>> https://ci.freebsd.org/job/FreeBSD-head-amd64-test/13912/ >>> Full change log: >>> https://ci.freebsd.org/job/FreeBSD-head-amd64-test/13912/changes >>> Full build log: >>> https://ci.freebsd.org/job/FreeBSD-head-amd64-test/13912/console >>> >>> Status explanation: >>> "Failure" - the build is suspected being broken by the following changes >>> "Still Failing" - the build has not been fixed by the following changes >>> and >>> this is a notification to note that these changes have >>> not been fully tested by the CI system >>> >>> Change summaries: >>> (Those commits are likely but not certainly responsible) >>> >>> 356671 by mjg: >>> ufs: use lazy list instead of active list for syncer >>> >>> Quota code is temporarily regressed to do a full vnode scan. >>> >>> Reviewed by:jeff >>> Tested by: pho (in a larger patch, previous version) >>> Differential Revision: https://reviews.freebsd.org/D22996 >>> >>> 356670 by mjg: >>> vfs: add per-mount vnode lazy list and use it for deferred inactive + >>> msync >>> >>> This obviates the need to scan the entire active list looking for vnodes >>> of interest. >>> >>> msync is handled by adding all vnodes with write count to the lazy list. >>> >>> deferred inactive directly adds vnodes as it sets the VI_DEFINACT flag. >>> >>> Vnodes get dequeued from the list when their hold count reaches 0. >>> >>> Newly added MNT_VNODE_FOREACH_LAZY* macros support filtering so that >>> spurious locking is avoided in the common case. >>> >>> Reviewed by:jeff >>> Tested by: pho (in a larger patch, previous version) >>> Differential Revision: https://reviews.freebsd.org/D22995 >>> >>> 356669 by mjg: >>> ufs: add a setter for inode i_flag field >>> >>> This will be used later to add vnodes to the lazy list. >>> >>> Reviewed by:kib (previous version), jeff >>> Tested by: pho (in a larger patch) >>> Differential Revision: https://reviews.freebsd.org/D22994 >> >> Hi Mateusz, >> >> I suspect these changes might have something to do about panic of i386 >> and amd64 in testing: > > I'm on it. > >> >> root@:/usr/tests # cd /usr/tests/usr.sbin/makefs/ >> root@:/usr/tests/usr.sbin/makefs # kyua debug >> makefs_cd9660_tests:o_flag_rockridge_dev_nodes >> VNASSERT failed >> 0xf8000f24a1e8: type VCHR >> usecount 1, writecount 0, refcount 1 rdev 0 >> flags () >> VI_LOCKedlock type ufs: SHARED (count 1) >> nlink=1, effnlink=1, size=0, extsize 0 >> generation=73c32c64, uid=0, gid=0, flags=0x0 >> ino 117778, on dev gpt/rootfs >> panic: ffs_unlock_debug: modified vnode (420) not on lazy list >> cpuid = 1 >> time = 1578910603 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xfe0038a70fd0 >> vpanic() at vpanic+0x185/frame 0xfe0038a71030 >> panic() at panic+0x43/frame 0xfe0038a71090 >> ffs_unlock_debug() at ffs_unlock_debug+0xa5/frame 0xfe0038a710c0 >> lookup() at lookup+0xd26/frame 0xfe0038a71160 >> namei() at namei+0x4d8/frame 0xfe0038a71250 >> kern_fchmodat() at kern_fchmodat+0x92/frame 0xfe0038a71380 >> amd64_syscall() at amd64_syscall+0x2d6/frame 0xfe0038a714b0 >> fast_syscall_common() at fast_syscall_common+0x101/frame >> 0xfe0038a714b0 >> --- syscall (15, FreeBSD ELF64, sys_chmod), rip = 0x8003ba95a, rsp = >> 0x7fffe758, rbp = 0x7fffe7e0 --- >> KDB: enter: panic >> [ thread pid 1393 tid 100092 ] >> Stopped at kdb_enter+0x37: movq$0,0x1084396(%rip) >> db:0:kdb.enter.panic> show pcpu >> cpuid= 1 >> dynamic pcpu = 0xfe00887a7d80 >> curthread= 0xf8000f25a000: pid 1393 tid 100092 critnest 1 >> "bsdtar" >> curpcb = 0xf8000f25a4f0 >> fpcurthread = 0xf8000f25a000: pid 1393 "bsdtar" >> idlethread = 0xf800033976e0: tid 14 "idle: cpu1" >> self = 0x82211000 >> curpmap = 0xf80003e35120 >> tssp = 0x82211384 >> rsp0 = 0xfe0038a71580 >> kcr3 = 0x8f2ab405 >> ucr3 = 0x8f287c05 >> scr3 = 0xf287c05 >> gs32p= 0x82211404 >> ldt = 0x82211444 >> tss = 0x82211434 >> tlb gen = 889 >> curvnet = 0 >> spin locks held: >> db:0:kdb.enter.panic> >> >> full log: >> https://ci.freebsd.org/job/FreeBSD-head-i386-test/8051/consoleFull >> https://ci.freebsd.org/job/FreeBSD-head-amd64-test/13912/consoleFull >> >> test image: >> https://artifact.ci.freebsd.org/snapshot/head/r356671/i386/i386/disk-test.img.xz >> https://artifact.ci.freebsd.org/snapshot/head/r356671/amd64/amd64/disk-test.img.xz >> >> Can you help check this? Thanks. >> >> Best, >> Li-Wen >> > > > -- > Mateusz Guzik > -- Mateusz Guzik
Re: FreeBSD-head-amd64-test - Build #13912 (r356671) - Failure
On 1/13/20, Li-Wen Hsu wrote: > On Mon, Jan 13, 2020 at 1:10 PM wrote: >> >> FreeBSD-head-amd64-test - Build #13912 (r356671) - Failure >> >> Build information: >> https://ci.freebsd.org/job/FreeBSD-head-amd64-test/13912/ >> Full change log: >> https://ci.freebsd.org/job/FreeBSD-head-amd64-test/13912/changes >> Full build log: >> https://ci.freebsd.org/job/FreeBSD-head-amd64-test/13912/console >> >> Status explanation: >> "Failure" - the build is suspected being broken by the following changes >> "Still Failing" - the build has not been fixed by the following changes >> and >> this is a notification to note that these changes have >> not been fully tested by the CI system >> >> Change summaries: >> (Those commits are likely but not certainly responsible) >> >> 356671 by mjg: >> ufs: use lazy list instead of active list for syncer >> >> Quota code is temporarily regressed to do a full vnode scan. >> >> Reviewed by:jeff >> Tested by: pho (in a larger patch, previous version) >> Differential Revision: https://reviews.freebsd.org/D22996 >> >> 356670 by mjg: >> vfs: add per-mount vnode lazy list and use it for deferred inactive + >> msync >> >> This obviates the need to scan the entire active list looking for vnodes >> of interest. >> >> msync is handled by adding all vnodes with write count to the lazy list. >> >> deferred inactive directly adds vnodes as it sets the VI_DEFINACT flag. >> >> Vnodes get dequeued from the list when their hold count reaches 0. >> >> Newly added MNT_VNODE_FOREACH_LAZY* macros support filtering so that >> spurious locking is avoided in the common case. >> >> Reviewed by:jeff >> Tested by: pho (in a larger patch, previous version) >> Differential Revision: https://reviews.freebsd.org/D22995 >> >> 356669 by mjg: >> ufs: add a setter for inode i_flag field >> >> This will be used later to add vnodes to the lazy list. >> >> Reviewed by:kib (previous version), jeff >> Tested by: pho (in a larger patch) >> Differential Revision: https://reviews.freebsd.org/D22994 > > Hi Mateusz, > > I suspect these changes might have something to do about panic of i386 > and amd64 in testing: I'm on it. > > root@:/usr/tests # cd /usr/tests/usr.sbin/makefs/ > root@:/usr/tests/usr.sbin/makefs # kyua debug > makefs_cd9660_tests:o_flag_rockridge_dev_nodes > VNASSERT failed > 0xf8000f24a1e8: type VCHR > usecount 1, writecount 0, refcount 1 rdev 0 > flags () > VI_LOCKedlock type ufs: SHARED (count 1) > nlink=1, effnlink=1, size=0, extsize 0 > generation=73c32c64, uid=0, gid=0, flags=0x0 > ino 117778, on dev gpt/rootfs > panic: ffs_unlock_debug: modified vnode (420) not on lazy list > cpuid = 1 > time = 1578910603 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfe0038a70fd0 > vpanic() at vpanic+0x185/frame 0xfe0038a71030 > panic() at panic+0x43/frame 0xfe0038a71090 > ffs_unlock_debug() at ffs_unlock_debug+0xa5/frame 0xfe0038a710c0 > lookup() at lookup+0xd26/frame 0xfe0038a71160 > namei() at namei+0x4d8/frame 0xfe0038a71250 > kern_fchmodat() at kern_fchmodat+0x92/frame 0xfe0038a71380 > amd64_syscall() at amd64_syscall+0x2d6/frame 0xfe0038a714b0 > fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe0038a714b0 > --- syscall (15, FreeBSD ELF64, sys_chmod), rip = 0x8003ba95a, rsp = > 0x7fffe758, rbp = 0x7fffe7e0 --- > KDB: enter: panic > [ thread pid 1393 tid 100092 ] > Stopped at kdb_enter+0x37: movq$0,0x1084396(%rip) > db:0:kdb.enter.panic> show pcpu > cpuid= 1 > dynamic pcpu = 0xfe00887a7d80 > curthread= 0xf8000f25a000: pid 1393 tid 100092 critnest 1 "bsdtar" > curpcb = 0xf8000f25a4f0 > fpcurthread = 0xf8000f25a000: pid 1393 "bsdtar" > idlethread = 0xf800033976e0: tid 14 "idle: cpu1" > self = 0x82211000 > curpmap = 0xf80003e35120 > tssp = 0x82211384 > rsp0 = 0xfe0038a71580 > kcr3 = 0x8f2ab405 > ucr3 = 0x8f287c05 > scr3 = 0xf287c05 > gs32p= 0x82211404 > ldt = 0x82211444 > tss = 0x82211434 > tlb gen = 889 > curvnet = 0 > spin locks held: > db:0:kdb.enter.panic> > > full log: > https://ci.freebsd.org/job/FreeBSD-head-i386-test/8051/consoleFull > https://ci.freebsd.org/job/FreeBSD-head-amd64-test/13912/consoleFull > > test image: > https://artifact.ci.freebsd.org/snapshot/head/r356671/i386/i386/disk-test.img.xz > https://artifact.ci.freebsd.org/snapshot/head/r356671/amd64/amd64/disk-test.img.xz > > Can you help check this? Thanks. > > Best, > Li-Wen > -- 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"
Re: FreeBSD-head-amd64-test - Build #13912 (r356671) - Failure
On Mon, Jan 13, 2020 at 1:10 PM wrote: > > FreeBSD-head-amd64-test - Build #13912 (r356671) - Failure > > Build information: https://ci.freebsd.org/job/FreeBSD-head-amd64-test/13912/ > Full change log: > https://ci.freebsd.org/job/FreeBSD-head-amd64-test/13912/changes > Full build log: > https://ci.freebsd.org/job/FreeBSD-head-amd64-test/13912/console > > Status explanation: > "Failure" - the build is suspected being broken by the following changes > "Still Failing" - the build has not been fixed by the following changes and > this is a notification to note that these changes have > not been fully tested by the CI system > > Change summaries: > (Those commits are likely but not certainly responsible) > > 356671 by mjg: > ufs: use lazy list instead of active list for syncer > > Quota code is temporarily regressed to do a full vnode scan. > > Reviewed by:jeff > Tested by: pho (in a larger patch, previous version) > Differential Revision: https://reviews.freebsd.org/D22996 > > 356670 by mjg: > vfs: add per-mount vnode lazy list and use it for deferred inactive + msync > > This obviates the need to scan the entire active list looking for vnodes > of interest. > > msync is handled by adding all vnodes with write count to the lazy list. > > deferred inactive directly adds vnodes as it sets the VI_DEFINACT flag. > > Vnodes get dequeued from the list when their hold count reaches 0. > > Newly added MNT_VNODE_FOREACH_LAZY* macros support filtering so that > spurious locking is avoided in the common case. > > Reviewed by:jeff > Tested by: pho (in a larger patch, previous version) > Differential Revision: https://reviews.freebsd.org/D22995 > > 356669 by mjg: > ufs: add a setter for inode i_flag field > > This will be used later to add vnodes to the lazy list. > > Reviewed by:kib (previous version), jeff > Tested by: pho (in a larger patch) > Differential Revision: https://reviews.freebsd.org/D22994 Hi Mateusz, I suspect these changes might have something to do about panic of i386 and amd64 in testing: root@:/usr/tests # cd /usr/tests/usr.sbin/makefs/ root@:/usr/tests/usr.sbin/makefs # kyua debug makefs_cd9660_tests:o_flag_rockridge_dev_nodes VNASSERT failed 0xf8000f24a1e8: type VCHR usecount 1, writecount 0, refcount 1 rdev 0 flags () VI_LOCKedlock type ufs: SHARED (count 1) nlink=1, effnlink=1, size=0, extsize 0 generation=73c32c64, uid=0, gid=0, flags=0x0 ino 117778, on dev gpt/rootfs panic: ffs_unlock_debug: modified vnode (420) not on lazy list cpuid = 1 time = 1578910603 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0038a70fd0 vpanic() at vpanic+0x185/frame 0xfe0038a71030 panic() at panic+0x43/frame 0xfe0038a71090 ffs_unlock_debug() at ffs_unlock_debug+0xa5/frame 0xfe0038a710c0 lookup() at lookup+0xd26/frame 0xfe0038a71160 namei() at namei+0x4d8/frame 0xfe0038a71250 kern_fchmodat() at kern_fchmodat+0x92/frame 0xfe0038a71380 amd64_syscall() at amd64_syscall+0x2d6/frame 0xfe0038a714b0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe0038a714b0 --- syscall (15, FreeBSD ELF64, sys_chmod), rip = 0x8003ba95a, rsp = 0x7fffe758, rbp = 0x7fffe7e0 --- KDB: enter: panic [ thread pid 1393 tid 100092 ] Stopped at kdb_enter+0x37: movq$0,0x1084396(%rip) db:0:kdb.enter.panic> show pcpu cpuid= 1 dynamic pcpu = 0xfe00887a7d80 curthread= 0xf8000f25a000: pid 1393 tid 100092 critnest 1 "bsdtar" curpcb = 0xf8000f25a4f0 fpcurthread = 0xf8000f25a000: pid 1393 "bsdtar" idlethread = 0xf800033976e0: tid 14 "idle: cpu1" self = 0x82211000 curpmap = 0xf80003e35120 tssp = 0x82211384 rsp0 = 0xfe0038a71580 kcr3 = 0x8f2ab405 ucr3 = 0x8f287c05 scr3 = 0xf287c05 gs32p= 0x82211404 ldt = 0x82211444 tss = 0x82211434 tlb gen = 889 curvnet = 0 spin locks held: db:0:kdb.enter.panic> full log: https://ci.freebsd.org/job/FreeBSD-head-i386-test/8051/consoleFull https://ci.freebsd.org/job/FreeBSD-head-amd64-test/13912/consoleFull test image: https://artifact.ci.freebsd.org/snapshot/head/r356671/i386/i386/disk-test.img.xz https://artifact.ci.freebsd.org/snapshot/head/r356671/amd64/amd64/disk-test.img.xz Can you help check this? Thanks. Best, Li-Wen ___ 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: M_TEMP trouble in 13.0-CURRENT #0 r355131M
Just to conclude this: Whatever is in 13.0-CURRENT #1 r356602M has solved the problem. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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"
