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
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: 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: 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
