I noticed a shiny new nouveau drop and had to try it out. Unfortunately I got this: [drm] Initialized drm 1.1.0 20060810 pci 0000:01:00.0: power state changed by ACPI to D0 pci 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 pci 0000:01:00.0: setting latency timer to 64 [drm] Detected an NV50 generation card (0x086900a2) [drm] Initialized nouveau 0.0.11 20060213 on minor 0 mtrr: type mismatch for e0000000,8000000 old: write-back new: write-combining [drm:nouveau_graph_trapped_channel] *ERROR* AIII, invalid/inactive channel id 128 [drm] PGRAPH_ERROR - nSource: PROTECTION_ERROR, nStatus: [drm] PGRAPH_ERROR - Ch -1/0 Class 0x0000 Mthd 0x0000 Data 0x00000000:0x00000000 [drm] Allocating FIFO number 1 [drm] nouveau_fifo_alloc: initialised FIFO 1 [drm] Allocating FIFO number 2 [drm] nouveau_fifo_alloc: initialised FIFO 2 [drm] nouveau_fifo_free: freeing fifo 2 [drm] nouveau_fifo_free: freeing fifo 1 ------------[ cut here ]------------ kernel BUG at mm/filemap.c:569! invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC Modules linked in: nouveau drm ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 xt_state nf_conntrack ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp rfcomm l2cap fuse sunrpc ipv6 cpufre q_ondemand acpi_cpufreq loop dm_multipath kvm_intel kvm sr_mod cdrom snd_hda_intel thinkpad_acpi hwmon arc4 ecb crypto_blkcipher snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq firewire_ohci firewire_co re pcspkr i2c_i801 joydev sdhci_pci snd_seq_device crc_itu_t i2c_core sdhci yenta_socket ata_piix iwlagn mmc_core rsrc_nonstatic ricoh_mmc ata_generic snd_pcm_oss pata_acpi iTCO_wdt snd_mixer_oss iwlcore iTC O_vendor_support snd_pcm snd_timer rfkill snd_page_alloc mac80211 snd_hwdep snd soundcore cfg80211 battery ac bay video output wmi btusb bluetooth dm_snapshot dm_zero dm_mirror dm_log dm_mod ahci ext3 jbd mb cache [last unloaded: microcode] Pid: 3237, comm: X Not tainted (2.6.27-0.312.rc5.git7.fc10.i686.PAE #1) EIP: 0060:[<c047f945>] EFLAGS: 00013246 CPU: 0 EIP is at unlock_page+0x16/0x53 EAX: 00000000 EBX: c1b73130 ECX: c045205c EDX: f79fb17c ESI: f79fb17c EDI: 00000000 EBP: f4c1ae48 ESP: f4c1ae44 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 Process X (pid: 3237, ti=f4c1a000 task=f5273ea0 task.ti=f4c1a000) Stack: f3149d50 f4c1ae68 f8d8303f f511b090 3452a000 00000000 f511b098 f511b090 f3149d50 f4c1ae7c f8d7d938 f511b098 f511b090 f50dea50 f4c1ae98 f8d5884d f4c1ae90 c05255c1 f511b098 f511b090 f50dea50 f4c1aec0 f8d58fd9 f4c5d200 Call Trace: [<f8d8303f>] ? nouveau_sgdma_takedown+0x6f/0xb0 [nouveau] [<f8d7d938>] ? nouveau_lastclose+0x84/0xfa [nouveau] [<f8d5884d>] ? drm_lastclose+0x3b/0x234 [drm] [<c05255c1>] ? _raw_spin_unlock+0x74/0x78 [<f8d58fd9>] ? drm_release+0x3bf/0x3d7 [drm] [<c04a5e9d>] ? __fput+0xb8/0x148 [<c04a5f49>] ? fput+0x1c/0x1e [<c0490c48>] ? remove_vma+0x41/0x60 [<c0490d2f>] ? exit_mmap+0xc8/0xe3 [<c0431b26>] ? mmput+0x3f/0x90 [<c0435161>] ? exit_mm+0xed/0xf5 [<c04369f0>] ? do_exit+0x1e6/0x79b [<c04ab7fb>] ? path_put+0x1a/0x1d [<c0437008>] ? do_group_exit+0x63/0x8a [<c0437047>] ? sys_exit_group+0x18/0x1a [<c0408bf7>] ? sysenter_do_call+0x12/0x3f ======================= Code: 00 00 6b c0 28 03 82 80 13 00 00 89 da e8 a5 5f fc ff 5b 5d c3 55 89 e5 53 0f 1f 44 00 00 89 c3 f0 0f ba 30 00 19 c0 85 c0 75 04 <0f> 0b eb fe 8b 13 69 c3 01 00 37 9e b9 20 00 00 00 c1 ea 1e 69 EIP: [<c047f945>] unlock_page+0x16/0x53 SS:ESP 0068:f4c1ae44 ---[ end trace 7ee323e93be6c84c ]--- Fixing recursive fault but reboot is needed! Works fine with my custom (vanilla) kernel and drm HEAD though.
Has this still been a problem in recent kernels Pierre?
Yes, every kernel I've tried since then crashes (I haven't checked if it's exactly the same dump though).
Checked the traceback for kernel-PAE-2.6.27.4-47.rc3.fc10.i686 and it still crashes in nouveau_sgdma_takedown(). The entries before it are a bit different though: Call Trace: [<f8cede9a>] ? nouveau_sgdma_takedown+0x6a/0xab [nouveau] [<f8cea960>] ? nouveau_mem_init+0x1cf/0x308 [nouveau] [<f8ce938a>] ? nouveau_card_init+0x6bc/0x72a [nouveau] [<f8ce9400>] ? nouveau_ioctl_card_init+0x8/0xc [nouveau] [<f8cc35e5>] ? drm_ioctl+0x1ad/0x222 [drm] [<f8ce93f8>] ? nouveau_ioctl_card_init+0x0/0xc [nouveau] [<c04a14e1>] ? vfs_ioctl+0x50/0x69 [<c04a175f>] ? do_vfs_ioctl+0x265/0x278 [<c04a17b2>] ? sys_ioctl+0x40/0x5a [<c0408b77>] ? sysenter_do_call+0x12/0x34
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Ping! Anyone looking at this?
Tested with .28-rc6 and drm HEAD and that combination works. So an update please. :)
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Per comment #6, this was likely fixed in Fedora 11 which picked up upstream stuff.