[Bug 230402] With buildworld, the system can not use swap
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230402 --- Comment #13 from Mark Millard --- (In reply to chris from comment #10) See: https://lists.freebsd.org/pipermail/freebsd-arm/2018-September/018797.html for a report that vm.pageout_oom_seq=1024 was helpful for someone that has had great difficulties getting rpi3 buildworld's to repeatedly complete. -- 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 231067] Random kernel panic after r338257
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231067 Bjoern A. Zeeb changed: What|Removed |Added Assignee|b...@freebsd.org|b...@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 231064] data abort in in_pcbremlbgrouphash() on ThunderX
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231064 --- Comment #1 from Mark Johnston --- It looks like the lbgroup hash table is getting corrupted; many of the list heads are equal to 0xff00ff or 0xff. Nothing on the system actually uses SO_REUSEPORT_LB, so we shouldn't be inserting any hash table entries. I tried making the hash-table read-only using pmap_protect(), but that doesn't seem to catch the problem - the system still panics the same way. This plus the fact that the bug is apparently sensitive to memory layout (goes away when compiling with GENERIC or when increasing KSTACK_PAGES) makes it seem like this isn't a generic kernel bug. That said, there are some bugs in the SO_REUSEPORT_LB implementation: - Lookups are protected with epoch, but the hash table doesn't use CK_ lists and we don't defer frees of the hash table entries. - in_pcblbgroup_free() uses the wrong malloc type. - Lots of style bugs. -- 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 231070] Crash in nvme_qpair_reset() on base/head r338418 on VirtualBox 5.2.18
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231070 --- Comment #1 from trond.endres...@ximalas.info --- I can easily reenable the simulated NVMe controller, boot the VM into the kernel debugger and look around if anyone's interested. -- 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 231080] callout struture corruption and panic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231080 Sean Bruno changed: What|Removed |Added Summary|Possible HPET timer panic |callout struture corruption ||and panic -- 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 231080] Possible HPET timer panic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231080
--- Comment #3 from Mark Johnston ---
(In reply to Konstantin Belousov from comment #1)
Indeed, this is the result of a corrupted callout structure:
(kgdb) p *cc->cc_callwheel[firstb & callwheelmask].lh_first->c_links.le.le_next
$12 = {
c_links = {
le = {
le_next = 0x40,
le_prev = 0xf800051ef9b0
},
sle = {
sle_next = 0x40
},
tqe = {
tqe_next = 0x40,
tqe_prev = 0xf800051ef9b0
}
},
c_time = 4,
c_precision = 20,
c_arg = 0x7fffef70,
c_func = 0x15,
c_lock = 0x18,
c_flags = 22,
c_iflags = 0,
c_cpu = 0
}
--
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 231080] Possible HPET timer panic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231080 --- Comment #2 from Sean Bruno --- I've dropped the kernel + debug + crashdump in my homedir on freefall:~sbruno/service1.rbsd.tgz -- 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 231080] Possible HPET timer panic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231080 --- Comment #1 from Konstantin Belousov --- This has nothing to do with HPET. It is some callout handling issue, e.g. the callout memory freed or reused without proper stop. I would start with reproduction case. -- 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 231080] Possible HPET timer panic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231080 Bug ID: 231080 Summary: Possible HPET timer panic Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: sbr...@freebsd.org Created attachment 196771 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=196771=edit Crashdump summary from this panic. FreeBSD service1.rbsd.freebsd.org 12.0-ALPHA3 FreeBSD 12.0-ALPHA3 #0 r338350M: Tue Aug 28 17:14:21 UTC 2018 pe...@build-12.freebsd.org:/usr/obj/usr/src/sys/CLUSTER12 amd64 This machine panic'd overnight. I've never seen this specific crash before. Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x48 fault code = supervisor write data, page not present instruction pointer = 0x20:0x8085978f stack pointer = 0x28:0xfe00188da770 frame pointer = 0x28:0xfe00188da7e0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= resume, IOPL = 0 current process = 11 (idle: cpu0) #0 doadump (textdump=16777216) at pcpu.h:230 230 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=16777216) at pcpu.h:230 #1 0x804ccb4c in db_fncall (dummy1=, dummy2=, dummy3=, dummy4=) at /usr/src/sys/ddb/db_command.c:609 #2 0x804cc689 in db_command (cmd_table=) at /usr/src/sys/ddb/db_command.c:481 #3 0x804cc404 in db_command_loop () at /usr/src/sys/ddb/db_command.c:534 #4 0x804cf6af in db_trap (type=, code=) at /usr/src/sys/ddb/db_main.c:252 #5 0x8088b803 in kdb_trap (type=12, code=0, tf=) at /usr/src/sys/kern/subr_kdb.c:693 #6 0x80bad6f1 in trap_fatal (frame=0xfe00188da6b0, eva=72) at /usr/src/sys/amd64/amd64/trap.c:920 #7 0x80bad7f9 in trap_pfault (frame=0xfe00188da6b0, usermode=0) at pcpu.h:230 #8 0x80bace1e in trap (frame=0xfe00188da6b0) at /usr/src/sys/amd64/amd64/trap.c:441 #9 0x80b8d1a5 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #10 0x8085978f in callout_process (now=1248557731072764) at /usr/src/sys/kern/kern_timeout.c:510 #11 0x80c323c8 in handleevents (now=1248557731072764, fake=0) at /usr/src/sys/kern/kern_clocksource.c:213 #12 0x80c32c41 in timercb (et=, arg=) at /usr/src/sys/kern/kern_clocksource.c:357 #13 0x80bbac99 in hpet_intr_single (arg=0xfeb440b0) at /usr/src/sys/dev/acpica/acpi_hpet.c:309 #14 0x80bbad3e in hpet_intr (arg=0xfeb44000) at /usr/src/sys/dev/acpica/acpi_hpet.c:327 #15 0x808097fd in intr_event_handle (ie=0xf80002169100, frame=0xfe00188da9a0) at ck_pr.h:40 #16 0x80c6b0b8 in intr_execute_handlers (isrc=0xf8000203ee40, frame=0xfe00188da9a0) at /usr/src/sys/x86/x86/intr_machdep.c:285 #17 0x80c71534 in lapic_handle_intr (vector=, frame=) at /usr/src/sys/x86/x86/local_apic.c:1270 #18 0x80b8e459 in Xapic_isr1 () at apic_vector.S:118 #19 0x80c67816 in acpi_cpu_c1 () at /usr/src/sys/x86/x86/cpu_machdep.c:139 #20 0x804f2637 in acpi_cpu_idle (sbt=) at /usr/src/sys/dev/acpica/acpi_cpu.c:1187 #21 0x80c67e7f in cpu_idle_acpi (sbt=31836195) at /usr/src/sys/x86/x86/cpu_machdep.c:433 #22 0x80c67f37 in cpu_idle (busy=0) at /usr/src/sys/x86/x86/cpu_machdep.c:581 #23 0x80873f25 in sched_idletd (dummy=) at /usr/src/sys/kern/sched_ule.c:2829 #24 0x80806c63 in fork_exit ( callout=0x80873a10 , arg=0x0, frame=0xfe00188dac00) at /usr/src/sys/kern/kern_fork.c:1057 #25 0x80b8e18e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:993 #26 0x in ?? () Current language: auto; currently minimal (kgdb) -- 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 --- Comment #12 from Mark Millard --- (In reply to Mark Millard from comment #11) I forgot to mention limiting the linker (lld) to single threaded operation as a potential help relative to RAM usage during builds: LDFLAGS.lld+= -Wl,--no-threads in a make.conf or src.conf like file used for the likes of buildworld buildkernel activity. -- 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 --- Comment #11 from Mark Millard --- (In reply to chris from comment #10) You are not explicit about what revision you are building. My experience is with head (12), not 11.x . If the following is supported: sysctl vm.pageout_oom_seq=120 then do that before starting the first build after booting. The default value of 12 is unlikely to work. Depending on what all is going on in your I/O environment, this may prove insufficient but it likely would get more of the build done. If the build does not complete, then investigating your I/O latencies becomes relevant. The figure is tied to how long FreeBSD tolerates low free RAM conditions. (This wording is a simplification.) FreeBSD does not swap running processes to gain more free RAM, only processes that are idle for a while. Another point is the use of -j4 or other such vs. -j1 . -j1 or other smaller figures are more likely to complete (use less memory and have fewer long-running processes at once). You were not explicit about your usage for this. As for the swap space sizing (1 page = 4*1024 Bytes): 1048576 pages is 1048576 * (4*1024) Bytes, so 4 GiBytes, not the 1 GiByte referenced. 924056 pages is 924056 * (4*1024) Bytes, so a little over 3.5 GiBytes. (Note the figures in the messages are system specific and can even change some from build revision to revision for the same system.) I'd recommend staying at or under the 3.5 GiByte figure. But going anywhere near 1 GiByte of swap is insufficient with 1 GiByte of RAM. 2 GiByte of swap should work with some room to spare. Is the reference to 512M of swap in another context similarly off by a factor of 4? If yes: 2 GiBytes of swap were in use. Otherwise? Again -j4 or other such vs. -j1 matters to the RAM+SWAP use and the number of long-running processes at once. I recommend using swap partitions and avoiding the use of swap files. (I've no clue which you are using.) -- 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 --- Comment #10 from ch...@crvintel.com --- I to am having this problem. I am trying to buildworld on a RPi 3 B+ (using FreeBSD Current with 1G of swap space and the build fails during make of the clang source. I notice too that in my dmesg log that I am getting: warning: total configured swap (1048576 pages) exceeds maximum recommended amount (924056 pages). I have been unable to find any useful documentation on kern.maxswzone. >From my own observations the build does not seem to use up much swap space as the build fails. The buildworld on my Rpi 1 B+ with 512M of swap space works fine, and there is no reference in dmesg about maximum recommended swap space being exceeded. Any support appreciated. -- 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 231072] Mtree calculates checksum wrong when verifying a specification against a directory.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231072 Bug ID: 231072 Summary: Mtree calculates checksum wrong when verifying a specification against a directory. Product: Base System Version: 11.2-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Many People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: kpaas...@gmail.com https://www.freebsd.org/doc/handbook/security-intro.html the mtree(8) example at section 13.2.6 Binary Verification is not working correctly. The output from the verification step is empty as expected but the checksum printed differs from the one calculated at the specification creation step. # mtree -s 3483151339707503 -c -K cksum,sha256digest -p /bin > /root/.bin_chksum_mtree mtree: /bin checksum: 1817933408 # mtree -s 3483151339707503 -p /bin < /root/.bin_chksum_mtree >> /root/.bin_chksum_output mtree: /bin checksum: 1510745247 # file .bin_chksum_output .bin_chksum_output: empty The system I'm using is: # uname -a FreeBSD firewall 11.2-RELEASE-p2 FreeBSD 11.2-RELEASE-p2 #3 r338073: Mon Aug 20 16:44:39 EEST 2018 root@firewall:/usr/obj/usr/src/sys/GENERIC amd64 Filesystems used are ZFS all around except tmpfs /tmp and /var/run. -- 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 231070] Crash in nvme_qpair_reset() on base/head r338418 on VirtualBox 5.2.18
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231070 Bug ID: 231070 Summary: Crash in nvme_qpair_reset() on base/head r338418 on VirtualBox 5.2.18 Product: Base System Version: CURRENT Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: trond.endres...@ximalas.info Host is VirtualBox 5.2.18, Windows 7 x64 SP1, and Intel Core i7 960 @ 3.2 GHz. Guest is amd64 base/head r338418. Last known good revision is r338206. This can so easily be a bug in the VirtualBox implementation as it can be a bug in the FreeBSD implementation. The NVMe controller isn't critical to me, so I removed it from the VM, edited /etc/fstab, and carried on. Screenshots are available at https://ximalas.info/~trond/NVMe-crash-base-head-r338418/ Kernel messages (typed in from the screenshots, typo's quite possible): nvme0: Resetting controller due to a timeout. nvme0: resetting controller Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x40 fault code = supervisor write data, page not present instruction pointer = 0x20:0x805d7bd9 stack pointer = 0x28:0ffe00331a6a80 frame pointer = 0x28:0xfe00331a6a90 code segment= base 0x0, limit 0xf, type 0x1b = CPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enable,d resume, IOPL = 0 current process = 0 (nvme taskq) [ thread pid 0 tid 100051 ] Stopped at 0x805d7bd9 = nvme_qpair_reset+0x9: movl$0,0x40 = ll+x1f(%rbx) db> bt Tracing pid 0 tid 100051 td 0xf8000c015580 nvme_qpair_reset() at 0x805d3207 = nvme_qpair_reset+0x9/frame 0xfe00113a6a90 nvme_ctrlr_start() at 0x805d3207 = nvme_ctrlr_start+0x57/frame 0xfe00331a6af0 taskqueue_run_locked() at 0x807ddaa4 = taskqueue_run_locked+0x154/frame 0xfe00331a6bb0 fork_exit() at 0x8073d8a3 = fork_exit+0x83/frame 0xfe00331a6bf0 forkt_rampoline() at 0x80ab97ae = fork_trampoline+0xe/frame 0xfe00331a6bf0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- db> -- 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 231067] Random kernel panic after r338257
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231067 Kristof Provost changed: What|Removed |Added CC||b...@freebsd.org, ||k...@freebsd.org --- Comment #1 from Kristof Provost --- cc Bjoern -- 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 231069] Official VMware image of FreeBSD 11.2-RELEASE can't be snapshot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231069 Bug ID: 231069 Summary: Official VMware image of FreeBSD 11.2-RELEASE can't be snapshot 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: freebsd...@patpro.net I've downloaded Vmware image of FreeBSD 11.2-RELEASE of late July, and it appears that the resulting virtual machine can't be snapshot: creating a snapshot of this VM results in an immediate shutdown and in a light corruption of the VM. Corruption can be reversed by manually editing the config file of the VM. I'm using: VMware ESXi 5.5.0 Update 3 (Build 3248547) VM is installed on an NFS datastore This datastore in served by a FreeBSD server (ZFS) Not sure whether the vmdk available for download is somehow defective or non-compatible with my setup. It's the first time I'm hit with this kind of bug. URL of the vmdk: https://download.freebsd.org/ftp/releases/VM-IMAGES/11.2-RELEASE/amd64/Latest/FreeBSD-11.2-RELEASE-amd64.vmdk.xz -- 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 231067] Random kernel panic after r338257
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231067 Bug ID: 231067 Summary: Random kernel panic after r338257 Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: fuyuhiko.maruy...@gmail.com After r338257, kernel panic happen in ramdom timing. This may be triggered by named, in my case dns/bind911. With kernel after r338257, make buildworld at /usr/src cannot be completed because of kernel panics. Typically kernel goes panics in a few minutes after beginning of make buildworld. I found the origin of this panics by binary searching of svn-head and determined that r338256(with r338260's small fixes for building) is the last stable kernel that can complete buildworld/buildkernel, and r338257(with r338260's small fixes) is the first revision that causes current problems. One instance of panic message is like below(with r338257 kernel), typed by hand: Fatal trap 12: page fault while in kernel mode cpuid = 1: apic id = 01 fault virtual address = 0x98 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80988c6f stack pointer = 0x28:0xfe00a274d370 frame pointer = 0x28:0xfe00a274d5d0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflag = interrupt enabled, resume, IOPL = 0 current process = 766 (isc-worker) [ thread pic 766 tid 100985 ] Stopped at ip6_output+0xeaf: movlll+0x77(%rdi),%eax db> bt Tracing pid 766 tid 100993 td 0xf80024446000 ip6_output() at ip6_output+0xeaf/frame 0xfe00a274d5d0 udp6_send() at udp6_send+0x86a/frame 0xfe00a274d790 sosend_dgram() at sosend_dgram+0x33b/frame 0xfe00a274d800 sosend() at sosend+0x50/frame 0xfe00a274d830 kern_sendit() at kern_sendit+0x237/frame 0xfe00a274d8d0 sendit() at sendit+0x19e/frame 0xfe00a274d920 sys_sendmsg() at sys_sendmsg+0x61/frame 0xfe00a274d980 amd64_syscall() at amd64_syscall+0x369/frame 0xfe00a274dab0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe00a274dab0 --- syscall (28, FreeBSD ELF64, sys_sendmsg), rip = 0x800fe0a9a, rsp = 0x7fffdfffb528, rbp = 0x7fffdfffb560 --- Another example here(with r338406 kernel): Fatal trap 12: page fault while in kernel mode cpuid = 2: apic id = 02 fault virtual address = 0x110 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80763428 stack pointer = 0x28:0xfe00a21242c0 frame pointer = 0x28:0xfe00a2124360 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflag = interrupt enabled, resume, IOPL = 0 current process = 766 (isc-worker) [ thread pic 766 tid 100985 ] Stopped at __rw_wlock_hard+0x1d8: movq(%rbx),%r14 db> -- 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"
Re: [Bug 231027] [META] FreeBSD-Foundation sponsored issues for FreeBSD 13-CURRENT
Hello! I don't want to be "that guy" but may you consider adding the bug 218660 to this list? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218660 This is a minor issue which just probably affect just a minor part of the users but can be very annoying sometimes, and I *suppose* the fix should be trivial for who know how to fix it. Thanks you. Alex. On Thu, Aug 30, 2018 at 04:42:02PM +, bugzilla-nore...@freebsd.org wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231027 > > Bug ID: 231027 >Summary: [META] FreeBSD-Foundation sponsored issues for FreeBSD > 13-CURRENT >Product: Base System >Version: CURRENT > Hardware: Any > OS: Any > Status: New > Severity: Affects Only Me > Priority: --- > Component: misc > Assignee: b...@freebsd.org > Reporter: ema...@freebsd.org > > This meta-PR will track FreeBSD Foundation-sponsored bugs and work items > targeted for commit to FreeBSD-CURRENT intended for FreeBSD 13. > > -- > 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" -- Best Regards. LBdM. ___ 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"
