[Bug 280028] S3 suspend of Thinkpad x270 stopped working after freebsd-update to 14.1-RELEASE-p1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280028 --- Comment #20 from cos --- Apologies for being a slow in reporting back. This being my daily driver, it took a few days before being able to reboot into the problematic bootenv. (In reply to Mark Johnston from comment #19) Thanks for looking at my files. They are as described. Maybe I should be more clear in pointing out that the kernel doesn't fully hang. The shutdown gets stuck in some kind of partial shutdown, without (at least some) wifi and usb drivers. As long as I'm not too picky with such functionality, I can still use the system as normal. ;) With X running, the first suspend completes successfully while the second attempt consistently fail, until calling halt. Without X, suspending + resuming x 10 works. Verified again today, with the actual increase from a few cycles up to ten. I also updated to 14.1-p2 on a cloned bootenv, experiencing identical results. Please let me highlight this dmesg difference and state that, supported by that stuff works after killing X, I believe the output to be related: -drmn0: [drm] [ENCODER:102:DDI B/PHY B] is disabled/in DSI mode with an ungated DDI clock, gate it -drmn0: [drm] [ENCODER:116:DDI C/PHY C] is disabled/in DSI mode with an ungated DDI clock, gate it I did some web searches of the above, but did unfortunately not become much wiser. I also made a half-baked attempt starting a git-bisect of `/usr/src`, but couldn't understand which commit 14.1-p1 was built from. Not even after looking in seemingly relevant handbooks and asking on irc. (It ended up only with #280186 being posted instead.) Should one just go with release/14.1.0 as the good tag and the HEAD of releng/14.1 as the known bad commit? (I would have expected 14.1.1 and 14.1.2 tags for 14.1-p1 and 14.1-p2 respectively, but am uncertain if it's the right place as those do not exist.) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280382] '#include ' fails when -std=c99 and -pedantic-errors options are specified (found on the multimedia/librist port)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280382 Bug ID: 280382 Summary: '#include ' fails when -std=c99 and -pedantic-errors options are specified (found on the multimedia/librist port) Product: Base System Version: 14.1-STABLE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: misc Assignee: b...@freebsd.org Reporter: y...@freebsd.org When '#include ' is compiled with '-pedantic -pedantic-errors -std=c++98' it fails: In file included from x.cpp:4: In file included from /usr/include/c++/v1/algorithm:1787: In file included from /usr/include/c++/v1/__algorithm/adjacent_find.h:14: /usr/include/c++/v1/__algorithm/iterator_operations.h:105:9: error: too many arguments provided to function-like macro invocation 105 | "It looks like your iterator's `iterator_traits::reference` does not match the return type of " | ^ etc etc Based on https://en.cppreference.com/w/cpp/header/algorithm existed in the c++98 standard, so such include should compile fine. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280382] '#include ' fails when -std=c99 and -pedantic-errors options are specified (found on the devel/benchmark port)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280382 Yuri Victorovich changed: What|Removed |Added Summary|'#include ' |'#include ' |fails when -std=c99 and |fails when -std=c99 and |-pedantic-errors options|-pedantic-errors options |are specified (found on the |are specified (found on the |multimedia/librist port)|devel/benchmark port) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280382] '#include ' fails when -std=c99 and -pedantic-errors options are specified (found on the devel/benchmark port)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280382 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.
[Bug 280383] Removing the last link to an open file prevents remounting read-only--suggest document and/or code change
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280383 Bug ID: 280383 Summary: Removing the last link to an open file prevents remounting read-only--suggest document and/or code change Product: Base System Version: Unspecified Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: billblake2...@gmail.com Long ago, an issue was resolved in which removing the last link to an open file followed by downgrading the file system to read-only could have unfortunate consequences, by forbidding a downgrade when any open file had no links. (https://svnweb.freebsd.org/base?view=revision&revision=89384) This was reasonable because closing the file would require deallocating the file's inode and disk blocks, which could no longer be done if the file system was downgraded. I got bit by this because, if this is documented at all, it is not documented in any obvious place. E.g., the mount(8) man page gives no clue that you can't do this; it only says, in the documentation for the -u option, that it will fail if any file is opened for write. mount(2) is similarly silent. A minimal improvement would be a document change to mount(8) so that the -u option indicates that one may not downgrade a file system if there are any open files with no links. In addition, mount(2) should say that one can get EBUSY from such an attempt. But I thought about this for awhile and realized that this is a problem with a relatively simple solution. It basically needs a directory with a specific name in a specific place and a single flag bit in an on-disk inode and in the corresponding vnode. Let's call this directory .lastlink and put it in the root of a mounted file system. Then one can make the following changes: 1) When the last link to an open file is to be removed: Choose a file name, say, "#" (as with lost+found). If the .lastlink directory exists and .lastlink/# does not exist, link .lastlink/# to the open file and flag the inode and its vnode before the (no longer) last link is removed. 2) When an open file with a flagged vnode is closed, unlink .lastlink/# if the file system is read/write. 3) Leave the current downgrade code alone, except possibly adding a comment. 4) When a file system is (re)mounted r/w, scan .lastlink, if it exists, for links to any flagged inodes and unlink those files if they are not open. 5) Make fsck know about .lastlink so that it can remove any flagged inodes. With these changes, if no directory .lastlink exists, the current behavior is preserved. But if that directory exists and nobody creates problematic file names in it, open, unlinked files never exist and so can't prevent downgrading the file system. If a downgrade does happen, the deletion that should have happened when the file was closed does actually happen, but only when the file system is next mounted r/w. If something other than the above code creates a # file in .lastlink, the worst that'll happen is that the system reverts to prior behavior if an inode whose matches has its last link removed while it is open. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280351] siftr.ko load/unload caused Fatal trap 12: page fault while in kernel mode
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280351 Mark Linimon changed: What|Removed |Added Flags||mfc-stable14? Assignee|b...@freebsd.org|k...@freebsd.org --- Comment #3 from Mark Linimon --- ^Triage: assign to committer. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280366] freebsd-update: Fails to upgrade 14.0-p11 to 14.1-RELEASE: incorrect hash
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280366 Mark Linimon changed: What|Removed |Added Summary|freebsd-update: Fails to|freebsd-update: Fails to |upgrade i386 14.0-p11 to|upgrade 14.0-p11 to |14.1-RELEASE: incorrect |14.1-RELEASE: incorrect |hash|hash -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280386] if_bridge throws output errors under load
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386 Bug ID: 280386 Summary: if_bridge throws output errors under load Product: Base System Version: 14.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: pascal.guitier...@gmail.com I'm able to easily make if_bridge spew thousands of output errors with a really simple config and using iperf3. this results into random "no buffer space" errors on the host and disruptions to services. only reproduceable when using a bridge - if no bridge involved there are no errors or disruptions. OS is 14.1-RELEASE-p2 on amd64. /etc/rc.conf: cloned_interfaces="bridge0" ifconfig_bridge0="addm igb0 192.168.0.150/24 up" ifconfig_igb0="-txcsum -txcsum6 -tso up" (the reason for turning off certain flags is to prevent link-flap when the VM is disconnected from the bridge) netstat -i: (note the Oerrs field below) Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll igb0 1500 5c:ed:8c:e9:c2:48 50259033 0 0 53166489 0 0 igb1*1500 5c:ed:8c:e9:c2:49 0 0 0 0 0 0 igb2*1500 5c:ed:8c:e9:c2:4a 0 0 0 0 0 0 igb3*1500 5c:ed:8c:e9:c2:4b 0 0 0 0 0 0 lo0 16384 lo0 24959 0 0 24959 0 0 lo0 - localhost localhost 0 - - 0 - - lo0 - fe80::%lo0/64 fe80::1%lo0 0 - - 0 - - lo0 - your-netlocalhost 24959 - - 24959 - - bridge0 1500 58:9c:fc:00:07:00 103262907 0 0 103141654 130543 0 bridge0 - 192.168.0.0/24 192.168.0.150235137 - -225757 - - ue0 1500 72:84:d1:bf:ad:2f 3587 0 0 3588 0 0 ue0 - 16.1.15.0/3016.1.15.2 3308 - - 3308 - - tap0 1500 58:9c:fc:10:f3:0f 53003359 0 0 48249364 0 0 can reproduce across multiple systems of varying compute and network power (have tested on ix* NICs with similar results) iperf3 cmd line used: iperf3 -P4 -c 192.168.0.5 -t 60 remote iperf3 system is a windows server, network is gigabit. errors occur only when testing in one direction (FreeBSD bridge client -> remote system server). if i don't use if_bridge, ie: ifconfig_igb0="-txcsum -txcsum6 -tso 192.168.0.150/24 up" then no errors or dropped packets are seen at all. is my config correct? are there known issues with if_bridge in freebsd? dmesg below: ---<>--- Copyright (c) 1992-2023 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 14.1-RELEASE releng/14.1-n267679-10e31f0946d8 GENERIC amd64 FreeBSD clang version 18.1.5 (https://github.com/llvm/llvm-project.git llvmorg-18.1.5-0-g617a15a9eac9) VT(efifb): resolution 1024x768 CPU: Intel(R) Xeon(R) E-2314 CPU @ 2.80GHz (2808.00-MHz K8-class CPU) Origin="GenuineIntel" Id=0xa0671 Family=0x6 Model=0xa7 Stepping=1 Features=0xbfebfbff Features2=0x7ffafbff AMD Features=0x2c100800 AMD Features2=0x121 Structured Extended Features=0xf2bf67ef Structured Extended Features2=0x40405f5e Structured Extended Features3=0xbc000410 XSAVE Features=0xf IA32_ARCH_CAPS=0x2023c6b VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 16503263232 (15738 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" random: unblocking device. ioapic0 irqs 0-119 Launching APs: 2 3 1 random: entropy device external interface kbd1 at kbdmux0 efirtc0: efirtc0: registered as a time-of-day clock, resolution 1.00s smbios0: at iomem 0x72fc8000-0x72fc801e smbios0: Version: 3.3, BCD Revision: 3.3 aesni0: acpi0: acpi0: Power Button (fixed) attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 2400 Hz quality 950 Event timer "HPET" frequency 2400 Hz quality 550 Event timer "HPET1" frequency 2400 Hz quality 440 Event timer "HPET2" frequency 2400 Hz quality 440 Event timer "HPET3" frequency 2400 Hz quality 440 Event timer "HPET4" frequency 2400
