在 2011年10月17日 下午2:34， <chenhc@xxxxxxxxxx>写道：
If I start X but switch to the console, then do suspend & resume, "GPU
reset" hardly happen. but there is a new problem that the IRQ of radeon
card is disabled. Maybe "GPU reset" has something to do with "IRQ
disabled"?
I have tried "irqpoll", it doesn't fix this problem.
[ 571.914062] irq 6: nobody cared (try booting with the "irqpoll" option)
[ 571.914062] Call Trace:
[ 571.914062] [<ffffffff806f3248>] dump_stack+0x8/0x34
[ 571.914062] [<ffffffff8027e1e4>] __report_bad_irq.clone.6+0x44/0x15c
[ 571.914062] [<ffffffff8027e584>] note_interrupt+0x204/0x2a0
[ 571.914062] [<ffffffff8027c7cc>] handle_irq_event_percpu+0x19c/0x1f8
[ 571.914062] [<ffffffff8027c890>] handle_irq_event+0x68/0xa8
[ 571.914062] [<ffffffff8027f038>] handle_level_irq+0xd8/0x13c
[ 571.914062] [<ffffffff8027bec8>] generic_handle_irq+0x48/0x58
[ 571.914062] [<ffffffff80204574>] do_IRQ+0x18/0x24
[ 571.914062] [<ffffffff8020152c>] mach_irq_dispatch+0xf0/0x194
[ 571.914062] [<ffffffff80202a40>] ret_from_irq+0x0/0x4
[ 571.914062]
[ 571.914062] handlers:
[ 571.914062] [<ffffffff8053bba8>] radeon_driver_irq_handler_kms
P.S.: use the latest kernel from git, and irq6 is not shared by other
devices.
Does fence_wait depends on GPU's interrupt? If yes, then can I say "GPU lockup" is caused by unexpected disabling of GPU's irq?
> Hi Alex, Michel
>
> 2011/10/5 Alex Deucher <alexdeucher@xxxxxxxxx>
>
>> 2011/10/5 Michel D鋘zer <michel@xxxxxxxxxxx>:
>> > On Don, 2011-09-29 at 17:17 +0800, Chen Jie wrote:
>> >>
>> >> We got occasionally "GPU lockup" after resuming from suspend(on
>> mipsel
>> >> platform with a mips64 compatible CPU and rs780e, the kernel is
>> >> 3.1.0-rc8 64bit). Related kernel message:
>> >
>> > [...]
>> >
>> >> [ 177.085937] radeon 0000:01:05.0: GPU lockup CP stall for more than
>> >> 10019msec
>> >> [ 177.089843] ------------[ cut here ]------------
>> >> [ 177.097656] WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:267
>> >> radeon_fence_wait+0x25c/0x33c()
>> >> [ 177.105468] GPU lockup (waiting for 0x000013C3 last fence id
>> >> 0x000013AD)
>> >> [ 177.113281] Modules linked in: psmouse serio_raw
>> >> [ 177.117187] Call Trace:
>> >> [ 177.121093] [<ffffffff806f3e7c>] dump_stack+0x8/0x34
>> >> [ 177.125000] [<ffffffff8022e4f4>] warn_slowpath_common+0x78/0xa0
>> >> [ 177.132812] [<ffffffff8022e5b8>] warn_slowpath_fmt+0x38/0x44
>> >> [ 177.136718] [<ffffffff80522ed8>] radeon_fence_wait+0x25c/0x33c
>> >> [ 177.144531] [<ffffffff804e9e70>] ttm_bo_wait+0x108/0x220
>> >> [ 177.148437] [<ffffffff8053b478>] radeon_gem_wait_idle_ioctl
>> >> +0x80/0x114
>> >> [ 177.156250] [<ffffffff804d2fe8>] drm_ioctl+0x2e4/0x3fc
>> >> [ 177.160156] [<ffffffff805a1820>] radeon_kms_compat_ioctl+0x28/0x38
>> >> [ 177.167968] [<ffffffff80311a04>] compat_sys_ioctl+0x120/0x35c
>> >> [ 177.171875] [<ffffffff80211d18>] handle_sys+0x118/0x138
>> >> [ 177.179687] ---[ end trace 92f63d998efe4c6d ]---
>> >> [ 177.187500] radeon 0000:01:05.0: GPU softreset
>> >> [ 177.191406] radeon 0000:01:05.0: R_008010_GRBM_STATUS=0xF57C2030
>> >> [ 177.195312] radeon 0000:01:05.0:
>> R_008014_GRBM_STATUS2=0x00111103
>> >> [ 177.203125] radeon 0000:01:05.0: R_000E50_SRBM_STATUS=0x20023040
>> >> [ 177.363281] radeon 0000:01:05.0: Wait for MC idle timedout !
>> >
>> > [...]
>> >
>> >> What may cause a "GPU lockup"?
>> >
>> > Lots of things... The most common cause is an incorrect command stream
>> > sent to the GPU by userspace or the kernel.
>> >
>> >> Why reset didn't work?
>> >
>> > Might be related to 'Wait for MC idle timedout !', but I don't know
>> > offhand what could be up with that.
>> >
>> >
>> >> BTW, one question:
>> >> I got 'RADEON_IS_PCI | RADEON_IS_IGP' in rdev->flags, which causes
>> >> need_dma32 was set.
>> >> Is it correct? (drivers/char/agp is not available on mips, could that
>> >> be the reason?)
>> >
>> > Not sure, Alex?
>>
>> You don't AGP for newer IGP cards (rs4xx+). It gets set by default if
>> the card is not AGP or PCIE. That should be changed as only the
>> legacy r1xx PCI GART block has that limitation. I'll send a patch out
>> shortly.
>>
>> Got it, thanks for the reply.
>
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
