Bug 455272 - kerneloops :radeon:radeon_do_cp_idle+0x169
Summary: kerneloops :radeon:radeon_do_cp_idle+0x169
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati
Version: 9
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Dave Airlie
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-07-14 15:52 UTC by Jack Tanner
Modified: 2018-04-11 19:28 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-12-04 19:42:00 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Xorg.0.log, no crash (90.04 KB, text/plain)
2008-07-15 21:25 UTC, Jack Tanner
no flags Details

Description Jack Tanner 2008-07-14 15:52:20 UTC
Breaking out for higher visibility...

+++ This bug was initially created as a clone of Bug #448609 +++

BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
IP: [<ffffffff883fb8a8>] :radeon:radeon_do_cp_idle+0x169/0x1af
PGD 0 
Oops: 0000 [1] SMP 
CPU 0 
Modules linked in: radeon drm bridge bnep rfcomm l2cap bluetooth ppdev
parport_pc parport fuse sunrpc ipt_REJECT nf_conntrack_ipv4 iptable_filter
ip_tables nf_conntrack_netbios_ns ip6t_REJECT xt_tcpudp nf_conntrack_ipv6
xt_state nf_conntrack ip6table_filter ip6_tables x_tables ipv6 cpufreq_ondemand
powernow_k8 freq_table loop dm_multipath snd_hda_intel snd_seq_dummy snd_seq_oss
snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm
i2c_nforce2 firewire_ohci firewire_core i2c_core snd_timer snd_page_alloc
snd_hwdep snd pata_amd forcedeth button soundcore e1000 crc_itu_t k8temp pcspkr
usb_storage hwmon sr_mod cdrom sg dm_snapshot dm_zero dm_mirror dm_mod
ata_generic pata_acpi sata_nv libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd
ohci_hcd ehci_hcd [last unloaded: scsi_wait_scan]
Pid: 3237, comm: Xorg Not tainted 2.6.25.9-76.fc9.x86_64 #1
RIP: 0010:[<ffffffff883fb8a8>]  [<ffffffff883fb8a8>]
:radeon:radeon_do_cp_idle+0x169/0x1af
RSP: 0018:ffff81010c433d28  EFLAGS: 00010202
RAX: 0000000000000000 RBX: ffff81011246e000 RCX: 0000000000033154
RDX: 0000000000033154 RSI: 000000000003ffff RDI: ffff81011246e000
RBP: ffff81010c433d38 R08: ffff81010c432000 R09: 0000000000000000
R10: ffff81010c4a2340 R11: ffff81010c49b010 R12: ffff81010c49b000
R13: ffff81010c4a2300 R14: ffff81010c4a2340 R15: ffff81010c49b010
FS:  00007f1001ee0780(0000) GS:ffffffff813f2000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000000201000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process Xorg (pid: 3237, threadinfo ffff81010c432000, task ffff81010c430000)
Stack:  ffff81010c4a2340 ffff81011246e000 ffff81010c433d58 ffffffff883fc53b
 ffff81010c49b00c ffff81010c49b000 ffff81010c433d68 ffffffff88405fc9
 ffff81010c433da8 ffffffff883cec96 ffff81010c4a2340 ffff81010c49b00c
Call Trace:
 [<ffffffff883fc53b>] :radeon:radeon_do_release+0x4f/0x12a
 [<ffffffff88405fc9>] :radeon:radeon_driver_lastclose+0x9/0xb
 [<ffffffff883cec96>] :drm:drm_lastclose+0x61/0x2ce
 [<ffffffff883cf5a6>] :drm:drm_release+0x478/0x495
 [<ffffffff810a4f07>] __fput+0xca/0x189
 [<ffffffff810a4fda>] fput+0x14/0x16
 [<ffffffff810a22d0>] filp_close+0x66/0x71
 [<ffffffff8103531e>] put_files_struct+0x74/0xc8
 [<ffffffff810353b9>] __exit_files+0x47/0x50
 [<ffffffff81036b8f>] do_exit+0x299/0x656
 [<ffffffff81036fc7>] do_group_exit+0x7b/0x96
 [<ffffffff81036ff4>] sys_exit_group+0x12/0x14
 [<ffffffff8100c052>] tracesys+0xd5/0xda
Code: 88 48 c7 c7 b3 e3 40 88 31 c0 e8 b7 97 e9 f8 eb 03 89 53 28 0f ae f0 83 bb
88 00 00 00 00 74 0f 48 8b 83 20 01 00 00 48 8b 40 18 <8b> 00 eb 11 48 8b 83 f8
03 00 00 48 8b 40 18 8b 80 10 07 00 00 
RIP  [<ffffffff883fb8a8>] :radeon:radeon_do_cp_idle+0x169/0x1af
 RSP <ffff81010c433d28>
CR2: 0000000000000000
---[ end trace cac7fab38fd89a9f ]---

Comment 1 Jack Tanner 2008-07-14 15:53:55 UTC
P.S. This is on

xorg-x11-server-Xorg-1.4.99.905-1.20080701.fc9.x86_64
xorg-x11-drv-ati-6.8.0-18.fc9.x86_64
Linux goldin-pc 2.6.25.9-76.fc9.x86_64 #1 SMP Fri Jun 27 15:58:30 EDT 2008
x86_64 x86_64 x86_64 GNU/Linux


Comment 2 Matěj Cepl 2008-07-14 22:43:19 UTC
Would you be able to find and attach /var/log/Xorg.*.log from the moment of crash?

Comment 3 Jack Tanner 2008-07-15 21:25:06 UTC
Created attachment 311886 [details]
Xorg.0.log, no crash

I can't seem to repro the crash. My machine has been running all day. The
kernel's changed; could that have fixed it? I'm now on
kernel-2.6.25.10-86.fc9.x86_64

I'm enclosing /var/log/Xorg.0.log just in case. Note this, which seems wrong:

(--) PCI:*(0@2:0:0) ATI Technologies Inc unknown chipset (0x71d2) rev 0, Mem @
0xe8000000/134217728, 0xfdbf0000/65536, I/O @ 0x00009c00/256, BIOS @
0x????????/131072
(--) PCI: (0@2:0:1) ATI Technologies Inc unknown chipset (0x71f2) rev 0, Mem @
0xfdbe0000/65536

Also, there's debugging output like this:

Output 66 disable success
Output 51 disable success
Blank CRTC 0 success
Disable CRTC 0 success
Blank CRTC 1 success
Disable CRTC 1 success
Enable CRTC 0 success
Unblank CRTC 0 success

Comment 4 Matěj Cepl 2008-07-15 23:28:16 UTC
Dave, do you see anything suspicious, or this could be just closed?

Comment 5 Jack Tanner 2008-07-16 16:48:00 UTC
Does it make sense that the oops got closed out by something fixed in the kernel
between 2.6.25.9-76.fc9.x86_64 and 2.6.25.10-86.fc9.x86_64 ?

Comment 6 Jack Tanner 2008-07-24 15:10:23 UTC
OK, there's no longer a hard crash... just a "soft" one. xorg uses up 100% of
CPU thereby locking the machine. This usually happens after about a day of
working (with compiz enabled).

Comment 7 Jack Tanner 2008-08-06 20:10:27 UTC
Ping?

Comment 8 Jack Tanner 2008-12-04 19:42:00 UTC
Well, I haven't seen either a crash or a lock-up in a while, and many a kernel has been released since. Closing.


Note You need to log in before you can comment on or make changes to this bug.