Re: i915 crash

From: Adrian Chadd <adrian_at_freebsd.org>
Date: Mon, 19 Jan 2015 22:50:50 -0800
I'm running with this patch right now; I was seeing "panic: in GPU
write domain" and with this patch I'm not.



-a


On 7 January 2015 at 10:23, Konstantin Belousov <kostikbel_at_gmail.com> wrote:
> On Wed, Jan 07, 2015 at 01:01:23AM -0500, Allan Jude wrote:
>> I grabbed the latest i915.8.patch from kib_at_'s website and compiled it
>> against r276774 (today)
>>
>> Machine is a Lenovo T530, booted UEFI, with the nvidia GPU disabled.
>>
>> CPU: Intel(R) Core(TM) i5-3320M CPU _at_ 2.60GHz (2594.16-MHz K8-class CPU)
>>
>> It is an Ivy-bridge CPU/GPU
>>
>> I installed xorg and kde, and when I try to start KDE, it loads, and
>> gets so far as showing the FreeBSD wallpaper, then panics:
>>
>>
>> text dump: http://www.allanjude.com/bsd/i915_core.3.txt
>> Full dump: (26mb compressed, 740mb original)
> This is useless for anybody except you.
>
>> http://www.allanjude.com/bsd/i915_vmcore.3.xz
>>
>> Unread portion of the kernel message buffer:
>> panic: In GPU write domain
>> cpuid = 3
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>> 0xfffffe045e52e600
>> vpanic() at vpanic+0x189/frame 0xfffffe045e52e680
>> kassert_panic() at kassert_panic+0x132/frame 0xfffffe045e52e6f0
>> i915_gem_pread_ioctl() at i915_gem_pread_ioctl+0x678/frame
>> 0xfffffe045e52e790
>> drm_ioctl() at drm_ioctl+0x318/frame 0xfffffe045e52e800
>> devfs_ioctl_f() at devfs_ioctl_f+0x122/frame 0xfffffe045e52e860
>> kern_ioctl() at kern_ioctl+0x2c0/frame 0xfffffe045e52e8c0
>> sys_ioctl() at sys_ioctl+0x153/frame 0xfffffe045e52e9a0
>> amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe045e52eab0
>> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe045e52eab0
>> --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8022a56fa, rsp =
>> 0x7fffffffe718, rbp = 0x7fffffffe740 ---
>> KDB: enter: panic
>> Uptime: 9m19s
>> Dumping 739 out of 16176
>> MB:..3%..11%..22%..31%..42%..52%..61%..72%..81%..91%
>>
>> 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 /boot/kernel/iicbb.ko.symbols...done.
>> Loaded symbols for /boot/kernel/iicbb.ko.symbols
>> #0  doadump (textdump=Unhandled dwarf expression opcode 0x93
>> ) at pcpu.h:219
>> 219   pcpu.h: No such file or directory.
>>       in pcpu.h
>> (kgdb) #0  doadump (textdump=Unhandled dwarf expression opcode 0x93
>> ) at pcpu.h:219
>> #1  0xffffffff80965d27 in kern_reboot (howto=Unhandled dwarf expression
>> opcode 0x93
>> )
>>     at /usr/src/sys/kern/kern_shutdown.c:448
>> #2  0xffffffff80966318 in vpanic (fmt=<value optimized out>,
>>     ap=<value optimized out>) at /usr/src/sys/kern/kern_shutdown.c:747
>> #3  0xffffffff80966142 in kassert_panic (fmt=<value optimized out>)
>>     at /usr/src/sys/kern/kern_shutdown.c:635
>> #4  0xffffffff81e1de88 in i915_gem_pread_ioctl (dev=0xfffff8002ffd1000,
>>     data=0xfffffe045e52e8f0, file=<value optimized out>)
>>     at
>> /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:3010
>
>> #5  0xffffffff81e9a398 in drm_ioctl (kdev=<value optimized out>,
>>     cmd=2149606492, data=0xfffffe045e52e8f0 "y", flags=Unhandled dwarf
>> expression opcode 0x93
>> )
>>     at /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_drv.c:942
>> #6  0xffffffff80849942 in devfs_ioctl_f (fp=0xfffff80009c15690,
>>     com=2149606492, data=0xfffffe045e52e8f0, cred=0xfffffe045e52e8f0,
>>     td=0xfffff80009c74000) at /usr/src/sys/fs/devfs/devfs_vnops.c:775
>> #7  0xffffffff809c3ad0 in kern_ioctl (td=0xfffff80009c74000,
>>     fd=<value optimized out>, com=0, data=<value optimized out>) at
>> file.h:318
>> #8  0xffffffff809c3763 in sys_ioctl (td=0xfffff80009c74000,
>>     uap=0xfffffe045e52ea40) at /usr/src/sys/kern/sys_generic.c:718
>> #9  0xffffffff80d8590a in amd64_syscall (td=0xfffff80009c74000, traced=0)
>>     at subr_syscall.c:133
>> #10 0xffffffff80d632ab in Xfast_syscall ()
>>     at /usr/src/sys/amd64/amd64/exception.S:395
>> #11 0x00000008022a56fa in ?? ()
>> Previous frame inner to this frame (corrupt stack?)
>> Current language:  auto; currently minimal
>>
>
> Is this reproducable ?
>
> Try the following patch on top of i915.8.
>
> commit 9af6c652745f551e2b6ce5218e350a5e47999feb
> Author: Konstantin Belousov <kib_at_freebsd.org>
> Date:   Wed Jan 7 20:21:46 2015 +0200
>
>     Properly move object into gtt domain when needed.
>
> diff --git a/sys/dev/drm2/i915/i915_gem.c b/sys/dev/drm2/i915/i915_gem.c
> index 0f72d08..58cbb59 100644
> --- a/sys/dev/drm2/i915/i915_gem.c
> +++ b/sys/dev/drm2/i915/i915_gem.c
> _at__at_ -1251,7 +1251,7 _at__at_ i915_gem_shmem_pread(struct drm_device *dev,
>                  * optimizes for the case when the gpu will dirty the data
>                  * anyway again before the next pread happens. */
>                 needs_clflush = !cpu_cache_is_coherent(dev, obj->cache_level);
> -               ret = i915_gem_object_wait_rendering(obj);
> +               ret = i915_gem_object_set_to_gtt_domain(obj, false);
>                 if (ret)
>                         return ret;
>         }
> _at__at_ -1579,7 +1579,7 _at__at_ i915_gem_shmem_pwrite(struct drm_device *dev,
>                  * optimizes for the case when the gpu will use the data
>                  * right away and we therefore have to clflush anyway. */
>                 needs_clflush_after = cpu_write_needs_clflush(obj);
> -               ret = i915_gem_object_wait_rendering(obj);
> +               ret = i915_gem_object_set_to_gtt_domain(obj, true);
>                 if (ret)
>                         return ret;
>         }
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
Received on Tue Jan 20 2015 - 05:50:52 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:55 UTC