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
Kernel now detecting cpu core faults? Two thumbs up.
My CPU shows as: AMD Phenom II X4 B60 Processor (3671.47-MHz), But in fact it's an X3-B60, with the 4th core unlocked by the BIOS. I was running poudriere today and dmesg gave this message: MCA: Bank 1, Status 0x94000151 MCA: Global Cap 0x0106, Status 0x MCA: Vendor AuthenticAMD, ID 0x100f53, APIC ID 3 MCA: CPU 3 COR ICACHE L1 IRD error MCA: Address 0x801cb2ca0 That's just awesome! The kernel now warns of problems on faulty core (which is why my CPU is an X4, priced and sold as X3). #2 r275010 -- FreeBSD_amd64_11-Current_RadeonKMS ___ 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
Build failed in Jenkins: Build-UFS-image #635
See https://jenkins.freebsd.org/job/Build-UFS-image/635/ -- [...truncated 8759 lines...] if [ -L https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/fs/nfs ]; then rm -f https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/fs/nfs; fi if [ -L https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/fs/nullfs ]; then rm -f https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/fs/nullfs; fi if [ -L https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/fs/procfs ]; then rm -f https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/fs/procfs; fi if [ -L https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/fs/smbfs ]; then rm -f https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/fs/smbfs; fi if [ -L https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/fs/udf ]; then rm -f https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/fs/udf; fi if [ -L https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/fs/unionfs ]; then rm -f https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/fs/unionfs; fi if [ -L https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/geom/cache ]; then rm -f https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/geom/cache; fi if [ -L https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/geom/concat ]; then rm -f https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/geom/concat; fi if [ -L https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/geom/eli ]; then rm -f https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/geom/eli; fi if [ -L https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/geom/gate ]; then rm -f https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/geom/gate; fi if [ -L https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/geom/journal ]; then rm -f https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/geom/journal; fi if [ -L https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/geom/label ]; then rm -f https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/geom/label; fi if [ -L https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/geom/mirror ]; then rm -f https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/geom/mirror; fi if [ -L https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/geom/mountver ]; then rm -f https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/geom/mountver; fi if [ -L https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/geom/multipath ]; then rm -f https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/geom/multipath; fi if [ -L https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/geom/nop ]; then rm -f https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/geom/nop; fi if [ -L https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/geom/raid ]; then rm -f https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/geom/raid; fi if [ -L https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/geom/raid3 ]; then rm -f https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/geom/raid3; fi if [ -L https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/geom/shsec ]; then rm -f https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/geom/shsec; fi if [ -L https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/geom/stripe ]; then rm -f https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/geom/stripe; fi if [ -L https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/geom/virstor ]; then rm -f https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/geom/virstor; fi if [ -L https://jenkins.freebsd.org/job/Build-UFS-image/ws/package/FreeBSD_HEAD/usr/include/netgraph/atm ]; then rm -f
Jenkins build is back to normal : Build-UFS-image #636
See https://jenkins.freebsd.org/job/Build-UFS-image/636/ ___ 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
nvidia-driver fails to load gui
Hey All, More new laptop woes. The good-ish news is that the VESA driver works, but x11/nvidia-driver doesn't. I'm on a Lenovo Y50-70. When I run `startx`, it appears that xorg switches to a new vty, but doesn't actually bring up the UI. I see a new console (as in vty) with a cursor at the top left corner. xorg.conf is pasted here: http://ix.io/1Dr Xorg.0.log is pasted here: http://ix.io/1Dq I'll just use the VESA driver for now, but it'd be nice to be able to hook the laptop up to a second monitor or a projector, which I can't do with the VESA driver. Thanks, Shawn ___ 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: nvidia-driver fails to load gui
On Wed, Dec 10, 2014 at 11:02 AM, Shawn Webb latt...@gmail.com wrote: Hey All, More new laptop woes. The good-ish news is that the VESA driver works, but x11/nvidia-driver doesn't. I'm on a Lenovo Y50-70. When I run `startx`, it appears that xorg switches to a new vty, but doesn't actually bring up the UI. I see a new console (as in vty) with a cursor at the top left corner. xorg.conf is pasted here: http://ix.io/1Dr Xorg.0.log is pasted here: http://ix.io/1Dq I'll just use the VESA driver for now, but it'd be nice to be able to hook the laptop up to a second monitor or a projector, which I can't do with the VESA driver. Is it an optimus laptop? Have you tried uninstalling nvidia driver and try the intel driver? Thanks, Shawn ___ 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 -- Cheers, Henry ___ 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: nvidia-driver fails to load gui
On Wed, Dec 10, 2014 at 11:14 AM, Henry Hu henry.hu...@gmail.com wrote: On Wed, Dec 10, 2014 at 11:02 AM, Shawn Webb latt...@gmail.com wrote: Hey All, More new laptop woes. The good-ish news is that the VESA driver works, but x11/nvidia-driver doesn't. I'm on a Lenovo Y50-70. When I run `startx`, it appears that xorg switches to a new vty, but doesn't actually bring up the UI. I see a new console (as in vty) with a cursor at the top left corner. xorg.conf is pasted here: http://ix.io/1Dr Xorg.0.log is pasted here: http://ix.io/1Dq I'll just use the VESA driver for now, but it'd be nice to be able to hook the laptop up to a second monitor or a projector, which I can't do with the VESA driver. Is it an optimus laptop? Have you tried uninstalling nvidia driver and try the intel driver? It's a Lenovo Y50-70, which is running Intel Haswell, so the intel driver won't work. Thanks, Shawn ___ 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: nvidia-driver fails to load gui
On Wed, Dec 10, 2014 at 11:17 AM, Shawn Webb latt...@gmail.com wrote: On Wed, Dec 10, 2014 at 11:14 AM, Henry Hu henry.hu...@gmail.com wrote: On Wed, Dec 10, 2014 at 11:02 AM, Shawn Webb latt...@gmail.com wrote: Hey All, More new laptop woes. The good-ish news is that the VESA driver works, but x11/nvidia-driver doesn't. I'm on a Lenovo Y50-70. When I run `startx`, it appears that xorg switches to a new vty, but doesn't actually bring up the UI. I see a new console (as in vty) with a cursor at the top left corner. xorg.conf is pasted here: http://ix.io/1Dr Xorg.0.log is pasted here: http://ix.io/1Dq I'll just use the VESA driver for now, but it'd be nice to be able to hook the laptop up to a second monitor or a projector, which I can't do with the VESA driver. Is it an optimus laptop? Have you tried uninstalling nvidia driver and try the intel driver? It's a Lenovo Y50-70, which is running Intel Haswell, so the intel driver won't work. I'm afrad that the nvidia card would not work either, at least for the internal LCD. Some optimus cards only provide 3d acceleration, and some are only connected to HDMI/DisplayPort outputs. Have you tried other outputs on the laptop? Thanks, Shawn -- Cheers, Henry ___ 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: nvidia-driver fails to load gui
On Wed, Dec 10, 2014 at 11:22 AM, Henry Hu henry.hu...@gmail.com wrote: On Wed, Dec 10, 2014 at 11:17 AM, Shawn Webb latt...@gmail.com wrote: On Wed, Dec 10, 2014 at 11:14 AM, Henry Hu henry.hu...@gmail.com wrote: On Wed, Dec 10, 2014 at 11:02 AM, Shawn Webb latt...@gmail.com wrote: Hey All, More new laptop woes. The good-ish news is that the VESA driver works, but x11/nvidia-driver doesn't. I'm on a Lenovo Y50-70. When I run `startx`, it appears that xorg switches to a new vty, but doesn't actually bring up the UI. I see a new console (as in vty) with a cursor at the top left corner. xorg.conf is pasted here: http://ix.io/1Dr Xorg.0.log is pasted here: http://ix.io/1Dq I'll just use the VESA driver for now, but it'd be nice to be able to hook the laptop up to a second monitor or a projector, which I can't do with the VESA driver. Is it an optimus laptop? Have you tried uninstalling nvidia driver and try the intel driver? It's a Lenovo Y50-70, which is running Intel Haswell, so the intel driver won't work. I'm afrad that the nvidia card would not work either, at least for the internal LCD. Some optimus cards only provide 3d acceleration, and some are only connected to HDMI/DisplayPort outputs. Have you tried other outputs on the laptop? I haven't tried the other outputs. My primary output will be the internal LCD. What would it take to get it to work? ___ 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: nvidia-driver fails to load gui
On Wed, Dec 10, 2014 at 11:25 AM, Shawn Webb latt...@gmail.com wrote: On Wed, Dec 10, 2014 at 11:22 AM, Henry Hu henry.hu...@gmail.com wrote: On Wed, Dec 10, 2014 at 11:17 AM, Shawn Webb latt...@gmail.com wrote: On Wed, Dec 10, 2014 at 11:14 AM, Henry Hu henry.hu...@gmail.com wrote: On Wed, Dec 10, 2014 at 11:02 AM, Shawn Webb latt...@gmail.com wrote: Hey All, More new laptop woes. The good-ish news is that the VESA driver works, but x11/nvidia-driver doesn't. I'm on a Lenovo Y50-70. When I run `startx`, it appears that xorg switches to a new vty, but doesn't actually bring up the UI. I see a new console (as in vty) with a cursor at the top left corner. xorg.conf is pasted here: http://ix.io/1Dr Xorg.0.log is pasted here: http://ix.io/1Dq I'll just use the VESA driver for now, but it'd be nice to be able to hook the laptop up to a second monitor or a projector, which I can't do with the VESA driver. Is it an optimus laptop? Have you tried uninstalling nvidia driver and try the intel driver? It's a Lenovo Y50-70, which is running Intel Haswell, so the intel driver won't work. I'm afrad that the nvidia card would not work either, at least for the internal LCD. Some optimus cards only provide 3d acceleration, and some are only connected to HDMI/DisplayPort outputs. Have you tried other outputs on the laptop? I haven't tried the other outputs. My primary output will be the internal LCD. What would it take to get it to work? Wait for the kernel driver update which would support Haswell graphics? -- Cheers, Henry ___ 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: nvidia-driver fails to load gui
On Wed, Dec 10, 2014 at 11:27 AM, Henry Hu henry.hu...@gmail.com wrote: On Wed, Dec 10, 2014 at 11:25 AM, Shawn Webb latt...@gmail.com wrote: On Wed, Dec 10, 2014 at 11:22 AM, Henry Hu henry.hu...@gmail.com wrote: On Wed, Dec 10, 2014 at 11:17 AM, Shawn Webb latt...@gmail.com wrote: On Wed, Dec 10, 2014 at 11:14 AM, Henry Hu henry.hu...@gmail.com wrote: On Wed, Dec 10, 2014 at 11:02 AM, Shawn Webb latt...@gmail.com wrote: Hey All, More new laptop woes. The good-ish news is that the VESA driver works, but x11/nvidia-driver doesn't. I'm on a Lenovo Y50-70. When I run `startx`, it appears that xorg switches to a new vty, but doesn't actually bring up the UI. I see a new console (as in vty) with a cursor at the top left corner. xorg.conf is pasted here: http://ix.io/1Dr Xorg.0.log is pasted here: http://ix.io/1Dq I'll just use the VESA driver for now, but it'd be nice to be able to hook the laptop up to a second monitor or a projector, which I can't do with the VESA driver. Is it an optimus laptop? Have you tried uninstalling nvidia driver and try the intel driver? It's a Lenovo Y50-70, which is running Intel Haswell, so the intel driver won't work. I'm afrad that the nvidia card would not work either, at least for the internal LCD. Some optimus cards only provide 3d acceleration, and some are only connected to HDMI/DisplayPort outputs. Have you tried other outputs on the laptop? I haven't tried the other outputs. My primary output will be the internal LCD. What would it take to get it to work? Wait for the kernel driver update which would support Haswell graphics? Who's in charge of that? I've pinged kib@ privately with no reply. Is there a patchset that I can help test out on 11-current? What's the status? I'd love to help get the Haswell update out the door, especially now that I have multiple systems running Haswell. ___ 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: nvidia-driver fails to load gui
Hi, On Wed, Dec 10, 2014 at 5:31 PM, Shawn Webb latt...@gmail.com wrote: On Wed, Dec 10, 2014 at 11:27 AM, Henry Hu henry.hu...@gmail.com wrote: On Wed, Dec 10, 2014 at 11:25 AM, Shawn Webb latt...@gmail.com wrote: On Wed, Dec 10, 2014 at 11:22 AM, Henry Hu henry.hu...@gmail.com wrote: On Wed, Dec 10, 2014 at 11:17 AM, Shawn Webb latt...@gmail.com wrote: On Wed, Dec 10, 2014 at 11:14 AM, Henry Hu henry.hu...@gmail.com wrote: On Wed, Dec 10, 2014 at 11:02 AM, Shawn Webb latt...@gmail.com wrote: Hey All, More new laptop woes. The good-ish news is that the VESA driver works, but x11/nvidia-driver doesn't. I'm on a Lenovo Y50-70. When I run `startx`, it appears that xorg switches to a new vty, but doesn't actually bring up the UI. I see a new console (as in vty) with a cursor at the top left corner. xorg.conf is pasted here: http://ix.io/1Dr Xorg.0.log is pasted here: http://ix.io/1Dq I'll just use the VESA driver for now, but it'd be nice to be able to hook the laptop up to a second monitor or a projector, which I can't do with the VESA driver. Is it an optimus laptop? Have you tried uninstalling nvidia driver and try the intel driver? It's a Lenovo Y50-70, which is running Intel Haswell, so the intel driver won't work. I'm afrad that the nvidia card would not work either, at least for the internal LCD. Some optimus cards only provide 3d acceleration, and some are only connected to HDMI/DisplayPort outputs. Have you tried other outputs on the laptop? I haven't tried the other outputs. My primary output will be the internal LCD. What would it take to get it to work? Wait for the kernel driver update which would support Haswell graphics? Who's in charge of that? I've pinged kib@ privately with no reply. Is there a patchset that I can help test out on 11-current? What's the status? I'd love to help get the Haswell update out the door, especially now that I have multiple systems running Haswell. you may be aware, there was https://lists.freebsd.org/pipermail/freebsd-current/2014-October/052532.html (and v2 of the patch) from kib@ that I and others gave a spin. The second version worked fine for me (including xorg-experimental repo w/ the Intel 3.0beta driver). Note however that this does not really include Haswell support according to kib@ but he seems to run it on a Haswell system. Maybe this helps? Other than that, I have heard to news (and I am eager to test...). HTH Johannes ___ 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 if_addr_lock/ifnet_rw
Hi, I got that LOR few minutes ago: lock order reversal: 1st 0xf800094f4990 if_addr_lock (if_addr_lock) @ /usr/src/sys/netinet/igmp.c:1716 2nd 0x818800d0 ifnet_rw (ifnet_rw) @ /usr/src/sys/net/if.c:243 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe01dd5964b0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe01dd596560 witness_checkorder() at witness_checkorder+0xdad/frame 0xfe01dd5965f0 __rw_rlock() at __rw_rlock+0x9a/frame 0xfe01dd596690 ifnet_byindex() at ifnet_byindex+0x22/frame 0xfe01dd5966b0 igmp_intr() at igmp_intr+0x1f/frame 0xfe01dd596730 netisr_dispatch_src() at netisr_dispatch_src+0x86/frame 0xfe01dd5967a0 igmp_v1v2_queue_report() at igmp_v1v2_queue_report+0x186/frame 0xfe01dd5967e0 igmp_fasttimo() at igmp_fasttimo+0x3ee/frame 0xfe01dd5968c0 pffasttimo() at pffasttimo+0x54/frame 0xfe01dd5968f0 softclock_call_cc() at softclock_call_cc+0x19c/frame 0xfe01dd5969d0 softclock() at softclock+0x47/frame 0xfe01dd5969f0 intr_event_execute_handlers() at intr_event_execute_handlers+0x93/frame 0xfe01dd596a30 ithread_loop() at ithread_loop+0xa6/frame 0xfe01dd596a70 fork_exit() at fork_exit+0x84/frame 0xfe01dd596ab0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe01dd596ab0 --- trap 0, rip = 0, rsp = 0xfe01dd596b70, rbp = 0 --- It caused lost of connectivity for a minute. Other info: FreeBSD darkstar 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r274373: Tue Nov 11 14:23:38 CET 2014 root@darkstar:/usr/obj/usr/src/sys/GENERIC amd64 iwn0: RF switch: radio enabled iwn0: iwn_read_firmware: ucode rev=0x12a80601 iwn0: iwn_read_firmware: ucode rev=0x12a80601 iwn0: iwn_read_firmware: ucode rev=0x12a80601 iwn0: Intel(R) Centrino(R) Wireless-N 2200 BGN mem 0xf2c0-0xf2c01fff irq 17 at device 0.0 on pci3 iwn0: iwn_read_firmware: ucode rev=0x12a80601 -- Kind Regards, Mateusz Kwiatkowski ___ 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
Build failed in Jenkins: FreeBSD_HEAD #2005
See https://jenkins.freebsd.org/job/FreeBSD_HEAD/2005/changes Changes: [ngie] Remove termcap entry reordering; install the file verbatim instead termcap entry reordering requires ex (which is available via usr.bin/vi), which breaks on build hosts where installworld is run with MK_VI == no (or when make delete-old is run on ^/projects/building-blocks as vi, et al, are removed on the branch when the knob is tweaked to = no) Reordering termcap was believed to improve performance, but the file is now accessed via /etc/termcap.db, so /etc/termcap (and /usr/share/misc/termcap by proxy) access is less preferred. Reordering the file broke the historical comment - entry mapping as well, which could muddle the purpose of entries in the file, so it could be potentially harmful to readers in its reordered state. Discussion took place on hackers@ here: https://lists.freebsd.org/pipermail/freebsd-hackers/2014-December/046657.html Discussed with: -hackers, mp MFC after: 1 month Sponsored by: EMC / Isilon Storage Division [andreast] Fix kernel build for booke. -- [...truncated 170971 lines...] ./iso-8859-1_to_cp437.mk iso-8859-1_to_cp437.tmp --- lib.all__D --- --- inflate.po --- cc -pg -O2 -pipe -DHAS_snprintf -DHAS_vsnprintf -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libz -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Qunused-arguments -c https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/lib/libz/inflate.c -o inflate.po --- share.all__D --- uuencode iso-8859-1_to_cp437.tmp iso-8859-1_to_cp437 iso-8859-1_to_cp437.scm rm -f iso-8859-1_to_cp437.tmp --- iso-8859-4_for_vga9.scm --- ./iso-8859-4_for_vga9.mk iso-8859-4_for_vga9.tmp uuencode iso-8859-4_for_vga9.tmp iso-8859-4_for_vga9 iso-8859-4_for_vga9.scm rm -f iso-8859-4_for_vga9.tmp --- iso-8859-7_to_cp437.scm --- ./iso-8859-7_to_cp437.mk iso-8859-7_to_cp437.tmp uuencode iso-8859-7_to_cp437.tmp iso-8859-7_to_cp437 iso-8859-7_to_cp437.scm rm -f iso-8859-7_to_cp437.tmp --- secure.all__D --- --- auth-rhosts.o --- --- share.all__D --- --- koi8-r2cp866.scm --- ./koi8-r2cp866.mk koi8-r2cp866.tmp uuencode koi8-r2cp866.tmp koi8-r2cp866 koi8-r2cp866.scm --- usr.bin.all__D --- --- panic.o --- --- secure.all__D --- cc -O2 -pipe -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/secure/usr.sbin/sshd/../../../crypto/openssh -include ssh_namespace.h -DHAVE_LDNS=1 -DUSE_BSM_AUDIT -DHAVE_GETAUDIT_ADDR -include krb5_config.h -std=gnu99 -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/secure/usr.sbin/sshd/../../../crypto/openssh/auth-rhosts.c --- share.all__D --- rm -f koi8-r2cp866.tmp --- usr.bin.all__D --- cc -O2 -pipe -DATJOB_DIR=\/var/at/jobs/\ -DLFILE=\/var/at/jobs/.lockfile\ -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\/var/at/spool\ -DVERSION=\2.9\ -DDAEMON_UID=1 -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\/var/at/\ -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wno-format -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c https://jenkins.freebsd.org/job/FreeBSD_HEAD/ws/usr.bin/at/panic.c --- share.all__D --- --- koi8-u2cp866u.scm --- ./koi8-u2cp866u.mk koi8-u2cp866u.tmp uuencode koi8-u2cp866u.tmp koi8-u2cp866u koi8-u2cp866u.scm rm -f koi8-u2cp866u.tmp --- us-ascii_to_cp437.scm --- ./us-ascii_to_cp437.mk us-ascii_to_cp437.tmp --- usr.bin.all__D --- --- parsetime.o --- --- share.all__D --- uuencode us-ascii_to_cp437.tmp us-ascii_to_cp437 us-ascii_to_cp437.scm --- usr.bin.all__D --- cc -O2 -pipe -DATJOB_DIR=\/var/at/jobs/\ -DLFILE=\/var/at/jobs/.lockfile\ -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\/var/at/spool\ -DVERSION=\2.9\ -DDAEMON_UID=1 -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\/var/at/\ -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings
Jenkins build is back to normal : FreeBSD_HEAD #2006
See https://jenkins.freebsd.org/job/FreeBSD_HEAD/2006/changes ___ 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
