Re: Ver 2 of the patch [was: Re: i915 driver update testing]
Hi, I finally fired this up on an older Intel to test. this is patch 8 from your website: vgapci0@pci0:0:2:0: class=0x03 card=0x20e417aa chip=0x2a428086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 4 Series Chipset Integrated Graphics Controller' class = display subclass = VGA vgapci1@pci0:0:2:1: class=0x038000 card=0x20e417aa chip=0x2a438086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 4 Series Chipset Integrated Graphics Controller' class = display .. works fine for me. Do you need any further information? I have some other pre-sandybridge devices that I'll spin this up on once they've been updated to the latest -HEAD. Thanks! -adrian ___ 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: Ver 2 of the patch [was: Re: i915 driver update testing]
Nope, spoke too soon: Unread portion of the kernel message buffer: panic: In GPU write domain cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper(c09d59ce,0,c09ad9fe,205,f1ce2938,...) at db_trace_self_wrapper+0x2d/frame 0xf1ce2908 kdb_backtrace(c0a10b67,1,c82fb835,f1ce29f8,f1ce2998,...) at kdb_backtrace+0x30/frame 0xf1ce2970 vpanic(c0b1c868,100,c82fb835,f1ce29f8,5d,...) at vpanic+0x120/frame 0xf1ce29b0 kassert_panic(c82fb835,c7bacd00,346,c95a8700,c95a8fa8,...) at kassert_panic+0x14f/frame 0xf1ce29ec i915_gem_pread_ioctl(c7ab1800,f1ce2b40,c7bacd00,c09c7175,86,...) at i915_gem_pread_ioctl+0x667/frame 0xf1ce2a5c drm_ioctl(c7bacc00,8020645c,f1ce2b40,3,c7e0e000,...) at drm_ioctl+0x213/frame 0xf1ce2aa4 devfs_ioctl_f(c7c135b0,8020645c,f1ce2b40,c7b77200,c7e0e000,...) at devfs_ioctl_f+0x11e/frame 0xf1ce2adc kern_ioctl(c7e0e000,a,8020645c,f1ce2b40,c7e0e000,...) at kern_ioctl+0x2e0/frame 0xf1ce2b18 sys_ioctl(c7e0e000,f1ce2c68,f1ce2bf4,16cc32,2710,...) at sys_ioctl+0x11d/frame 0xf1ce2bd8 syscall(f1ce2ca8) at syscall+0x31a/frame 0xf1ce2c9c Xint0x80_syscall() at Xint0x80_syscall+0x21/frame 0xf1ce2c9c --- syscall (54, FreeBSD ELF32, sys_ioctl), eip = 0x28673fff, esp = 0xbfbfe90c, ebp = 0xbfbfe928 --- (kgdb) #0 doadump (textdump=-1061574304) at pcpu.h:233 #1 0xc04fb4cd in db_fncall (dummy1=-238147896, dummy2=0, dummy3=-951565744, dummy4=0xf1ce26b4 �OR�`���) at /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:568 #2 0xc04fb1bb in db_command (cmd_table=value optimized out) at /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:440 #3 0xc04faee0 in db_command_loop () at /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_command.c:493 #4 0xc04fd97e in db_trap (code=value optimized out) at /usr/home/adrian/work/freebsd/head/src/sys/ddb/db_main.c:251 #5 0xc06d453c in kdb_trap (type=3, code=value optimized out, tf=value optimized out) at /usr/home/adrian/work/freebsd/head/src/sys/kern/subr_kdb.c:654 #6 0xc094ca90 in trap (frame=value optimized out) at /usr/home/adrian/work/freebsd/head/src/sys/i386/i386/trap.c:693 #7 0xc093705c in calltrap () at /usr/home/adrian/work/freebsd/head/src/sys/i386/i386/exception.s:169 #8 0xc06d3dad in kdb_enter (why=0xc09d0b25 panic, msg=value optimized out) at cpufunc.h:71 #9 0xc0696aa4 in vpanic (fmt=value optimized out, ap=value optimized out) at /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_shutdown.c:739 #10 0xc069695f in kassert_panic (fmt=value optimized out) at /usr/home/adrian/work/freebsd/head/src/sys/kern/kern_shutdown.c:634 #11 0xc82b2bd7 in i915_gem_pread_ioctl (dev=0xc09d5a19, data=0xf1ce2b40, file=value optimized out) at /usr/home/adrian/work/freebsd/head/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:3010 #12 0xc8323f53 in drm_ioctl (kdev=0xc7bacc00, cmd=value optimized out, data=value optimized out, flags=3, p=value optimized out) at /usr/home/adrian/work/freebsd/head/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_drv.c:942 #13 0xc057105e in devfs_ioctl_f (fp=value optimized out, com=2149606492, data=value optimized out, cred=value optimized out, td=0xc7e0e000) at /usr/home/adrian/work/freebsd/head/src/sys/fs/devfs/devfs_vnops.c:775 #14 0xc06f6050 in kern_ioctl (td=0x2, fd=value optimized out, com=9, data=value optimized out) at file.h:318 #15 0xc06f5cfd in sys_ioctl (uap=value optimized out) at /usr/home/adrian/work/freebsd/head/src/sys/kern/sys_generic.c:718 #16 0xc094d79a in syscall (frame=value optimized out) at subr_syscall.c:133 #17 0xc09370f1 in Xint0x80_syscall () at /usr/home/adrian/work/freebsd/head/src/sys/i386/i386/exception.s:269 #18 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) .. anything else you'd like? -adrian On 19 January 2015 at 22:00, Adrian Chadd adr...@freebsd.org wrote: Hi, I finally fired this up on an older Intel to test. this is patch 8 from your website: vgapci0@pci0:0:2:0: class=0x03 card=0x20e417aa chip=0x2a428086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 4 Series Chipset Integrated Graphics Controller' class = display subclass = VGA vgapci1@pci0:0:2:1: class=0x038000 card=0x20e417aa chip=0x2a438086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 4 Series Chipset Integrated Graphics Controller' class = display .. works fine for me. Do you need any further information? I have some other pre-sandybridge devices that I'll spin this up on once they've been updated to the latest -HEAD. Thanks! -adrian ___ 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: Ver 2 of the patch [was: Re: i915 driver update testing]
On Mon, Oct 27, 2014 at 12:02:11AM +0300, Chagin Dmitry wrote: On Thu, Oct 23, 2014 at 10:03:29PM +0300, Konstantin Belousov wrote: On Wed, Oct 22, 2014 at 03:59:23PM -0400, Adam McDougall wrote: On 10/22/2014 08:26, Konstantin Belousov wrote: Use https://www.kib.kiev.ua/kib/drm/i915.6.patch. I already have one private report of the patch worked from person who got the same panic in iicbb. Hi, Kostik! i915.6.patch i7-4700. FreeBSD dchagin.static.corbina.net 11.0-CURRENT FreeBSD 11.0-CURRENT #93 r273708+3ca71ce(lemul)-dirty: Sun Oct 26 23:38:47 MSK 2014 r...@dchagin.static.corbina.net:/home/rootobj/home/dchagin/head/sys/YOY amd64 Unread portion of the kernel message buffer: FDI TX state assertion failure (expected off, current on) error: [drm:pid840:assert_fdi_rx] *ERROR* Attempting to enable FDI_RX on Haswell pipe 0 error: [drm:pid840:assert_fdi_rx] *ERROR* Attempting to enable FDI_RX on Haswell pipe 0 drmn1: taking over the fictitious range 0xe000-0xf000 info: [drm] Enabling RC6 states: RC6 off, RC6p off, RC6pp off info: [drm] GMBUS [gmbus dpb] timed out, falling back to bit banging on pin 5 panic: _sx_xlock_hard: recursed on non-recursive sx gmbus @ /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c:370 cpuid = 2 Uptime: 27s Dumping 582 out of 11954 MB:..3%..11%..22%..31%..42%..53%..61%..72%..83%..91% Reading symbols from /boot/kernel/acpi_ibm.ko.symbols...done. Loaded symbols for /boot/kernel/acpi_ibm.ko.symbols Reading symbols from /boot/kernel/i915kms.ko.symbols...done. Loaded symbols for /boot/kernel/i915kms.ko.symbols Reading symbols from /boot/kernel/drm2.ko.symbols...done. Loaded symbols for /boot/kernel/drm2.ko.symbols #0 doadump (textdump=1) at /home/dchagin/head/sys/kern/kern_shutdown.c:261 261 dumptid = curthread-td_tid; (kgdb) #0 doadump (textdump=1) at /home/dchagin/head/sys/kern/kern_shutdown.c:261 #1 0x80691a75 in kern_reboot (howto=260) at /home/dchagin/head/sys/kern/kern_shutdown.c:447 #2 0x80692670 in vpanic ( fmt=0x80c763b9 _sx_xlock_hard: recursed on non-recursive sx %s @ %s:%d\n, ap=0xfe033c750d60) at /home/dchagin/head/sys/kern/kern_shutdown.c:746 #3 0x8069204c in kassert_panic ( fmt=0x80c763b9 _sx_xlock_hard: recursed on non-recursive sx %s @ %s:%d\n) at /home/dchagin/head/sys/kern/kern_shutdown.c:634 #4 0x806a09b0 in _sx_xlock_hard (sx=0xfe00039480e8, tid=18446735277793944768, opts=0, file=0x8166d4e7 /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c, line=370) at /home/dchagin/head/sys/kern/kern_sx.c:519 #5 0x8069f9ed in __sx_xlock (sx=0xfe00039480e8, td=0xf8000a9324c0, opts=0, file=0x8166d4e7 /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c, line=370) at sx.h:154 #6 0x8069f893 in _sx_xlock (sx=0xfe00039480e8, opts=0, file=0x8166d4e7 /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c, line=370) at /home/dchagin/head/sys/kern/kern_sx.c:311 #7 0x816464e6 in intel_gmbus_transfer (idev=0xf80080a99900, msgs=0xfe033c7511e0, nmsgs=2) at /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c:370 #8 0x81646ac7 in intel_gmbus_transfer (idev=value optimized out, msgs=value optimized out, nmsgs=value optimized out) at iicbus_if.h:131 #9 0x8044a445 in IICBUS_TRANSFER (dev=0xf80080a99900, msgs=0xfe033c7511e0, nmsgs=2) at iicbus_if.h:131 #10 0x8044a39b in iicbus_transfer (bus=0xf80080a99800, msgs=0xfe033c7511e0, nmsgs=2) at /home/dchagin/head/sys/dev/iicbus/iiconf.c:355 #11 0x8169309d in drm_do_probe_ddc_edid (adapter=0xf80080a99800, buf=0xfe033c751257 y, block=value optimized out, len=1) at /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_edid.c:290 #12 0x816909bc in drm_get_edid (connector=0xf80080826c00, adapter=0xf80080a99800) at /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_edid.c:388 #13 0x81645690 in intel_hdmi_detect (connector=0xf80080826c00, force=value optimized out) at /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_hdmi.c:465 #14 0x8168adf5 in drm_helper_probe_single_connector_modes ( connector=0xf80080826c00, maxX=8192, maxY=8192) at /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_crtc_helper.c:135 #15 0x8169387f in drm_fb_helper_initial_config ( fb_helper=0xf8008093b200, bpp_sel=32) at /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_fb_helper.c:1164 #16 0x81643e41 in intel_fbdev_init (dev=value optimized out) at
Re: Ver 2 of the patch [was: Re: i915 driver update testing]
This is Haswell, right? Didn't Kib say not interested in haswell testing yet ? -adrian On 26 October 2014 14:02, Chagin Dmitry dcha...@freebsd.org wrote: On Thu, Oct 23, 2014 at 10:03:29PM +0300, Konstantin Belousov wrote: On Wed, Oct 22, 2014 at 03:59:23PM -0400, Adam McDougall wrote: On 10/22/2014 08:26, Konstantin Belousov wrote: Use https://www.kib.kiev.ua/kib/drm/i915.6.patch. I already have one private report of the patch worked from person who got the same panic in iicbb. Hi, Kostik! i915.6.patch i7-4700. FreeBSD dchagin.static.corbina.net 11.0-CURRENT FreeBSD 11.0-CURRENT #93 r273708+3ca71ce(lemul)-dirty: Sun Oct 26 23:38:47 MSK 2014 r...@dchagin.static.corbina.net:/home/rootobj/home/dchagin/head/sys/YOY amd64 Unread portion of the kernel message buffer: FDI TX state assertion failure (expected off, current on) error: [drm:pid840:assert_fdi_rx] *ERROR* Attempting to enable FDI_RX on Haswell pipe 0 error: [drm:pid840:assert_fdi_rx] *ERROR* Attempting to enable FDI_RX on Haswell pipe 0 drmn1: taking over the fictitious range 0xe000-0xf000 info: [drm] Enabling RC6 states: RC6 off, RC6p off, RC6pp off info: [drm] GMBUS [gmbus dpb] timed out, falling back to bit banging on pin 5 panic: _sx_xlock_hard: recursed on non-recursive sx gmbus @ /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c:370 cpuid = 2 Uptime: 27s Dumping 582 out of 11954 MB:..3%..11%..22%..31%..42%..53%..61%..72%..83%..91% Reading symbols from /boot/kernel/acpi_ibm.ko.symbols...done. Loaded symbols for /boot/kernel/acpi_ibm.ko.symbols Reading symbols from /boot/kernel/i915kms.ko.symbols...done. Loaded symbols for /boot/kernel/i915kms.ko.symbols Reading symbols from /boot/kernel/drm2.ko.symbols...done. Loaded symbols for /boot/kernel/drm2.ko.symbols #0 doadump (textdump=1) at /home/dchagin/head/sys/kern/kern_shutdown.c:261 261 dumptid = curthread-td_tid; (kgdb) #0 doadump (textdump=1) at /home/dchagin/head/sys/kern/kern_shutdown.c:261 #1 0x80691a75 in kern_reboot (howto=260) at /home/dchagin/head/sys/kern/kern_shutdown.c:447 #2 0x80692670 in vpanic ( fmt=0x80c763b9 _sx_xlock_hard: recursed on non-recursive sx %s @ %s:%d\n, ap=0xfe033c750d60) at /home/dchagin/head/sys/kern/kern_shutdown.c:746 #3 0x8069204c in kassert_panic ( fmt=0x80c763b9 _sx_xlock_hard: recursed on non-recursive sx %s @ %s:%d\n) at /home/dchagin/head/sys/kern/kern_shutdown.c:634 #4 0x806a09b0 in _sx_xlock_hard (sx=0xfe00039480e8, tid=18446735277793944768, opts=0, file=0x8166d4e7 /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c, line=370) at /home/dchagin/head/sys/kern/kern_sx.c:519 #5 0x8069f9ed in __sx_xlock (sx=0xfe00039480e8, td=0xf8000a9324c0, opts=0, file=0x8166d4e7 /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c, line=370) at sx.h:154 #6 0x8069f893 in _sx_xlock (sx=0xfe00039480e8, opts=0, file=0x8166d4e7 /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c, line=370) at /home/dchagin/head/sys/kern/kern_sx.c:311 #7 0x816464e6 in intel_gmbus_transfer (idev=0xf80080a99900, msgs=0xfe033c7511e0, nmsgs=2) at /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c:370 #8 0x81646ac7 in intel_gmbus_transfer (idev=value optimized out, msgs=value optimized out, nmsgs=value optimized out) at iicbus_if.h:131 #9 0x8044a445 in IICBUS_TRANSFER (dev=0xf80080a99900, msgs=0xfe033c7511e0, nmsgs=2) at iicbus_if.h:131 #10 0x8044a39b in iicbus_transfer (bus=0xf80080a99800, msgs=0xfe033c7511e0, nmsgs=2) at /home/dchagin/head/sys/dev/iicbus/iiconf.c:355 #11 0x8169309d in drm_do_probe_ddc_edid (adapter=0xf80080a99800, buf=0xfe033c751257 y, block=value optimized out, len=1) at /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_edid.c:290 #12 0x816909bc in drm_get_edid (connector=0xf80080826c00, adapter=0xf80080a99800) at /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_edid.c:388 #13 0x81645690 in intel_hdmi_detect (connector=0xf80080826c00, force=value optimized out) at /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_hdmi.c:465 #14 0x8168adf5 in drm_helper_probe_single_connector_modes ( connector=0xf80080826c00, maxX=8192, maxY=8192) at /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_crtc_helper.c:135 #15 0x8169387f in drm_fb_helper_initial_config ( fb_helper=0xf8008093b200, bpp_sel=32) at /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_fb_helper.c:1164 #16
Re: Ver 2 of the patch [was: Re: i915 driver update testing]
On Thu, Oct 23, 2014 at 10:03:29PM +0300, Konstantin Belousov wrote: On Wed, Oct 22, 2014 at 03:59:23PM -0400, Adam McDougall wrote: On 10/22/2014 08:26, Konstantin Belousov wrote: Use https://www.kib.kiev.ua/kib/drm/i915.6.patch. I already have one private report of the patch worked from person who got the same panic in iicbb. Hi, Kostik! i915.6.patch i7-4700. FreeBSD dchagin.static.corbina.net 11.0-CURRENT FreeBSD 11.0-CURRENT #93 r273708+3ca71ce(lemul)-dirty: Sun Oct 26 23:38:47 MSK 2014 r...@dchagin.static.corbina.net:/home/rootobj/home/dchagin/head/sys/YOY amd64 Unread portion of the kernel message buffer: FDI TX state assertion failure (expected off, current on) error: [drm:pid840:assert_fdi_rx] *ERROR* Attempting to enable FDI_RX on Haswell pipe 0 error: [drm:pid840:assert_fdi_rx] *ERROR* Attempting to enable FDI_RX on Haswell pipe 0 drmn1: taking over the fictitious range 0xe000-0xf000 info: [drm] Enabling RC6 states: RC6 off, RC6p off, RC6pp off info: [drm] GMBUS [gmbus dpb] timed out, falling back to bit banging on pin 5 panic: _sx_xlock_hard: recursed on non-recursive sx gmbus @ /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c:370 cpuid = 2 Uptime: 27s Dumping 582 out of 11954 MB:..3%..11%..22%..31%..42%..53%..61%..72%..83%..91% Reading symbols from /boot/kernel/acpi_ibm.ko.symbols...done. Loaded symbols for /boot/kernel/acpi_ibm.ko.symbols Reading symbols from /boot/kernel/i915kms.ko.symbols...done. Loaded symbols for /boot/kernel/i915kms.ko.symbols Reading symbols from /boot/kernel/drm2.ko.symbols...done. Loaded symbols for /boot/kernel/drm2.ko.symbols #0 doadump (textdump=1) at /home/dchagin/head/sys/kern/kern_shutdown.c:261 261 dumptid = curthread-td_tid; (kgdb) #0 doadump (textdump=1) at /home/dchagin/head/sys/kern/kern_shutdown.c:261 #1 0x80691a75 in kern_reboot (howto=260) at /home/dchagin/head/sys/kern/kern_shutdown.c:447 #2 0x80692670 in vpanic ( fmt=0x80c763b9 _sx_xlock_hard: recursed on non-recursive sx %s @ %s:%d\n, ap=0xfe033c750d60) at /home/dchagin/head/sys/kern/kern_shutdown.c:746 #3 0x8069204c in kassert_panic ( fmt=0x80c763b9 _sx_xlock_hard: recursed on non-recursive sx %s @ %s:%d\n) at /home/dchagin/head/sys/kern/kern_shutdown.c:634 #4 0x806a09b0 in _sx_xlock_hard (sx=0xfe00039480e8, tid=18446735277793944768, opts=0, file=0x8166d4e7 /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c, line=370) at /home/dchagin/head/sys/kern/kern_sx.c:519 #5 0x8069f9ed in __sx_xlock (sx=0xfe00039480e8, td=0xf8000a9324c0, opts=0, file=0x8166d4e7 /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c, line=370) at sx.h:154 #6 0x8069f893 in _sx_xlock (sx=0xfe00039480e8, opts=0, file=0x8166d4e7 /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c, line=370) at /home/dchagin/head/sys/kern/kern_sx.c:311 #7 0x816464e6 in intel_gmbus_transfer (idev=0xf80080a99900, msgs=0xfe033c7511e0, nmsgs=2) at /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c:370 #8 0x81646ac7 in intel_gmbus_transfer (idev=value optimized out, msgs=value optimized out, nmsgs=value optimized out) at iicbus_if.h:131 #9 0x8044a445 in IICBUS_TRANSFER (dev=0xf80080a99900, msgs=0xfe033c7511e0, nmsgs=2) at iicbus_if.h:131 #10 0x8044a39b in iicbus_transfer (bus=0xf80080a99800, msgs=0xfe033c7511e0, nmsgs=2) at /home/dchagin/head/sys/dev/iicbus/iiconf.c:355 #11 0x8169309d in drm_do_probe_ddc_edid (adapter=0xf80080a99800, buf=0xfe033c751257 y, block=value optimized out, len=1) at /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_edid.c:290 #12 0x816909bc in drm_get_edid (connector=0xf80080826c00, adapter=0xf80080a99800) at /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_edid.c:388 #13 0x81645690 in intel_hdmi_detect (connector=0xf80080826c00, force=value optimized out) at /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_hdmi.c:465 #14 0x8168adf5 in drm_helper_probe_single_connector_modes ( connector=0xf80080826c00, maxX=8192, maxY=8192) at /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_crtc_helper.c:135 #15 0x8169387f in drm_fb_helper_initial_config ( fb_helper=0xf8008093b200, bpp_sel=32) at /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_fb_helper.c:1164 #16 0x81643e41 in intel_fbdev_init (dev=value optimized out) at /home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_fb.c:245 #17 0x81617082 in i915_driver_load (dev=0xf80009807800, flags=0) at
Re: Ver 2 of the patch [was: Re: i915 driver update testing]
On Fri, Oct 24, 2014 at 3:03 AM, Konstantin Belousov kostik...@gmail.com wrote: Due to my mistake during the patch generation, i915.5.patch is just a garbage. Use https://www.kib.kiev.ua/kib/drm/i915.6.patch. I already have one private report of the patch worked from person who got the same panic in iicbb. panic when I was opening Google maps in Chromium 38. But I was unable to reproduce it. The original code does not panic. src is r273588. CPU is an i5-3450. debug message attached. screenshot: https://lh3.googleusercontent.com/-BpPTfNTObtU/VEs9RGT7i6I/gfA/TvOnT-BP3zo/w894-h671-no/IMG_20141025_134906.jpg -Jia-Shiun. agp0: IvyBridge desktop GT1 IG on vgapci0 agp0: aperture size is 256M, detected 65532k stolen memory agp0: AGP_SNB_GFX_MODE: agp0: AGP_SNB_GCC1: 0x0211 agp0: Mappable GTT entries: 65536 agp0: Total GTT entries: 524288 info: [drm] Initialized drm 1.1.0 20060810 [drm:pid958:drm_probe] desc : (null) drmn0: Intel IvyBridge on vgapci0 [drm:pid958:drm_attach] MSI count = 1 vgapci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 267 to local APIC 2 vector 51 vgapci0: using IRQ 267 for MSI info: [drm] MSI enabled 1 message(s) [drm:pid958:drm_load] [drm:pid958:drm_agp_init] agp_available = 1 info: [drm] AGP at 0xe000 256MB [drm:pid958:drm_ctxbitmap_next] bit : 0 [drm:pid958:drm_ctxbitmap_init] drm_ctxbitmap_init : 0 [drm:pid958:drm_addmap] offset = 0xf780, size = 0x0040, type = 1 [drm:pid958:drm_addmap] Added map 1 0xf780/0x40 [drm:pid958:intel_setup_mchbar] mchbar already enabled iicbus0: Philips I2C bus on iicbb0 addr 0xff iic0: I2C generic I/O on iicbus0 iic1: I2C generic I/O on iicbus1 iicbus2: Philips I2C bus on iicbb1 addr 0x0 iic2: I2C generic I/O on iicbus2 iic3: I2C generic I/O on iicbus3 iicbus4: Philips I2C bus on iicbb2 addr 0x0 iic4: I2C generic I/O on iicbus4 iic5: I2C generic I/O on iicbus5 iicbus6: Philips I2C bus on iicbb3 addr 0x0 iic6: I2C generic I/O on iicbus6 iic7: I2C generic I/O on iicbus7 iicbus8: Philips I2C bus on iicbb4 addr 0x0 iic8: I2C generic I/O on iicbus8 iic9: I2C generic I/O on iicbus9 iicbus10: Philips I2C bus on iicbb5 addr 0x0 iic10: I2C generic I/O on iicbus10 iic11: I2C generic I/O on iicbus11 iicbus12: Philips I2C bus on iicbb6 addr 0x0 iic12: I2C generic I/O on iicbus12 iic13: I2C generic I/O on iicbus13 [drm:pid958:intel_opregion_setup] graphic opregion physical addr: 0xd8a87018 [drm:pid958:intel_opregion_setup] SWSCI supported info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. [drm:KMS:pid958:intel_detect_pch] Found PatherPoint PCH [drm:KMS:pid958:init_vbt_defaults] Set default to SSC at 100MHz [drm:KMS:pid958:intel_parse_bios] Using VBT from OpRegion: $VBT SNB/IVB-DESKTOPd [drm:KMS:pid958:parse_general_features] BDB_GENERAL_FEATURES int_tv_support 0 int_crt_support 1 lvds_use_ssc 0 lvds_ssc_freq 120 display_clock_mode 0 [drm:KMS:pid958:parse_general_definitions] crt_ddc_bus_pin: 2 [drm:KMS:pid958:parse_lfp_panel_data] Found panel mode in BIOS VBT tables: [drm:KMS:pid958:drm_mode_debug_printmodeline] Modeline 0:1024x768 0 65000 1024 1048 1184 1344 768 771 777 806 0x8 0xa [drm:KMS:pid958:parse_lfp_panel_data] VBT initial LVDS value 300 [drm:KMS:pid958:parse_sdvo_panel_data] Found SDVO panel mode in BIOS VBT tables: [drm:KMS:pid958:drm_mode_debug_printmodeline] Modeline 0:1600x1200 0 162000 1600 1664 1856 2160 1200 1201 1204 1250 0x8 0xa [drm:KMS:pid958:parse_sdvo_device_mapping] No SDVO device info is found in VBT [drm:KMS:pid958:intel_init_pm] Using MT version of forcewake [drm:KMS:pid958:intel_modeset_init] 3 display pipes available. [drm:KMS:pid958:intel_lvds_init] LVDS is not present in VBT [drm:KMS:pid958:intel_crt_init] pch crt adpa set to 0x80f40010 [drm:KMS:pid958:intel_setup_outputs] HDMIB 0 PCH_DP_B 0 HDMIC 1 HDMID 1 PCH_DP_C 1 PCH_DP_D 1 LVDS 0 [drm:KMS:pid958:intel_dp_i2c_init] i2c_init DPDDC-C [drm:KMS:pid958:intel_dp_aux_ch] dp_aux_ch timeout status 0x5145003f [drm:KMS:pid958:intel_dp_i2c_aux_ch] aux_ch failed -60 [drm:KMS:pid958:intel_dp_aux_ch] dp_aux_ch timeout status 0x5145003f [drm:KMS:pid958:intel_dp_i2c_aux_ch] aux_ch failed -60 [drm:KMS:pid958:intel_dp_i2c_init] i2c_init DPDDC-D [drm:KMS:pid958:intel_dp_aux_ch] dp_aux_ch timeout status 0x5145003f [drm:KMS:pid958:intel_dp_i2c_aux_ch] aux_ch failed -60 [drm:KMS:pid958:intel_dp_aux_ch] dp_aux_ch timeout status 0x5145003f [drm:KMS:pid958:intel_dp_i2c_aux_ch] aux_ch failed -60 [drm:KMS:pid958:ironlake_crtc_dpms] crtc 0/0 dpms off [drm:KMS:pid958:intel_update_fbc] [drm:KMS:pid958:ironlake_crtc_dpms] crtc 1/1 dpms off [drm:pid958:gm45_get_vblank_counter] i915: trying to get vblank count for disabled pipe B [drm:pid958:gm45_get_vblank_counter] i915: trying to get vblank count for disabled pipe B [drm:KMS:pid958:intel_update_fbc] [drm:KMS:pid958:ironlake_crtc_dpms] crtc 2/2 dpms off [drm:pid958:gm45_get_vblank_counter] i915: trying to get vblank
Re: Ver 2 of the patch [was: Re: i915 driver update testing]
Hi, I can confirm v6 of the patch works for me with a r273559 kernel on a i5-3320M notebook as well. Only interesting new output to messages: Oct 25 23:11:19 kernel: error: [drm:pid1159:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 0007, was 1807 Oct 25 23:11:28 kernel: error: [drm:pid1159:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1807, was Oct 25 23:11:36 kernel: error: [drm:pid1159:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1807, was 1800 Oct 25 23:11:48 kernel: error: [drm:pid1159:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1807, was 1800 Thanks a lot! Johannes On Thu, Oct 23, 2014 at 9:03 PM, Konstantin Belousov kostik...@gmail.com wrote: On Wed, Oct 22, 2014 at 03:59:23PM -0400, Adam McDougall wrote: On 10/22/2014 08:26, Konstantin Belousov wrote: On Wed, Oct 08, 2014 at 03:12:08PM -0400, Adam McDougall wrote: On 10/08/2014 13:05, Konstantin Belousov wrote: There are more occurences of the bug I fixed once in patch version 2. Also, since pmap changes were committed in modified form, please try the updated patch at https://www.kib.kiev.ua/kib/drm/i915.3.patch . No apparent change: http://www.egr.msu.edu/~mcdouga9/i915-patch3-1.txt cite (kgdb) p *(struct drm_i915_private *)(dev_private) cite No symbol dev_private in current context. This is p *(struct drm_i915_private *)(dev-dev_private) http://www.egr.msu.edu/~mcdouga9/dev_private.txt I regenerated patch after recent merges and changes in KPI on HEAD. https://www.kib.kiev.ua/kib/drm/i915.4.patch Please apply it, I think the issue should be there still. Then apply the following debugging patch, and set kenv drm.debug=0x3 before loading i915kms.ko. I want to see the same debugging information, and dmesg from the moment of loading the driver. In fact, try https://www.kib.kiev.ua/kib/drm/i915.5.patch Due to my mistake during the patch generation, i915.5.patch is just a garbage. Use https://www.kib.kiev.ua/kib/drm/i915.6.patch. I already have one private report of the patch worked from person who got the same panic in iicbb. ___ 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: Ver 2 of the patch [was: Re: i915 driver update testing]
On Wed, Oct 22, 2014 at 03:59:23PM -0400, Adam McDougall wrote: On 10/22/2014 08:26, Konstantin Belousov wrote: On Wed, Oct 08, 2014 at 03:12:08PM -0400, Adam McDougall wrote: On 10/08/2014 13:05, Konstantin Belousov wrote: There are more occurences of the bug I fixed once in patch version 2. Also, since pmap changes were committed in modified form, please try the updated patch at https://www.kib.kiev.ua/kib/drm/i915.3.patch . No apparent change: http://www.egr.msu.edu/~mcdouga9/i915-patch3-1.txt cite (kgdb) p *(struct drm_i915_private *)(dev_private) cite No symbol dev_private in current context. This is p *(struct drm_i915_private *)(dev-dev_private) http://www.egr.msu.edu/~mcdouga9/dev_private.txt I regenerated patch after recent merges and changes in KPI on HEAD. https://www.kib.kiev.ua/kib/drm/i915.4.patch Please apply it, I think the issue should be there still. Then apply the following debugging patch, and set kenv drm.debug=0x3 before loading i915kms.ko. I want to see the same debugging information, and dmesg from the moment of loading the driver. In fact, try https://www.kib.kiev.ua/kib/drm/i915.5.patch Due to my mistake during the patch generation, i915.5.patch is just a garbage. Use https://www.kib.kiev.ua/kib/drm/i915.6.patch. I already have one private report of the patch worked from person who got the same panic in iicbb. ___ 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: Ver 2 of the patch [was: Re: i915 driver update testing]
On 10/23/2014 15:03, Konstantin Belousov wrote: Use https://www.kib.kiev.ua/kib/drm/i915.6.patch. I already have one private report of the patch worked from person who got the same panic in iicbb. Yes, this one works (does not panic) and X works! I kldloaded it after boot as I usually do. For the 3 minutes my computer has been up so far, it seems the same as 10-stable. Thanks. ___ 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: Ver 2 of the patch [was: Re: i915 driver update testing]
On Wed, Oct 08, 2014 at 03:12:08PM -0400, Adam McDougall wrote:
On 10/08/2014 13:05, Konstantin Belousov wrote:
There are more occurences of the bug I fixed once in patch version 2.
Also, since pmap changes were committed in modified form, please try
the updated patch at https://www.kib.kiev.ua/kib/drm/i915.3.patch .
No apparent change:
http://www.egr.msu.edu/~mcdouga9/i915-patch3-1.txt
cite (kgdb) p *(struct drm_i915_private *)(dev_private)
cite No symbol dev_private in current context.
This is p *(struct drm_i915_private *)(dev-dev_private)
I regenerated patch after recent merges and changes in KPI on HEAD.
https://www.kib.kiev.ua/kib/drm/i915.4.patch
Please apply it, I think the issue should be there still. Then apply
the following debugging patch, and set
kenv drm.debug=0x3
before loading i915kms.ko. I want to see the same debugging information,
and dmesg from the moment of loading the driver.
diff --git a/sys/dev/drm2/i915/intel_sdvo.c b/sys/dev/drm2/i915/intel_sdvo.c
index 74e479a..e1f1d09 100644
--- a/sys/dev/drm2/i915/intel_sdvo.c
+++ b/sys/dev/drm2/i915/intel_sdvo.c
@@ -1952,8 +1952,10 @@ intel_sdvo_select_i2c_bus(struct drm_i915_private
*dev_priv,
sdvo-i2c = intel_gmbus_get_adapter(dev_priv, pin);
intel_gmbus_set_speed(sdvo-i2c, GMBUS_RATE_1MHZ);
intel_gmbus_force_bit(sdvo-i2c, true);
+printf(i915: select i2c pin %d priv %p i2c %p\n, pin, dev_priv, sdvo-i2c);
} else {
sdvo-i2c = intel_gmbus_get_adapter(dev_priv, GMBUS_PORT_DPB);
+printf(i915: select i2c DPB %d priv %p i2c %p\n, pin, dev_priv, sdvo-i2c);
}
}
@@ -2601,6 +2603,7 @@ bool intel_sdvo_init(struct drm_device *dev, uint32_t
sdvo_reg, bool is_sdvob)
intel_sdvo = malloc(sizeof(struct intel_sdvo), DRM_MEM_KMS,
M_WAITOK | M_ZERO);
+printf(i915: intel_sdvo %p\n, intel_sdvo);
intel_sdvo-sdvo_reg = sdvo_reg;
intel_sdvo-is_sdvob = is_sdvob;
___
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: Ver 2 of the patch [was: Re: i915 driver update testing]
In fact, try https://www.kib.kiev.ua/kib/drm/i915.5.patch ___ 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: Ver 2 of the patch [was: Re: i915 driver update testing]
On 10/22/2014 08:26, Konstantin Belousov wrote: On Wed, Oct 08, 2014 at 03:12:08PM -0400, Adam McDougall wrote: On 10/08/2014 13:05, Konstantin Belousov wrote: There are more occurences of the bug I fixed once in patch version 2. Also, since pmap changes were committed in modified form, please try the updated patch at https://www.kib.kiev.ua/kib/drm/i915.3.patch . No apparent change: http://www.egr.msu.edu/~mcdouga9/i915-patch3-1.txt cite (kgdb) p *(struct drm_i915_private *)(dev_private) cite No symbol dev_private in current context. This is p *(struct drm_i915_private *)(dev-dev_private) http://www.egr.msu.edu/~mcdouga9/dev_private.txt I regenerated patch after recent merges and changes in KPI on HEAD. https://www.kib.kiev.ua/kib/drm/i915.4.patch Please apply it, I think the issue should be there still. Then apply the following debugging patch, and set kenv drm.debug=0x3 before loading i915kms.ko. I want to see the same debugging information, and dmesg from the moment of loading the driver. In fact, try https://www.kib.kiev.ua/kib/drm/i915.5.patch http://www.egr.msu.edu/~mcdouga9/dconschat.txt ___ 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: Ver 2 of the patch [was: Re: i915 driver update testing]
On Tue, Oct 07, 2014 at 04:04:54PM -0400, Adam McDougall wrote: On 10/07/2014 14:01, Konstantin Belousov wrote: On Tue, Oct 07, 2014 at 07:44:19PM +0300, Konstantin Belousov wrote: From the same frame, please do p *(struct drm_i915_private *)(dev-private) p *(struct drm_i915_private *)(dev-dev_private) I probably figured out what is wrong, but it is still interesting to see this piece of data. For everybody who has the issue with blank screen or panic after the patch: 1. please try the updated patch, https://www.kib.kiev.ua/kib/drm/i915.2.patch 2. if you use kldload i915kms to test the patch and get the blank screen, verify do you get panic or just a black screen. It is expected for sc, not so for vt. For vt, if you do get blank screen and not a panic, do not load i915kms manually and run the X server. I am interested if running X server does show proper output. Backtrace seems the same, I repeated the prior commands: http://www.egr.msu.edu/~mcdouga9/i915-patch2-1.txt There are more occurences of the bug I fixed once in patch version 2. Also, since pmap changes were committed in modified form, please try the updated patch at https://www.kib.kiev.ua/kib/drm/i915.3.patch . ___ 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: Ver 2 of the patch [was: Re: i915 driver update testing]
On 10/08/2014 13:05, Konstantin Belousov wrote: On Tue, Oct 07, 2014 at 04:04:54PM -0400, Adam McDougall wrote: On 10/07/2014 14:01, Konstantin Belousov wrote: On Tue, Oct 07, 2014 at 07:44:19PM +0300, Konstantin Belousov wrote: From the same frame, please do p *(struct drm_i915_private *)(dev-private) p *(struct drm_i915_private *)(dev-dev_private) I probably figured out what is wrong, but it is still interesting to see this piece of data. For everybody who has the issue with blank screen or panic after the patch: 1. please try the updated patch, https://www.kib.kiev.ua/kib/drm/i915.2.patch 2. if you use kldload i915kms to test the patch and get the blank screen, verify do you get panic or just a black screen. It is expected for sc, not so for vt. For vt, if you do get blank screen and not a panic, do not load i915kms manually and run the X server. I am interested if running X server does show proper output. Backtrace seems the same, I repeated the prior commands: http://www.egr.msu.edu/~mcdouga9/i915-patch2-1.txt There are more occurences of the bug I fixed once in patch version 2. Also, since pmap changes were committed in modified form, please try the updated patch at https://www.kib.kiev.ua/kib/drm/i915.3.patch . No apparent change: http://www.egr.msu.edu/~mcdouga9/i915-patch3-1.txt I made a log of the source operations and compile to be certain I was using the right patch properly: http://www.egr.msu.edu/~mcdouga9/20141008-compile.txt Are any of these an issue in the patch? Seem unrelated but hopefully harmless: diff --git a/sys/dev/md/md.c b/sys/dev/md/md.c diff --git a/sys/fs/tmpfs/tmpfs_subr.c b/sys/fs/tmpfs/tmpfs_subr.c diff --git a/sys/kern/kern_exec.c b/sys/kern/kern_exec.c diff --git a/sys/kern/uipc_shm.c b/sys/kern/uipc_shm.c diff --git a/sys/kern/uipc_syscalls.c b/sys/kern/uipc_syscalls.c diff --git a/sys/vm/default_pager.c b/sys/vm/default_pager.c diff --git a/sys/vm/device_pager.c b/sys/vm/device_pager.c diff --git a/sys/vm/phys_pager.c b/sys/vm/phys_pager.c diff --git a/sys/vm/sg_pager.c b/sys/vm/sg_pager.c diff --git a/sys/vm/swap_pager.c b/sys/vm/swap_pager.c diff --git a/sys/vm/vm_fault.c b/sys/vm/vm_fault.c diff --git a/sys/vm/vm_glue.c b/sys/vm/vm_glue.c diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c diff --git a/sys/vm/vm_pager.c b/sys/vm/vm_pager.c diff --git a/sys/vm/vm_pager.h b/sys/vm/vm_pager.h diff --git a/sys/vm/vnode_pager.c b/sys/vm/vnode_pager.c Thanks. ___ 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: Ver 2 of the patch [was: Re: i915 driver update testing]
2014-10-08 19:05 GMT+02:00 Konstantin Belousov kostik...@gmail.com: On Tue, Oct 07, 2014 at 04:04:54PM -0400, Adam McDougall wrote: On 10/07/2014 14:01, Konstantin Belousov wrote: On Tue, Oct 07, 2014 at 07:44:19PM +0300, Konstantin Belousov wrote: From the same frame, please do p *(struct drm_i915_private *)(dev-private) p *(struct drm_i915_private *)(dev-dev_private) I probably figured out what is wrong, but it is still interesting to see this piece of data. For everybody who has the issue with blank screen or panic after the patch: 1. please try the updated patch, https://www.kib.kiev.ua/kib/drm/i915.2.patch 2. if you use kldload i915kms to test the patch and get the blank screen, verify do you get panic or just a black screen. It is expected for sc, not so for vt. For vt, if you do get blank screen and not a panic, do not load i915kms manually and run the X server. I am interested if running X server does show proper output. Backtrace seems the same, I repeated the prior commands: http://www.egr.msu.edu/~mcdouga9/i915-patch2-1.txt There are more occurences of the bug I fixed once in patch version 2. Also, since pmap changes were committed in modified form, please try the updated patch at https://www.kib.kiev.ua/kib/drm/i915.3.patch . On my Samsung ATIV Book 2 the result is always the blank screen with i915.2.patch or i9153.patch. The result of the command kldload i915kms or running the X server is always the blank screen. Note: if I listen some music, after the blank screen, I can hear some noise from speakers. ___ 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: i915 driver update testing
Am Sun, 05 Oct 2014 21:54:22 +0200 Koop Mast k...@rainbow-runner.nl schrieb: On Fri, 2014-10-03 at 20:02 +0300, Konstantin Belousov wrote: Please find at the https://kib.kiev.ua/kib/drm/i915.1.patch a patch which provides some updates to the i915 driver. At large, this is import of the batch of Linux commits, and as such, it is interesting mostly as attempt to restart the race to get us more up to date Linux code imported. It might provide some bug fixes, most likely for IvyBridge. Interesting from the development PoV is the update of the GEM i/o ioctl code path to mimic Linux code structure. I am asking _only_ for reports of regressions with the patch applied, comparing with the code which is currently in HEAD. I will not debug any existing bugs, my goal right now is to commit this update, which is needed for further work. I.e., only when you get an issue with the patch applied, but cannot reproduce the problem without the patch, please prepare a bug report. FYI, the driver will attach to haswell gfx, but I am not interested in reports about this (see above paragraph). On my test box, which is Core i7 4770S, the mode-setting and front-buffer rendering works, but Mesa immediately cause renderer to bug out. Work was sponsored by The FreeBSD Foundation, both by time and hardware, and Intel provided access to the documentation. Hi, I got a working X-server and framebuffer console on my Sandybridge system. The only regression I noticed so far is the line below, where the number after 'expected' changes per time the line is printed. Oct 5 21:50:12 crashalot kernel: error: [drm:pid1049:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 160d, was 1600 Oct 5 21:51:04 crashalot kernel: error: [drm:pid1049:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 160d, was 1600 Oct 5 21:53:14 crashalot kernel: error: [drm:pid1170:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 160d, was 1600 ___ 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 Is this patch supposed to work also with IvyBridge type iGPUs, i.w. P4600 (the iGPU of some XEONs of the i5-122Xv2 series)? When I load drm2 and i915kms via loader.conf, the box gets black screen and then dies. Oliver signature.asc Description: PGP signature
Re: i915 driver update testing
On 10/7/2014 12:20 AM, Konstantin Belousov wrote: On Mon, Oct 06, 2014 at 07:30:20PM -0400, Adam McDougall wrote: On 10/05/2014 13:00, Konstantin Belousov wrote: On Sun, Oct 05, 2014 at 11:01:14AM -0400, Adam McDougall wrote: (kgdb) #0 doadump (textdump=1) at pcpu.h:219 #1 0x80661efd in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0x80662450 in panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:746 #3 0x808fe52f in trap_fatal (frame=value optimized out, eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:866 #4 0x808fe87c in trap_pfault (frame=0xfe01fe0b21b0, usermode=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:677 #5 0x808fde9e in trap (frame=0xfe01fe0b21b0) at /usr/src/sys/amd64/amd64/trap.c:426 #6 0x808e00a2 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #7 0x8166808e in i915_write32 (dev_priv=0xf800031f1c00, reg=20736, val=0) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_drv.c:992 In kgdb, from this frame, please do p *dev_priv p *(dev_priv-dev) p *(dev_priv-info) http://www.egr.msu.edu/~mcdouga9/i915-1b.txt Sorry for the delay. I duplicated this on a spare computer of the same model so I can test easier. Great, thank you. Please also do, from the frame 12, p *dev http://www.egr.msu.edu/~mcdouga9/i915-2.txt ___ 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: i915 driver update testing
On Tue, Oct 07, 2014 at 09:00:56AM -0400, Adam McDougall wrote: On 10/7/2014 12:20 AM, Konstantin Belousov wrote: On Mon, Oct 06, 2014 at 07:30:20PM -0400, Adam McDougall wrote: On 10/05/2014 13:00, Konstantin Belousov wrote: On Sun, Oct 05, 2014 at 11:01:14AM -0400, Adam McDougall wrote: (kgdb) #0 doadump (textdump=1) at pcpu.h:219 #1 0x80661efd in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0x80662450 in panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:746 #3 0x808fe52f in trap_fatal (frame=value optimized out, eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:866 #4 0x808fe87c in trap_pfault (frame=0xfe01fe0b21b0, usermode=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:677 #5 0x808fde9e in trap (frame=0xfe01fe0b21b0) at /usr/src/sys/amd64/amd64/trap.c:426 #6 0x808e00a2 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #7 0x8166808e in i915_write32 (dev_priv=0xf800031f1c00, reg=20736, val=0) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_drv.c:992 In kgdb, from this frame, please do p *dev_priv p *(dev_priv-dev) p *(dev_priv-info) http://www.egr.msu.edu/~mcdouga9/i915-1b.txt Sorry for the delay. I duplicated this on a spare computer of the same model so I can test easier. Great, thank you. Please also do, from the frame 12, p *dev http://www.egr.msu.edu/~mcdouga9/i915-2.txt From the same frame, please do p *(struct drm_i915_private *)(dev-private) ___ 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
Ver 2 of the patch [was: Re: i915 driver update testing]
On Tue, Oct 07, 2014 at 07:44:19PM +0300, Konstantin Belousov wrote: From the same frame, please do p *(struct drm_i915_private *)(dev-private) I probably figured out what is wrong, but it is still interesting to see this piece of data. For everybody who has the issue with blank screen or panic after the patch: 1. please try the updated patch, https://www.kib.kiev.ua/kib/drm/i915.2.patch 2. if you use kldload i915kms to test the patch and get the blank screen, verify do you get panic or just a black screen. It is expected for sc, not so for vt. For vt, if you do get blank screen and not a panic, do not load i915kms manually and run the X server. I am interested if running X server does show proper output. ___ 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: i915 driver update testing
On 10/07/2014 12:44, Konstantin Belousov wrote: On Tue, Oct 07, 2014 at 09:00:56AM -0400, Adam McDougall wrote: On 10/7/2014 12:20 AM, Konstantin Belousov wrote: On Mon, Oct 06, 2014 at 07:30:20PM -0400, Adam McDougall wrote: On 10/05/2014 13:00, Konstantin Belousov wrote: On Sun, Oct 05, 2014 at 11:01:14AM -0400, Adam McDougall wrote: (kgdb) #0 doadump (textdump=1) at pcpu.h:219 #1 0x80661efd in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0x80662450 in panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:746 #3 0x808fe52f in trap_fatal (frame=value optimized out, eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:866 #4 0x808fe87c in trap_pfault (frame=0xfe01fe0b21b0, usermode=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:677 #5 0x808fde9e in trap (frame=0xfe01fe0b21b0) at /usr/src/sys/amd64/amd64/trap.c:426 #6 0x808e00a2 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #7 0x8166808e in i915_write32 (dev_priv=0xf800031f1c00, reg=20736, val=0) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_drv.c:992 In kgdb, from this frame, please do p *dev_priv p *(dev_priv-dev) p *(dev_priv-info) http://www.egr.msu.edu/~mcdouga9/i915-1b.txt Sorry for the delay. I duplicated this on a spare computer of the same model so I can test easier. Great, thank you. Please also do, from the frame 12, p *dev http://www.egr.msu.edu/~mcdouga9/i915-2.txt From the same frame, please do p *(struct drm_i915_private *)(dev-private) (kgdb) f 12 #12 0x81681bd7 in intel_modeset_init (dev=0xf80003bd9000) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_display.c:6603 6603found = intel_sdvo_init(dev, PCH_SDVOB, true); Current language: auto; currently minimal (kgdb) p *(struct drm_i915_private *)(dev-private) There is no member named private. ___ 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: i915 driver update testing
On Tue, Oct 07, 2014 at 02:08:06PM -0400, Adam McDougall wrote: On 10/07/2014 12:44, Konstantin Belousov wrote: On Tue, Oct 07, 2014 at 09:00:56AM -0400, Adam McDougall wrote: On 10/7/2014 12:20 AM, Konstantin Belousov wrote: On Mon, Oct 06, 2014 at 07:30:20PM -0400, Adam McDougall wrote: On 10/05/2014 13:00, Konstantin Belousov wrote: On Sun, Oct 05, 2014 at 11:01:14AM -0400, Adam McDougall wrote: (kgdb) #0 doadump (textdump=1) at pcpu.h:219 #1 0x80661efd in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0x80662450 in panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:746 #3 0x808fe52f in trap_fatal (frame=value optimized out, eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:866 #4 0x808fe87c in trap_pfault (frame=0xfe01fe0b21b0, usermode=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:677 #5 0x808fde9e in trap (frame=0xfe01fe0b21b0) at /usr/src/sys/amd64/amd64/trap.c:426 #6 0x808e00a2 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #7 0x8166808e in i915_write32 (dev_priv=0xf800031f1c00, reg=20736, val=0) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_drv.c:992 In kgdb, from this frame, please do p *dev_priv p *(dev_priv-dev) p *(dev_priv-info) http://www.egr.msu.edu/~mcdouga9/i915-1b.txt Sorry for the delay. I duplicated this on a spare computer of the same model so I can test easier. Great, thank you. Please also do, from the frame 12, p *dev http://www.egr.msu.edu/~mcdouga9/i915-2.txt From the same frame, please do p *(struct drm_i915_private *)(dev-private) (kgdb) f 12 #12 0x81681bd7 in intel_modeset_init (dev=0xf80003bd9000) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_display.c:6603 6603 found = intel_sdvo_init(dev, PCH_SDVOB, true); Current language: auto; currently minimal (kgdb) p *(struct drm_i915_private *)(dev-private) There is no member named private. It is dev_private, typo. ___ 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: Ver 2 of the patch [was: Re: i915 driver update testing]
2014-10-07 20:01 GMT+02:00 Konstantin Belousov kostik...@gmail.com: On Tue, Oct 07, 2014 at 07:44:19PM +0300, Konstantin Belousov wrote: From the same frame, please do p *(struct drm_i915_private *)(dev-private) I probably figured out what is wrong, but it is still interesting to see this piece of data. For everybody who has the issue with blank screen or panic after the patch: 1. please try the updated patch, https://www.kib.kiev.ua/kib/drm/i915.2.patch 2. if you use kldload i915kms to test the patch and get the blank screen, verify do you get panic or just a black screen. It is expected for sc, not so for vt. For vt, if you do get blank screen and not a panic, do not load i915kms manually and run the X server. I am interested if running X server does show proper output. ___ 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 Hi, applying the patch I receive this message: # patch -p1 -C ~/downloads/i915.2.patch . . . Patching file sys/amd64/amd64/pmap.c using Plan A... Hunk #1 succeeded at 1710. Hunk #2 succeeded at 6226. Hunk #3 succeeded at 6562. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -- |diff --git a/sys/amd64/conf/X b/sys/amd64/conf/X |index 0cd80c6..2d630d5 100644 |--- a/sys/amd64/conf/X |+++ b/sys/amd64/conf/X -- File to patch: I haven't the file X. Regards, 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: Ver 2 of the patch [was: Re: i915 driver update testing]
On 7 October 2014 15:20, Ranjan1018 . 21474...@gmail.com wrote: Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -- |diff --git a/sys/amd64/conf/X b/sys/amd64/conf/X |index 0cd80c6..2d630d5 100644 |--- a/sys/amd64/conf/X |+++ b/sys/amd64/conf/X -- File to patch: I haven't the file X. You can just hit Enter and then answer 'y' to the skip this patch question: File to patch: No file found--skip this patch? [n] y Skipping patch... Hunk #1 ignored at 67. 1 out of 1 hunks ignored--saving rejects to Oops.rej X in the patch is a kernel config file that's not important for the change itself. ___ 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: i915 driver update testing
On 10/07/2014 14:24, Konstantin Belousov wrote: On Tue, Oct 07, 2014 at 02:08:06PM -0400, Adam McDougall wrote: On 10/07/2014 12:44, Konstantin Belousov wrote: On Tue, Oct 07, 2014 at 09:00:56AM -0400, Adam McDougall wrote: On 10/7/2014 12:20 AM, Konstantin Belousov wrote: On Mon, Oct 06, 2014 at 07:30:20PM -0400, Adam McDougall wrote: On 10/05/2014 13:00, Konstantin Belousov wrote: On Sun, Oct 05, 2014 at 11:01:14AM -0400, Adam McDougall wrote: (kgdb) #0 doadump (textdump=1) at pcpu.h:219 #1 0x80661efd in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0x80662450 in panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:746 #3 0x808fe52f in trap_fatal (frame=value optimized out, eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:866 #4 0x808fe87c in trap_pfault (frame=0xfe01fe0b21b0, usermode=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:677 #5 0x808fde9e in trap (frame=0xfe01fe0b21b0) at /usr/src/sys/amd64/amd64/trap.c:426 #6 0x808e00a2 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #7 0x8166808e in i915_write32 (dev_priv=0xf800031f1c00, reg=20736, val=0) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_drv.c:992 In kgdb, from this frame, please do p *dev_priv p *(dev_priv-dev) p *(dev_priv-info) http://www.egr.msu.edu/~mcdouga9/i915-1b.txt Sorry for the delay. I duplicated this on a spare computer of the same model so I can test easier. Great, thank you. Please also do, from the frame 12, p *dev http://www.egr.msu.edu/~mcdouga9/i915-2.txt From the same frame, please do p *(struct drm_i915_private *)(dev-private) (kgdb) f 12 #12 0x81681bd7 in intel_modeset_init (dev=0xf80003bd9000) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_display.c:6603 6603 found = intel_sdvo_init(dev, PCH_SDVOB, true); Current language: auto; currently minimal (kgdb) p *(struct drm_i915_private *)(dev-private) There is no member named private. It is dev_private, typo. I actually took a guess at that too, but this didn't look helpful: (kgdb) p *(struct drm_i915_private *)(dev_private) No symbol dev_private in current context. ___ 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: Ver 2 of the patch [was: Re: i915 driver update testing]
2014-10-07 21:29 GMT+02:00 Ed Maste ema...@freebsd.org: On 7 October 2014 15:20, Ranjan1018 . 21474...@gmail.com wrote: Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -- |diff --git a/sys/amd64/conf/X b/sys/amd64/conf/X |index 0cd80c6..2d630d5 100644 |--- a/sys/amd64/conf/X |+++ b/sys/amd64/conf/X -- File to patch: I haven't the file X. You can just hit Enter and then answer 'y' to the skip this patch question: File to patch: No file found--skip this patch? [n] y Skipping patch... Hunk #1 ignored at 67. 1 out of 1 hunks ignored--saving rejects to Oops.rej X in the patch is a kernel config file that's not important for the change itself. Thanks Ed, it works. ___ 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: Ver 2 of the patch [was: Re: i915 driver update testing]
On 10/07/2014 14:01, Konstantin Belousov wrote: On Tue, Oct 07, 2014 at 07:44:19PM +0300, Konstantin Belousov wrote: From the same frame, please do p *(struct drm_i915_private *)(dev-private) I probably figured out what is wrong, but it is still interesting to see this piece of data. For everybody who has the issue with blank screen or panic after the patch: 1. please try the updated patch, https://www.kib.kiev.ua/kib/drm/i915.2.patch 2. if you use kldload i915kms to test the patch and get the blank screen, verify do you get panic or just a black screen. It is expected for sc, not so for vt. For vt, if you do get blank screen and not a panic, do not load i915kms manually and run the X server. I am interested if running X server does show proper output. Backtrace seems the same, I repeated the prior commands: http://www.egr.msu.edu/~mcdouga9/i915-patch2-1.txt ___ 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: i915 driver update testing
On Fri, Oct 03, 2014 at 08:02:59PM +0300, Konstantin Belousov wrote: K Please find at the K https://kib.kiev.ua/kib/drm/i915.1.patch K a patch which provides some updates to the i915 driver. At large, this K is import of the batch of Linux commits, and as such, it is interesting K mostly as attempt to restart the race to get us more up to date Linux code K imported. It might provide some bug fixes, most likely for IvyBridge. K Interesting from the development PoV is the update of the GEM i/o ioctl K code path to mimic Linux code structure. K K I am asking _only_ for reports of regressions with the patch applied, K comparing with the code which is currently in HEAD. I will not debug K any existing bugs, my goal right now is to commit this update, which is K needed for further work. I.e., only when you get an issue with the patch K applied, but cannot reproduce the problem without the patch, please K prepare a bug report. Thinkpad X1 Carbon: screen black after X starts. -- Totus tuus, Glebius. ___ 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: i915 driver update testing
On 10/05/2014 13:00, Konstantin Belousov wrote: On Sun, Oct 05, 2014 at 11:01:14AM -0400, Adam McDougall wrote: (kgdb) #0 doadump (textdump=1) at pcpu.h:219 #1 0x80661efd in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0x80662450 in panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:746 #3 0x808fe52f in trap_fatal (frame=value optimized out, eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:866 #4 0x808fe87c in trap_pfault (frame=0xfe01fe0b21b0, usermode=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:677 #5 0x808fde9e in trap (frame=0xfe01fe0b21b0) at /usr/src/sys/amd64/amd64/trap.c:426 #6 0x808e00a2 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #7 0x8166808e in i915_write32 (dev_priv=0xf800031f1c00, reg=20736, val=0) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_drv.c:992 In kgdb, from this frame, please do p *dev_priv p *(dev_priv-dev) p *(dev_priv-info) http://www.egr.msu.edu/~mcdouga9/i915-1b.txt Sorry for the delay. I duplicated this on a spare computer of the same model so I can test easier. ___ 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: i915 driver update testing
On Mon, Oct 06, 2014 at 07:30:20PM -0400, Adam McDougall wrote: On 10/05/2014 13:00, Konstantin Belousov wrote: On Sun, Oct 05, 2014 at 11:01:14AM -0400, Adam McDougall wrote: (kgdb) #0 doadump (textdump=1) at pcpu.h:219 #1 0x80661efd in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0x80662450 in panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:746 #3 0x808fe52f in trap_fatal (frame=value optimized out, eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:866 #4 0x808fe87c in trap_pfault (frame=0xfe01fe0b21b0, usermode=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:677 #5 0x808fde9e in trap (frame=0xfe01fe0b21b0) at /usr/src/sys/amd64/amd64/trap.c:426 #6 0x808e00a2 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #7 0x8166808e in i915_write32 (dev_priv=0xf800031f1c00, reg=20736, val=0) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_drv.c:992 In kgdb, from this frame, please do p *dev_priv p *(dev_priv-dev) p *(dev_priv-info) http://www.egr.msu.edu/~mcdouga9/i915-1b.txt Sorry for the delay. I duplicated this on a spare computer of the same model so I can test easier. Great, thank you. Please also do, from the frame 12, p *dev ___ 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: i915 driver update testing
On 10/03/2014 13:02, Konstantin Belousov wrote: Please find at the https://kib.kiev.ua/kib/drm/i915.1.patch a patch which provides some updates to the i915 driver. At large, this is import of the batch of Linux commits, and as such, it is interesting mostly as attempt to restart the race to get us more up to date Linux code imported. It might provide some bug fixes, most likely for IvyBridge. Interesting from the development PoV is the update of the GEM i/o ioctl code path to mimic Linux code structure. I am asking _only_ for reports of regressions with the patch applied, comparing with the code which is currently in HEAD. I will not debug any existing bugs, my goal right now is to commit this update, which is needed for further work. I.e., only when you get an issue with the patch applied, but cannot reproduce the problem without the patch, please prepare a bug report. FYI, the driver will attach to haswell gfx, but I am not interested in reports about this (see above paragraph). On my test box, which is Core i7 4770S, the mode-setting and front-buffer rendering works, but Mesa immediately cause renderer to bug out. Work was sponsored by The FreeBSD Foundation, both by time and hardware, and Intel provided access to the documentation. I receive a Fatal trap 12: page fault while in kernel mode. I was previously loading i915kms in rc.conf on 10-stable where the screen would blank out for a short time then switch to native resolution. Last night I compiled a fresh kernel from -head so I could test recent ZFS code (userland still from 10). It behaved like 10. After applying i915.1.patch, the screen blanks in the same place then invisibly panics with a page fault. I hastily replaced the broken kernel so I didn't accidentally boot it, but I would be happy to compile a new one (FYI since info below may not match a new compile). Please tell me if or how you would like me to help. Thanks. FreeBSD colfax 11.0-CURRENT FreeBSD 11.0-CURRENT #2 r272549M: Sun Oct 5 10:32:28 EDT 2014 mcdouga9@colfax:/usr/obj/usr/src/sys/AMD64-11 amd64 panic: page fault CPU: Intel(R) Core(TM) i5 CPU 660 @ 3.33GHz (3325.07-MHz K8-class CPU) [11] Loading kernel modules: [11] info: [drm] Initialized drm 1.1.0 20060810 [11] drmn0: Intel IronLake on vgapci0 [11] info: [drm] MSI enabled 1 message(s) [11] info: [drm] AGP at 0xd000 256MB [11] iicbus0: Philips I2C bus on iicbb0 addr 0xff [11] iic0: I2C generic I/O on iicbus0 [11] iic1: I2C generic I/O on iicbus1 [11] iicbus2: Philips I2C bus on iicbb1 addr 0x0 [11] iic2: I2C generic I/O on iicbus2 [11] iic3: I2C generic I/O on iicbus3 [11] iicbus4: Philips I2C bus on iicbb2 addr 0x0 [11] iic4: I2C generic I/O on iicbus4 [11] iic5: I2C generic I/O on iicbus5 [11] iicbus6: Philips I2C bus on iicbb3 addr 0x0 [11] iic6: I2C generic I/O on iicbus6 [11] iic7: I2C generic I/O on iicbus7 [11] iicbus8: Philips I2C bus on iicbb4 addr 0x0 [11] iic8: I2C generic I/O on iicbus8 [11] iic9: I2C generic I/O on iicbus9 [11] iicbus10: Philips I2C bus on iicbb5 addr 0x0 [11] iic10: I2C generic I/O on iicbus10 [11] iic11: I2C generic I/O on iicbus11 [11] info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [11] info: [drm] Driver supports precise vblank timestamp query. [11] [11] [11] Fatal trap 12: page fault while in kernel mode [11] cpuid = 0; apic id = 00 [11] fault virtual address = 0x0 [11] fault code = supervisor read data, page not present [11] instruction pointer= 0x20:0x8166808e [11] stack pointer = 0x28:0xfe01fe0b2260 [11] frame pointer = 0x28:0xfe01fe0b22a0 [11] code segment = base 0x0, limit 0xf, type 0x1b [11]= DPL 0, pres 1, long 1, def32 0, gran 1 [11] processor eflags = interrupt enabled, resume, IOPL = 0 [11] current process= 124 (kldload) [11] trap number= 12 [11] panic: page fault [11] cpuid = 0 [11] Uptime: 11s [11] Dumping 252 out of 3874 MB:..7%..13%..26%..32%..45%..51%..64%..76%..83%..95% Reading symbols from /boot/kernel/zfs.ko.symbols...done. Loaded symbols for /boot/kernel/zfs.ko.symbols Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. Loaded symbols for /boot/kernel/opensolaris.ko.symbols Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. Loaded symbols for /boot/kernel/linprocfs.ko.symbols Reading symbols from /boot/kernel/linux.ko.symbols...done. Loaded symbols for /boot/kernel/linux.ko.symbols Reading symbols from /boot/kernel/i915kms.ko.symbols...done. Loaded symbols for /boot/kernel/i915kms.ko.symbols Reading symbols from /boot/kernel/drm2.ko.symbols...done. Loaded symbols for /boot/kernel/drm2.ko.symbols Reading symbols from /boot/kernel/iicbus.ko.symbols...done. Loaded symbols for /boot/kernel/iicbus.ko.symbols Reading symbols from /boot/kernel/iic.ko.symbols...done. Loaded symbols for /boot/kernel/iic.ko.symbols Reading symbols from
Re: i915 driver update testing
On Sun, Oct 05, 2014 at 11:01:14AM -0400, Adam McDougall wrote: (kgdb) #0 doadump (textdump=1) at pcpu.h:219 #1 0x80661efd in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0x80662450 in panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:746 #3 0x808fe52f in trap_fatal (frame=value optimized out, eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:866 #4 0x808fe87c in trap_pfault (frame=0xfe01fe0b21b0, usermode=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:677 #5 0x808fde9e in trap (frame=0xfe01fe0b21b0) at /usr/src/sys/amd64/amd64/trap.c:426 #6 0x808e00a2 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #7 0x8166808e in i915_write32 (dev_priv=0xf800031f1c00, reg=20736, val=0) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_drv.c:992 In kgdb, from this frame, please do p *dev_priv p *(dev_priv-dev) p *(dev_priv-info) #8 0x816928ae in intel_iicbb_pre_xfer (idev=value optimized out) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c:144 #9 0x81725a17 in iicbb_transfer (dev=0xf800066fa400, msgs=0xfe01fe0b2410, nmsgs=2) at iicbb_if.h:38 #10 0x816931b7 in intel_gmbus_transfer (idev=value optimized out, msgs=value optimized out, nmsgs=value optimized out) at iicbus_if.h:131 #11 0x816a16b3 in intel_sdvo_init (dev=value optimized out, sdvo_reg=value optimized out, is_sdvob=value optimized out) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_sdvo.c:286 #12 0x81681bd7 in intel_modeset_init (dev=0xf80003c04000) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_display.c:6603 #13 0x81664fb7 in i915_driver_load (dev=0xf80003c04000, flags=20736) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_dma.c:1167 #14 0x816e4b85 in drm_attach (kdev=0xf800031e3500, idlist=value optimized out) at /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_drv.c:591 at device_if.h:180 #16 0x806990f9 in bus_generic_driver_added ( dev=value optimized out, driver=value optimized out) at /usr/src/sys/kern/subr_bus.c:2793 #17 0x80695d5a in devclass_driver_added (dc=0xf80003085580, driver=0x816bdf20) at bus_if.h:204 #18 0x80695cbc in devclass_add_driver (dc=0xf80003085580, driver=0x816bdf20, pass=value optimized out, dcp=value optimized out) at /usr/src/sys/kern/subr_bus.c:1137 #19 0x80649d12 in module_register_init (arg=0x816bdf08) at /usr/src/sys/kern/kern_module.c:123 #20 0x8063d214 in linker_load_module (kldname=value optimized out, modname=0xf800060fc400 i915kms, parent=0x0, verinfo=0x0, lfpp=0xfe01fe0b2a80) at /usr/src/sys/kern/kern_linker.c:224 #21 0x8063ed08 in kern_kldload (td=value optimized out, file=value optimized out, fileid=0xfe01fe0b2ac4) at /usr/src/sys/kern/kern_linker.c:1029 #22 0x8063ee4b in sys_kldload (td=0xf80006584920, uap=value optimized out) at /usr/src/sys/kern/kern_linker.c:1055 #23 0x808fef8b in amd64_syscall (td=0xf80006584920, traced=0) at subr_syscall.c:133 #24 0x808e038b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:390 #25 0x000800888cba in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) ___ 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: i915 driver update testing
On Fri, 2014-10-03 at 20:02 +0300, Konstantin Belousov wrote: Please find at the https://kib.kiev.ua/kib/drm/i915.1.patch a patch which provides some updates to the i915 driver. At large, this is import of the batch of Linux commits, and as such, it is interesting mostly as attempt to restart the race to get us more up to date Linux code imported. It might provide some bug fixes, most likely for IvyBridge. Interesting from the development PoV is the update of the GEM i/o ioctl code path to mimic Linux code structure. I am asking _only_ for reports of regressions with the patch applied, comparing with the code which is currently in HEAD. I will not debug any existing bugs, my goal right now is to commit this update, which is needed for further work. I.e., only when you get an issue with the patch applied, but cannot reproduce the problem without the patch, please prepare a bug report. FYI, the driver will attach to haswell gfx, but I am not interested in reports about this (see above paragraph). On my test box, which is Core i7 4770S, the mode-setting and front-buffer rendering works, but Mesa immediately cause renderer to bug out. Work was sponsored by The FreeBSD Foundation, both by time and hardware, and Intel provided access to the documentation. Hi, I got a working X-server and framebuffer console on my Sandybridge system. The only regression I noticed so far is the line below, where the number after 'expected' changes per time the line is printed. Oct 5 21:50:12 crashalot kernel: error: [drm:pid1049:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 160d, was 1600 Oct 5 21:51:04 crashalot kernel: error: [drm:pid1049:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 160d, was 1600 Oct 5 21:53:14 crashalot kernel: error: [drm:pid1170:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 160d, was 1600 ___ 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: i915 driver update testing
2014-10-03 19:02 GMT+02:00 Konstantin Belousov kostik...@gmail.com: Please find at the https://kib.kiev.ua/kib/drm/i915.1.patch a patch which provides some updates to the i915 driver. At large, this is import of the batch of Linux commits, and as such, it is interesting mostly as attempt to restart the race to get us more up to date Linux code imported. It might provide some bug fixes, most likely for IvyBridge. Interesting from the development PoV is the update of the GEM i/o ioctl code path to mimic Linux code structure. I am asking _only_ for reports of regressions with the patch applied, comparing with the code which is currently in HEAD. I will not debug any existing bugs, my goal right now is to commit this update, which is needed for further work. I.e., only when you get an issue with the patch applied, but cannot reproduce the problem without the patch, please prepare a bug report. FYI, the driver will attach to haswell gfx, but I am not interested in reports about this (see above paragraph). On my test box, which is Core i7 4770S, the mode-setting and front-buffer rendering works, but Mesa immediately cause renderer to bug out. Work was sponsored by The FreeBSD Foundation, both by time and hardware, and Intel provided access to the documentation. ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-x11 To unsubscribe, send any mail to freebsd-x11-unsubscr...@freebsd.org On a Samsung ATIV Book 2 15.6” Notebook - NP270E5E, specs, http://www.samsung.com/us/computer/pcs/NP270E5E-K02US-specs the patch does not works. The result of the command # kldload i915kms is a blank screen. After rebooting the notebook, in /var/log/messages I can read: Oct 4 08:12:44 ativ kernel: info: [drm] Initialized drm 1.1.0 20060810 Oct 4 08:12:45 ativ kernel: drmn0: Intel IvyBridge (M) on vgapci0 Oct 4 08:12:45 ativ kernel: info: [drm] MSI enabled 1 message(s) Oct 4 08:12:45 ativ kernel: info: [drm] AGP at 0xe000 256MB Oct 4 08:12:45 ativ kernel: iicbus0: Philips I2C bus on iicbb0 addr 0xff Oct 4 08:12:45 ativ kernel: iic0: I2C generic I/O on iicbus0 Oct 4 08:12:45 ativ kernel: iic1: I2C generic I/O on iicbus1 Oct 4 08:12:45 ativ kernel: iicbus2: Philips I2C bus on iicbb1 addr 0x0 Oct 4 08:12:45 ativ kernel: iic2: I2C generic I/O on iicbus2 Oct 4 08:12:45 ativ kernel: iic3: I2C generic I/O on iicbus3 Oct 4 08:12:45 ativ kernel: iicbus4: Philips I2C bus on iicbb2 addr 0x0 Oct 4 08:12:45 ativ kernel: iic4: I2C generic I/O on iicbus4 Oct 4 08:12:45 ativ kernel: iic5: I2C generic I/O on iicbus5 Oct 4 08:12:45 ativ kernel: iicbus6: Philips I2C bus on iicbb3 addr 0x0 Oct 4 08:12:45 ativ kernel: iic6: I2C generic I/O on iicbus6 Oct 4 08:12:45 ativ kernel: iic7: I2C generic I/O on iicbus7 Oct 4 08:12:45 ativ kernel: iicbus8: Philips I2C bus on iicbb4 addr 0x0 Oct 4 08:12:45 ativ kernel: iic8: I2C generic I/O on iicbus8 Oct 4 08:12:45 ativ kernel: iic9: I2C generic I/O Oct 4 08:12:45 ativ kernel: on iicbus9 Oct 4 08:12:45 ativ kernel: iicbus10: Philips I2C bus on iicbb5 addr 0x0 Oct 4 08:12:45 ativ kernel: iic10: I2C generic I/O on iicbus10 Oct 4 08:12:45 ativ kernel: iic11: I2C generic I/O on iicbus11 Oct 4 08:12:45 ativ kernel: info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). Oct 4 08:12:45 ativ kernel: info: [drm] Driver supports precise vblank timestamp query. Regards 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: i915 driver update testing
Dear all, sorry for cross-posting (I am not subscribed to x11@). Same behavior for me (i5-3320M on a Thinkpad T430s w/ Optimus support) as reported by Maurizio. When boot switches to graphics from text mode, display remains black with backlight on. I am running the experimental xorg-stack from https://trillian.chruetertee.ch/svn/ports/branches/experimental which works with an unmodified r272482 w/o problem (minus the Optimus, obviously). No entry in Xorg.0.log. /var/log/messages only contains output from consolekit, saying it waits for a native display on tty 9. Please let me know if you want me to test anything further. Best Johannes On Fri, Oct 3, 2014 at 7:02 PM, Konstantin Belousov kostik...@gmail.com wrote: Please find at the https://kib.kiev.ua/kib/drm/i915.1.patch a patch which provides some updates to the i915 driver. At large, this is import of the batch of Linux commits, and as such, it is interesting mostly as attempt to restart the race to get us more up to date Linux code imported. It might provide some bug fixes, most likely for IvyBridge. Interesting from the development PoV is the update of the GEM i/o ioctl code path to mimic Linux code structure. I am asking _only_ for reports of regressions with the patch applied, comparing with the code which is currently in HEAD. I will not debug any existing bugs, my goal right now is to commit this update, which is needed for further work. I.e., only when you get an issue with the patch applied, but cannot reproduce the problem without the patch, please prepare a bug report. FYI, the driver will attach to haswell gfx, but I am not interested in reports about this (see above paragraph). On my test box, which is Core i7 4770S, the mode-setting and front-buffer rendering works, but Mesa immediately cause renderer to bug out. Work was sponsored by The FreeBSD Foundation, both by time and hardware, and Intel provided access to the documentation. ___ 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
