Bug#648398: xserver-xorg-video-radeon: Soft Kernel Panic with DRI and modeset=1 on Mac Mini G4 causes black screen

Fri Nov 11 05:24:06 PST 2011

On Don, 2011-11-10 at 21:57 -0700, Robert LeBlanc wrote: 
> 
> If I set modeset=0, the system is stable albeit that it is not using
> the hardware acceleration.

The r200 drivers don't require KMS for acceleration. What exactly is the
problem in that case?

> Nov 10 21:16:57 debmac kernel: [  330.214801] radeon 0000:00:10.0: GPU lockup CP stall for more than 10000msec
> Nov 10 21:16:58 debmac kernel: [  330.214814] GPU lockup (waiting for 0x000002F6 last fence id 0x000002F3)

Something (most likely the libgl1-mesa-dri r200 driver, or possibly the
xserver-xorg-video-radeon driver) is causing the GPU to lock up.

> Nov 10 21:16:58 debmac kernel: [  330.352677] radeon: wait for empty RBBM fifo failed ! Bad things might happen.
> Nov 10 21:16:58 debmac kernel: [  330.489510] Failed to wait GUI idle while programming pipes. Bad things might happen.
> Nov 10 21:16:58 debmac kernel: [  330.493286] radeon 0000:00:10.0: (r100_asic_reset:2093) RBBM_STATUS=0x8002C139
> Nov 10 21:16:58 debmac kernel: [  330.497263] Machine check in kernel mode.
> Nov 10 21:16:58 debmac kernel: [  330.497268] Caused by (from SRR1=149030): Transfer error ack signal
> Nov 10 21:16:58 debmac kernel: [  330.497305] Oops: Machine check, sig: 7 [#1]
> Nov 10 21:16:58 debmac kernel: [  330.497480] PowerMac
> Nov 10 21:16:58 debmac kernel: [  330.497560] Modules linked in: uinput fuse nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc ext2 snd_aoa_codec_toonie snd_aoa_i2sbus snd_pcm snd_page_alloc snd_aoa_fabric_layout snd_aoa_soundbus snd_aoa snd_seq snd_timer snd_seq_device snd soundcore loop firewire_sbp2 radeon evdev ttm drm_kms_helper drm i2c_powermac power_supply ext4 mbcache jbd2 crc16 dm_mod sg usbhid hid sr_mod sd_mod crc_t10dif cdrom usb_storage uas ohci_hcd pata_macio libata ehci_hcd scsi_mod firewire_ohci firewire_core crc_itu_t sungem sungem_phy usbcore [last unloaded: scsi_wait_scan]
> Nov 10 21:16:58 debmac kernel: [  330.499618] NIP: f215d0f4 LR: f215d084 CTR: c000bd38
> Nov 10 21:16:58 debmac kernel: [  330.499803] REGS: c1fb7c00 TRAP: 0200   Tainted: G        W    (3.1.0.2011.10.31.01)
> Nov 10 21:16:58 debmac kernel: [  330.500091] MSR: 00149030 <EE,ME,IR,DR>  CR: 44024884  XER: 20000000
> Nov 10 21:16:58 debmac kernel: [  330.500352] TASK = c199a8f0[1121] 'Xorg' THREAD: c1fb6000
> Nov 10 21:16:58 debmac kernel: [  330.500550] GPR00: ac04007c c1fb7cb0 c199a8f0 0000a028 00000000 00010004 00000004 0000a260 
> Nov 10 21:16:58 debmac kernel: [  330.500889] GPR08: 00007e14 f22200f0 00000000 c1fb7cb0 84024882 2037b9c4 208ccb98 20373b10 
> Nov 10 21:16:58 debmac kernel: [  330.501228] GPR16: 20373af4 ef8e2000 20373af8 f21d0000 f21d0000 c04b0000 f21c5ed0 c005d900 
> Nov 10 21:16:58 debmac kernel: [  330.501697] GPR24: 00000001 000002f3 c1fb7d14 c190b774 00000001 00000000 00000000 c190b000 
> Nov 10 21:16:58 debmac kernel: [  330.502109] NIP [f215d0f4] r100_asic_reset+0x2a0/0x4e4 [radeon]
> Nov 10 21:16:58 debmac kernel: [  330.502349] LR [f215d084] r100_asic_reset+0x230/0x4e4 [radeon]
> Nov 10 21:16:58 debmac kernel: [  330.502647] Call Trace:
> Nov 10 21:16:58 debmac kernel: [  330.502765] [c1fb7cb0] [f215d084] r100_asic_reset+0x230/0x4e4 [radeon] (unreliable)

[...]

> Nov 10 21:16:58 debmac kernel: [  330.508368] Machine check in kernel mode.
> Nov 10 21:16:58 debmac kernel: [  330.508533] Caused by (from SRR1=149030): Transfer error ack signal
> Nov 10 21:16:58 debmac kernel: [  330.508790] Oops: Machine check, sig: 7 [#2]
> Nov 10 21:16:58 debmac kernel: [  330.508948] PowerMac
> Nov 10 21:16:58 debmac kernel: [  330.509027] Modules linked in: uinput fuse nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc ext2 snd_aoa_codec_toonie snd_aoa_i2sbus snd_pcm snd_page_alloc snd_aoa_fabric_layout snd_aoa_soundbus snd_aoa snd_seq snd_timer snd_seq_device snd soundcore loop firewire_sbp2 radeon evdev ttm drm_kms_helper drm i2c_powermac power_supply ext4 mbcache jbd2 crc16 dm_mod sg usbhid hid sr_mod sd_mod crc_t10dif cdrom usb_storage uas ohci_hcd pata_macio libata ehci_hcd scsi_mod firewire_ohci firewire_core crc_itu_t sungem sungem_phy usbcore [last unloaded: scsi_wait_scan]
> Nov 10 21:16:58 debmac kernel: [  330.511075] NIP: f2134134 LR: f213dba8 CTR: f213db6c
> Nov 10 21:16:58 debmac kernel: [  330.511260] REGS: c1fb7670 TRAP: 0200   Tainted: G        W    (3.1.0.2011.10.31.01)
> Nov 10 21:16:58 debmac kernel: [  330.511547] MSR: 00149030 <EE,ME,IR,DR>  CR: 24024884  XER: 00000000
> Nov 10 21:16:58 debmac kernel: [  330.511808] TASK = c199a8f0[1121] 'Xorg' THREAD: c1fb6000
> Nov 10 21:16:58 debmac kernel: [  330.512007] GPR00: 00010000 c1fb7720 c199a8f0 c184aa00 00000001 f1f9f0f4 f1f9f580 0000000a 
> Nov 10 21:16:58 debmac kernel: [  330.512346] GPR08: 00000000 c190b000 00000018 08000048 00000400 2037b9c4 efb7c800 c1895000 
> Nov 10 21:16:58 debmac kernel: [  330.512685] GPR16: edb16f60 f1f9f54c 00000000 ef329800 c184aa00 c18dab20 00000000 00000000 
> Nov 10 21:16:58 debmac kernel: [  330.513024] GPR24: f21b6378 00000001 ed87a080 ef8e2258 ef8e2000 00000000 efb7f080 c184aa00 
> Nov 10 21:16:58 debmac kernel: [  330.513418] NIP [f2134134] radeon_combios_output_lock+0x3c/0x94 [radeon]

This is a known long-standing issue when the radeon driver tries to
reset the locked up GPU. It looks like the GPU stops responding to CPU
access at some point.

When I tried narrowing this down, I had a hard time getting debugging
output out of the r100_asic_reset() function. If you can get that
reliably, it would be great if you could try narrowing down where
exactly the first machine check occurs. So far, it looks like it happens
somewhere between the first and second dev_info() call about the
RBBM_STATUS register.

Let us know if you need help with this.

-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer