Bug 479229 - radeon provokes GPF with F10 kernel
Summary: radeon provokes GPF with F10 kernel
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 10
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-01-08 07:01 UTC by Pierre Ossman
Modified: 2009-10-14 14:50 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-10-14 14:50:20 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Pierre Ossman 2009-01-08 07:01:46 UTC
I upgraded my HTPC to F10 and I started getting hangs whenever the system comes under some heavy video load. If I boot the system with the old F9 kernel, the problem goes away.

I've primarily been running with radeon HEAD and nomodeset, but I see the issue with the "normal" radeon driver as well.

This is the GPF I'm getting (the taint is caused by bug 438046):

general protection fault: 0000 [1] SMP 
CPU 1 
Modules linked in: nfs lockd nfs_acl lirc_serial lirc_dev f71882fg sunrpc ipv6 cpufreq_ondemand powernow_k8 freq_table dm_multipath ppdev snd_seq_dummy parport_pc parport snd_trident gameport snd_ac97_codec ac97_bus snd_util_mem snd_seq_oss snd_seq_midi_event snd_seq firewire_ohci k8temp hwmon pcspkr snd_mpu401_uart snd_rawmidi firewire_core crc_itu_t snd_hda_intel snd_seq_device snd_pcm_oss snd_mixer_oss i2c_piix4 snd_pcm ati_remote snd_timer snd_page_alloc snd_hwdep snd r8169 mii soundcore shpchp ata_generic pata_acpi pata_atiixp radeon drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan]
Pid: 3755, comm: mplayer Tainted: G        W 2.6.27.9-159.fc10.x86_64 #1
RIP: 0010:[<ffffffff81171028>]  [<ffffffff81171028>] list_del+0xc/0x85
RSP: 0018:ffff88005f9738b8  EFLAGS: 00210096
RAX: ff000000feffffd8 RBX: ff000000ff000000 RCX: ffff880000012258
RDX: ffff880000012220 RSI: 0000000000000000 RDI: ff000000ff000000
RBP: ffff88005f9738c8 R08: 0000000000000002 R09: 0000000000000000
R10: 000000000000080e R11: 0000000000000001 R12: 0000000000000000
R13: ffff880000012000 R14: 0000000000000000 R15: ffff880000012000
FS:  00007fbc34487750(0000) GS:ffff880077804880(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00007fc61b294000 CR3: 000000006847a000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process mplayer (pid: 3755, threadinfo ffff88005f972000, task ffff880071e01710)
Stack:  0000000000000000 ff000000ff000000 ffff88005f973938 ffffffff810928b1
 0000000000000020 0000000000000002 0000000000000020 ffff880000012200
 000000005f973908 ffff880000012258 ff000000feffffd8 ffff880000012000
Call Trace:
 [<ffffffff810928b1>] __rmqueue_smallest+0x81/0x14d
 [<ffffffff8109299c>] __rmqueue+0x1f/0x1de
 [<ffffffff81092ba7>] rmqueue_bulk+0x4c/0x99
 [<ffffffff810945eb>] get_page_from_freelist+0x2db/0x6d1
 [<ffffffff810340a6>] ? pick_next_task_fair+0x9d/0xac
 [<ffffffff81094d17>] __alloc_pages_internal+0xfe/0x457
 [<ffffffff810b2676>] alloc_pages_current+0xb9/0xc2
 [<ffffffff8108ed1b>] __page_cache_alloc+0x67/0x6c
 [<ffffffff81096afd>] __do_page_cache_readahead+0x8d/0x163
 [<ffffffff81096ed1>] ondemand_readahead+0x178/0x18a
 [<ffffffff81096f7c>] page_cache_sync_readahead+0x17/0x1b
 [<ffffffff810903fd>] generic_file_aio_read+0x1fe/0x564
 [<ffffffffa0314af2>] nfs_file_read+0xe5/0xf8 [nfs]
 [<ffffffff810c0093>] do_sync_read+0xe7/0x12d
 [<ffffffff810551e1>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff81332aba>] ? _spin_lock+0x9/0xc
 [<ffffffff8113bf0c>] ? security_file_permission+0x11/0x13
 [<ffffffff810c0a10>] vfs_read+0xa8/0x102
 [<ffffffff810c0b2e>] sys_read+0x47/0x6e
 [<ffffffff8101024a>] system_call_fastpath+0x16/0x1b

I've tested kernel-2.6.27.9-159.fc10.x86_64 and kernel-2.6.27.7-134.fc10.x86_64 and they both get this. Using kernel-2.6.27.5-41.fc9.x86_64 makes the problem go away.

Comment 1 François Cami 2009-02-16 15:17:56 UTC
Pierre,

Could you add your full dmesg and /var/log/Xorg.0.log as uncompressed text/plain attachments to this bug ? 

Thanks

---
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 2 Pierre Ossman 2009-02-26 15:11:35 UTC
Is it sufficient with one without the crash? It is very rarely the machine stays up enough to get a dump once this happens.

Comment 3 François Cami 2009-02-26 19:38:11 UTC
It can help, yes.
Were you using NFS ?

Comment 4 Jérôme Glisse 2009-10-14 10:56:47 UTC
Can you test with fedora 12 livecd and report if it works with it.

Comment 5 Pierre Ossman 2009-10-14 13:57:47 UTC
Hmm... This problem is not present anymore on the system. I don't remember when it went away to be honest. Just close the bug, I'll reopen it if the bug ever resurfaces.

Comment 6 Jérôme Glisse 2009-10-14 14:50:20 UTC
Ok closing the bug.


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