Re: LOR on head using virtualbox between intel kms and sound, with system lockup
On Sat, Dec 13, 2014 at 01:13:04AM +0100, Guido Falsi wrote: On 12/10/14 09:58, Guido Falsi wrote: On 12/10/14 09:52, Konstantin Belousov wrote: On Tue, Dec 09, 2014 at 11:39:57PM +0100, Guido Falsi wrote: [...] --- trap 0xc, tip = 0x8056834d, rsp = 0xfe022ed8f6b0, rbp = 0xfe022ed8f6e0 --- sbappendstream_locked() at sbappendstream_locked+0x2d/frame 0xfe022ed8f6e0 sbappendstream() at sbappendstream+0x3c/frame 0xfe022ed8f710 tcp_usr_send() at tcp_usr_send+0x1ab/frame 0xfe022ed8f790 sosend_generic() at sosend_generic+0x40b/frame 0xfe022ed8f850 kern_sendit() at kern_sendit+0x19e/frame 0xfe022ed8f900 sendit() at sendit+0x129/frame 0xfe022ed8f950 sys_sendto() at sys_sendto+0x4d/frame 0xfe022ed8f9a0 amd64_syscall() at amd64_syscall+0x211/frame 0xfe022ed8fab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe022ed8fab0 --- syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x80126c5a, rsp = 0x7fffdf1e9df8, rbp = 0x7fffdf1e9e40 --- This is plain fault, in network stack, in the tcp send path. It has nothing to do with sound at all, and the LOR between DRM device lock and send buffer socket lock is a consequence of drm activated when panic occured in the locked region. That said, first thing to do when you experience panic with vbox or fuse modules loaded, is to remove the modules and see if it happens still. If it is persistent, contact net@. I see. Problem with removing the virtualbox module is I have been able to trigger the panic only by starting the VBox VM. I have no idea how to trigger it some other way. I'll try though. Thanks for the insight! Quick followup, for any interested party, I isolated the commit in r274712, reverting this one the problem disappears. If anyone has some ideas about this please reply to me or followup in bug 195822 on bugzilla. I suspect that the issue is vbox and not the revision itself. Anyway, your best route is to ask Gleb. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: LOR on head using virtualbox between intel kms and sound, with system lockup
On 12/13/14 11:26, Konstantin Belousov wrote: On Sat, Dec 13, 2014 at 01:13:04AM +0100, Guido Falsi wrote: On 12/10/14 09:58, Guido Falsi wrote: On 12/10/14 09:52, Konstantin Belousov wrote: On Tue, Dec 09, 2014 at 11:39:57PM +0100, Guido Falsi wrote: [...] --- trap 0xc, tip = 0x8056834d, rsp = 0xfe022ed8f6b0, rbp = 0xfe022ed8f6e0 --- sbappendstream_locked() at sbappendstream_locked+0x2d/frame 0xfe022ed8f6e0 sbappendstream() at sbappendstream+0x3c/frame 0xfe022ed8f710 tcp_usr_send() at tcp_usr_send+0x1ab/frame 0xfe022ed8f790 sosend_generic() at sosend_generic+0x40b/frame 0xfe022ed8f850 kern_sendit() at kern_sendit+0x19e/frame 0xfe022ed8f900 sendit() at sendit+0x129/frame 0xfe022ed8f950 sys_sendto() at sys_sendto+0x4d/frame 0xfe022ed8f9a0 amd64_syscall() at amd64_syscall+0x211/frame 0xfe022ed8fab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe022ed8fab0 --- syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x80126c5a, rsp = 0x7fffdf1e9df8, rbp = 0x7fffdf1e9e40 --- This is plain fault, in network stack, in the tcp send path. It has nothing to do with sound at all, and the LOR between DRM device lock and send buffer socket lock is a consequence of drm activated when panic occured in the locked region. That said, first thing to do when you experience panic with vbox or fuse modules loaded, is to remove the modules and see if it happens still. If it is persistent, contact net@. I see. Problem with removing the virtualbox module is I have been able to trigger the panic only by starting the VBox VM. I have no idea how to trigger it some other way. I'll try though. Thanks for the insight! Quick followup, for any interested party, I isolated the commit in r274712, reverting this one the problem disappears. If anyone has some ideas about this please reply to me or followup in bug 195822 on bugzilla. I suspect that the issue is vbox and not the revision itself. It's quite possible. Just to clarify, I did not mean that commit is wrong or anything like that. In fact I'm unable to tell not having a clear understanding of that code. I just thought this bit of information could help the diagnosis. Anyway, your best route is to ask Gleb. I did. He sad he's taking a look. -- Guido Falsi m...@madpilot.net ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: LOR on head using virtualbox between intel kms and sound, with system lockup
On 12/10/14 09:58, Guido Falsi wrote: On 12/10/14 09:52, Konstantin Belousov wrote: On Tue, Dec 09, 2014 at 11:39:57PM +0100, Guido Falsi wrote: [...] --- trap 0xc, tip = 0x8056834d, rsp = 0xfe022ed8f6b0, rbp = 0xfe022ed8f6e0 --- sbappendstream_locked() at sbappendstream_locked+0x2d/frame 0xfe022ed8f6e0 sbappendstream() at sbappendstream+0x3c/frame 0xfe022ed8f710 tcp_usr_send() at tcp_usr_send+0x1ab/frame 0xfe022ed8f790 sosend_generic() at sosend_generic+0x40b/frame 0xfe022ed8f850 kern_sendit() at kern_sendit+0x19e/frame 0xfe022ed8f900 sendit() at sendit+0x129/frame 0xfe022ed8f950 sys_sendto() at sys_sendto+0x4d/frame 0xfe022ed8f9a0 amd64_syscall() at amd64_syscall+0x211/frame 0xfe022ed8fab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe022ed8fab0 --- syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x80126c5a, rsp = 0x7fffdf1e9df8, rbp = 0x7fffdf1e9e40 --- This is plain fault, in network stack, in the tcp send path. It has nothing to do with sound at all, and the LOR between DRM device lock and send buffer socket lock is a consequence of drm activated when panic occured in the locked region. That said, first thing to do when you experience panic with vbox or fuse modules loaded, is to remove the modules and see if it happens still. If it is persistent, contact net@. I see. Problem with removing the virtualbox module is I have been able to trigger the panic only by starting the VBox VM. I have no idea how to trigger it some other way. I'll try though. Thanks for the insight! Quick followup, for any interested party, I isolated the commit in r274712, reverting this one the problem disappears. If anyone has some ideas about this please reply to me or followup in bug 195822 on bugzilla. Thanks again! -- Guido Falsi m...@madpilot.net ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: LOR on head using virtualbox between intel kms and sound, with system lockup
2014-12-09 23:39 GMT+01:00 Guido Falsi m...@madpilot.net: Hi, I've experienced a hard lockup on head r275563, amd64. The hardware is a laptop with an intel graphics card. If any further info is required just ask. I had just launched a virtualbox VM with Windows 7, the system locked up just after the startup sound was played in the VM, X11 disappeared and the system locked hard and a LOR data on screen. (I already tested recompiling the virtualbox kmod and the bug shows up with and without 3d/2d acceleration enabled in the VM) I copied (by hand, so sorry for any typos) the LOR data: Lock order reversal: (sleepable after non-sleepable) 1st 0xf8000874da90 so_snd (so_snd) @ /usr/src/sys/kern/uipc_sockbuf.c:666 2nd 0xf80057ff20a0 drmslk (drmslk) @ /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_display.c:2317 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe022ed8eff0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe022ed8f0a0 witness_checkorder() at witness_checkorder+x0dad/frame 0xfe022ed8f130 _sx_xlock() at _sx_xlock+0x71/frame 0xfe022ed8f170 intel_pipe_set_base() at intel_pipe_set_base+0x77/frame 0xfe022ed8f1d8 drm_crtc_helper_set_config() at drm_crtc_helper_set_config+0x7c0/frame 0xfe022ed8f290 vt_kms_postswitch() at vt_kms_postswitch+0x5c/frame 0xfe022ed8f2c0 vt_window_switch() at vt_window_switch+0xc3/frame 0xfe022ed8f300 vtterm_cngrab() at vtterm_cngrab+0x23/frame 0xfe022ed8f320 cngrab() at cngrab+0x35/frame 0xfe022ed8f340 kdb_trap() at kdb_trap+0x183/frame 0xfe022ed8f3e0 trap_fatal() at ytap_fatal+0x34c/frame 0xfe022ed8f440 trap_pfault() at trap_pfault+0x262/frame 0xfe022ed8f4a0 trap() at trap+0x44c/frame 0xfe022ed8f5f0 calltrap() at calltrap+0x8/frame 0xfe022ed8f5f0 --- trap 0xc, tip = 0x8056834d, rsp = 0xfe022ed8f6b0, rbp = 0xfe022ed8f6e0 --- sbappendstream_locked() at sbappendstream_locked+0x2d/frame 0xfe022ed8f6e0 sbappendstream() at sbappendstream+0x3c/frame 0xfe022ed8f710 tcp_usr_send() at tcp_usr_send+0x1ab/frame 0xfe022ed8f790 sosend_generic() at sosend_generic+0x40b/frame 0xfe022ed8f850 kern_sendit() at kern_sendit+0x19e/frame 0xfe022ed8f900 sendit() at sendit+0x129/frame 0xfe022ed8f950 sys_sendto() at sys_sendto+0x4d/frame 0xfe022ed8f9a0 amd64_syscall() at amd64_syscall+0x211/frame 0xfe022ed8fab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe022ed8fab0 --- syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x80126c5a, rsp = 0x7fffdf1e9df8, rbp = 0x7fffdf1e9e40 --- Please note that this is the last one, but at least another one, almost identical to this one, was scrolled up. I've been unable to recover their data, since, as I said the system is hard locked and did not even write them to any system log. Anyone can help? should this one be looked into? How can I try to debut it more? Thanks in advance! -- Guido Falsi m...@madpilot.net Hi Guido, I have opened a PR for this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195822 For me works if the VM Network Adapter is attached to Bridged Adapter. Please comment this bug in the PR. Maurizio ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: LOR on head using virtualbox between intel kms and sound, with system lockup
On Tue, Dec 09, 2014 at 11:39:57PM +0100, Guido Falsi wrote: Hi, I've experienced a hard lockup on head r275563, amd64. The hardware is a laptop with an intel graphics card. If any further info is required just ask. I had just launched a virtualbox VM with Windows 7, the system locked up just after the startup sound was played in the VM, X11 disappeared and the system locked hard and a LOR data on screen. (I already tested recompiling the virtualbox kmod and the bug shows up with and without 3d/2d acceleration enabled in the VM) I copied (by hand, so sorry for any typos) the LOR data: LOR data is not interesting, there is a panic message before it, which is interesting. Lock order reversal: (sleepable after non-sleepable) 1st 0xf8000874da90 so_snd (so_snd) @ /usr/src/sys/kern/uipc_sockbuf.c:666 2nd 0xf80057ff20a0 drmslk (drmslk) @ /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_display.c:2317 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe022ed8eff0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe022ed8f0a0 witness_checkorder() at witness_checkorder+x0dad/frame 0xfe022ed8f130 _sx_xlock() at _sx_xlock+0x71/frame 0xfe022ed8f170 intel_pipe_set_base() at intel_pipe_set_base+0x77/frame 0xfe022ed8f1d8 drm_crtc_helper_set_config() at drm_crtc_helper_set_config+0x7c0/frame 0xfe022ed8f290 vt_kms_postswitch() at vt_kms_postswitch+0x5c/frame 0xfe022ed8f2c0 vt_window_switch() at vt_window_switch+0xc3/frame 0xfe022ed8f300 vtterm_cngrab() at vtterm_cngrab+0x23/frame 0xfe022ed8f320 cngrab() at cngrab+0x35/frame 0xfe022ed8f340 kdb_trap() at kdb_trap+0x183/frame 0xfe022ed8f3e0 trap_fatal() at ytap_fatal+0x34c/frame 0xfe022ed8f440 trap_pfault() at trap_pfault+0x262/frame 0xfe022ed8f4a0 trap() at trap+0x44c/frame 0xfe022ed8f5f0 calltrap() at calltrap+0x8/frame 0xfe022ed8f5f0 --- trap 0xc, tip = 0x8056834d, rsp = 0xfe022ed8f6b0, rbp = 0xfe022ed8f6e0 --- sbappendstream_locked() at sbappendstream_locked+0x2d/frame 0xfe022ed8f6e0 sbappendstream() at sbappendstream+0x3c/frame 0xfe022ed8f710 tcp_usr_send() at tcp_usr_send+0x1ab/frame 0xfe022ed8f790 sosend_generic() at sosend_generic+0x40b/frame 0xfe022ed8f850 kern_sendit() at kern_sendit+0x19e/frame 0xfe022ed8f900 sendit() at sendit+0x129/frame 0xfe022ed8f950 sys_sendto() at sys_sendto+0x4d/frame 0xfe022ed8f9a0 amd64_syscall() at amd64_syscall+0x211/frame 0xfe022ed8fab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe022ed8fab0 --- syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x80126c5a, rsp = 0x7fffdf1e9df8, rbp = 0x7fffdf1e9e40 --- Please note that this is the last one, but at least another one, almost identical to this one, was scrolled up. I've been unable to recover their data, since, as I said the system is hard locked and did not even write them to any system log. This is plain fault, in network stack, in the tcp send path. It has nothing to do with sound at all, and the LOR between DRM device lock and send buffer socket lock is a consequence of drm activated when panic occured in the locked region. That said, first thing to do when you experience panic with vbox or fuse modules loaded, is to remove the modules and see if it happens still. If it is persistent, contact net@. Anyone can help? should this one be looked into? How can I try to debut it more? Thanks in advance! -- Guido Falsi m...@madpilot.net ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: LOR on head using virtualbox between intel kms and sound, with system lockup
On 12/10/14 09:52, Konstantin Belousov wrote: On Tue, Dec 09, 2014 at 11:39:57PM +0100, Guido Falsi wrote: Lock order reversal: (sleepable after non-sleepable) 1st 0xf8000874da90 so_snd (so_snd) @ /usr/src/sys/kern/uipc_sockbuf.c:666 2nd 0xf80057ff20a0 drmslk (drmslk) @ /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_display.c:2317 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe022ed8eff0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe022ed8f0a0 witness_checkorder() at witness_checkorder+x0dad/frame 0xfe022ed8f130 _sx_xlock() at _sx_xlock+0x71/frame 0xfe022ed8f170 intel_pipe_set_base() at intel_pipe_set_base+0x77/frame 0xfe022ed8f1d8 drm_crtc_helper_set_config() at drm_crtc_helper_set_config+0x7c0/frame 0xfe022ed8f290 vt_kms_postswitch() at vt_kms_postswitch+0x5c/frame 0xfe022ed8f2c0 vt_window_switch() at vt_window_switch+0xc3/frame 0xfe022ed8f300 vtterm_cngrab() at vtterm_cngrab+0x23/frame 0xfe022ed8f320 cngrab() at cngrab+0x35/frame 0xfe022ed8f340 kdb_trap() at kdb_trap+0x183/frame 0xfe022ed8f3e0 trap_fatal() at ytap_fatal+0x34c/frame 0xfe022ed8f440 trap_pfault() at trap_pfault+0x262/frame 0xfe022ed8f4a0 trap() at trap+0x44c/frame 0xfe022ed8f5f0 calltrap() at calltrap+0x8/frame 0xfe022ed8f5f0 --- trap 0xc, tip = 0x8056834d, rsp = 0xfe022ed8f6b0, rbp = 0xfe022ed8f6e0 --- sbappendstream_locked() at sbappendstream_locked+0x2d/frame 0xfe022ed8f6e0 sbappendstream() at sbappendstream+0x3c/frame 0xfe022ed8f710 tcp_usr_send() at tcp_usr_send+0x1ab/frame 0xfe022ed8f790 sosend_generic() at sosend_generic+0x40b/frame 0xfe022ed8f850 kern_sendit() at kern_sendit+0x19e/frame 0xfe022ed8f900 sendit() at sendit+0x129/frame 0xfe022ed8f950 sys_sendto() at sys_sendto+0x4d/frame 0xfe022ed8f9a0 amd64_syscall() at amd64_syscall+0x211/frame 0xfe022ed8fab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe022ed8fab0 --- syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x80126c5a, rsp = 0x7fffdf1e9df8, rbp = 0x7fffdf1e9e40 --- Please note that this is the last one, but at least another one, almost identical to this one, was scrolled up. I've been unable to recover their data, since, as I said the system is hard locked and did not even write them to any system log. This is plain fault, in network stack, in the tcp send path. It has nothing to do with sound at all, and the LOR between DRM device lock and send buffer socket lock is a consequence of drm activated when panic occured in the locked region. That said, first thing to do when you experience panic with vbox or fuse modules loaded, is to remove the modules and see if it happens still. If it is persistent, contact net@. I see. Problem with removing the virtualbox module is I have been able to trigger the panic only by starting the VBox VM. I have no idea how to trigger it some other way. I'll try though. Thanks for the insight! -- Guido Falsi m...@madpilot.net ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
LOR on head using virtualbox between intel kms and sound, with system lockup
Hi, I've experienced a hard lockup on head r275563, amd64. The hardware is a laptop with an intel graphics card. If any further info is required just ask. I had just launched a virtualbox VM with Windows 7, the system locked up just after the startup sound was played in the VM, X11 disappeared and the system locked hard and a LOR data on screen. (I already tested recompiling the virtualbox kmod and the bug shows up with and without 3d/2d acceleration enabled in the VM) I copied (by hand, so sorry for any typos) the LOR data: Lock order reversal: (sleepable after non-sleepable) 1st 0xf8000874da90 so_snd (so_snd) @ /usr/src/sys/kern/uipc_sockbuf.c:666 2nd 0xf80057ff20a0 drmslk (drmslk) @ /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_display.c:2317 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe022ed8eff0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe022ed8f0a0 witness_checkorder() at witness_checkorder+x0dad/frame 0xfe022ed8f130 _sx_xlock() at _sx_xlock+0x71/frame 0xfe022ed8f170 intel_pipe_set_base() at intel_pipe_set_base+0x77/frame 0xfe022ed8f1d8 drm_crtc_helper_set_config() at drm_crtc_helper_set_config+0x7c0/frame 0xfe022ed8f290 vt_kms_postswitch() at vt_kms_postswitch+0x5c/frame 0xfe022ed8f2c0 vt_window_switch() at vt_window_switch+0xc3/frame 0xfe022ed8f300 vtterm_cngrab() at vtterm_cngrab+0x23/frame 0xfe022ed8f320 cngrab() at cngrab+0x35/frame 0xfe022ed8f340 kdb_trap() at kdb_trap+0x183/frame 0xfe022ed8f3e0 trap_fatal() at ytap_fatal+0x34c/frame 0xfe022ed8f440 trap_pfault() at trap_pfault+0x262/frame 0xfe022ed8f4a0 trap() at trap+0x44c/frame 0xfe022ed8f5f0 calltrap() at calltrap+0x8/frame 0xfe022ed8f5f0 --- trap 0xc, tip = 0x8056834d, rsp = 0xfe022ed8f6b0, rbp = 0xfe022ed8f6e0 --- sbappendstream_locked() at sbappendstream_locked+0x2d/frame 0xfe022ed8f6e0 sbappendstream() at sbappendstream+0x3c/frame 0xfe022ed8f710 tcp_usr_send() at tcp_usr_send+0x1ab/frame 0xfe022ed8f790 sosend_generic() at sosend_generic+0x40b/frame 0xfe022ed8f850 kern_sendit() at kern_sendit+0x19e/frame 0xfe022ed8f900 sendit() at sendit+0x129/frame 0xfe022ed8f950 sys_sendto() at sys_sendto+0x4d/frame 0xfe022ed8f9a0 amd64_syscall() at amd64_syscall+0x211/frame 0xfe022ed8fab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe022ed8fab0 --- syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x80126c5a, rsp = 0x7fffdf1e9df8, rbp = 0x7fffdf1e9e40 --- Please note that this is the last one, but at least another one, almost identical to this one, was scrolled up. I've been unable to recover their data, since, as I said the system is hard locked and did not even write them to any system log. Anyone can help? should this one be looked into? How can I try to debut it more? Thanks in advance! -- Guido Falsi m...@madpilot.net ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
LOR on head ...
Not sure if this is a known issue since I don't usually use UFS. Yesterday I put current on an acer laptop with an i3 processor/4GB RAM with UFS file system on a OCZ vertex 2 SSD and trim enabled via tunefs. Below is the dmesg along with the LOR message at the bottom. I can provide more information if it is helpful. Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #0: Sun Aug 4 16:54:51 UTC 2013 r...@beam.macktronics.com:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Core(TM) i3-2370M CPU @ 2.40GHz (2394.61-MHz K8-class CPU) Origin = GenuineIntel Id = 0x206a7 Family = 0x6 Model = 0x2a Stepping = 7 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x1dbae3bfSSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,XSAVE,OSXSAVE,AVX AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 3785801728 (3610 MB) Event timer LAPIC quality 600 ACPI APIC Table: ACRSYS ACRPRDCT FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: ACRSYS ACRPRDCT on motherboard acpi0: Power Button (fixed) cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 950 Event timer HPET frequency 14318180 Hz quality 550 Event timer HPET1 frequency 14318180 Hz quality 440 Event timer HPET2 frequency 14318180 Hz quality 440 Event timer HPET3 frequency 14318180 Hz quality 440 Event timer HPET4 frequency 14318180 Hz quality 440 atrtc0: AT realtime clock port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. Event timer RTC frequency 32768 Hz quality 0 attimer0: AT timer port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 acpi_ec0: Embedded Controller: GPE 0x17 port 0x62,0x66 on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 vgapci0: VGA-compatible display port 0x2000-0x203f mem 0xc000-0xc03f,0xb000-0xbfff irq 16 at device 2.0 on pci0 agp0: SandyBridge mobile GT2 IG on vgapci0 agp0: aperture size is 256M, detected 131068k stolen memory pci0: simple comms at device 22.0 (no driver attached) ehci0: Intel Panther Point USB 2.0 controller mem 0xc0609000-0xc06093ff irq 16 at device 26.0 on pci0 usbus0: EHCI version 1.0 usbus0 on ehci0 hdac0: Intel Panther Point HDA Controller mem 0xc060-0xc0603fff irq 22 at device 27.0 on pci0 pcib1: ACPI PCI-PCI bridge irq 17 at device 28.0 on pci0 pci2: ACPI PCI bus on pcib1 bge0: Broadcom BCM57765 B0, ASIC rev. 0x57785100 mem 0xc043-0xc043,0xc044-0xc044 irq 16 at device 0.0 on pci2 bge0: CHIP ID 0x57785100; ASIC REV 0x57785; CHIP REV 0x577851; PCI-E miibus0: MII bus on bge0 brgphy0: BCM57765 1000BASE-T media interface PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: dc:0e:a1:b1:e8:d4 sdhci_pci0: Generic SD HCI mem 0xc040-0xc040 irq 17 at device 0.1 on pci2 sdhci_pci0: 1 slot(s) allocated pci2: base peripheral at device 0.2 (no driver attached) pci2: base peripheral at device 0.3 (no driver attached) pcib2: ACPI PCI-PCI bridge irq 16 at device 28.1 on pci0 pci3: ACPI PCI bus on pcib2 ath0: Atheros AR9485 mem 0xc050-0xc057 irq 17 at device 0.0 on pci3 ar9300_set_stub_functions: setting stub functions ar9300_set_stub_functions: setting stub functions ar9300_attach: calling ar9300_hw_attach ar9300_hw_attach: calling ar9300_eeprom_attach ar9300_flash_map: unimplemented for now Restoring Cal data from DRAM Restoring Cal data from EEPROM Restoring Cal data from Flash Restoring Cal data from Flash Restoring Cal data from OTP ar9300_hw_attach: ar9300_eeprom_attach returned 0 ath0: RX status length: 48 ath0: RX buffer size: 4096 ath0: TX descriptor length: 128 ath0: TX status length: 36 ath0: TX buffers per descriptor: 4 ar9300_freebsd_setup_x_tx_desc: called, 0x0/0, 0x0/0, 0x0/0
Re: LOR on head ...
I am going to respond to this before I forget I had the SAME exact LOR's with ath 9300 and I reported them, however I have since switched out motherboards and the LOR's have strangely diapered here is a full dmesg for a perfectly working system FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 CPU: AMD FX(tm)-4100 Quad-Core Processor (3600.30-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x600f12 Family = 0x15 Model = 0x1 Stepping = 2 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x1e98220bSSE3,PCLMULQDQ,MON,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AESNI,XSAVE,OSXSAVE,AVX AMD Features=0x2e500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM AMD Features2=0x1c9bfffLAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,XOP,SKINIT,WDT,LWP,FMA4,NodeId,Topology,b23,b24 TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) avail memory = 7868518400 (7504 MB) Event timer LAPIC quality 400 ACPI APIC Table: ALASKA A M I FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 17 cpu2 (AP): APIC ID: 18 cpu3 (AP): APIC ID: 19 ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has zero address or length: 0x/0x1 (20130725/tbfadt-630) ioapic0 Version 2.1 irqs 0-23 on motherboard ioapic1 Version 2.1 irqs 24-55 on motherboard kbd1 at kbdmux0 acpi0: ALASKA A M I on motherboard acpi0: Power Button (fixed) cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 attimer0: AT timer port 0x40-0x43 irq 0 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 atrtc0: AT realtime clock port 0x70-0x71 irq 8 on acpi0 Event timer RTC frequency 32768 Hz quality 0 hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 950 Event timer HPET frequency 14318180 Hz quality 450 Event timer HPET1 frequency 14318180 Hz quality 450 Event timer HPET2 frequency 14318180 Hz quality 450 Timecounter ACPI-safe frequency 3579545 Hz quality 850 acpi_timer0: 32-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_ec0: Embedded Controller: GPE 0xa port 0x62,0x66 on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: base peripheral at device 0.2 (no driver attached) pcib1: ACPI PCI-PCI bridge irq 52 at device 2.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible display mem 0xfd00-0xfdff,0xc000-0xcfff,0xfc00-0xfcff irq 24 at device 0.0 on pci1 pcib2: ACPI PCI-PCI bridge irq 52 at device 4.0 on pci0 pci2: ACPI PCI bus on pcib2 re0: RealTek 8168/8111 B/C/CP/D/DP/E/F PCIe Gigabit Ethernet port 0xe000-0xe0ff mem 0xd0004000-0xd0004fff,0xd000-0xd0003fff irq 44 at device 0.0 on pci2 re0: Using 1 MSI-X message re0: Chip rev. 0x4800 re0: MAC rev. 0x miibus0: MII bus on re0 rgephy0: RTL8169S/8110S/8211 1000BASE-T media interface PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 60:a4:4c:57:02:c4 pcib3: ACPI PCI-PCI bridge irq 52 at device 5.0 on pci0 pci3: ACPI PCI bus on pcib3 xhci0: ASMedia ASM1042 USB 3.0 controller mem 0xfe40-0xfe407fff irq 46 at device 0.0 on pci3 xhci0: 32 byte context size. usbus0 on xhci0 pcib4: ACPI PCI-PCI bridge irq 53 at device 7.0 on pci0 pci4: ACPI PCI bus on pcib4 xhci1: ASMedia ASM1042 USB 3.0 controller mem 0xfe30-0xfe307fff irq 50 at device 0.0 on pci4 xhci1: 32 byte context size. usbus1 on xhci1 pcib5: ACPI PCI-PCI bridge irq 53 at device 9.0 on pci0 pci5: ACPI PCI bus on pcib5 ath0: Atheros AR938x mem 0xfe20-0xfe21 irq 48 at device 0.0 on pci5 ar9300_set_stub_functions: setting stub functions ar9300_set_stub_functions: setting stub functions ar9300_attach: calling ar9300_hw_attach ar9300_hw_attach: calling ar9300_eeprom_attach ar9300_flash_map: unimplemented for now Restoring Cal data from DRAM Restoring Cal data from EEPROM ar9300_hw_attach: ar9300_eeprom_attach returned 0 ath0: RX status length: 48 ath0: RX buffer size: 4096 ath0: TX descriptor length: 128 ath0: TX status length: 36 ath0: TX buffers per descriptor: 4 ar9300_freebsd_setup_x_tx_desc: called, 0x0/0, 0x0/0, 0x0/0 ath0: ath_edma_setup_rxfifo: type=0, FIFO depth = 16 entries ath0: ath_edma_setup_rxfifo: type=1, FIFO depth = 128 entries ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 stream STBC transmit enabled ath0: [HT] 3 RX streams; 3 TX streams ath0: AR9380 mac 448.3 RF5110 phy 0.0 ath0: 2GHz radio: 0x; 5GHz radio: 0x ahci0: ATI IXP700 AHCI SATA controller port
Re: LOR on head ...
On Mon, Aug 5, 2013 at 4:24 PM, Sam Fourman Jr. sfour...@gmail.com wrote: I am going to respond to this before I forget I had the SAME exact LOR's with ath 9300 and I reported them, however I have since switched out motherboards and the LOR's have strangely diapered here is a full dmesg for a perfectly working system FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 CPU: AMD FX(tm)-4100 Quad-Core Processor (3600.30-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x600f12 Family = 0x15 Model = 0x1 Stepping = 2 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x1e98220bSSE3,PCLMULQDQ,MON,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AESNI,XSAVE,OSXSAVE,AVX AMD Features=0x2e500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM AMD Features2=0x1c9bfffLAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,XOP,SKINIT,WDT,LWP,FMA4,NodeId,Topology,b23,b24 TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) avail memory = 7868518400 (7504 MB) Event timer LAPIC quality 400 ACPI APIC Table: ALASKA A M I FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 17 cpu2 (AP): APIC ID: 18 cpu3 (AP): APIC ID: 19 ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has zero address or length: 0x/0x1 (20130725/tbfadt-630) ioapic0 Version 2.1 irqs 0-23 on motherboard ioapic1 Version 2.1 irqs 24-55 on motherboard kbd1 at kbdmux0 acpi0: ALASKA A M I on motherboard acpi0: Power Button (fixed) cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 attimer0: AT timer port 0x40-0x43 irq 0 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 atrtc0: AT realtime clock port 0x70-0x71 irq 8 on acpi0 Event timer RTC frequency 32768 Hz quality 0 hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 950 Event timer HPET frequency 14318180 Hz quality 450 Event timer HPET1 frequency 14318180 Hz quality 450 Event timer HPET2 frequency 14318180 Hz quality 450 Timecounter ACPI-safe frequency 3579545 Hz quality 850 acpi_timer0: 32-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_ec0: Embedded Controller: GPE 0xa port 0x62,0x66 on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: base peripheral at device 0.2 (no driver attached) pcib1: ACPI PCI-PCI bridge irq 52 at device 2.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible display mem 0xfd00-0xfdff,0xc000-0xcfff,0xfc00-0xfcff irq 24 at device 0.0 on pci1 pcib2: ACPI PCI-PCI bridge irq 52 at device 4.0 on pci0 pci2: ACPI PCI bus on pcib2 re0: RealTek 8168/8111 B/C/CP/D/DP/E/F PCIe Gigabit Ethernet port 0xe000-0xe0ff mem 0xd0004000-0xd0004fff,0xd000-0xd0003fff irq 44 at device 0.0 on pci2 re0: Using 1 MSI-X message re0: Chip rev. 0x4800 re0: MAC rev. 0x miibus0: MII bus on re0 rgephy0: RTL8169S/8110S/8211 1000BASE-T media interface PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 60:a4:4c:57:02:c4 pcib3: ACPI PCI-PCI bridge irq 52 at device 5.0 on pci0 pci3: ACPI PCI bus on pcib3 xhci0: ASMedia ASM1042 USB 3.0 controller mem 0xfe40-0xfe407fff irq 46 at device 0.0 on pci3 xhci0: 32 byte context size. usbus0 on xhci0 pcib4: ACPI PCI-PCI bridge irq 53 at device 7.0 on pci0 pci4: ACPI PCI bus on pcib4 xhci1: ASMedia ASM1042 USB 3.0 controller mem 0xfe30-0xfe307fff irq 50 at device 0.0 on pci4 xhci1: 32 byte context size. usbus1 on xhci1 pcib5: ACPI PCI-PCI bridge irq 53 at device 9.0 on pci0 pci5: ACPI PCI bus on pcib5 ath0: Atheros AR938x mem 0xfe20-0xfe21 irq 48 at device 0.0 on pci5 ar9300_set_stub_functions: setting stub functions ar9300_set_stub_functions: setting stub functions ar9300_attach: calling ar9300_hw_attach ar9300_hw_attach: calling ar9300_eeprom_attach ar9300_flash_map: unimplemented for now Restoring Cal data from DRAM Restoring Cal data from EEPROM ar9300_hw_attach: ar9300_eeprom_attach returned 0 ath0: RX status length: 48 ath0: RX buffer size: 4096 ath0: TX descriptor length: 128 ath0: TX status length: 36 ath0: TX buffers per descriptor: 4 ar9300_freebsd_setup_x_tx_desc: called, 0x0/0, 0x0/0, 0x0/0 ath0: ath_edma_setup_rxfifo: type=0, FIFO depth = 16 entries ath0: ath_edma_setup_rxfifo: type=1, FIFO depth = 128 entries ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 stream STBC transmit
Re: LOR on head ...
On Mon, 5 Aug 2013, Davide Italiano wrote: The LOR is a false positive. See the comment in sys/ufs/ufs/ufs_dirhash.c Also, switching motherboards is not related to this in any way. You'll eventually hit that LOR report, unless you disabled WITNESS. Ah, thank you Davide; sorry for the noise ... I've been using only ZFS for so long that I haven't run across this yet. I'm also getting these too which appear to be the same sort of thing, no? lock order reversal: 1st 0xfe010157d418 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2099 2nd 0xff80ec37fa78 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:262 3rd 0xfe010157b9a0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2099 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xff81166cecb0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xff81166ced60 witness_checkorder() at witness_checkorder+0xd4f/frame 0xff81166cedf0 __lockmgr_args() at __lockmgr_args+0x6f2/frame 0xff81166cef20 ffs_lock() at ffs_lock+0x84/frame 0xff81166cef70 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xff81166cefa0 _vn_lock() at _vn_lock+0xab/frame 0xff81166cf010 vget() at vget+0x70/frame 0xff81166cf060 vfs_hash_get() at vfs_hash_get+0xf5/frame 0xff81166cf0b0 ffs_vgetf() at ffs_vgetf+0x41/frame 0xff81166cf140 softdep_sync_buf() at softdep_sync_buf+0x8fa/frame 0xff81166cf1f0 ffs_syncvnode() at ffs_syncvnode+0x258/frame 0xff81166cf270 ffs_truncate() at ffs_truncate+0x5ca/frame 0xff81166cf450 ufs_direnter() at ufs_direnter+0x891/frame 0xff81166cf510 ufs_makeinode() at ufs_makeinode+0x573/frame 0xff81166cf6d0 VOP_CREATE_APV() at VOP_CREATE_APV+0xea/frame 0xff81166cf700 vn_open_cred() at vn_open_cred+0x300/frame 0xff81166cf850 kern_openat() at kern_openat+0x1f5/frame 0xff81166cf9a0 amd64_syscall() at amd64_syscall+0x265/frame 0xff81166cfab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xff81166cfab0 --- syscall (5, FreeBSD ELF64, sys_open), rip = 0x80093d3ea, rsp = 0x7fffd758, rbp = 0x7fffd7b0 --- dan -- Dan Mack ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
