From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jochen Rollwagen Subject: Re: possible regression Radeon RV280 (R3xx/R4xx ?) card freeze, re-apply old patch ? Date: Fri, 22 Nov 2013 14:21:30 +0100 Message-ID: <528F5A5A.6020501@t-online.de> References: <526A6C61.1030405@t-online.de> <527C9444.4010505@t-online.de> <5283BFE9.5060208@t-online.de> <1384393062.18541.25.camel@thor.local> <5285D1FE.7080908@t-online.de> <1384504050.20465.9.camel@thor.local> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0785162914==" Return-path: Received: from mailout05.t-online.de (mailout05.t-online.de [194.25.134.82]) by gabe.freedesktop.org (Postfix) with ESMTP id 87B66FA7A3 for ; Fri, 22 Nov 2013 05:22:16 -0800 (PST) In-Reply-To: <1384504050.20465.9.camel@thor.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org To: =?UTF-8?B?TWljaGVsIETDpG56ZXI=?= Cc: Maling list - DRI developers List-Id: dri-devel@lists.freedesktop.org This is a multi-part message in MIME format. --===============0785162914== Content-Type: multipart/alternative; boundary="------------030305090304090900010803" This is a multi-part message in MIME format. --------------030305090304090900010803 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Am 15.11.2013 09:27, schrieb Michel D=C3=A4nzer: > On Fre, 2013-11-15 at 08:49 +0100, Jochen Rollwagen wrote: >> I think there are two issues here: the first is the missing alignment >> workaround, since i'll be upgrading to 3.4.69 anyway i'll insert some >> diagnostic messages in radeon_device.c and see what happens. > Yes, please do that before speculating more about the problem. > > >> But i'm pretty certain now that this isn't the cause for the lockups. >> They are probably (quite certainly) caused by the dynamic >> binding/unbinding of AGP memory which the Uninorth chipset used in >> 32-bit powermacs obviously doesn't support. > "doesn't support" is too strong; it's working fine on this PowerBook5,8= . > But the older the revision of UniNorth, the more quirks. > >> All it supports seems to be statically allocating a 256 MB contigouous >> non-cacheable AGP aperture and using that (since the chipset doesn't >> do any address mapping via the GART as indicated in the OpenBSD code). > It does address mapping for the GPU, that's the whole point of the GART= . > What UniNorth doesn't do in contrast to most AGP bridges is provide a > linear aperture to the CPU as well. But that shouldn't be an issue per > se. > >> So to get AGP mode working again on those machines one would have to >> disable the dynamic memory stuff. Question: Would that require changes >> in the driver only or also in the DRM ? > It's not really possible with radeon KMS. > > the relevant syslog part is: /var/log/syslog:Nov 22 11:32:08 mac-mini kernel: [ 3.363099] [drm]=20 Initialized radeon 2.16.0 20080528 for 0000:00:10.0 on minor 0 /var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [ 554.476580] radeon=20 0000:00:10.0: GPU lockup CP stall for more than 10000msec /var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [ 554.477629] radeon=20 0000:00:10.0: GPU reset succeed /var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [ 554.655218] kernel=20 BUG at drivers/gpu/drm/radeon/radeon_object.c:410! /var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [ 554.660331] Modules=20 linked in: dm_crypt arc4 btusb parport_pc ppdev b43 bnep joydev=20 bluetooth lp mac_hid parport rtc_generic mac80211 snd_aoa_codec_onyx=20 snd_aoa_codec_tas snd_aoa_codec_toonie cfg80211 snd_aoa_fabric_layout=20 snd_aoa snd_aoa_i2sbus snd_aoa_soundbus bcma snd_powermac snd_pcm=20 snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer=20 snd_seq_device snd soundcore snd_page_alloc usbhid hid radeon=20 firewire_ohci sungem firewire_core crc_itu_t sungem_phy ttm=20 drm_kms_helper ssb drm /var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [ 554.664059] NIP=20 [f15b5158] radeon_bo_get_surface_reg+0x30/0x144 [radeon] /var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [ 554.664313] LR=20 [f159b7b8] radeon_surface_init+0x3c/0xac [radeon] /var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [ 554.664657]=20 [eba63c10] [f15d10bc] r100_pll_rreg+0x58/0x70 [radeon] (unreliable) /var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [ 554.664931]=20 [eba63c30] [f159b7b8] radeon_surface_init+0x3c/0xac [radeon] /var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [ 554.665184]=20 [eba63c50] [f15d2edc] r100_resume+0x68/0x104 [radeon] /var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [ 554.665414]=20 [eba63c70] [f159d54c] radeon_gpu_reset+0x120/0x164 [radeon] /var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [ 554.665661]=20 [eba63c90] [f15b2544] radeon_fence_wait+0x3d8/0x404 [radeon] /var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [ 554.665914]=20 [eba63d00] [f15c7618] radeon_ib_get+0x250/0x2d0 [radeon] /var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [ 554.666155]=20 [eba63d50] [f15c9c80] radeon_cs_ioctl+0x3c4/0x6e0 [radeon] the code where the kernel bug seems to hit is int radeon_bo_get_surface_reg(struct radeon_bo *bo) { struct radeon_device *rdev =3D bo->rdev; struct radeon_surface_reg *reg; struct radeon_bo *old_object; int steal; int i; BUG_ON(!atomic_read(&bo->tbo.reserved)); --------------030305090304090900010803 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Am 15.11.2013 09:27, schrieb Michel D=C3=A4nzer:
On Fre, 2013-11-15 at 08:49 +0100, Jochen Rollwagen =
wrote:

I think there are two issues here: the first is th=
e missing alignment=20
workaround, since i'll be upgrading to 3.4.69 anyway i'll insert some=20
diagnostic messages in radeon_device.c and see what happens.

Yes, please do that before speculating more about the problem.



But i'm pretty certain now that this isn't the cau=
se for the lockups.
They are probably (quite certainly) caused by the dynamic
binding/unbinding of AGP memory which the Uninorth chipset used in
32-bit powermacs obviously doesn't support.

"doesn't support" is too strong; it's working fine on this PowerBook5,8.
But the older the revision of UniNorth, the more quirks.


All it supports seems to be statically allocating =
a 256 MB contigouous
non-cacheable AGP aperture and using that (since the chipset doesn't
do any address mapping via the GART as indicated in the OpenBSD code).

It does address mapping for the GPU, that's the whole point of the GART.
What UniNorth doesn't do in contrast to most AGP bridges is provide a
linear aperture to the CPU as well. But that shouldn't be an issue per
se.


So to get AGP mode working again on those machines=
 one would have to
disable the dynamic memory stuff. Question: Would that require changes
in the driver only or also in the DRM ?

It's not really possible with radeon KMS.
the relevant syslog part is:

/var/log/syslog:Nov 22 11:32:08 mac-mini kernel: [=C2=A0=C2=A0=C2=A0= 3.363099] [drm] Initialized radeon 2.16.0 20080528 for 0000:00:10.0 on minor 0
/var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [=C2=A0 554.476580= ] radeon 0000:00:10.0: GPU lockup CP stall for more than 10000msec /var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [=C2=A0 554.477629= ] radeon 0000:00:10.0: GPU reset succeed
/var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [=C2=A0 554.655218= ] kernel BUG at drivers/gpu/drm/radeon/radeon_object.c:410!
/var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [=C2=A0 554.660331= ] Modules linked in: dm_crypt arc4 btusb parport_pc ppdev b43 bnep joydev bluetooth lp mac_hid parport rtc_generic mac80211 snd_aoa_codec_onyx snd_aoa_codec_tas snd_aoa_codec_toonie cfg80211 snd_aoa_fabric_layout snd_aoa snd_aoa_i2sbus snd_aoa_soundbus bcma snd_powermac snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd soundcore snd_page_alloc usbhid hid radeon firewire_ohci sungem firewire_core crc_itu_t sungem_phy ttm drm_kms_helper ssb drm
/var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [=C2=A0 554.664059= ] NIP [f15b5158] radeon_bo_get_surface_reg+0x30/0x144 [radeon]
/var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [=C2=A0 554.664313= ] LR [f159b7b8] radeon_surface_init+0x3c/0xac [radeon]
/var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [=C2=A0 554.664657= ] [eba63c10] [f15d10bc] r100_pll_rreg+0x58/0x70 [radeon] (unreliable)
/var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [=C2=A0 554.664931= ] [eba63c30] [f159b7b8] radeon_surface_init+0x3c/0xac [radeon]
/var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [=C2=A0 554.665184= ] [eba63c50] [f15d2edc] r100_resume+0x68/0x104 [radeon]
/var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [=C2=A0 554.665414= ] [eba63c70] [f159d54c] radeon_gpu_reset+0x120/0x164 [radeon]
/var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [=C2=A0 554.665661= ] [eba63c90] [f15b2544] radeon_fence_wait+0x3d8/0x404 [radeon]
/var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [=C2=A0 554.665914= ] [eba63d00] [f15c7618] radeon_ib_get+0x250/0x2d0 [radeon]
/var/log/syslog:Nov 22 11:41:03 mac-mini kernel: [=C2=A0 554.666155= ] [eba63d50] [f15c9c80] radeon_cs_ioctl+0x3c4/0x6e0 [radeon]

the code where the kernel bug seems to hit is

int radeon_bo_get_surface_reg(struct radeon_bo *bo)
{
=C2=A0=C2=A0=C2=A0 struct radeon_device *rdev =3D bo->rdev;<= br> =C2=A0=C2=A0=C2=A0 struct radeon_surface_reg *reg;
=C2=A0=C2=A0=C2=A0 struct radeon_bo *old_object;
=C2=A0=C2=A0=C2=A0 int steal;
=C2=A0=C2=A0=C2=A0 int i;

=C2=A0=C2=A0=C2=A0 BUG_ON(!atomic_read(&bo->tbo.reserved= ));

--------------030305090304090900010803-- --===============0785162914== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============0785162914==--