[Bug 239801] mfi errors causing zfs checksum errors
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239801 Hiroki Sato changed: What|Removed |Added Status|Open|In Progress --- Comment #5 from Hiroki Sato --- (In reply to Daniel Mafua from comment #4) Thanks for your report. I have several other systems which are suffering from the same problem. Here is information about this problem which I got so far: * mfi(4) can report I/O errors which is not related to an actual hardware failure after upgrading FreeBSD to 11.3 or 12.0. * The error does not depend on ZFS while ZFS is very likely to report checksum errors of the zpool. On a system using UFS, the I/O error can cause a system panic, boot failure, or something fatal. * It seems that the I/O error depends on a specific firmware version. Some older firmware versions work fine even with mfi(4) on 11.3 and 12.0. * If the device is also supported by mrsas(4), switching to it will solves the error. Note that it will cause an incompatibility issue---mfi(4) uses /dev/mfi* device nodes for the attached drives and mfiutil(8) as the userland utility. mrsas(4) uses /dev/da* and a vendor-supplied utility such as megaCli instead. I am investigating what caused this regression but a workaround is to use mrsas(4) instead of mfi(4) by specifying hw.mfi.mrsas_enable="1" at boot time. -- 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 240320] [ixgbe] [patch] EEE state change causes core dump on X552
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240320 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|n...@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 231828] em(4) is unusable after suspend/resume
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231828 --- Comment #15 from Mason Loring Bliss --- *** Bug 239443 has been marked as a duplicate of this bug. *** -- 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 239801] mfi errors causing zfs checksum errors
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239801 --- Comment #4 from Daniel Mafua --- The firmware has not been upgraded on any of the servers. I was able to switch from mfi to mrsas on one of the servers, but because they're at remote locations I need to be careful on how aggressive I am on this. I've successfully scrubbed out errors and everything is clear now. However, this also has been the case after any reboot, and errors started appearing again around 3-4 days later. It will probably take me two weeks to verify it's working okay, then I'll report back. -- 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 240320] [ixgbe] [patch] EEE state change causes core dump on X552
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240320 Zach Vargas changed: What|Removed |Added Keywords||IntelNetworking, crash -- 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 240320] [ixgbe] [patch] EEE state change causes core dump on X552
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240320 Bug ID: 240320 Summary: [ixgbe] [patch] EEE state change causes core dump on X552 Product: Base System Version: 12.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: zvar...@xes-inc.com Created attachment 207168 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=207168=edit Patch to disable EEE support on X552 devices in the ix driver. Overview: My system has a Xeon-D 1500 series SoC with two 10GbE Intel X552 backplane connections (device ID: 0x15AB). In FreeBSD 12.0 RELEASE, attempting to use the sysctl utility to transition Energy Efficient Ethernet (EEE) states causes a core dump (see below for details). I believe that this is the result of the fact that X552 devices do not support EEE. This assertion is based on the following documentation from Intel: The note below table 1.2 (Network Features) in Section 1.6 of volume 4 of the datasheet for Xeon-D 1500 (https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/xeon-d-1500-datasheet-vol-4.pdf) states: EEE is ONLY supported for 10GBASE-T interfaces via the X557-AT2 PHY. The Intel® Xeon® Processor D-1500 Product Family LANcontroller does not support EEE feature. Furthermore, in the README for the Linux ixgbe driver (version 5.6.1), EEE is listed as an unsupported feature: NOTE: Devices based on the Intel(R) Ethernet Connection X552 and Intel(R) Ethernet Connection X553 do not support the following features: * Energy Efficient Ethernet (EEE) * Intel PROSet for Windows Device Manager * Intel ANS teams or VLANs (LBFO is supported) * Fibre Channel over Ethernet (FCoE) * Data Center Bridging (DCB) * IPSec Offloading * MACSec Offloading The FreeBSD ix driver (version 3.3.10) release README also has a list of unsupported features for X552. However, these lists do not match. The FreeBSD version lists 'Low Latency Interrupts (LLI)' as the only unsupported feature. I have attached a patch (0001-X552-does-not-support-eee.patch) to disable EEE support on X552 devices in the ix driver. This patch was created against r350420 of FreeBSD which was the latest in CURRENT at the time of my investigation. Steps to Reproduce: Attempt to change EEE state via the ix driver eee_state attribute via the sysctl utility. Actual results: Running 12.0 RELEASE FreeBSD from https://svn.freebsd.org/base/releng/12.0, attempting to change the EEE state of an ix adapter: root@bsd:~ # uname -r 12.0-RELEASE root@bsd:~ # sysctl dev.ix.1.eee_state dev.ix.1.eee_state: 1 root@bsd:~ # sysctl dev.ix.1.eee_state=0 Fatal trap 12: page fault while in kernel mode cpuid = 5; apic id = 05 fault virtual address = 0x0 fault code = supervisor read instruction, page not present instruction pointer= 0x20:0x0 stack pointer = 0x28:0xfe008a86d718 frame pointer = 0x28:0xfe008a86d760 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= 2424 (sysctl) trap number= 12 panic: page fault cpuid = 5 time = 1563820937 KDB: stack backtrace: #0 0x80bdcbc7 at kdb_backtrace+0x67 #1 0x80b907b3 at vpanic+0x1a3 #2 0x80b90603 at panic+0x43 #3 0x8106996f at trap_fatal+0x35f #4 0x810699c9 at trap_pfault+0x49 #5 0x81068fee at trap+0x29e #6 0x81044425 at calltrap+0x8 #7 0x80b9f56b at sysctl_root_handler_locked+0x8b #8 0x80b9ec27 at sysctl_root+0x257 #9 0x80b9f29a at userland_sysctl+0x17a #10 0x80b9f0df at sys___sysctl+0x5f #11 0x8106a449 at amd64_syscall+0x369 #12 0x81044d0d at fast_syscall_common+0x101 Uptime: 36m40s Dumping 736 out of 16329 MB:..3%..11%..22%..31%..42%..53%..61%..72%..81%..92% Dump complete I see the same behaviour in CURRENT and core dump on boot in previous versions (11.3). Expected Results: Transition EEE state or error out without coredump. Testing with this patch applied: root@bsd:~/freebsd-ixgbe # sysctl dev.ix.1.eee_state sysctl: unknown oid 'dev.ix.1.eee_state' root@bsd:~/freebsd-ixgbe # -- 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 239894] security.bsd.stack_guard_page default causes Java to crash
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894 --- Comment #19 from commit-h...@freebsd.org --- A commit references this bug: Author: kib Date: Tue Sep 3 18:58:48 UTC 2019 New revision: 351774 URL: https://svnweb.freebsd.org/changeset/base/351774 Log: Add stackgap control mode to proccontrol(1). PR: 239894 Reviewed by: alc Sponsored by: The FreeBSD Foundation MFC after:1 week Differential revision:https://reviews.freebsd.org/D21352 Changes: head/usr.bin/proccontrol/proccontrol.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 239894] security.bsd.stack_guard_page default causes Java to crash
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239894 --- Comment #18 from commit-h...@freebsd.org --- A commit references this bug: Author: kib Date: Tue Sep 3 18:56:27 UTC 2019 New revision: 351773 URL: https://svnweb.freebsd.org/changeset/base/351773 Log: Add procctl(PROC_STACKGAP_CTL) It allows a process to request that stack gap was not applied to its stacks, retroactively. Also it is possible to control the gaps in the process after exec. PR: 239894 Reviewed by: alc Sponsored by: The FreeBSD Foundation Differential revision:https://reviews.freebsd.org/D21352 Changes: head/lib/libc/sys/procctl.2 head/sys/compat/freebsd32/freebsd32_misc.c head/sys/kern/kern_exec.c head/sys/kern/kern_fork.c head/sys/kern/kern_procctl.c head/sys/sys/proc.h head/sys/sys/procctl.h head/sys/vm/vm_map.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 239552] Quotas on NFS shares broken (return: none) on 11.3-RELEASE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239552
--- Comment #3 from Sean Eric Fagan ---
I don't have a way to reproduce this; anyone who can, it would be useful to
find out if both client and server are using the same RPC version for rquota.
For Version 1, it should be using the structure
struct getquota_args {
string gqa_pathp; /* path to filesystem of interest */
int gqa_uid;/* Inquire about quota for uid */
};
to request a quota; for Version 2, it should be usingstruct ext_getquota_args {
string gqa_pathp; /* path to filesystem of interest */
int gqa_type; /* Type of quota info is needed about
*/
int gqa_id; /* Inquire about quota for id */
};
Note that USRQUOTA is 0, which matches the behaviour from the comments above.
(But it could be 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 233413] lld does not accept -format arg used by lazarus build system
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233413 Jose Alonso Cardenas Marquez changed: What|Removed |Added Resolution|--- |FIXED Status|In Progress |Closed --- Comment #13 from Jose Alonso Cardenas Marquez --- fpc/lazarus ports will use binutils from ports. I think that lld will not supported in short time but now we can set LDPATH if it is supported later -- 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 233413] lld does not accept -format arg used by lazarus build system
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233413 --- Comment #12 from commit-h...@freebsd.org --- A commit references this bug: Author: acm Date: Tue Sep 3 15:52:00 UTC 2019 New revision: 510956 URL: https://svnweb.freebsd.org/changeset/ports/510956 Log: - Rebuild bootstrap (ppcx64 and ppc386) with ld patches - Fix build on 12-STABLE and CURRENT (amd64 and i386) - Bump PORTREVISION for all ports that depends of lang/fpc - Add USE_BINUTILS to fpc and lazarus based ports - Add binutils dependency to Uses/fpc.mk and Uses/lazarus.mk PR: 240293 239934 233413 214864 Exp-run by: antoine Changes: head/Mk/Uses/fpc.mk head/Mk/Uses/lazarus.mk head/archivers/peazip/Makefile head/archivers/peazip/pkg-plist head/cad/zcad/Makefile head/comms/cqrlog/Makefile head/databases/fpc-fpindexer/Makefile head/databases/fpc-gdbm/Makefile head/databases/fpc-ibase/Makefile head/databases/fpc-postgres/Makefile head/devel/fpc-fcl-db/Makefile head/devel/fpc-fcl-js/Makefile head/devel/fpc-fcl-json/Makefile head/devel/fpc-fcl-passrc/Makefile head/devel/fpc-fcl-pdf/Makefile head/devel/fpc-fcl-sdo/Makefile head/devel/fpc-fcl-stl/Makefile head/devel/fpc-fcl-web/Makefile head/devel/fpc-fppkg/Makefile head/devel/fpc-sdl/Makefile head/editors/cudatext/Makefile head/editors/lazarus/Makefile head/editors/picpas/Makefile head/games/hedgewars/Makefile head/graphics/fpc-imagemagick/Makefile head/graphics/lazpaint/Makefile head/lang/fpc/Makefile head/lang/fpc/distinfo head/lang/fpc/files/patch-compiler_systems_t__bsd.pas head/lang/fpc-base/Makefile head/lang/fpc-rtl-objpas/Makefile head/lang/fpc-source/Makefile head/lang/fpc-utils/Makefile head/lang/nbc/Makefile head/multimedia/fpc-libvlc/Makefile head/multimedia/winff/Makefile head/net-p2p/awgg/Makefile head/net-p2p/transmission-remote-gui/Makefile head/russian/emkatic/Makefile head/science/checkmol/Makefile head/science/mol2ps/Makefile head/www/fpc-googleapi/Makefile head/x11/fpc-x11/Makefile head/x11-fm/doublecmd/Makefile -- 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 239801] mfi errors causing zfs checksum errors
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239801 --- Comment #3 from ma...@tols.org --- Hi, so my bit more detailed story is this: We have 2 identical Dell R730xd systems with each 12 6TB drives in them, running on raidz2. It also has 2 SSD's in it which add to the system as ZIL and cache drives. Both have been running 11.1-RELEASE which gave no problems. The systems also have been on 11.2-RELEASE, also without any problems. In between the upgrades I have also done "zpool upgrade" where available. Then I upgraded to version 11.3-RELEASE, and trusting that all was as flawless as in the first 2 years, I gave it not much attention other then keeping an eye on it from the monitoring host. Unfortunately we only monitor zpool status, which has been ONLINE throughout the entire process. I left it running for quite a while when at some point I wanted to show the pool to someone and found out both systems had a few 100K checksum errors on each of the 12 drives in the pool. Not on the SSDs that make up the ZIL and cache. One of the systems was running 11.3-RELEASE-p1, and the other was running 11.3-RELEASE-p3. My path to fixing this was this: - Google for the issue, and find out mrsas was a potential fix - Change the system on p3 to mrsas and reboot - Do a zpool scrub to autoheal all broken sectors, which ended up fixing almost 100GB of data - Do a zpool clear to clear the counters - Do another zpool scrub to see if the counters remain 0, which they did. - Do the same on the other system, which was on p1, and bring it to p3 in the process Hope this helps, Marco van Tol -- 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 240061] MADV_FREE rewinds time to before fork()
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240061
--- Comment #6 from Mark Johnston ---
One possible alternative is to convert MADV_FREE to MADV_DONTNEED if the object
has a backing object. pmap_advise() needs to be updated to preserve the
modified bits, but this should be fine since vm_page_advise(MADV_FREE) calls
vm_page_undirty() anyway.
Some basic testing on my workstation showed that virtually all calls to
vm_object_madvise(MADV_FREE) are acting on an object with no backing object.
Obviously this may not be true in general.
# dtrace -n 'fbt::vm_object_madvise:entry /args[0] && args[3] ==
5/{@[args[0]->backing_object == NULL] = count();}'
^C
0 13
117504
Untested patch here: https://people.freebsd.org/~markj/patches/madvise_cow.diff
--
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 239801] mfi errors causing zfs checksum errors
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239801 Hiroki Sato changed: What|Removed |Added Status|New |Open --- Comment #2 from Hiroki Sato --- Can you tell me whether you updated or not the firmware before or after upgrading FreeBSD? -- 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 239801] mfi errors causing zfs checksum errors
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239801 ma...@tols.org changed: What|Removed |Added CC||ma...@tols.org --- Comment #1 from ma...@tols.org --- I had this exact same problem with a large array on a PERC H730/P. I could fix this by changing the controller driver from mfi to mrsas. See https://www.freebsd.org/cgi/man.cgi?query=mrsas=0=0=FreeBSD+11.3-RELEASE=default=html on details on how to do that. (loader.conf variable) Please make sure you do a "zfs scrub" afterwards to autoheal all checksum errors. Marco van Tol -- 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 239552] Quotas on NFS shares broken (return: none) on 11.3-RELEASE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239552 --- Comment #2 from Dani --- I took some time and manually reverted base r336017 for FreeBSD 11.3, which fixed the quota bug on NFS. As you can see below, the output of 11.3(unpatched) is broken, while the patched system reports the correct quota queried from the rquotad running on our NetApp Storage. As far as i can tell, this problem does not exist when mounting an exported ufs-FS via NFS from an other FreeBSD host. Here are the outputs befor and after the revert: == BEFOR revert (Original FreeBSD-11.3-p3) == [root@113-original:~] 1 # quota -f /home/test01/ -u test01 Disk quotas for user test01 (uid 216426): none [test01@113-original:~] $ quota|grep test01 Disk quotas for user test01 (uid 216426): /home/test01 17083181722417594* 1330618343798705 45212120835836397535435945233days 8319591592418178159* 7935465087977743732 832080836963869527799576432257295days [test01@113-original:~] $ quota -f /home/test01 Disk quotas for user test01 (uid 216426): none == AFTER revert of base r336017 (Patched FreeBSD-11.3-p3) == [root@113-patched:~] 1 # quota -f /home/test01/ -u test01 Disk quotas for user test01 (uid 216426): Filesystemusagequota limit grace files quota limit grace /home/test0135484 524288000 524288000434 60 60 [test01@113-patched:~] $ quota Disk quotas for user test01 (uid 216426): /home/test0135484 524288000 524288000434 60 60 [test01@113-patched:~] $ quota -f /home/test01 Disk quotas for user test01 (uid 216426): Filesystemusagequota limit grace files quota limit grace /home/test0135484 524288000 524288000434 60 60 -- 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 234576] hastd exits ungracefully
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234576 --- Comment #7 from Michel Le Cocq --- Hi, thanks for your answer. I change my way of doing, it appears that's it's faster and easier to remove log device from a pool then add one on the other server than syncing them with hast and check that everything is ok. But maybe my hast sync test before pool import was to complicated ! -- 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"
