[Bug 224496] mpr and mps drivers seems to have issues with large seagate drives
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224496 Bane Ivosev changed: What|Removed |Added CC||bane.ivo...@pmf.uns.ac.rs --- Comment #1 from Bane Ivosev --- We have the very same problem but with WD Red disks. System randomly reboot sometimes after 20 days of working. Different disk everytime. It's our production nfs server and now it's very frustrating. Supermicro 5049p 64 GB ECC RAM LSI 3008 IT mode 18x WD Red 4 TB Mar 23 07:39:46 fap kernel: (da17:mpr0:0:25:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00 length 0 SMID 357 Command timeout on target 25(0x001c), 6 set, 60.107418057 elapsed Mar 23 07:39:46 fap kernel: mpr0: At enclosure level 0, slot 17, connector name () Mar 23 07:39:46 fap kernel: mpr0: Sending abort to target 25 for SMID 357 Mar 23 07:39:46 fap kernel: (da17:mpr0:0:25:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00 length 0 SMID 357 Aborting command 0xfe00b7aa6130 Mar 23 07:39:46 fap kernel: (pass19:mpr0:0:25:0): ATA COMMAND PASS THROUGH(16). CDB: 85 08 0e 00 d0 00 01 00 00 00 4f 00 c2 00 b0 00 length 512 SMID 1182 Command timeout on target 25(0x001c), 6 set, 60.217681679 elampr0: At enclosure level 0, slot 17, connector name () Mar 23 07:39:46 fap kernel: mpr0: Controller reported scsi ioc terminated tgt 25 SMID 1182 loginfo 3113 Mar 23 07:39:46 fap kernel: mpr0: Abort failed for target 25, sending logical unit reset Mar 23 07:39:46 fap kernel: mpr0: Sending logical unit reset to target 25 lun 0 Mar 23 07:39:46 fap kernel: mpr0: At enclosure level 0, slot 17, connector name () Mar 23 07:39:46 fap kernel: (da17:mpr0:0:25:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00 Mar 23 07:39:46 fap kernel: (da17:mpr0:0:25:0): CAM status: CCB request aborted by the host Mar 23 07:39:46 fap kernel: (da17:mpr0:0:25:0): Retrying command, 0 more tries remain Mar 23 07:39:46 fap kernel: mpr0: mprsas_action_scsiio: Freezing devq for target ID 25 Mar 23 07:39:46 fap kernel: (da17:mpr0:0:25:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00 Mar 23 07:39:46 fap kernel: (da17:mpr0:0:25:0): CAM status: CAM subsystem is busy Mar 23 07:39:46 fap kernel: (da17:mpr0:0:25:0): Error 5, Retries exhausted Mar 23 07:39:46 fap smartd[95746]: Device: /dev/da17 [SAT], failed to read SMART Attribute Data Mar 23 07:39:46 fap kernel: mpr0: mprsas_action_scsiio: Freezing devq for target ID 25 Mar 23 07:39:46 fap kernel: (da17:mpr0:0:25:0): WRITE(10). CDB: 2a 00 09 4a 32 a8 00 00 08 00 Mar 23 07:39:46 fap kernel: (da17:mpr0:0:25:0): CAM status: CAM subsystem is busy Mar 23 07:39:46 fap kernel: (da17:mpr0:0:25:0): Retrying command, 3 more tries remain Mar 23 07:43:19 fap syslogd: kernel boot file is /boot/kernel/kernel Mar 23 07:43:19 fap kernel: ---<>--- -- 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 224496] mpr and mps drivers seems to have issues with large seagate drives
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224496 --- Comment #2 from Bane Ivosev --- Forgot to say, its FreeBSD 12-RELEASE. -- 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 235944] jedec_dimm(4) does not attach to KFA2 (aka Galax) Hall of Fame DDR4 sticks
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235944 --- Comment #30 from Greg V --- (In reply to Ravi Pokala from comment #29) Yes, it does -- 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 236737] recvmsg() under COMPAT_FREEBSD32 returns the wrong msg_controllen value
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236737 Bug ID: 236737 Summary: recvmsg() under COMPAT_FREEBSD32 returns the wrong msg_controllen value Product: Base System Version: 12.0-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: paulz...@gmail.com Created attachment 203071 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=203071&action=edit udp recvmsg with IP_RECVDSTADDR, IP_RECVTTL and IP_RECVIF setsockopts enabled The returned msg_controllen is shorter under FreeBSD AMD64 12.0-RELEASE with COMPAT_FREEBSD32 mode compared to the same value on an actual i386 system. While the returned msg_controllen is shorter, the corresponding cmsg_len values remain the same. This causes the last cmsg to exceed the msg_control[0:msg_controllen] buffer. This does not seem to be detected using the CMSG_NXTHDR/CMSG_DATA macros. This behavior triggers unit test failures in the Go golang.org/x/net package. A workaround has been applied in https://go-review.googlesource.com/c/net/+/168297 where the kernel returned msg_controllen is effectively extended to size passed by the caller. Attached is a C demonstrator based on one of the unit tests. -- 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 207359] head -r339076 TARGET_ARCH=powerpc64 via powerpc64-gcc : some or all c++ exceptions unbounded loop in _Unwind_RaiseException
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207359 --- Comment #13 from Andrey Rusev --- The problem has gone after updating build machine to FreeBSD 8.4-RELEASE-p35 and GCC 4.2.1 20070831. -- 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 207359] head -r339076 TARGET_ARCH=powerpc64 via powerpc64-gcc : some or all c++ exceptions unbounded loop in _Unwind_RaiseException
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207359 --- Comment #14 from Mark Millard --- (In reply to Andrey Rusev from comment #12) My original submittal did not involve "unknown pointer encoding". What you report for amd64 is not similar at all. (Modern amd64 uses llvm libunwind, not the historical unwind code.) Please submit your own defect report for your context. Things have progressed, in that for lbgcc_s.so historical unwind code I now run with a patch that completes the implementation of DW_CFA_remember_state and DW_CFA_restore_state. building via devel/powerpc64-xtoolchain-gcc materials ( such as devel./powerpc64-gcc ) works for C++ exception handling. There is a patch under review for llvm materials to fix llvm's libunwind for pwoerpc64 code so that it correctly handles the r2 (TOC) register, at least for the code models normally used. -- 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 207359] head -r339076 TARGET_ARCH=powerpc64 via powerpc64-gcc : some or all c++ exceptions unbounded loop in _Unwind_RaiseException
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207359 --- Comment #15 from Mark Millard --- (In reply to Andrey Rusev from comment #13) Please submit your own defect report. For powerpc64 reverting to FreeBSD 8.4-RELEASE-p35 and gcc 4.2.1 is irrelevant to what I was reporting. powerpc64 does not have the history that amd64 has and a lot has changed since back then. I was reporting an issue explicit tied to giving information for using more modern toolchains than gcc 4.2.1 . For powerpc64, more is now known for what I was reporting and patching efforts to fix both the historical unwind code's DW_CFA_remember_state and DW_CFA_restore_state hnndling and llvm's libunwind's handling of r2 during unwind (the TOC register for powerpc64) are in progress. (It may be that only llvm libunwind will be fixed and used going forward.) -- 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"
