[Bug 230491] stat(1): Improve performance with getpwuid() and getgrgid() caching
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230491 --- Comment #16 from Conrad Meyer --- (In reply to Thomas Hurst from comment #15) Thanks, that helps. It still seems like a weird way to go about it (smells like a hand-rolled backup solution or something) but it's more concrete. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230491] stat(1): Improve performance with getpwuid() and getgrgid() caching
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230491 --- Comment #15 from Thomas Hurst --- As for the use-case, here's the initial report: > I'm seeing really, *REALLY* bad performance from stat(1) on FreeNAS. Case in > point: a `find . -print0 | xargs -0 shasum >file.sha` takes about 7.5h on > dirtree with 1.9TiB and 24.5M > > while a `find . -print0 | xargs -0 stat -f '%d %i %#p %l %u %g %r %z %a %m %c > %B %k %b %f %N%SY' >file.stat` takes 21 hours > > almost TRIPLE the time for reading just the metadata versus reading ALL THE > DATA, seems really weird! Seems like they were making a catalogue of the metadata of a large set of small files. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230491] stat(1): Improve performance with getpwuid() and getgrgid() caching
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230491 --- Comment #14 from Thomas Hurst --- 11.2-STABLE, consistent across several runs: Conrad's patch: 8.792 real, 4.506 user, 4.788 sys; page: 0 hard/13520 soft, swap: 0, I/O: 8818/0 My patch: 8.577 real, 4.547 user, 4.525 sys; page: 0 hard/13264 soft, swap: 0, I/O: 8818/0 Looks good, particularly given it makes the code more straight-forward. Reducing thread count improves performance with nscd, but at "threads 1" it's still 52s vs 22s uncached. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230491] stat(1): Improve performance with getpwuid() and getgrgid() caching
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230491 Conrad Meyer changed: What|Removed |Added Status|Open|In Progress --- Comment #13 from Conrad Meyer --- Thomas, please try the proposed patch and report back if it is adequate for your needs. If it is still significantly worse than the simpler cache, I'd like your help to understand (1) the use case that benefits from this microbenchmark and (2) the magnitude of the difference. Thanks again for the report and patch. And of course, thanks to Garance as well for the productive discussion and suggestion to refer to ls(1). -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230491] stat(1): Improve performance with getpwuid() and getgrgid() caching
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230491 --- Comment #12 from commit-h...@freebsd.org --- A commit references this bug: Author: cem Date: Sat Aug 11 02:56:44 UTC 2018 New revision: 337600 URL: https://svnweb.freebsd.org/changeset/base/337600 Log: stat(1): cache id->name resolution When invoked on a large list of files, it is most common for a small number of uids/gids to own most of the results. Like ls(1), use pwcache(3) to avoid repeatedly looking up the same IDs. Example microbenchmark and non-scientific results: $ time (find /usr/src -type f -print0 | xargs -0 stat >/dev/null) BEFORE: 3.62s user 5.23s system 102% cpu 8.655 total 3.47s user 5.38s system 102% cpu 8.647 total AFTER: 1.23s user 1.81s system 108% cpu 2.810 total 1.43s user 1.54s system 107% cpu 2.754 total Does this microbenchmark have any real-world significance? Until a use case is demonstrated otherwise, I doubt it. Ordinarily I would be resistant to optimizing pointless microbenchmarks in base utilities (e.g., recent totally gratuitous changes to yes(1)). However, the pwcache(3) APIs actually simplify stat(1) logic ever so slightly compared to the raw APIs they wrap, so I think this is at worst harmless. PR: 230491 Reported by: Thomas Hurst Discussed with: gad@ Changes: head/usr.bin/stat/stat.c -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230491] stat(1): Improve performance with getpwuid() and getgrgid() caching
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230491 --- Comment #11 from Conrad Meyer --- Here's my non-scientific results for my proposed patch (on CURRENT GENERIC, i.e., WITNESS and INVARIANTS are on, which introduces wider error bars than without, but still): BEFORE conrad@n /u/s/u/stat ❯❯❯ time (find /usr/src -type f -print0 | xargs -0 stat >/dev/null) ( find /usr/src -type f -print0 | xargs -0 stat > /dev/null; ) 3.62s user 5.23s system 102% cpu 8.655 total conrad@n /u/s/u/stat ❯❯❯ time (find /usr/src -type f -print0 | xargs -0 stat >/dev/null) ( find /usr/src -type f -print0 | xargs -0 stat > /dev/null; ) 3.47s user 5.38s system 102% cpu 8.647 total AFTER conrad@n /u/s/u/stat ❯❯❯ time (find /usr/src -type f -print0 | xargs -0 $(make -V .OBJDIR)/stat >/dev/null) ( find /usr/src -type f -print0 | xargs -0 $(make -V .OBJDIR)/stat > /dev/nul) 1.23s user 1.81s system 108% cpu 2.810 total conrad@n /u/s/u/stat ❯❯❯ time (find /usr/src -type f -print0 | xargs -0 $(make -V .OBJDIR)/stat >/dev/null) ( find /usr/src -type f -print0 | xargs -0 $(make -V .OBJDIR)/stat > /dev/nul) 1.43s user 1.54s system 107% cpu 2.754 total (I gave both programs a throw-away warm-up run first to make sure the disk caches were comparably primed, etc.) Seems like a clear win. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230491] stat(1): Improve performance with getpwuid() and getgrgid() caching
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230491 Conrad Meyer changed: What|Removed |Added Attachment #196041|0 |1 is obsolete|| --- Comment #10 from Conrad Meyer --- Created attachment 196068 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=196068=edit Untested counter-proposal using existing pwcache(3) mechanism I have not tested this patch, other than to verify it compiles. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230491] stat(1): Improve performance with getpwuid() and getgrgid() caching
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230491 --- Comment #9 from Conrad Meyer --- And, heh, the need to cache id->name resolution was recognized *long* ago: HISTORY The user_from_uid() and group_from_gid() functions first appeared in 4.4BSD. :-D. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230491] stat(1): Improve performance with getpwuid() and getgrgid() caching
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230491 --- Comment #8 from Conrad Meyer --- (In reply to Garance A Drosehn from comment #5) (In reply to Garance A Drosehn from comment #7) > but why would using nscd be so much slower than doing a totally non-cached > look > up of the user and group names each time? Doesn't that seem a little odd? You're totally right, that does seem suspect. Maybe our ncsd isn't the same one as on Linux, or is an older version, or has some other deficiency? I admit total lack of familiarity with any version or use of ncsd. :-) > And the local-to-stat caching: won't that only help if many commands are > 'stat'-ed in a single command, as opposed to doing many stat-commands with one > file per command? Correct. That's the use case described in Thomas' description, although I don't know if it represents any realworld workflow or if it's just an arbitrary pessimistic microbenchmark. If the latter, I don't think it's worth bringing in the stat(1) patch. (Even if it is a real-world use, the non-general optimization is questionable and we need to investigate why ncsd doesn't solve the problem first.) > Does 'ls' do local caching? If there is a big benefit in doing local-caching > in 'stat', should we also do it with 'ls'? I know I do a lot more 'ls -l's > than I do 'stat'-commands of any kind. Another great question, and the answer is yes — through a 3rd method. ls uses user_from_uid(), group_from_gid(), which caches any implementation of getpwuid() / getgrgid(). Fortunately, libc's default implementation of these routines already uses _nsdispatch(), so it is not limited to local /etc/passwd. So tl;dr: Instead of this patch, stat(1) should just use user_from_uid(3) / group_from_gid(3) (pwcache(3) API). -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230491] stat(1): Improve performance with getpwuid() and getgrgid() caching
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230491 --- Comment #7 from Garance A Drosehn --- (In reply to Conrad Meyer from comment #4) Just how much overhead is there in IPC? It's easy to see that a local cache will beat the caching done by a separate nscd process, but why would using nscd be so much slower than doing a totally non-cached look up of the user and group names each time? Doesn't that seem a little odd? And the local-to-stat caching: won't that only help if many commands are 'stat'-ed in a single command, as opposed to doing many stat-commands with one file per command? Does 'ls' do local caching? If there is a big benefit in doing local-caching in 'stat', should we also do it with 'ls'? I know I do a lot more 'ls -l's than I do 'stat'-commands of any kind. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230491] stat(1): Improve performance with getpwuid() and getgrgid() caching
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230491 --- Comment #6 from Garance A Drosehn --- (In reply to Garance A Drosehn from comment #5) for instance, on one sample directory: time ls -ln real0m0.010s user0m0.001s sys 0m0.007s time ls -l# on host with nscd real0m0.012s user0m0.002s sys 0m0.006s time ls -l# on host without nscd real0m1.156s user0m0.003s sys 0m0.009s -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230491] stat(1): Improve performance with getpwuid() and getgrgid() caching
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230491 --- Comment #5 from Garance A Drosehn --- (In reply to Garance A Drosehn from comment #3) Ugh. I didn't notice that 'ncsd' was mentioned in the response right before mine! The performance of nscd might depend on how it's configured in /etc/nscd.conf. On the linux systems where I use this, we have over 11000 userids, and turning on 'nscd' does make a huge difference in 'ls' and 'stat'. The resulting speed is *almost* as fast as doing 'ls -ln /sample/directory', for instance. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230491] stat(1): Improve performance with getpwuid() and getgrgid() caching
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230491 --- Comment #4 from Conrad Meyer --- (In reply to Garance A Drosehn from comment #3) See comment #2 :-). It's understandable given IPC overhead vs accessing a static variable. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230491] stat(1): Improve performance with getpwuid() and getgrgid() caching
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230491 Garance A Drosehn changed: What|Removed |Added CC||g...@freebsd.org --- Comment #3 from Garance A Drosehn --- Just out of curiosity: Have you tried 'nscd' (name service caching daemon). I have never had reason to try it on my freebsd systems, but I've used it on some linux systems where it can produce a huge performance boost. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230402] With buildworld, the system can not use swap
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230402 Rodney W. Grimes changed: What|Removed |Added CC||rgri...@freebsd.org --- Comment #6 from Rodney W. Grimes --- I would suggest that make with -j3 on a 1024MB machine is not a reasonable expectation. It is very easy for a compile or linker process to get into the 500MB size region and suggest you either increase avaliable memory to the VM, or decrease the job count. Due to the fact that "runnable" processes are not swapped in FreeBSD, this leads to an OOM condition, and the kill you see. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230511] Kernel panic on Xeon gold 6144
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230511 --- Comment #4 from Rikard --- I have a lot of issues with my NAS. The GUI is hard to reach now through the GUI and I'm typing this on Microsoft Edge of all browsers... ;:/ Leaving the puns, I am not sure I get all what you guys wrote. The first one I do get, I'll try to install the latest version 12-CURRENT. If this works after 10 reboots, I would be happy to use it. I am just not sure I will be able to mount a ZFS array from it as it won't readily recognize if I just install that OS, or would it? I will try that one first. After this, I'll try the other suggestions in succession. Now know exactly what you mean, I'll do my best. I'm far from a noob, but I'm also way off your expertise. I'll update you during the weekend. /R -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230260] [FUSE] [PERFORMANCE]: Performance issue (I/O block size)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230260 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|f...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230454] Compiling world fails on /usr/src/contrib/llvm/tools/clang/lib/CodeGen/CGCXXABI.cpp
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230454 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|toolch...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230501] EFI loader fails with "panic: free: guard1 fail" when booting
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230501 Kyle Evans changed: What|Removed |Added CC||kev...@freebsd.org --- Comment #2 from Kyle Evans --- Hi, I see this is with 11.2- can you please try booting one of the head snapshots and see if this is still reproducible there? A number of improvements went into the loader.efi that hadn't necessarily stabilized in time for 11.2. Thanks, Kyle Evans -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230487] jail -m works incorrectly in some cases
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230487 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|j...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230510] iflib/vlan panic: sleeping thread
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230510 Mark Linimon changed: What|Removed |Added Keywords||panic Assignee|b...@freebsd.org|n...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230491] stat(1): Improve performance with getpwuid() and getgrgid() caching
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230491 Mark Linimon changed: What|Removed |Added Keywords||patch -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230511] Kernel panic on Xeon gold 6144
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230511 Mark Johnston changed: What|Removed |Added CC||ma...@freebsd.org --- Comment #3 from Mark Johnston --- (In reply to Conrad Meyer from comment #1) > Please open GDB on an 11.1 system and show the result of 'l > *(_mca_init+0x534)'. To be clear, invoke "kgdb" to do this. You might need to install the gdb package first. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230511] Kernel panic on Xeon gold 6144
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230511 --- Comment #2 from Conrad Meyer --- Did you try a 12-CURRENT image also? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230511] Kernel panic on Xeon gold 6144
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230511 Conrad Meyer changed: What|Removed |Added CC||c...@freebsd.org --- Comment #1 from Conrad Meyer --- Please open GDB on an 11.1 system and show the result of 'l *(_mca_init+0x534)'. I suspect this has nothing to do with MCA exactly, it is just calling something that gets inlined, and/or static symbol that ddb does not know how to resolve. Another option would be to rebuild kernel with -O0 and retry. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230511] Kernel panic on Xeon gold 6144
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230511 Bug ID: 230511 Summary: Kernel panic on Xeon gold 6144 Product: Base System Version: 11.1-STABLE Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: energyrik...@gmail.com Created attachment 196064 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=196064=edit Screendump showing the kernel panic. Dear esteemed FreeBSD developers, I am in a little desperate situation... :) The developers of iXsystems behind FreeNAS are running the latest FreeBSD. They told me to post here as this is 100% FreeBSD related. When I'm booting up the system, I get a kernel panic around 50% of the time. I'm running the latest firmware and bios on the IPMI BMC, Supermicro motherboard, Avago/LSI SAS3 HBA and the Chelsio NIC. >From the log-files it seems the CPU and the FreeBSD kernel don't like each other. I have tried to enable debug mode in the OS, but the panic happens before anything useful is logged. I submitted the log to the FreeNAS developers and they said they couldn't find anything useful in that log as the panic happened too early. If you take a look at the attached JPEG, perhaps you can spot something? Their recommendation was to disable the Machine Check Architecture support by setting loader tunable hw.mca.enabled=0. I haven't done this yet. Shall I do it? The CPU is 8 cores with 16 threads each. Is there anything that I can do to assist you to remedy the issue? Kind Regards, Rikard P.S. I could of course install the latest stable FreeBSD version on a disk but i find it meaningless as the FreeNAS kernel is the same as the FreeBSD. The panics all appear on FreeNAS 11.1-U4, 11.1-U5, 11.2-latest beta -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230510] iflib/vlan panic: sleeping thread
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230510 --- Comment #1 from Harald Schmalzbauer --- P.P.S.: Backtrace is from todays sources, but I saw the panic happening much longer ago. Maybe monthly since April this year. Haven't found time to report earlier, sorry. -harry -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230510] iflib/vlan panic: sleeping thread
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230510 Bug ID: 230510 Summary: iflib/vlan panic: sleeping thread Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: bugzilla.free...@omnilan.de If I utilize rc.network(8) to create a vlan(4) child of a iflib em0(4) parent device, I get really a lot of LOR's (most likely all LOR's too fast to read). Estimated 500-2000 LOR's before panic. Here's the backtrace: #1 0x803ecb2b in db_dump (dummy=, dummy2=, dummy3=, dummy4=) at /usr/local/share/deploy-tools/HEAD/src/sys/ddb/db_command.c:574 #2 0x803ec8f9 in db_command (cmd_table=) at /usr/local/share/deploy-tools/HEAD/src/sys/ddb/db_command.c:481 #3 0x803ec674 in db_command_loop () at /usr/local/share/deploy-tools/HEAD/src/sys/ddb/db_command.c:534 #4 0x803ef8ff in db_trap (type=, code=) at /usr/local/share/deploy-tools/HEAD/src/sys/ddb/db_main.c:252 #5 0x80834923 in kdb_trap (type=3, code=0, tf=) at /usr/local/share/deploy-tools/HEAD/src/sys/kern/subr_kdb.c:693 #6 0x80b4a3ef in trap (frame=0xfe00751e8560) at /usr/local/share/deploy-tools/HEAD/src/sys/amd64/amd64/trap.c:605 #7 0x80b25d95 in calltrap () at /usr/local/share/deploy-tools/HEAD/src/sys/amd64/amd64/exception.S:232 #8 0x80833ffb in kdb_enter (why=0x80ca81cc "panic", msg=) at cpufunc.h:65 #9 0x807e9c00 in vpanic (fmt=, ap=0xfe00751e86d0) at /usr/local/share/deploy-tools/HEAD/src/sys/kern/kern_shutdown.c:852 #10 0x807e9c93 in panic (fmt=) at /usr/local/share/deploy-tools/HEAD/src/sys/kern/kern_shutdown.c:790 #11 0x8084bab5 in propagate_priority (td=) at /usr/local/share/deploy-tools/HEAD/src/sys/kern/subr_turnstile.c:228 #12 0x8084c56d in turnstile_wait (ts=0xf80003089e40, owner=0xf800035da580, queue=) at /usr/local/share/deploy-tools/HEAD/src/sys/kern/subr_turnstile.c:783 #13 0x807c7cf1 in __mtx_lock_sleep (c=0xf80003636ee0, v=, opts=, file=, line=) at /usr/local/share/deploy-tools/HEAD/src/sys/kern/kern_mutex.c:639 #14 0x807c7a79 in __mtx_lock_flags (c=0xf80003636ee0, opts=, file=, line=) at /usr/local/share/deploy-tools/HEAD/src/sys/kern/kern_mutex.c:255 #15 0x807e3725 in _rm_wlock (rm=0xf80003636e88) at /usr/local/share/deploy-tools/HEAD/src/sys/kern/kern_rmlock.c:540 #16 0x807e3a94 in _rm_wlock_debug (rm=0xf80003636e88, file=0x80cb26fe "/usr/local/share/deploy-tools/HEAD/src/sys/net/if_vlan.c", line=1639) at /usr/local/share/deploy-tools/HEAD/src/sys/kern/kern_rmlock.c:605 #17 0x80904f9b in vlan_link_state (ifp=0xf80003ba3000) at /usr/local/share/deploy-tools/HEAD/src/sys/net/if_vlan.c:1639 #18 0x808efd90 in do_link_state_change (arg=0xf80003ba3000, pending=1) at /usr/local/share/deploy-tools/HEAD/src/sys/net/if.c:2332 #19 0x808484bc in taskqueue_run_locked (queue=0xf800030b3500) at /usr/local/share/deploy-tools/HEAD/src/sys/kern/subr_taskqueue.c:465 #20 0x8084832a in taskqueue_run (queue=0xf800030b3500) at /usr/local/share/deploy-tools/HEAD/src/sys/kern/subr_taskqueue.c:484 #21 0x807ab180 in ithread_loop (arg=) at /usr/local/share/deploy-tools/HEAD/src/sys/kern/kern_intr.c:1043 #22 0x807a8004 in fork_exit (callout=0x807ab040 , arg=0xf8000359e080, frame=0xfe00751e8ac0) ---Type to continue, or q to quit--- at /usr/local/share/deploy-tools/HEAD/src/sys/kern/kern_fork.c:1057 #23 0x80b26d6e in fork_trampoline () at /usr/local/share/deploy-tools/HEAD/src/sys/amd64/amd64/exception.S:990 #24 0x in ?? () Unfortunately I don't have the source easily accessabele on that system and also no easy way to capture console output. Please tell me if additional info is a prerequisite to analyze the problem, I'll provide the missing parts. Thanks, -harry P.S.: If I manually create the vlan(4) child from multi user shell, there are LOR's but _no_ panic happening. Also, the vlan(4) device works afterwards. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 186435] [libexec] [patch] Allow for an alternative run-time loader
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186435 --- Comment #8 from Yuri Victorovich --- (In reply to Kyle Evans from comment #7) Hi Kyle, I'll update the patch within a few days. Thanks! Yuri -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230507] sed 'q' command preventing -i from creating backup
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230507 Bug ID: 230507 Summary: sed 'q' command preventing -i from creating backup Product: Base System Version: 11.2-STABLE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: free...@tim.thechases.com To reproduce $ jot 5 > a $ wc -c a # it's 10 bytes 10 $ sed -e '/2/d;q' a # this is the expected output 1 $ sed -i.bak '/2/d;q' a # demonstrate issue $ wc -c a # it's still 10 bytes 10 $ ls a* # there's no a.bak file a I've not yet traced down the source of the issue, but there seems to be some odd interaction between `q` and `-i`. Original thread on Twitter where the issue was noticed: https://twitter.com/mulle_nat/status/1027907848423067650 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Classic Gear Priced to Sell
[[HEADLINE]] [[PERMALINK_FULL_LINK]] TITLE OF YOUR EMAIL The content of your email goes here. You can drag and drop blocks of text, images or other content elements to add them to your message. Customize the font and the colors. Add links to track clicks. This is a second paragraph you can customize as your please. If you have stored contact properties with your contacts, you can include personalization variables such as first name, last name in your message content. [[DELIVERY_INFO]] [[POSTAL_ADDRESS]] ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230491] stat(1): Improve performance with getpwuid() and getgrgid() caching
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230491 --- Comment #2 from Thomas Hurst --- The built-in caching doesn't seem useful for this case. Enabling it results in a test run creating this unfortunate entry in top: 63957 root 9 520 24000K 4696K uwait 19 9:15 268.91% nscd and actually *slows down* stat(1) in my tests - /usr/src goes from 22 seconds to almost 90, and my CVS repository scan goes from 55 seconds to 2 minutes. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230501] EFI loader fails with "panic: free: guard1 fail" when booting
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230501 --- Comment #1 from Ka Ho Ng --- Created attachment 196057 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=196057=edit output of dmidecode -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230501] EFI loader fails with "panic: free: guard1 fail" when booting
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230501 Bug ID: 230501 Summary: EFI loader fails with "panic: free: guard1 fail" when booting Product: Base System Version: 11.2-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: misc Assignee: b...@freebsd.org Reporter: khng...@gmail.com Created attachment 196056 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=196056=edit Photo taken during booting -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230489] [patch] bin/cat compiled with -DNO_UDOM_SUPPORT will fail to compile as it is missing #include
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230489 Maxim Konovalov changed: What|Removed |Added Assignee|b...@freebsd.org|ema...@freebsd.org --- Comment #3 from Maxim Konovalov --- Hi Ed, This is a bug report for the issue that you fixed a year ago for your consideration. Maxim -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230489] [patch] bin/cat compiled with -DNO_UDOM_SUPPORT will fail to compile as it is missing #include
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230489 Maxim Konovalov changed: What|Removed |Added CC||ma...@freebsd.org --- Comment #2 from Maxim Konovalov --- Hi Will, that was fixed a year ago by emaste@, see the commit: https://svnweb.freebsd.org/base?view=revision=322325 I'll reassign the ticket to him. Thanks for the report. Maxim -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230498] Fatal trap 12: page fault while in kernel mode in sysctl_dumpentry from sysctl NET_RT_DUMP
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230498 --- Comment #1 from i...@niw.com.au --- The point at which it fails appears to be Line 1559 in /usr/src/sys/net/rtsock.c info.rti_info[RTAX_IFP] = rt->rt_ifp->if_addr->ifa_addr; At the point where it runs this, (kgdb) print rt->rt_ifp->if_addr $3 = (struct ifaddr *) 0x0 Its trying to access via a NULL pointer. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230498] Fatal trap 12: page fault while in kernel mode in sysctl_dumpentry from sysctl NET_RT_DUMP
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230498 Bug ID: 230498 Summary: Fatal trap 12: page fault while in kernel mode in sysctl_dumpentry from sysctl NET_RT_DUMP Product: Base System Version: 11.2-STABLE Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: i...@niw.com.au We have seen a repeatable kernel panic that seems to originate from a sysctl route table dump (as used in netstat -r) This is occuring daily since upgrade from 10.3 to 11.2 stable. There is an unstabl link causing a reasonable number of routing table updates. Backtrace shows Fatal trap 12: page fault while in kernel mode cpuid = 4; apic id = 08 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80950356 stack pointer = 0x28:0xfe084f5353e0 frame pointer = 0x28:0xfe084f535520 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 9837 (nsgproxy) trap number = 12 panic: page fault cpuid = 4 Uptime: 1d1h14m45s Dumping 1712 out of 32431 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% #0 doadump (textdump=) at pcpu.h:230 230 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump (textdump=) at pcpu.h:230 #1 0x8082b16b in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:383 #2 0x8082b557 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:776 #3 0x8082b3d3 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:707 #4 0x80bb66d7 in trap_fatal (frame=0xfe084f535320, eva=0) at /usr/src/sys/amd64/amd64/trap.c:877 #5 0x80bb6a5b in trap_pfault (frame=0xfe084f535320, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:787 #6 0x80bb5f88 in trap (frame=0xfe084f535320) at /usr/src/sys/amd64/amd64/trap.c:415 #7 0x80b97aac in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #8 0x80950356 in sysctl_dumpentry (rn=0xf8012bf4b410, vw=0xfe084f535688) at /usr/src/sys/net/rtsock.c:1559 #9 0x8094acc0 in rn_walktree (h=, f=, w=) at /usr/src/sys/net/radix.c:1094 #10 0x8094fcdf in sysctl_rtsock (oidp=, arg1=, arg2=, req=) at /usr/src/sys/net/rtsock.c:1916 #11 0x8083854b in sysctl_root_handler_locked (oid=0x81433718, arg1=0xfe084f535908, arg2=5, req=0xfe084f535840, tracker=0xfe084f5357b8) at /usr/src/sys/kern/kern_sysctl.c:165 #12 0x80837da1 in sysctl_root (arg1=0xfe084f535908, arg2=5) at /usr/src/sys/kern/kern_sysctl.c:1913 #13 0x808382c6 in userland_sysctl (td=, name=0xfe084f535900, namelen=7, old=0x8039e7540, oldlenp=, inkernel=, new=0x0, newlen=0, retval=0xfe084f535968, flags=0) at /usr/src/sys/kern/kern_sysctl.c:2009 #14 0x8083814f in sys___sysctl (td=0xf802b8974000, uap=0xf802b8974538) at /usr/src/sys/kern/kern_sysctl.c:1943 #15 0x80bb77e8 in amd64_syscall (td=0xf802b8974000, traced=0) at subr_syscall.c:132 #16 0x80b9838d in fast_syscall_common () at /usr/src/sys/amd64/amd64/exception.S:494 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 167688] [fusefs] Incorrect signal handling with direct_io
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=167688 Conrad Meyer changed: What|Removed |Added CC||c...@freebsd.org --- Comment #3 from Conrad Meyer --- Is this still present? I had a quick look around but don't see any recent changes that I would expect to fix this. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 160790] [fusefs] [panic] VPUTX: negative ref count with FUSE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=160790 --- Comment #6 from Conrad Meyer --- (In reply to landsidel.allen from comment #4) Looks similar to bug 186645 (also on 9.x). -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 186645] [fusefs] Crash after unmounting wdfs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186645 Conrad Meyer changed: What|Removed |Added CC||c...@freebsd.org --- Comment #3 from Conrad Meyer --- Stack looks identical to bug 160790 comment #4, starting at VOP_RECLAIM. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 212318] sysutils/fusefs-libs: fails to unmount due to a uniq dev node
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212318 Conrad Meyer changed: What|Removed |Added Status|New |Closed CC||c...@freebsd.org Resolution|--- |Overcome By Events --- Comment #14 from Conrad Meyer --- Either the compat22 routine was removed, or its use should be avoided, or if that absolutely fails maybe it can be patched not to be broken. Unclear if anything is still tripping over this broken path anymore. Sounds like encfs was fixed not to use it and fusefs-libs may have removed it too. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 216998] sysutils/fusefs-ntfs: man page gives invalid example of fstab entry
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216998 Oleksandr Tymoshenko changed: What|Removed |Added Component|Documentation |Manual Pages Assignee|d...@freebsd.org |b...@freebsd.org CC||d...@freebsd.org Conrad Meyer changed: What|Removed |Added Assignee|b...@freebsd.org|ports-b...@freebsd.org Product|Documentation |Ports & Packages Component|Manual Pages|Individual Port(s) -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
