[Bug 262332] libxo: Update to 1.6.0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262332 Jose Luis Duran changed: What|Removed |Added Status|New |Closed Resolution|--- |FIXED --- Comment #2 from Jose Luis Duran --- Committed in 7087c8de43b0d5d27c52da6ba2ba4957b7e336ff. Thank you! -- You are receiving this mail because: You are the assignee for the bug.
[Bug 269244] [iwm] intel 7265 bluetooth inquiry doesn't work
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269244 Bug ID: 269244 Summary: [iwm] intel 7265 bluetooth inquiry doesn't work Product: Base System Version: CURRENT Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: mi...@freebsd.org Created attachment 239807 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=239807&action=edit dmesg dmesg attached, latest iwmbt-firmware installed, # iwmbt -D -I -d ugen1.2 main: opening dev 1.2 iwmbt_is_7260: found 7260/7265 main: Firmware has already been downloaded main: Firmware download is successful! after 'service bluetooth start ubt0' i see error message ng_hci_process_command_timeout: ubt0hci - unable to complete HCI command OGF=0x3 OCF=0x3. Timeout and # hccontrol -n ubt0hci inquiry hccontrol: Could not find HCI nodes so scan is unsuccessful, although bluetooth devices are present around -- You are receiving this mail because: You are the assignee for the bug.
[Bug 269245] [acpi] after charging to 100% battery starts to uncharge even if on AC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269245 Bug ID: 269245 Summary: [acpi] after charging to 100% battery starts to uncharge even if on AC Product: Base System Version: 13.1-STABLE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: mi...@freebsd.org Created attachment 239808 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=239808&action=edit dmesg 13 I have a F+ laptop, which has strange behavior regarding battery: when it's being charged it charges to 100% and then battery light turns off and uncharging begins even if I don't remove the AC, this uncharging continues until 0% and laptop turns off, this behavior is not presented in -current - everything works there as expected, i tried to bisect the commit, but it seems we had a zfs update and when I try to find first bad commit kernel can't mount root zfs FS with error 45, if I use UFS, laptop simply won't run more than 5 minutes and hangs with some error messages regarding nvme0 and being unable to complete the i/o acpidump -dt on 13 is interrupted with 'acpidump: DSDT is corrupt', on 14 this command runs fine -- You are receiving this mail because: You are the assignee for the bug.
[Bug 269245] [acpi] after charging to 100% battery starts to uncharge even if on AC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269245 --- Comment #1 from Mikhail Pchelin --- Created attachment 239809 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=239809&action=edit dmesg 14 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 269245] [acpi] after charging to 100% battery starts to uncharge even if on AC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269245 Mikhail Pchelin changed: What|Removed |Added Attachment #239810|text/x-csrc |text/plain mime type|| --- Comment #2 from Mikhail Pchelin --- Created attachment 239810 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=239810&action=edit dt asl 13 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 269245] [acpi] after charging to 100% battery starts to uncharge even if on AC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269245 --- Comment #3 from Mikhail Pchelin --- Created attachment 239811 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=239811&action=edit dt asl 14 zipped because the file excesses 1000kb limit -- You are receiving this mail because: You are the assignee for the bug.
[Bug 269228] coretemp: incorrect tjmax for desktop and server Core 2 Duo/Xeon 51xx/30xx 2cores 65nm (Conroe, Woodcrest, possible Allendale): 85°C, but must be 100°C
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269228 VVD changed: What|Removed |Added Summary|coretemp: incorrect tjmax |coretemp: incorrect tjmax |for desktop and server Core |for desktop and server Core |2 Duo/Xeon 51xx 2cores 65nm |2 Duo/Xeon 51xx/30xx 2cores |(Conroe, Woodcrest, |65nm (Conroe, Woodcrest, |possible Allendale): 85°C, |possible Allendale): 85°C, |but must be 100°C |but must be 100°C -- You are receiving this mail because: You are the assignee for the bug.
[Bug 269245] [acpi] after charging to 100% battery starts to uncharge even if on AC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269245 --- Comment #4 from Mikhail Pchelin --- (In reply to Mikhail Pchelin from comment #0) It looks like we have same problem on -current too, but it takes a little bit to reproduce. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 269233] Randomly is kernel is not rebooting
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269233 Mitchell Horne changed: What|Removed |Added CC||mho...@freebsd.org --- Comment #1 from Mitchell Horne --- (In reply to Ravi from comment #0) There are a couple of confusing details in this report. The utility is /sbin/reboot, not /bin/reboot. Maybe that was just a typo? I do not see a '-z' option to reboot, neither in 14-CURRENT or in 12-STABLE. "reboot -zn" should exit with an "illegal option" error. I also do not see a kern.force_kmod_shutdown sysctl in either branch, so this option has no effect. Finally, do you have a reason to specify '-n' to reboot? The man page suggests that it shouldn't be used, unless you know what you are doing. "shutdown -r now" should provide a consistent reboot behaviour. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 269250] split(1): auto-extend suffix length if required
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269250 Bug ID: 269250 Summary: split(1): auto-extend suffix length if required Product: Base System Version: Unspecified Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: jscha...@netmeister.org I've just committed a change to NetBSD's split(1) to auto-extend the suffix-length if needed: If the input cannot be split into the number of files resulting from the default suffix length, automatically extend the suffix length rather than bailing out with 'too many files'. Suffixes are extended such that the resulting files continue to sort lexically and "cat *" would reproduce the input. For example, splitting a 1M lines file into (default) 1000 lines per file would yield files named 'xaa', 'xab', ..., 'xyy', 'xyz', 'xzaaa', 'xzaab', ..., 'xzanl'. If '-a' is specified, the suffix length is not auto-extended. This behavior matches GNU sort(1) since around version 8.16. The NetBSD diffs are here: http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/split/split.c.diff?r1=1.28&r2=1.29 http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/split/split.1.diff?r1=1.15&r2=1.16 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 269251] Unable to build the kernel on linux as host
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269251 Bug ID: 269251 Summary: Unable to build the kernel on linux as host Product: Base System Version: CURRENT Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: mcsm...@gmail.com Hi, I tried to build the kernel on a linux host (archlinux), i followed the instructions in the wiki https://wiki.freebsd.org/BuildingOnNonFreeBSD. I couldn't bootstrap bmake so i used the one in my system (gcc kept complaining about strclpy). I was able to build world, but not kernel. It failed at "stage 1 : configuring the kernel", with the error "sh: line 29: config: command not found". my hierarchy: /expr/vb/freebsd_experiment/ -> freebsd # freebsd src tree -> obj # object directory If it weren't for the wiki article i would think that it is normal to not be able to build it on a non bsd host. Thanks. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 269251] Unable to build the kernel on linux as host
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269251 --- Comment #1 from mcsm...@gmail.com --- Created attachment 239814 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=239814&action=edit the error i get when i try to build the kernel -- You are receiving this mail because: You are the assignee for the bug.
[Bug 269250] split(1): auto-extend suffix length if required
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269250 --- Comment #1 from jscha...@netmeister.org --- Possible diff adjusted for FreeBSD: https://reviews.freebsd.org/differential/diff/116051/ Note: this strategy doesn't play well with '-d', so only is enabled for when that flag is not specified. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 269251] Unable to build the kernel on linux as host
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269251 Mina Galić changed: What|Removed |Added CC||free...@igalic.co --- Comment #2 from Mina Galić --- (In reply to mcsm224 from comment #1) could you please copy paste the text, instead of posting an image that's not great for accessibility. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 267871] /usr/bin/rs compile fails after udate to c++
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267871 John Baldwin changed: What|Removed |Added Resolution|--- |FIXED Status|Open|Closed --- Comment #13 from John Baldwin --- After more investigating, I think the case that was broken was doing a 'make buildworld' without NO_CLEAN=yes after a different commit I made to make MK_CXX conditional on bsd.compiler.mk. The issue was kind of the inverse of b9cb80883bce6dc992cf05ae2e59089a60d311ec. Same issue, but applied to the !NO_CLEAN case. It has been rendered OBE though by the removal of the MK_CXX option in ac4c695ad61e81d00cff2a03202a4afe94a92513. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 269251] Unable to build the kernel on linux as host
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269251 --- Comment #3 from mcsm...@gmail.com --- Sorry, here is the full text: [b@a freebsd]$ env MAKEOBJDIRPREFIX=/expr/vb/freebsd_experiment/obj tools/build/make.py clean --bootstrap-toolchain -j4 buildkernel TARGET=amd64 TARGET_ARCH=amd64 [Creating objdir /expr/vb/freebsd_experiment/obj/expr/vb/freebsd_experiment/freebsd...] --- clean --- --- buildkernel --- --- clean --- awk: cmd. line:1: warning: regexp escape sequence `\#' is not a known regexp operator --- buildkernel --- awk: cmd. line:1: warning: regexp escape sequence `\#' is not a known regexp operator [Creating objdir /expr/vb/freebsd_experiment/obj/expr/vb/freebsd_experiment/freebsd/amd64.amd64...] bmake[1]: "/expr/vb/freebsd_experiment/freebsd/Makefile.inc1" line 331: SYSTEM_COMPILER: libclang will be built for bootstrapping a cross-compiler. bmake[1]: "/expr/vb/freebsd_experiment/freebsd/Makefile.inc1" line 336: SYSTEM_LINKER: libclang will be built for bootstrapping a cross-linker. --- buildkernel --- --- clean --- --- clean_subdir_lib --- ===> lib (clean) --- buildkernel --- -- --- clean --- --- clean_subdir_bin --- ===> bin (clean) --- clean_subdir_libexec --- ===> libexec (clean) --- clean_subdir_lib --- bmake[2]: warning: /lib: Permission denied. --- buildkernel --- >>> Kernel build for GENERIC started on Mon Jan 30 18:36:56 CET 2023 -- ===> GENERIC mkdir -p /expr/vb/freebsd_experiment/obj/expr/vb/freebsd_experiment/freebsd/amd64.amd64/sys -- >>> stage 1: configuring the kernel -- cd /expr/vb/freebsd_experiment/freebsd/sys/amd64/conf; PATH=/expr/vb/freebsd_experiment/obj/expr/vb/freebsd_experiment/freebsd/amd64.amd64/tmp/bin:/expr/vb/freebsd_experiment/obj/expr/vb/freebsd_experiment/freebsd/amd64.amd64/tmp/usr/sbin:/expr/vb/freebsd_experiment/obj/expr/vb/freebsd_experiment/freebsd/amd64.amd64/tmp/usr/bin:/expr/vb/freebsd_experiment/obj/expr/vb/freebsd_experiment/freebsd/amd64.amd64/tmp/legacy/usr/sbin:/expr/vb/freebsd_experiment/obj/expr/vb/freebsd_experiment/freebsd/amd64.amd64/tmp/legacy/usr/bin:/expr/vb/freebsd_experiment/obj/expr/vb/freebsd_experiment/freebsd/amd64.amd64/tmp/legacy/bin:/expr/vb/freebsd_experiment/obj/expr/vb/freebsd_experiment/freebsd/amd64.amd64/tmp/legacy/usr/libexec: config -d /expr/vb/freebsd_experiment/obj/expr/vb/freebsd_experiment/freebsd/amd64.amd64/sys/GENERIC -I '/expr/vb/freebsd_experiment/freebsd/sys/amd64/conf' -I '/expr/vb/freebsd_experiment/freebsd/sys/amd64/conf' '/expr/vb/freebsd_experiment/freebsd/sys/amd64/conf/GENERIC' sh: line 29: config: command not found bmake[1]: stopped in /expr/vb/freebsd_experiment/freebsd bmake: stopped in /expr/vb/freebsd_experiment/freebsd --- clean --- bmake: stopped in /expr/vb/freebsd_experiment/freebsd -- You are receiving this mail because: You are the assignee for the bug.
[Bug 262332] libxo: Update to 1.6.0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262332 --- Comment #3 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=e1e2080fc1ce59cc2ef3ba4ae6031cd550d75bed commit e1e2080fc1ce59cc2ef3ba4ae6031cd550d75bed Author: Phil Shafer AuthorDate: 2023-01-30 18:35:27 + Commit: Phil Shafer CommitDate: 2023-01-30 18:37:33 + Import Juniper libxo-1.6.0 PR: 262332 lib/libxo/add.man | 4 ++-- lib/libxo/libxo/xo_config.h | 17 ++--- usr.bin/xohtml/xohtml.sh| 2 +- 3 files changed, 13 insertions(+), 10 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 253893] sed "/^\s*$/d" complains about trailing backslash (\)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253893 Quanah Gibson-Mount changed: What|Removed |Added CC||quanah.gibsonmo...@gmail.co ||m --- Comment #19 from Quanah Gibson-Mount --- This also broke the OpenLDAP test suite when running on FreeBSD 13: Testing account lockout... sed: 1: "s/.*seconds_before_unlo ...": RE error: trailing backslash (\) ldapsearch failed (49)! Affected line is: DELAY=`echo "$DELAYATTR" | sed -n -e 's/.*seconds_before_unlock=\(\d*\)/\1/p'` -- You are receiving this mail because: You are the assignee for the bug.
[Bug 253893] sed "/^\s*$/d" complains about trailing backslash (\)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253893 --- Comment #20 from Quanah Gibson-Mount --- (In reply to Quanah Gibson-Mount from comment #19) Note: fixed by using [[:digit:]] in OpenLDAP instead following the standard. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 253893] sed "/^\s*$/d" complains about trailing backslash (\)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253893 --- Comment #21 from Kyle Evans --- (In reply to Quanah Gibson-Mount from comment #20) Thanks; [[:digit:]] is indeed preferred, though I didn't know about \d when I implemented these extensions in libregex so I'll need to add that one to the list to support. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 261349] Modernise hier(7)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261349 --- Comment #12 from Graham Perrin --- % ls -hln /usr/share/doc total 1 drwxr-xr-x 2 0 0 6B 29 Jan 01:03 atf drwxr-xr-x 2 0 0 3B 29 Jan 01:03 IPv6 drwxr-xr-x 2 0 0 5B 29 Jan 01:06 kyua drwxr-xr-x 2 0 0 9B 29 Jan 01:03 legal drwxr-xr-x 3 0 0 5B 29 Jan 01:03 llvm drwxr-xr-x 2 0 0 4B 29 Jan 01:01 ncurses drwxr-xr-x 7 0 073B 29 Jan 01:06 ntp drwxr-xr-x 2 0 0 3B 29 Jan 01:03 pjdfstest % uname -KU 1400078 1400078 % That's quite different from the manual page description of what's in /usr/share/doc -- You are receiving this mail because: You are the assignee for the bug.
[Bug 269261] data corruption with fspacectl and mmap
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269261 Bug ID: 269261 Summary: data corruption with fspacectl and mmap Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: asom...@freebsd.org When using mmap to read and write to a file, intermixed with fspacectl, data corruption can occur. It seems like a cacheing bug, as though the data written via mmap doesn't get evicted from the cache during fspacectl, and is subsequently returned via mmap reads. I can reliably reproduce this bug on UFS and fusefs, but not ZFS, tmpfs or fusefs-ext2. Steps to reproduce: 0) Install a Rust toolchain 1) checkout https://github.com/asomers/fsx-rs.git at rev c3e726d 2) cd fsx-rs 3) cargo build 4) truncate -s 1g /tmp/ufs.img 5) sudo mdconfig -a -t vnode -f /tmp/ufs.img 6) sudo newfs /dev/md0 7) sudo mount /dev/md0 /mnt 8) sudo mkdir /mnt/tmp 9) sudo chmod 1777 /mnt/tmp 10) cat < fsx.toml nomsyncafterwrite = true [weights] close_open = 0.1 invalidate = 0.2 truncate = 1 fsync = 1 fdatasync = 1 punch_hole = 100 HERE 10) env RUST_LOG=debug cargo run -- -f fsx.toml -N 1000 -P /tmp -S 2153242284826767701 /mnt/tmp/fsx.bin The output will look like this: [INFO fsx] Using seed 2153242284826767701 [DEBUG fsx] 1 skipping zero size hole punch [DEBUG fsx] 2 skipping zero size hole punch [DEBUG fsx] 3 skipping zero size hole punch [DEBUG fsx] 4 skipping zero size hole punch [DEBUG fsx] 5 skipping zero size read [DEBUG fsx] 6 skipping zero size hole punch [DEBUG fsx] 7 skipping zero size hole punch [DEBUG fsx] 8 skipping zero size hole punch [DEBUG fsx] 9 skipping zero size hole punch [DEBUG fsx] 10 skipping zero size hole punch [DEBUG fsx] 11 skipping zero size hole punch [INFO fsx] 12 mapwrite 0x1ffb4 .. 0x280a4 ( 0x80f1 bytes) [INFO fsx] 13 punch_hole 0xe4e5 .. 0x185c2 ( 0xa0de bytes) [INFO fsx] 14 punch_hole 0x27eae .. 0x280a4 ( 0x1f7 bytes) [INFO fsx] 15 punch_hole 0xee3c .. 0x17541 ( 0x8706 bytes) [INFO fsx] 16 punch_hole 0x24fc5 .. 0x280a4 ( 0x30e0 bytes) [INFO fsx] 17 punch_hole 0x27dc2 .. 0x280a4 ( 0x2e3 bytes) [INFO fsx] 18 punch_hole 0x14efa .. 0x16be0 ( 0x1ce7 bytes) [INFO fsx] 19 mapread 0xe210 .. 0x1153c ( 0x332d bytes) [INFO fsx] 20 mapread 0x1159f .. 0x1cb3d ( 0xb59f bytes) [INFO fsx] 21 mapread 0x16252 .. 0x21bd3 ( 0xb982 bytes) [INFO fsx] 22 punch_hole 0x2c14 .. 0x2d44 ( 0x131 bytes) [INFO fsx] 23 punch_hole 0xc1b4 .. 0x18eed ( 0xcd3a bytes) [INFO fsx] 24 mapwrite 0x36f14 .. 0x3 ( 0x90ec bytes) [INFO fsx] 25 read 0xe4a9 .. 0x16bf9 ( 0x8751 bytes) [INFO fsx] 26 punch_hole 0xeedd .. 0x13904 ( 0x4a28 bytes) [INFO fsx] 27 mapwrite 0x2a9e0 .. 0x2c675 ( 0x1c96 bytes) [INFO fsx] 28 punch_hole 0x13374 .. 0x1f95e ( 0xc5eb bytes) [INFO fsx] 29 mapread 0xff83 .. 0x1bcb8 ( 0xbd36 bytes) [INFO fsx] 30 mapwrite 0x3cc44 .. 0x3 ( 0x33bc bytes) [INFO fsx] 31 mapwrite 0x14b65 .. 0x1969b ( 0x4b37 bytes) [INFO fsx] 32 write 0xcc6e .. 0x152f6 ( 0x8689 bytes) [INFO fsx] 33 write0x30da5 .. 0x340ae ( 0x330a bytes) [INFO fsx] 34 punch_hole 0x3b300 .. 0x3 ( 0x4d00 bytes) [INFO fsx] 35 read 0x3d33c .. 0x3 ( 0x2cc4 bytes) [INFO fsx] 36 punch_hole 0x279cf .. 0x30304 ( 0x8936 bytes) [INFO fsx] 37 mapread 0x2441c .. 0x2d04e ( 0x8c33 bytes) [ERROR fsx] miscompare: offset= 0x2441c, size = 0x8c33 [ERROR fsx] OFFSET GOOD BAD RANGE [ERROR fsx] 0x24fc5 0x00 0x4f 0x3024 [ERROR fsx] Step# (mod 256) for a misdirected write may be 12 [ERROR fsx] LOG DUMP [ERROR fsx] 0 SKIPPED (punch_hole) [ERROR fsx] 1 SKIPPED (punch_hole) [ERROR fsx] 2 SKIPPED (punch_hole) [ERROR fsx] 3 SKIPPED (punch_hole) [ERROR fsx] 4 SKIPPED (read) [ERROR fsx] 5 SKIPPED (punch_hole) [ERROR fsx] 6 SKIPPED (punch_hole) [ERROR fsx] 7 SKIPPED (punch_hole) [ERROR fsx] 8 SKIPPED (punch_hole) [ERROR fsx] 9 SKIPPED (punch_hole) [ERROR fsx] 10 SKIPPED (punch_hole) [ERROR fsx] 11 MAPWRITE 0x1ffb4 => 0x280a5 ( 0x80f1 bytes) HOLE [ERROR fsx] 12 PUNCH_HOLE 0xe4e5 => 0x185c2 ( 0xa0de bytes) [ERROR fsx] 13 PUNCH_HOLE 0x27eae => 0x280a4 ( 0x1f7 bytes) [ERROR fsx] 14 PUNCH_HOLE 0xee3c => 0x17541 ( 0x8706 bytes) [ERROR fsx] 15 PUNCH_HOLE 0x24fc5 => 0x280a4 ( 0x30e0 bytes) [ERROR fsx] 16 PUNCH_HOLE 0x27dc2 => 0x280a4 ( 0x2e3 bytes) [ERROR fsx] 17 PUNCH_HOLE 0x14efa => 0x16be0 ( 0x1ce7 bytes) [ERROR fsx] 18 MAPREAD 0xe210 => 0x1153d ( 0x332d bytes) [ERROR fsx] 19 MAPREAD 0x1159f => 0x1cb3e ( 0xb59f bytes) [ERROR fsx] 20 MAPREAD 0x16252 => 0x21bd4 ( 0xb982 bytes) [ERROR fsx] 21 PUNCH_HOLE 0x2c14 => 0x2d44 ( 0x131 bytes) [ERROR fsx] 22 PUNCH_HOLE 0xc1b4 => 0x18eed ( 0xcd3a bytes) [ERROR fsx] 23 MAPWRITE 0x36f14 => 0x4 ( 0x90ec bytes) HOLE [ERROR fsx] 24 READ
[Bug 269261] data corruption with fspacectl and mmap
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269261 Konstantin Belousov changed: What|Removed |Added CC||k...@freebsd.org --- Comment #1 from Konstantin Belousov --- Could you please provide a simple standalone reproducer for UFS? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 269261] data corruption with fspacectl and mmap
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269261 --- Comment #2 from Alan Somers --- Created attachment 239822 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=239822&action=edit Add a test case for fusefs Here is a minimal test case for fusefs. I can probably come up with a standalone program tomorrow. Also, I discovered that the bug goes away if I msync() after doing the mmap write. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 268400] Page fault kernel panic with KTLS enabled
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268400 --- Comment #2 from Zhenlei Huang --- Can you please share you network interfaces and firewall configuration `pf.conf` ? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 267766] epair naming during creation time only rename the first interface
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267766 --- Comment #1 from Zhenlei Huang --- (In reply to Olivier Cochard from comment #0) I thinks it works as intended. For epair(4), rename on create seems not useful compared with other cloning interfaces. As on create always a pair of interfaces are created and you can not simply rename both to the same name (name collision in vnet). But rename only one side you will take caution to find the name of the other side (e). -- You are receiving this mail because: You are the assignee for the bug.
[Bug 253893] sed "/^\s*$/d" complains about trailing backslash (\)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253893 --- Comment #22 from Kyle Evans --- (In reply to Kyle Evans from comment #21) \d doesn't actually seem to be supported in GNU sed, either? % echo "n9ne" | sed -e 's/\d/x/' n9ne % sed --version sed (GNU sed) 4.8 It's just that they're not as strict as we now are about bogus escapes, so this was a hidden bug. -- You are receiving this mail because: You are the assignee for the bug.
