[Bug 217287] if_em: "Off by 8" error in network streams under -CURRENT as of roughly Feb 1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217287 Jeffrey Baitis changed: What|Removed |Added URL||https://github.com/trueos/t ||rueos-core/issues/327 -- 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 217287] if_em: "Off by 8" error in network streams under -CURRENT as of roughly Feb 1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217287 --- Comment #1 from Jeffrey Baitis --- Upon further inspection, the WORKING kernel was built on Wed Jan 18: $ uname -a FreeBSD raid.baitis.home 12.0-CURRENT FreeBSD 12.0-CURRENT #18 4f888bf(drm-next): Wed Jan 18 14:31:26 UTC 2017 root@gauntlet:/usr/obj/usr/src/sys/GENERIC amd64 So, changes in -CURRENT made after Jan 18 and before Feb 1 were likely to have precipitated this problem. -- 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 217287] if_em: "Off by 8" error in network streams under -CURRENT as of roughly Feb 1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217287 Bug ID: 217287 Summary: if_em: "Off by 8" error in network streams under -CURRENT as of roughly Feb 1 Product: Base System Version: CURRENT Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: j...@baitis.net Originally discovered in TrueOS UNSTABLE and tested / verified in vanilla FreeBSD kernel source as of 12.0-CURRENT FreeBSD 12.0-CURRENT #1 7a0e1ff53(master) -- originally recorded at https://github.com/trueos/trueos-core/issues/327 Summary: Corruption observed in network data within socket stream resulting in changes of a +8 value added, at seemingly random intervals, to bytes within the stream Hardware: CPU: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz Selected data from `lspci -v`: 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3 Processor DRAM Controller (rev 06) 00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I217-LM (rev 04) 00:1f.0 ISA bridge: Intel Corporation C226 Series Chipset Family Server Advanced SKU LPC Controller (rev 04) 00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller (rev 04) 01:00.0 VGA compatible controller: NVIDIA Corporation GK208 [GeForce GT 730] (rev a1) Steps to reproduce: $ curl http://norvig.com/big.txt -o big.txt $ curl http://norvig.com/big.txt -o big2.txt $ sha256 big.txt SHA256 (big.txt) = a36fe438864ad8c7b76ca310c2d1176689bbf79536f84338ebd3dc253997efd5 $ sha256 big2.txt SHA256 (big2.txt) = 71f0fa4bf8585feae457dbfc0b48dd6dfef8dcd03a07220a5754e0876b9e4efc `diff -u big.txt big2.txt` results in lines such as: -There was a movement and an mxclamation from my right, and peering through the gloom, I saw Whitney, pale, haggard, and unkempt, staring out at me. +There was a movement and an exclamation from my right, and peering through the gloom, I saw Whitney, pale, haggard, and unkempt, staring out at me. -" 'You may as well face the matter,' said I; 'you have been caught in the act, and no confession could make your guilt more heinous. If you but make such reparation as is in your power, by telling us where the beryls are, all shall be forgiven and forgotten.' +" 'You may as well face the matter,' said I; 'you have been caught in the act, and no confession could make your guilt more heino}s. If you but make such reparation as is in your power, by telling us where the beryls are, all shall be forgiven and forgotten.' Diagnostic: +>>> ord('m') - ord('e') 8 +>>> ord('}') - ord('u') 8 Last working state: The last working version in -CURRENT occurs somewhere prior to commit '8f3781173d79d5b83e19f59b10b54263976dd66e' which was merged into the TrueOS "drm-next" branch on Jan 27. -- 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 217282] panics during bootup due to a race between vt_change_font() and termcn_cnputc()
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217282 Jonathan T. Looney changed: What|Removed |Added Assignee|freebsd-bugs@FreeBSD.org|j...@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 217282] panics during bootup due to a race between vt_change_font() and termcn_cnputc()
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217282 Jonathan T. Looney 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 217282] panics during bootup due to a race between vt_change_font() and termcn_cnputc()
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217282 Bug ID: 217282 Summary: panics during bootup due to a race between vt_change_font() and termcn_cnputc() Product: Base System Version: CURRENT Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: j...@freebsd.org Running an internal fork of FreeBSD -CURRENT (synced as of r312388), we have had several machines crash early in bootup with backtraces such as these: db> bt Tracing pid 20 tid 100135 td 0xf80015090500 vga_bitblt_one_text_pixels_block() at vga_bitblt_one_text_pixels_block+0x135/frame 0xfe15a81af570 vga_bitblt_text() at vga_bitblt_text+0xd0/frame 0xfe15a81af5d0 vt_flush() at vt_flush+0x2ae/frame 0xfe15a81af610 termcn_cnputc() at termcn_cnputc+0x108/frame 0xfe15a81af650 cnputc() at cnputc+0x6d/frame 0xfe15a81af680 cnputs() at cnputs+0xd8/frame 0xfe15a81af6a0 putchar() at putchar+0x15e/frame 0xfe15a81af720 kvprintf() at kvprintf+0x119/frame 0xfe15a81af830 _vprintf() at _vprintf+0x8d/frame 0xfe15a81af910 printf() at printf+0x53/frame 0xfe15a81af970 g_mirror_update_device() at g_mirror_update_device+0x8aa/frame 0xfe15a81af9b0 g_mirror_worker() at g_mirror_worker+0x1709/frame 0xfe15a81afa70 fork_exit() at fork_exit+0x85/frame 0xfe15a81afab0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe15a81afab0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- This appears to be occurring in /FreeBSD/sys/dev/vt/hw/vga/vt_vga.c at line 648: c = VTBUF_GET_FIELD(vb, row, col); It is crashing while trying to extract the column from the array of rows. (In other words, the row points to a NULL value.) There are 500 rows: db> x/lx 0x80d638c0 vt_conswindow+0x38: 1f4 The code is trying to access row 383: rdx 0x17f And, that does indeed point to a NULL column: db> x/gx 0xf80015886bf8 0xf80015886bf8: fe000493eec0 db> x/gx 0xfe000493eec0 0xfe000493eec0: 0 However, this other thread was running at the same time: db> bt 10 Tracing pid 0 tid 10 td 0x81020020 cpustop_handler() at cpustop_handler+0x28/frame 0xfe1362b62d40 ipi_nmi_handler() at ipi_nmi_handler+0x4a/frame 0xfe1362b62d60 trap() at trap+0x3a/frame 0xfe1362b62f20 nmi_calltrap() at nmi_calltrap+0x8/frame 0xfe1362b62f20 --- trap 0x13, rip = 0x807f683a, rsp = 0x815369a0, rbp = 0x815369a0 --- bcopy() at bcopy+0x1a/frame 0x815369a0 memmove() at memmove+0x14/frame 0x815369c0 vtbuf_grow() at vtbuf_grow+0x2d5/frame 0x81536a50 vt_change_font() at vt_change_font+0x1ac/frame 0x81536ac0 vt_upgrade() at vt_upgrade+0x66c/frame 0x81536b50 mi_startup() at mi_startup+0x118/frame 0x81536b70 btext() at btext+0x2c It looks like there is a race condition between vt_change_font() and termcn_cnputc(). vt_change_font() calls vtbuf_grow(), which messes around with the vt data structures. (In fact, vtbuf_grow() was in the middle of re-initializing these row data structures, which is probably why they were NULL.) vt_change_font() uses terminal_mute() to keep the terminal from using the vt data structures during the vtbuf_grow() call. That is all well and good except that termcn_cnputc() drops the terminal lock (and, necessarily, doesn't check if TF_MUTE is set) prior to running tm->tm_class->tc_done(tm). And, the tc_done function points to vtterm_done(), which calls vt_flush(), which eventually tries to read from those data structures. So, some sort of locking change is needed here to prevent the terminal from using the vt data structures while they are being re-initialized. -- 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 28789] [patch] last(1) does not filter for uucp connects
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=28789 wolfg...@lyxys.ka.sub.org changed: What|Removed |Added Resolution|--- |Overcome By Events Status|In Progress |Closed --- Comment #3 from wolfg...@lyxys.ka.sub.org --- After 16 years of being "in progress", I think this bug report is not relevant anymore: freebsd-uucp nowadays writes an empty tty field while ftp doesn't create an utmp-entry at all. I'm closing this PR. -- 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 213903] Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213903 --- Comment #7 from Franco Fichtner --- So far we haven't heard back from users regarding the debug info. But we have a suspect: https://lists.freebsd.org/pipermail/freebsd-current/2015-November/058122.html Some CPU info of previous user reports: CPU: Intel(R) Atom(TM) CPU C2758 @ 2.40GHz (2400.06-MHz K8-class CPU) Origin="GenuineIntel" Id=0x406d8 Family=0x6 Model=0x4d Stepping=8 Features=0xbfebfbff Features2=0x43d8e3bf AMD Features=0x28100800 AMD Features2=0x101 Structured Extended Features=0x2282 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 16515608576 (15750 MB) CPU: Intel(R) Celeron(R) CPU N2930 @ 1.83GHz (1833.38-MHz K8-class CPU) Origin="GenuineIntel" Id=0x30678 Family=0x6 Model=0x37 Stepping=8 Features=0xbfebfbff Features2=0x41d8e3bf AMD Features=0x28100800 AMD Features2=0x101 Structured Extended Features=0x2282 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) avail memory = 8072794112 (7698 MB) CPU: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz (2000.05-MHz K8-class CPU) Origin="GenuineIntel" Id=0x30678 Family=0x6 Model=0x37 Stepping=8 Features=0xbfebfbff Features2=0x41d8e3bf AMD Features=0x28100800 AMD Features2=0x101 Structured Extended Features=0x2282 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 3961688064 (3778 MB) -- 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 204340] [panic] nfsd, em, msix, fatal trap 9
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204340 --- Comment #31 from Rick Macklem --- And thanks go to you for doing the testing and commits. -- You are receiving this mail because: You are on the CC list 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 217267] mkdir and rename triggering a deadlock in ZFS
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217267 Xavier Garcia changed: What|Removed |Added Status|New |Closed Resolution|--- |DUPLICATE --- Comment #2 from Xavier Garcia --- (In reply to Andriy Gapon from comment #1) Thank you for the clarification. Closing the ticket. *** This bug has been marked as a duplicate of bug 209158 *** -- 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 217267] mkdir and rename triggering a deadlock in ZFS
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217267 --- Comment #1 from Andriy Gapon --- This should be fixed in stable/10, stable/11 and head. Also in 11.0 release. See bug #209158. -- 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 217267] mkdir and rename triggering a deadlock in ZFS
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217267 Bug ID: 217267 Summary: mkdir and rename triggering a deadlock in ZFS Product: Base System Version: 10.3-STABLE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: xavi.gar...@gmail.com Similarly to #209158 mkdir and rename triggered a deadlock in ZFS. procstat -kka | grep zfs 12471 101243 mv -mi_switch+0xe1 sleepq_wait+0x3a sleeplk+0x15d __lockmgr_args+0xca0 vop_stdlock+0x3c VOP_LOCK1_APV+0xab _vn_lock+0x43 vputx+0x21f zfs_rename_unlock+0x3e zfs_freebsd_rename+0xe39 VOP_RENAME_APV+0xab kern_renameat+0x4a6 amd64_syscall+0x40f Xfast_syscall+0xfb 12472 101019 mv -mi_switch+0xe1 sleepq_wait+0x3a sleeplk+0x15d __lockmgr_args+0x91a vop_stdlock+0x3c VOP_LOCK1_APV+0xab _vn_lock+0x43 zfs_lookup+0x45d zfs_freebsd_lookup+0x6d VOP_CACHEDLOOKUP_APV+0xa1 vfs_cache_lookup+0xd6 VOP_LOOKUP_APV+0xa1 lookup+0x5a1 namei+0x4d4 kern_statat_vnhook+0xae sys_stat+0x2d amd64_syscall+0x40f Xfast_syscall+0xfb 12486 102454 mkdir-mi_switch+0xe1 sleepq_wait+0x3a sleeplk+0x15d __lockmgr_args+0x91a vop_stdlock+0x3c VOP_LOCK1_APV+0xab _vn_lock+0x43 zfs_lookup+0x45d zfs_freebsd_lookup+0x6d VOP_CACHEDLOOKUP_APV+0xa1 vfs_cache_lookup+0xd6 VOP_LOOKUP_APV+0xa1 lookup+0x5a1 namei+0x4d4 kern_mkdirat+0xcb amd64_syscall+0x40f Xfast_syscall+0xfb This server has several jails running Poudriere inside and delegated volume (jailed=on) for the data. These jails are used by our developers to build and test our software stack and there is a lot of snapshotting and cloning involved together with the normal filesystem activity when packages are being compiled. We had to reboot the server to recover from the deadlock. -- 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 204340] [panic] nfsd, em, msix, fatal trap 9
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204340 Andriy Gapon changed: What|Removed |Added Status|In Progress |Closed Resolution|--- |FIXED --- Comment #30 from Andriy Gapon --- Rick, thank you again! -- You are receiving this mail because: You are on the CC list 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 204340] [panic] nfsd, em, msix, fatal trap 9
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204340 --- Comment #29 from commit-h...@freebsd.org --- A commit references this bug: Author: avg Date: Tue Feb 21 09:29:47 UTC 2017 New revision: 314034 URL: https://svnweb.freebsd.org/changeset/base/314034 Log: MFC r313735: add svcpool_close to handle killed nfsd threads PR: 204340 Reported by: Panzura Reviewed by: rmacklem Approved by: rmacklem Changes: _U stable/10/ stable/10/sys/fs/nfsserver/nfs_nfsdkrpc.c stable/10/sys/rpc/svc.c stable/10/sys/rpc/svc.h -- You are receiving this mail because: You are on the CC list 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 204340] [panic] nfsd, em, msix, fatal trap 9
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204340 --- Comment #28 from commit-h...@freebsd.org --- A commit references this bug: Author: avg Date: Tue Feb 21 09:29:11 UTC 2017 New revision: 314033 URL: https://svnweb.freebsd.org/changeset/base/314033 Log: MFC r313735: add svcpool_close to handle killed nfsd threads PR: 204340 Reported by: Panzura Approved by: rmacklem Obtained from:rmacklem Changes: _U stable/11/ stable/11/sys/fs/nfsserver/nfs_nfsdkrpc.c stable/11/sys/rpc/svc.c stable/11/sys/rpc/svc.h -- You are receiving this mail because: You are on the CC list 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"