[Bug 162036] [geom] Fatal trap 12: page fault while in kernel mode -- Stopped at atomic_subtract_int+0x4
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=162036 --- Comment #2 from Fabian Keil --- Created attachment 185874 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=185874&action=edit Let g_eli deal with lost devices without crashing I've been using the attached patchset since 2013 to prevent the crashes and just noticed that I hadn't attached it to the PR yet. Obtained from: ElectroBSD -- 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 221906] sys/cddl: Allow to modify the ZFS deadman sysctls after the system is up
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221906 Bug ID: 221906 Summary: sys/cddl: Allow to modify the ZFS deadman sysctls after the system is up Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Keywords: patch Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: f...@fabiankeil.de Flags: mfc-stable11? Created attachment 185875 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=185875&action=edit sys/cddl: Allow to modify the ZFS deadman sysctls after the system is up The attached patch changes the ZFS deadman sysctls from CTLFLAG_RDTUN to CTLFLAG_RWTUN so they can be changed after the system is up. There does not seem to be a technical reason why it shouldn't be done and being able to temporarily disable the deadman is useful when importing a pool that is backed by remote storage (such as ggated running as onion service). Obtained from: ElectroBSD -- 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 221909] [ZFS] Add a sysctl to toggle send_corrupt_data
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221909 Bug ID: 221909 Summary: [ZFS] Add a sysctl to toggle send_corrupt_data Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Keywords: patch Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: f...@fabiankeil.de Flags: mfc-stable11? Created attachment 185878 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=185878&action=edit sys/cddl: Add a sysctl to toggle send_corrupt_data The attached patch adds a sysctl to toggle send_corrupt_data. Enabling it allows to send datasets with corrupted blocks which is useful to recover data from pools with dying disks. Blocks filled with 0x'zfs badd bloc' are sent instead of the corrupted data. As a result, the receiving side may end up with more corrupt data than the sending side. While it would be preferable to send the corrupt data as is (assuming the block can be read but contains flipped bits), this would probably have to happen at a different layer and currently isn't done. The ZFSOnLinux people already added an option for this in 2013: https://github.com/zfsonlinux/zfs/issues/1982 Usage example: fk@t520 ~ $sudo zpool status -v wde2 pool: wde2 state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: https://illumos.org/msg/ZFS-8000-8A scan: scrub repaired 0 in 11h40m with 10 errors on Sun Jan 1 10:25:26 2017 config: NAME STATE READ WRITE CKSUM wde2 ONLINE 0 0 0 label/wde2.eli ONLINE 0 0 0 errors: Permanent errors have been detected in the following files: wde2/backup/t520/tank/home/fk@2011-07-28_04:54:/Mail/Tor/Read/15654 wde2/backup/t520/tank/home/fk@2011-07-28_04:54:/Mail/Tor/Read/16411 [...] fk@t520 ~ $cat /wde2/backup/t520/tank/home/fk/.zfs/snapshot/2011-07-28_04\:54/Mail/Tor/Read/16411 cat: /wde2/backup/t520/tank/home/fk/.zfs/snapshot/2011-07-28_04:54/Mail/Tor/Read/16411: Input/output error fk@t520 ~ $dd if=/wde2/backup/t520/tank/home/fk/.zfs/snapshot/2011-07-28_04\:54/Mail/Tor/Read/16411 bs=1 dd: /wde2/backup/t520/tank/home/fk/.zfs/snapshot/2011-07-28_04:54/Mail/Tor/Read/16411: Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 0.026960 secs (0 bytes/sec) fk@t520 ~ $sudo zfs send wde2/backup/t520/tank/home/fk@2011-07-28_04:54 | mbuffer | sudo zfs receive -v tank/corruption-test receiving full stream of wde2/backup/t520/tank/home/fk@2011-07-28_04:54 into tank/corruption-test@2011-07-28_04:54 in @ 0.0 KiB/s, out @ 0.0 KiB/s, 1178 MiB total, buffer 0% fullwarning: cannot send 'wde2/backup/t520/tank/home/fk@2011-07-28_04:54': Input/output error summary: 1178 MiByte in 5min 44.0sec - average of 3508 KiB/s cannot receive new filesystem stream: checksum mismatch or incomplete stream Toggling vfs.zfs.send_corrupt_data allows to send the whole snapshot with the corrupted data: fk@t520 ~ $sudo sysctl vfs.zfs.send_corrupt_data=1 vfs.zfs.send_corrupt_data: 0 -> 1 fk@t520 ~ $sudo zfs send wde2/backup/t520/tank/home/fk@2011-07-28_04:54 | mbuffer | sudo zfs receive -v tank/corruption-test receiving full stream of wde2/backup/t520/tank/home/fk@2011-07-28_04:54 into tank/corruption-test@2011-07-28_04:54 in @ 7193 KiB/s, out @ 7193 KiB/s, 1238 MiB total, buffer 0% full summary: 1239 MiByte in 43.6sec - average of 28.4 MiB/s received 1.21GB stream in 59 seconds (21.0MB/sec) fk@t520 ~ $sudo sysctl vfs.zfs.send_corrupt_data=0 vfs.zfs.send_corrupt_data: 1 -> 0 On the receiving side the corrupted block now has a valid checksum, the 0x'zfs badd bloc' pattern isn't obvious from userland and from ZFS's point of view the data is legit (which doesn't seem ideal either): fk@t520 ~ $hd /tank/corruption-test/Mail/Tor/Read/15654 0c b1 dd ba f5 02 00 00 0c b1 dd ba f5 02 00 00 || * 1170 fk@t520 ~ $sudo zfs send tank/corruption-test@2011-07-28_04:54 | dd of=/dev/null bs=1m 0+198030 records in 1238+1 records out 1298720968 bytes transferred in 1.788083 secs (726320368 bytes/sec) Obtained from: ElectroBSD -- 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 162036] [geom] Fatal trap 12: page fault while in kernel mode -- Stopped at atomic_subtract_int+0x4
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=162036 Mark Linimon changed: What|Removed |Added Assignee|freebsd-bugs@FreeBSD.org|freebsd-g...@freebsd.org 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 221909] [ZFS] Add a sysctl to toggle send_corrupt_data
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221909 Mark Linimon changed: What|Removed |Added Assignee|freebsd-bugs@FreeBSD.org|freebsd...@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 221799] [ofed] no ipv6 support in iw_cm_id structure
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221799 --- Comment #3 from Hans Petter Selasky --- Navdeep is the one to add iWarp support to the bsd_rdma_4_9 branch. --HPS -- 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 169964] zfs(8): "zfs receive -F" not destroying snapshots that do not exist on the sending side
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=169964 Fabian Keil changed: What|Removed |Added CC||f...@fabiankeil.de --- Comment #1 from Fabian Keil --- The man page could make this more obvious but this is the expected behaviour. The -F option only affects snapshots located after the snapshot to which the dataset is rolled back before starting the receive operation. Without the -F option they would cause the receive operation to fail. Snapshots outside the "rollback window" aren't relevant for the receive operation and thus can be kept. -- 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 221869] bc doesn't always convert ibase to obase correctly
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221869 Conrad Meyer changed: What|Removed |Added Status|New |Closed CC||c...@freebsd.org Resolution|--- |Not A Bug --- Comment #1 from Conrad Meyer --- Note that as soon as you set ibase=2, numbers are input in base 2. obase=10 assigns 0b10 (== decimal 2) to obase. You want obase=1010, or assign obase before changing ibase. I believe this is identical in GNU bc. $ bc (GNU) bc 1.06 Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. ibase=2 obase=1010 15 $ /usr/bin/bc (BSD) ibase=2 obase=1010 15 -- 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 221919] ixl: TX queue hang when using TSO and having a high and mixed network load
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221919 Bug ID: 221919 Summary: ixl: TX queue hang when using TSO and having a high and mixed network load Product: Base System Version: 11.1-STABLE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: nik...@elyzion.net In my scenario, when having an hundred of iscsi sessions that are doing a load of around 10Gib (but it happen with a smaller load less often too) of mixed RX/TX, my XL710-DA2 cards start to flap with the following output in dmesg: ``` ... kernel: ixl0: WARNING: queue 4 appears to be hung! kernel: ixl0: WARNING: Resetting! kernel: ixl0: Malicious Driver Detection event 2 on TX queue 0, pf number 0 kernel: ixl0: MDD TX event is for this function! ... kernel: ixl0: Interface stopped DISTRIBUTING, possible flapping ... ``` (and then a lot iscsi session drop due to the flap) It happens, during the network load, something like every 5min. It seems to me to be related to TSO because when I have disabled it, the bug was gone and I was unable to reproduce it anymore. Reenabling TSO make the bug appearing again. My FW : dev.ixl.0.fw_version: fw 5.0.40043 api 1.5 nvm 5.05 etid 800028a6 oem 1.262.0 But I also reproduced it with fw 4.33.31377 api 1.2 nvm 4.42 -- 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 221919] ixl: TX queue hang when using TSO and having a high and mixed network load
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221919 Mark Linimon changed: What|Removed |Added CC||sbr...@freebsd.org Assignee|freebsd-bugs@FreeBSD.org|freebsd-...@freebsd.org Keywords||IntelNetworking -- 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 221920] local_unbound NOT working
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221920
Bug ID: 221920
Summary: local_unbound NOT working
Product: Base System
Version: 11.1-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Many People
Priority: ---
Component: kern
Assignee: freebsd-bugs@FreeBSD.org
Reporter: jo...@a1poweruser.com
1. The first time startup logic has usage problem. Requires the
"local_unbound_enable="YES" statement in rc.conf and a reboot to create the
correct files on first time setup.
2. When stopping unbound the /etc/resolv.conf created by unbound needs to be
replaced with the saved original version so dns lookups will still work. That
means that on unbound startup the unbound version of the /etc/resolv.conf has
to be swapped back into place. The/etc/rc.d/local_unbound script needs to be
changed adding this function.
3.The logfile: verbosity: and local-zone: parameters of the
/var/unbound/unbound.conf file do not work. Maybe these are compile time
options that need to be enabled when the local_unbound binary was created.
4. The /usr/sbin/local-unbound-setup script needs to be changed in
gen_resolvconf_conf() section replacing
echo "unbound_conf=\"${forward_conf}\""
with
echo "unbound_conf=\"${unbound_conf}\""
I did the number 4 change and then did "service local_unbound start". Ps ax
shows local_unbound running. I have the built in version of ntpd running and
keep getting this message repeated all day long
Aug 29 10:11:35 testsys ntpd[952]: error resolving pool 0.freebsd.poo
l.ntp.org: hostname nor servname provided, or not known (8)
When I try to run any svn download job I get this message
svn: E170013: Unable to connect to a repository at URL
'svn://svn.freebsd.org/po
rts/head/sysutils/qjail'
svn: E670008: Unknown hostname 'svn.freebsd.org'
When I issue "service local_unbound stop" and followed by number 2, the normal
dns environment started working and everything is good again.
The above error messages do not show up when local_unbound is off, so must be
problem with local_unbound.
I can not see how this new built in function has ever worked.
--
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 221849] Kernel panic, kqueue related NULL pointer dereference sys/kern/kern_event.c
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221849 Andrey V. Elsukov changed: What|Removed |Added Assignee|freebsd-bugs@FreeBSD.org|a...@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 221854] makefs: Reject UFS labels that are too long to fit
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221854 Ed Maste changed: What|Removed |Added Status|New |In Progress -- 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 221029] AMD Ryzen: strange compilation failures using poudriere or plain buildkernel/buildworld
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029 --- Comment #98 from Mark Millard --- I tried an experiment of an amd64 -> armv6 cross build of lang/gcc7 via poudriere and it appears that I got a SIGSEGV in: /wrkdirs/usr/ports/lang/gcc7/work/.build/./gcc/xgcc that may be one of the Ryzen ones. (It will be a while before a retry might stop at the same place if it does. I'll report if the stopping point turns out to be repeatable.) The context here is FreeBSD 11.1-STABLE -r322591 running as a Hyper-V guest on a machine booted via Windows 10 Pro. Default work stealing for hardware threads and load redistribution across threads are still in place in the kernel settings: no adjustments. -- 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 221029] AMD Ryzen: strange compilation failures using poudriere or plain buildkernel/buildworld
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029 --- Comment #99 from Mark Millard --- (In reply to Mark Millard from comment #98) The retry is way past the earlier SIGSEGV point (but is still building). So even under qemu-arm-static emulation of arm instructions from an arm xgcc the Ryzen failures appear to occur. -- 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 221848] sys/conf/newvers.sh: Only accept git-svn-id: attributes at the start of the line
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221848 Ed Maste changed: What|Removed |Added Status|New |In Progress Assignee|freebsd-bugs@FreeBSD.org|ema...@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 204749] [patch] Don't (try to) build qlxbge if the user objects to binary blobs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204749 Ed Maste changed: What|Removed |Added Assignee|freebsd-bugs@FreeBSD.org|ema...@freebsd.org Status|New |In Progress -- 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 221356] [patch] Improve swapon_check_swzone() function in swap_pager.c
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221356 Ed Maste changed: What|Removed |Added Status|New |Open --- Comment #3 from Ed Maste --- D11435 is now committed with a planned MFC near end of September. -- 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 211852] Unsafe shutdowns on Intel 750 SSD
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211852 Ed Maste changed: What|Removed |Added CC||ema...@freebsd.org Status|New |In Progress -- 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 201734] [patch] etherswitch: spelling correction in miiproxy
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201734 Ed Maste changed: What|Removed |Added Status|New |Closed CC||ema...@freebsd.org Resolution|--- |FIXED --- Comment #3 from Ed Maste --- Thank you for the report. This was fixed by r281686; "rendevous" no longer appears in the tree. -- 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 199810] libdtrace should probably use O_CLOEXEC while calling open() instead of setting FD_CLOEXEC using fcntl()
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199810 Ed Maste changed: What|Removed |Added Status|New |Open -- 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 199810] libdtrace should probably use O_CLOEXEC while calling open() instead of setting FD_CLOEXEC using fcntl()
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199810 Ed Maste changed: What|Removed |Added CC||ema...@freebsd.org, ||ma...@freebsd.org --- Comment #2 from Ed Maste --- The patch looks good to me. Mark, as the one most likely to be affected by changes in cddl/contrib/opensolaris/lib/libdtrace on a future import, what do you think of the approach in the patch, vs #ifdef FreeBSD / #ifdef illumos guards throughout? -- 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 199810] libdtrace should probably use O_CLOEXEC while calling open() instead of setting FD_CLOEXEC using fcntl()
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199810 Mark Johnston changed: What|Removed |Added Assignee|freebsd-bugs@FreeBSD.org|ma...@freebsd.org --- Comment #3 from Mark Johnston --- (In reply to Ed Maste from comment #2) I think the patch is fine as-is. Given the relatively slow pace of upstream development, I'm not inclined to add ifdefs around every small deviation. Also, illumos now has O_CLOEXEC, so it'd be easy to integrate this upstream at some point in the future. -- 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"
