[Bug 227436] increasing kern.maxswzone does nothing
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227436 Bug ID: 227436 Summary: increasing kern.maxswzone does nothing Product: Base System Version: 11.1-STABLE Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: cur...@ipv6.occnc.com Created attachment 192425 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=192425&action=edit patch to sys/vm/swap_pager.c (see comments for description) On current and on 11.1 when using a large amount of swap, increasing kern.maxswzone does not allow more swap to be used as it used to in 11.0. A patch is attached which has been tested on AMD64 and ARM64 kernels using 11.1 stable and current. It does the following: 1. If maxswzone is set to less than the system guess (based on RAM), then reduce maxswzone as specified (current behaviour). 2. There is a conditional that could be removed that caps the increase in maxswzone to 8 times the guess based on RAM (lots of swap, but lots is needed for small ARM stuff that has 512MB or 1GB RAM. Also had to increase kern.maxswzone on some of my AMD64 servers with 8GB RAM). 3. An increase is made to the effective maxswzone value used (n in the code) subject to the above conditional (which could be removed). 4. Change a printf statement to give swap sizes in pages and MB when kern.maxswzone is too small for the amount of swap. 5. Add printf indicating the minimum value of kern.maxswzone that will quiet the warning (and presumably allow that amount of swap to be used). 6. Add a conditional that catches the case where the guess at the size of struct swblk in sys/i386/include/param.h is wrong. This code was removed in other architectures so affects i386 only. I added this code temporarily to amd64 to test. I've been using this patch with no adverse affect on multiple production servers and vm for a few weeks. Given that all it does is allow increase in kern.maxswzone to take effect, it should be safe and should go into 11.2, but at least go into 12. -- 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 227409] mandoc(1) renders ".Aq" as something that looks weird in vt(4)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227409 Ed Maste changed: What|Removed |Added CC||ema...@freebsd.org --- Comment #1 from Ed Maste --- I cannot reproduce this; for me it renders correctly as: Aq, Ao, Ac enclose in angle brackets: 45f0 20 20 5f 08 41 5f 08 71 2c 20 5f 08 41 5f 08 6f | _.A_.q, _.A_.o| 4600 2c 20 5f 08 41 5f 08 63 20 20 20 20 20 20 20 65 |, _.A_.c e| 4610 6e 63 6c 6f 73 65 20 69 6e 20 61 6e 67 6c 65 20 |nclose in angle | 4620 62 72 61 63 6b 65 74 73 3a 20 3c 74 65 78 74 3e |brackets: | 4630 0a 20 20 20 20 20 5f 08 45 5f 08 6f 2c 20 5f 08 |. _.E_.o, _.| -- 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 155163] [patch] Add Recursive Functionality to setfacl(1)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=155163 Ed Maste changed: What|Removed |Added Flags||mfc-stable10-, ||mfc-stable11? -- 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 155163] [patch] Add Recursive Functionality to setfacl(1)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=155163 --- Comment #11 from commit-h...@freebsd.org --- A commit references this bug: Author: emaste Date: Tue Apr 10 23:29:57 UTC 2018 New revision: 332396 URL: https://svnweb.freebsd.org/changeset/base/332396 Log: setfacl: add recursive functionality Add a -R option to setfacl to operate recursively on directories, along with the accompanying flags -H, -L, and -P (whose behaviour mimics chmod). A patch was submitted with PR 155163, but this is a new implementation based on comments raised in the Phabricator review for that patch (review D9096). PR: 155163 Submitted by: Mitchell Horne Reviewed by: jilles MFC after:2 weeks Relnotes: Yes Sponsored by: The FreeBSD Foundation Differential Revision:https://reviews.freebsd.org/D14934 Changes: head/bin/setfacl/setfacl.1 head/bin/setfacl/setfacl.c head/bin/setfacl/setfacl.h head/bin/setfacl/util.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 184758] error in rtadvd.conf example
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184758 Oleksandr Tymoshenko changed: What|Removed |Added Assignee|d...@freebsd.org |b...@freebsd.org Component|Documentation |Manual Pages CC||d...@freebsd.org CC||go...@freebsd.org Component|Manual Pages|Documentation Assignee|b...@freebsd.org|d...@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"
RE: [Bug 227404] UP FreeBSD VM always hangs on reboot since 20180329-r331740
> From: Bruce Evans > Sent: Tuesday, April 10, 2018 13:09 > > Here the bug is that UP FreeBSD VM hangs on reboot or power-off, and > > I'm sure this recent patch (which was committed by Jeff on Mar 26) caused > > this bug: > > r331561:Fix a bug introduced in r329612 that slowly invalidates all clean > > bufs. > > > > However, SMP VM with 2 or more CPUs doesn't hang on reboot/power-off > > according to our tests. > > Actually, r329612 is what causes this bug. I already did the bisection > to find almost this bug a couple of weeks ago. The hang occurs on amd64 > with 4 CPUs but not on amd64 with 8 CPUs or i386 with 4 or 8 CPUS. I > just checked that it occurs on i386 with 1 CPU. All on the same machine. > But r329611 doesn't hang for any of these cases. So, it looks to me that: r329612 introduced a hang issue, so Jeff made r331561, trying to fix the issue, but it looks the issue is not completely fixed (at least for me). I didn't test r329612. We noticed our amd64 VM (which has a single CPU) hung . The VM kernel was built with yesterday's latest kernel code + the default GENERIC kernel config. However, using the same kernel binary, if we configure 2 or more CPUs to the VM, the VM doesn't hang on reboot. If I use the latest code but manually remove the changes made by r331561, the hang issue with our single-CPU VM will go away. I hope the info is helpful. > I still think there is an older bug, but now think it is related. I > only tested with SCHED_4BSD. For SCHED_4BSD, I suspect that the bug > is from pinning a thread to a CPU and then stopping that CPU. Pure > UP has no problems since pinning is null for it. SCHED_4BSD has especially > special handing for SMP (a separate runq for each CPU. I have been > modifying > SCHED_4BSD and the separate queues mostly get in the way). > > Bruce I always use the default GENERIC kernel options, so I guess I'm using SCHED_4BSD(?).. Thanks, -- Dexuan ___ 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 227404] UP FreeBSD VM always hangs on reboot since 20180329-r331740
On Tue, 10 Apr 2018, Dexuan Cui wrote: From: Bruce Evans Sent: Tuesday, April 10, 2018 00:45 On Tue, 10 Apr 2018 a bug that doesn't want repl...@freebsd.org wrote: (The bug didn't even Cc freebsd-bugs for this followup.) Thanks for the reminder! I Cc'd bugs@ just now. --- Comment #4 from Dexuan Cui --- ... I think I saw this a few months before that. My only history of this is that I built a UP kernel on 17 Dec 2017 to see if UP kernels had the bug. So SMP kernels probably had the bug then. Bruce Here the bug is that UP FreeBSD VM hangs on reboot or power-off, and I'm sure this recent patch (which was commited by Jeff on Mar 26) caused this bug: https://github.com/freebsd/freebsd/commit/63a483ed5f4eaadb8979992c7a5de24c7a471c61 ("Fix a bug introduced in r329612 that slowly invalidates all clean bufs"). However, SMP VM with 2 or more CPUs doesn't hang on reboot/power-off according to our tests. Actually, r329612 is what causes this bug. I already did the bisection to find almost this bug a couple of weeks ago. The hang occurs on amd64 with 4 CPUs but not on amd64 with 8 CPUs or i386 with 4 or 8 CPUS. I just checked that it occurs on i386 with 1 CPU. All on the same machine. But r329611 doesn't hang for any of these cases. XX From b...@optusnet.com.au Fri Mar 23 20:06:40 2018 +1100 XX Date: Fri, 23 Mar 2018 20:06:39 +1100 (EST) XX From: Bruce Evans XX X-X-Sender: b...@besplex.bde.org XX To: j...@freebsd.org XX Subject: r329612 breaks sync for shutdown XX Message-ID: <20180323192409.f1...@besplex.bde.org> XX MIME-Version: 1.0 XX Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed XX Status: O XX X-Status: XX X-Keywords: XX X-UID: 7935 XX XX r329612 (with or without later changes) sometimes (consistently in one XX hardware coniguration) hangs in clean shutdowns by init: XX XX i386 with 8 or 4 CPUs: it hasn't failed yet XX amd64 with 8 CPUs:: it hasn't failed yet XX and64 with 4 CPUs (by turning off HTT): it always or almost always hangs XX XX The hang is usually in "Syncing disks, vnodes remaining... 0 ". Less than XX 10% of the time it hangs earlier in "Waiting ... for syncer' ...". XX It is just waiting for a wakeup that never arrives: In the working case, XX it prints about 2 more 0's, with about half a second between each. If it XX reaches the second 0, it always completes. XX XX This is with SCHED_4BSD. SCHED_ULE seems to work. I recently looked for XX missing wakeups and found some for idle threads in mwait. This affects XX both schedulers but fixing it makes little difference. The bug is invariant XX under other large changes in options and code. XX XX XX KDB: enter: Break to debugger XX XX [ thread pid 9 tid 100069 ] XX XX Stopped at kdb_enter+0x3a: movq$0,0x700c97(%rip) XX XX db> ps XX XX pid ppid pgrp uid state wmesg wchan cmd XX XX18 0 0 0 DL - 0x80be8462 [schedcpu] XX XX17 0 0 0 DL kpsusp 0xf80003e1a6e0 [vnlru] XX XX16 0 0 0 RL [syncer] XX XX 9 0 0 0 RL (threaded) [bufdaemon] XX XX 100059 RunQ[bufdaemon] XX XX 100064 Run CPU 1 [bufspacedaemon-0] XX XX 100065 Run CPU 3 [bufspacedaemon-1] XX XX 100066 RunQ [bufspacedaemon-2] XX XX 100067 RunQ [bufspacedaemon-3] XX XX 100068 Run CPU 0 [bufspacedaemon-4] XX XX 100069 Run CPU 2 [bufspacedaemon-5] XX XX 100070 CanRun [bufspacedaemon-6] XX XX 8 0 0 0 DL (threaded) [pagedaemon] XX XX 100058 D psleep 0x80c7b82d [pagedaemon] XX XX 100062 D launds 0x80c7b834 [laundry: dom0] XX XX 100063 D umarcl 0x80676967 [uma] XX XX 7 0 0 0 DL - 0x80c73dd4 [soaiod4] XX XX 6 0 0 0 DL - 0x80c73dd4 [soaiod3] XX XX 5 0 0 0 DL - 0x80c73dd4 [soaiod2] XX XX --More--4 0 0 0 DL - 0x80c73dd4 [soaiod1] XX XX15 0 0 0 DL cooling 0xf8000186a758 [acpi_cooling1] XX XX14 0 0 0 DL tzpoll 0x80aaa110 [acpi_thermal] XX XX 3 0 0 0 DL - 0x80aab218 [rand_harvestq] XX XX13 0 0 0 DL (threaded) [usb] XX XX 100023 D - 0xfe00839d4460 [usbus0] XX XX 100024 D - 0xfe00839d44b8 [usbus0] XX XX 100025
[Bug 200109] [PATCH] Minor EFI boot image enhancements
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200109 --- Comment #3 from Pedro F. Giffuni --- (In reply to Ed Maste from comment #1) Well, it's rather silly but I wanted to keep some standard floppy size (perhaps 1.44M ?). What would be really cool is if there were some way to install the Clover EFI bootloader: https://sourceforge.net/projects/cloverefiboot/ This would be really useful for those of us that still keep an old BIOS machine with an under-utilized 3T HD and want to dual boot. -- 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 200109] [PATCH] Minor EFI boot image enhancements
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200109 Pedro F. Giffuni changed: What|Removed |Added Attachment #156626|0 |1 is obsolete|| --- Comment #2 from Pedro F. Giffuni --- Created attachment 192400 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=192400&action=edit Small enhancements to the EFI image generation Update for new path and other changes. -- 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 227422] i386 mini-memstick 11-stable installer not recognized as bootable device on Lenovo x220
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227422 --- Comment #5 from Ed Maste --- Perhaps: diff --git a/release/i386/make-memstick.sh b/release/i386/make-memstick.sh index 1943e07942c1..1eb5d57942e3 100755 --- a/release/i386/make-memstick.sh +++ b/release/i386/make-memstick.sh @@ -36,10 +36,8 @@ makefs -B little -o label=FreeBSD_Install -o version=2 ${2}.part ${1} rm ${1}/etc/fstab rm ${1}/etc/rc.conf.local -mkimg -s gpt -b ${1}/boot/pmbr \ --p freebsd-boot:=${1}/boot/gptboot \ --p freebsd-ufs:=${2}.part \ --p freebsd-swap::1M \ +mkimg -s mbr -b ${1}/boot/mbr \ +-p freebsd:-"mkimg -s bsd -b ${1}/boot/boot -p freebsd-ufs:=${2}.part" \ -o ${2} rm ${2}.part -- 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 211000] [Hyper-V] Online VHDX Resize doesn't work properly
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211000 Dexuan Cui changed: What|Removed |Added Status|Open|Closed Resolution|--- |FIXED --- Comment #10 from Dexuan Cui --- I believe the bug has been fixed, at least in 11. -- 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 222908] Boot hangs on HPET on Intel Apollo Lake
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222908 --- Comment #4 from Hannes Hauswedell --- The workaround does indeed work, other issues are unrelated to 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"
RE: [Bug 227404] UP FreeBSD VM always hangs on reboot since 20180329-r331740
> From: Bruce Evans > Sent: Tuesday, April 10, 2018 00:45 > > On Tue, 10 Apr 2018 a bug that doesn't want repl...@freebsd.org wrote: > > (The bug didn't even Cc freebsd-bugs for this followup.) Thanks for the reminder! I Cc'd bugs@ just now. > > --- Comment #4 from Dexuan Cui --- > ... > > I think I saw this a few months before that. > > My only history of this is that I built a UP kernel on 17 Dec 2017 to see > if UP kernels had the bug. So SMP kernels probably had the bug then. > > Bruce Here the bug is that UP FreeBSD VM hangs on reboot or power-off, and I'm sure this recent patch (which was commited by Jeff on Mar 26) caused this bug: https://github.com/freebsd/freebsd/commit/63a483ed5f4eaadb8979992c7a5de24c7a471c61 ("Fix a bug introduced in r329612 that slowly invalidates all clean bufs"). However, SMP VM with 2 or more CPUs doesn't hang on reboot/power-off according to our tests. Thanks, -- Dexuan ___ 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 194766] [drm:pid12:i915_hangcheck_elapsed] [drm:pid12:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194766 --- Comment #46 from Michael Danilov --- Actually I mean from 10.something, haven't seriously used intel graphics before that, maybe it was something else. -- 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 194766] [drm:pid12:i915_hangcheck_elapsed] [drm:pid12:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194766 Michael Danilov changed: What|Removed |Added CC||mike.d.ft...@gmail.com --- Comment #45 from Michael Danilov --- Not fixed, ok? I still get this as of 11.1 -- and been since 10.0 or before, thinking it was my hardware. I found a more or less reliable way to cause it: do a lot of 2D graphics -- like drawing something in graphics/inkscape or in WED from games/xptools. Happens at least once in half an hour and is very annoying. I don't know if related, but I also often get corruption like missing/blinking characters in fonts, broken transparency and black areas with dark blue dots that sometimes move/blink. Sometimes they show up in 3d textures as well. Should I attach hw.dri.0.info.i915_error_state next time this happens? Or could anyone at least point me to a setting in the kernel sources defining how often the hangcheck happens -- so that I have to wait only 10 seconds instead of sitting there for a whole minute each time it hangs? Cheers, Mike -- 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 227404] UP FreeBSD VM always hangs on reboot since 20180329-r331740
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227404 Dexuan Cui changed: What|Removed |Added CC||b...@freebsd.org -- You are receiving this mail because: You are on the CC list for the bug. 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 227422] i386 mini-memstick 11-stable installer not recognized as bootable device on Lenovo x220
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227422 --- Comment #4 from Ed Maste --- Or perhaps we should just be using MBR -- 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 227422] i386 mini-memstick 11-stable installer not recognized as bootable device on Lenovo x220
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227422 --- Comment #3 from Ed Maste --- 11-1-RELEASE-i386 fails in the same way -- 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 227422] i386 mini-memstick 11-stable installer not recognized as bootable device on Lenovo x220
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227422 Allan Jude changed: What|Removed |Added CC||allanj...@freebsd.org --- Comment #2 from Allan Jude --- This is likely related to changes Benno has been making. You might compare what is in that snapshot to what is in the 11.1 release .img One option is to apply the lenovofix to the images, but it is not clear if that might cause issues on any other buggy BIOSes. -- 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 227422] i386 mini-memstick 11-stable installer not recognized as bootable device on Lenovo x220
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227422 --- Comment #1 from Ed Maste --- amd64 fails the same way on this hardware when BIOS configured for "legacy only" boot; UEFI boot is successful. -- 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 227422] i386 mini-memstick 11-stable installer not recognized as bootable device on Lenovo x220
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227422 Bug ID: 227422 Summary: i386 mini-memstick 11-stable installer not recognized as bootable device on Lenovo x220 Product: Base System Version: 11.1-STABLE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: misc Assignee: b...@freebsd.org Reporter: ema...@freebsd.org I fetched an i386 mini-memstick snapshot image from https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/11.1/FreeBSD-11.1-STABLE-i386-20180315-r330998-mini-memstick.img.xz and wrote it to a USB hard drive. When attempting to boot on a Lenvo x220 laptop the BIOS does not recognize this as a bootable drive - it appears in the boot selection menu, but choosing it returns immediately to the selection menu, as occurs with other non-bootable drives. For reference, same drive boots and kernel starts on a ASRock J3455B (but the kernel hangs for other reasons, under investigation elsewhere) -- 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 155163] [patch] Add Recursive Functionality to setfacl(1)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=155163 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 227409] mandoc(1) renders ".Aq" as something that looks weird in vt(4)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227409 Bug ID: 227409 Summary: mandoc(1) renders ".Aq" as something that looks weird in vt(4) Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: tr...@freebsd.org mandoc(1) renders .Aq and .Ao as something that renders as a square (missing glyph, I suppose) in vt(4) consoles. To reproduce: switch to a virtual console, log in, do "man mdoc", search for Ao and see the example output right next to it. -- 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 227404] UP FreeBSD VM always hangs on reboot since 20180329-r331740
On Tue, 10 Apr 2018 a bug that doesn't want repl...@freebsd.org wrote: (The bug didn't even Cc freebsd-bugs for this followup.) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227404 --- Comment #4 from Dexuan Cui --- I think the first bad patch is this one: https://github.com/freebsd/freebsd/commit/63a483ed5f4eaadb8979992c7a5de24c7a471c61 (Fix a bug introduced in r329612 that slowly invalidates all clean bufs.): Today's https://github.com/freebsd/freebsd/commit/66e8725e8d24141506bc4f458ec7d1a51e86304c is broken, but if I revert 63a483ed5f4eaadb8979992c7a5de24c7a471c61, the bug can not reproduce. Cc bde & jeff. I think I saw this a few months before that. My only history of this is that I built a UP kernel on 17 Dec 2017 to see if UP kernels had the bug. So SMP kernels probably had the bug then. Bruce ___ 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 227408] apropos(1) doesn't sort
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227408 Bug ID: 227408 Summary: apropos(1) doesn't sort Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: tr...@freebsd.org It appears that apropos(1) fails to sort. It kind of does, but in a funny way. You can see it with "apropos -s 9 map", and look for eg "pmap" in the output. -- 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 227404] UP FreeBSD VM always hangs on reboot since 20180329-r331740
On Tue, 10 Apr 2018 a bug that doesn't want repl...@freebsd.org wrote: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227404 ... --- Comment #1 from Dexuan Cui --- When the issue happens, the cpu utilization of the UP VM is 100%. While we're trying to find the first bad revision, it would be great if somebody can report if the issue also happens to bare metal or other hypervisors. This has been happening for at least several months on real hardware too. SMP kernels hang on a 1-CPU system and on an 8-CPU systems with all except 1 CPU turned off in the BIOS. They don't hang on the 8-CPU system with at least 2 CPUs turned on. UP kernels don't hang. I use SCHED_4BSD. SCHED_ULE is apparently not much different for this. Bruce ___ 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 227404] UP FreeBSD VM always hangs on reboot since 20180329-r331740
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227404 --- Comment #5 from Dexuan Cui --- (In reply to Dexuan Cui from comment #4) When the bug reproduces, the log is: Stopping cron. Stopping sshd. appending output to nohup.out Stopping devd. Writing entropy file:. Writing early boot entropy file:. Terminated . Apr 10 14:46:40 decui-b11 syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop... done Waiting (max 60 seconds) for system process `bufdaemon' to stop... done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining... 4 (It hangs here) After I revert 63a483ed5f4eaadb8979992c7a5de24c7a471c61, the bug can't reproduce, despite the messages: Apr 10 14:28:44 decui-b11 syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop... done Waiting (max 60 seconds) for system process `bufdaemon' to stop... done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining... 4 1 0 done All buffers synced. lock order reversal: 1st 0xf80008533ba8 ufs (ufs) @ /root/bsd.git/sys/kern/vfs_mount.c:1335 2nd 0xf800085d0428 syncer (syncer) @ /root/bsd.git/sys/kern/vfs_subr.c:2732 stack backtrace: #0 0x80bccfa3 at witness_debugger+0x73 #1 0x80bcce24 at witness_checkorder+0xe34 #2 0x80b3bb9b at lockmgr_lock_fast_path+0x17b #3 0x8119d069 at VOP_LOCK1_APV+0xd9 #4 0x80c488a6 at _vn_lock+0x66 #5 0x80c379a7 at vputx+0x157 #6 0x80c2f7d9 at dounmount+0x4d9 #7 0x80c3919b at vfs_unmountall+0x6b #8 0x80c14a25 at bufshutdown+0x2c5 #9 0x80b66d7a at kern_reboot+0x21a #10 0x80b66b09 at sys_reboot+0x3a9 #11 0x8102706b at amd64_syscall+0x79b #12 0x8100191d at fast_syscall_common+0x101 lock order reversal: 1st 0xf80008533ba8 ufs (ufs) @ /root/bsd.git/sys/kern/vfs_mount.c:1335 2nd 0xf800085d07e8 devfs (devfs) @ /root/bsd.git/sys/ufs/ffs/ffs_vfsops.c:1371 stack backtrace: #0 0x80bccfa3 at witness_debugger+0x73 #1 0x80bcce24 at witness_checkorder+0xe34 #2 0x80b3bb9b at lockmgr_lock_fast_path+0x17b #3 0x8119d069 at VOP_LOCK1_APV+0xd9 #4 0x80c488a6 at _vn_lock+0x66 #5 0x80e67a93 at ffs_flushfiles+0x93 #6 0x80e4adf2 at softdep_flushfiles+0x82 #7 0x80e6a147 at ffs_unmount+0x77 #8 0x80c2f819 at dounmount+0x519 #9 0x80c3919b at vfs_unmountall+0x6b #10 0x80c14a25 at bufshutdown+0x2c5 #11 0x80b66d7a at kern_reboot+0x21a #12 0x80b66b09 at sys_reboot+0x3a9 #13 0x8102706b at amd64_syscall+0x79b #14 0x8100191d at fast_syscall_common+0x101 Uptime: 2m50s acpi0: Powering system off BTW, when the patch is reverted, I occasionally get this when the VM boots, but I guess that's a different issue: (da1:storvsc2:0:0:0): storvsc inquiry (6) [0 b2 0 4 1 ... ] da2 at storvsc2 bus 0 scbus4 target 0 lun 2 da2: Fixed Direct Access SPC-3 SCSI device da2: 300.000MB/s transfers da2: Command Queueing enabled da2: 51200MB (104857600 512 byte sectors) s_debugger+0x73 #1 0x80(da2:storvsc2:0:0:2): storvsc inquiry (6) [0 b2 0 4 1 ... ] (da1:storvsc2:0:0:0): storvsc inquiry (5) [0 b0 0 3c 0 ... ] bce381 at witness_warn+0x461 #2 0x81026273 at trap_pfa(da2:storvsc2:0:0:2): storvsc inquiry (5) [0 b0 0 3c 0 ... ] (da1:storvsc2:0:0:0): storvsc inquiry (5) [0 b1 0 3c 0 ... ] da1: Delete methods: ult+0x53 #3 0x81025a72 (da2:storvsc2:0:0:2): storvsc inquiry (5) [0 b1 0 3c 0 ... ] da2: Delete methods: at trap+0x2f2 #4 0x810010cc at calltrap+0x8 #5 0x80c1af78 at vfs_vmio_unwire+0x78 #6 0x80c16350 at bGEOM: new disk da2 relse+0x3c0 #7 0x80e6af3a at ffs_use_bread+0x9a #8 0x80e6659c at ffs_sbget+0x8c #9 0x80e69213 at ffs_mount+0xe03 #10 0x80c2e449 at vfs_domount+0x719 #11 0x80c2d727 at vfs_donmount+0x7f7 #12 0x80c30a32 at kernel_mount+0x62 #13 0x80c32ddd at parse_mount+0x43d #14 0x80c3150c at vfs_mountroot+0x68c #15 0x80afe567 at start_init+0x27 #16 0x80b277b4 at fork_exit+0x84 #17 0x81001dee at fork_trampoline+0xe Fatal trap 12: page fault while in kernel mode cpuid = 12; apic id = 0c fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80ea6081 stack pointer = 0x28:0xfe002d0b1140 frame pointer = 0x28:0xfe002d0b1150 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 = 1 (kernel) [ thread pid 1 tid 12 ] Stopped at _vm_page_deactivate+0xb1: cmpq%rcx,(%rax) db> bt Tracing pid 1 tid 12 td 0xf800032e0560 _vm_page_deactivate() at _vm_page_deactivate+0xb1/frame 0xfe002d0
[Bug 227404] UP FreeBSD VM always hangs on reboot since 20180329-r331740
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227404 Dexuan Cui changed: What|Removed |Added CC||b...@freebsd.org, ||j...@freebsd.org --- Comment #4 from Dexuan Cui --- I think the first bad patch is this one: https://github.com/freebsd/freebsd/commit/63a483ed5f4eaadb8979992c7a5de24c7a471c61 (Fix a bug introduced in r329612 that slowly invalidates all clean bufs.): Today's https://github.com/freebsd/freebsd/commit/66e8725e8d24141506bc4f458ec7d1a51e86304c is broken, but if I revert 63a483ed5f4eaadb8979992c7a5de24c7a471c61, the bug can not reproduce. Cc bde & jeff. -- 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"