[Intel-gfx] Fedora Core 12 x86_64 lockup/crash

[Avedissian, Vahe Y (AS)]

Hi Dave,

Is there an quick way to patch an existing Fedora kernel with these fixes? I have the
Patch downloaded, but am unclear how to proceed.

Vahe


> -----Original Message-----
> From: Dave Airlie [mailto:airlied at gmail.com]
> Sent: Wednesday, December 02, 2009 8:35 PM
> To: Zhenyu Wang; Avedissian, Vahe Y (AS); Clemens Eisserer; intel-
> gfx at lists.freedesktop.org
> Subject: Re: [Intel-gfx] Fedora Core 12 x86_64 lockup/crash
> 
> On Thu, Dec 3, 2009 at 12:17 PM, Zhenyu Wang <zhenyuw at linux.intel.com>
> wrote:
> > On 2009.12.02 15:38:29 -0600, Avedissian, Vahe Y (AS) wrote:
> >> Hi Clemens,
> >>
> >> You were right. The kernel was not crashed and I was able to ssh to
> the machine. I have attached the dmesg output.
> >> There is an error about dereferencing a NULL pointer...
> >
> >> BUG: unable to handle kernel NULL pointer dereference at
> 0000000000000008
> >> IP: [<ffffffffa007516d>] intel_tv_mode_set+0x231/0x7b2 [i915]
> >> PGD 173436067 PUD 170dfd067 PMD 0
> >> Oops: 0000 [#1] SMP
> >> last sysfs file:
> /sys/devices/pci0000:00/0000:00:1c.0/0000:04:00.0/resource
> >> CPU 1
> >> Modules linked in: sunrpc ip6t_REJECT nf_conntrack_ipv6
> ip6table_filter ip6_tables ipv6 cpufreq_ondemand acpi_cpufreq
> freq_table dm_multipath uinput snd_hda_codec_idt snd_hda_intel
> snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm ppdev snd_timer
> i2c_i801 iTCO_wdt parport_pc iTCO_vendor_support snd e1000e soundcore
> snd_page_alloc parport csx pata_acpi ata_generic pata_sil680 floppy
> i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last
> unloaded: microcode]
> >> Pid: 6475, comm: X Not tainted 2.6.31.5-127.fc12.x86_64 #1 Scotch
> Bonnet
> >> RIP: 0010:[<ffffffffa007516d>]  [<ffffffffa007516d>]
> intel_tv_mode_set+0x231/0x7b2 [i915]
> >> RSP: 0018:ffff88013cfc18a8  EFLAGS: 00010246
> >> RAX: 0000000000000000 RBX: ffff88017851c000 RCX: 0000000000000000
> >> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000000000c
> >> RBP: ffff88013cfc1948 R08: 00000000000001df R09: 0000000000000000
> >> R10: 0000000000000040 R11: 0000000000000000 R12: ffff8801785e3800
> >> R13: ffff8801785e6bd8 R14: ffffffffa007c0c0 R15: 00000000400200c0
> >> FS:  00007f48116087e0(0000) GS:ffff880028045000(0000)
> knlGS:0000000000000000
> >> CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> >> CR2: 0000000000000008 CR3: 000000013cdb3000 CR4: 00000000000006e0
> >> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> >> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> >> Process X (pid: 6475, threadinfo ffff88013cfc0000, task
> ffff8801731ac680)
> >> Stack:
> >>  0000034a785e5000 0000000c0000002c 0000000000000000 0000000000000000
> >> <0> 0000000000000000 ffff880100000000 0000002c0000000c
> ffff8801785e5000
> >> <0> 0000007a3cfc1948 0000000000000000 ffff880100000000
> ffff880100000000
> >> Call Trace:
> >>  [<ffffffffa00521f4>] drm_crtc_helper_set_mode+0x287/0x34e
> [drm_kms_helper]
> >>  [<ffffffffa006ca8a>] intel_get_load_detect_pipe+0x101/0x14a [i915]
> >>  [<ffffffffa0075f35>] intel_tv_detect+0x8d/0x14d [i915]
> >>  [<ffffffffa0052b8b>]
> drm_helper_probe_single_connector_modes+0xba/0x282 [drm_kms_helper]
> >>  [<ffffffffa002faa0>] drm_mode_getconnector+0xf5/0x39a [drm]
> >>  [<ffffffffa002f9ab>] ? drm_mode_getconnector+0x0/0x39a [drm]
> >>  [<ffffffffa002521f>] drm_ioctl+0x237/0x2f4 [drm]
> >>  [<ffffffff81108a15>] vfs_ioctl+0x6f/0x87
> >>  [<ffffffff81049021>] ? finish_task_switch+0xc3/0xe6
> >>  [<ffffffff81108f24>] do_vfs_ioctl+0x47b/0x4c1
> >>  [<ffffffff81108fc0>] sys_ioctl+0x56/0x79
> >>  [<ffffffff81011cf2>] system_call_fastpath+0x16/0x1b
> >> Code: 0f 45 d3 45 8b 9e 8c 00 00 00 44 89 5d 88 41 89 d3 41 81 cb 00
> 00 00 20 83 7d 88 00 41 0f 45 d3 45 8b 9e 90 00 00 00 44 89 5d c8 <45>
> 8b 59 08 44 89 5d 8c 45 8b 5e 7c 44 89 5d bc 45 8b 9e 80 00
> >> RIP  [<ffffffffa007516d>] intel_tv_mode_set+0x231/0x7b2 [i915]
> >>  RSP <ffff88013cfc18a8>
> >> CR2: 0000000000000008
> >> ---[ end trace 7c726309abe9f24b ]---
> >
> > Looks this should be fixed by Chris's TV mode_set patch.
> > Could you test the patch on drm-intel-next?
> >
> > commit d271817baecbccb47da0d9f28c285a0dae8a06b7
> > Author: Chris Wilson <chris at chris-wilson.co.uk>
> > Date:   Fri Nov 27 13:06:56 2009 +0000
> >
> >    drm/i915: Avoid NULL dereference with component_only tv_modes
> 
> This patch should be in the latest F12 kernel in koji for anyone who
> wants to test.
> 
> Dave.