If I use the nomodeset kernel paramater the bug is happened again.

It is happened again even if I upgrade notebook BIOS to a new version:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
IP: [<ffffffffa00756c1>] intel_tv_mode_set+0x231/0x7c4 [i915]
PGD 66850067 PUD 65818067 PMD 0 
Oops: 0000 [#1] SMP 
last sysfs file: /sys/devices/virtual/net/virbr0/address
CPU 0 
Modules linked in: ipt_MASQUERADE iptable_nat nf_nat rfcomm sco bridge stp llc bnep l2cap sunrpc xt_physdev ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand acpi_cpufreq freq_table dm_multipath kvm_intel kvm uinput snd_hda_codec_intelhdmi snd_hda_codec_idt snd_hda_intel arc4 snd_hda_codec ecb firewire_ohci iwlagn snd_hwdep firewire_core snd_seq iwlcore crc_itu_t dell_laptop dcdbas snd_seq_device snd_pcm wmi iTCO_wdt mac80211 cfg80211 i2c_i801 sdhci_pci sdhci tg3 mmc_core ricoh_mmc btusb snd_timer bluetooth snd soundcore iTCO_vendor_support joydev snd_page_alloc rfkill yenta_socket rsrc_nonstatic i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: microcode]
Pid: 1573, comm: Xorg Not tainted 2.6.31.6-145.fc12.x86_64 #1 Latitude E5400                  
RIP: 0010:[<ffffffffa00756c1>]  [<ffffffffa00756c1>] intel_tv_mode_set+0x231/0x7c4 [i915]
RSP: 0018:ffff8800785998a8  EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff88003790e000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000000000c
RBP: ffff880078599948 R08: 00000000000001df R09: 0000000000000000
R10: 0000000000000040 R11: 0000000000000000 R12: ffff88003780d000
R13: ffff8800776c13d8 R14: ffffffffa007c630 R15: 00000000000200c0
FS:  00007fc7080307e0(0000) GS:ffff8800019bf000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00007f31609135e0 CR3: 000000006604f000 CR4: 00000000000426f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process Xorg (pid: 1573, threadinfo ffff880078598000, task ffff88007191de00)
Stack:
 0000034a3780d800 0000000c0000002c 0000000000000000 0000000000000000
<0> 0000000000000000 ffff880000000000 0000002c0000000c ffff88003780d800
<0> 0000007a78599948 0000000000000000 ffff880000000000 ffff880000000000
Call Trace:
 [<ffffffffa00521f4>] drm_crtc_helper_set_mode+0x287/0x34e [drm_kms_helper]
 [<ffffffffa006ceda>] intel_get_load_detect_pipe+0x101/0x14a [i915]
 [<ffffffffa00764a6>] intel_tv_detect+0x8d/0x14d [i915]
 [<ffffffffa0052b8b>] drm_helper_probe_single_connector_modes+0xba/0x282 [drm_kms_helper]
 [<ffffffffa002fac8>] drm_mode_getconnector+0xf5/0x39a [drm]
 [<ffffffffa002f9d3>] ? drm_mode_getconnector+0x0/0x39a [drm]
 [<ffffffffa002521f>] drm_ioctl+0x237/0x2f4 [drm]
 [<ffffffff81108b29>] vfs_ioctl+0x6f/0x87
 [<ffffffff81109038>] do_vfs_ioctl+0x47b/0x4c1
 [<ffffffff811090d4>] 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  [<ffffffffa00756c1>] intel_tv_mode_set+0x231/0x7c4 [i915]
 RSP <ffff8800785998a8>
CR2: 0000000000000008
---[ end trace a76b80ebc564ea9a ]---

Yeah I am experiencing the exact same problem on an HP 6930p laptop ... it appears to only happen when dracut builds with the video driver ... if you install the basic Fedora with "basic video driver support" then you get past this.

FYI --- also booting with nomodeset on the kernel line which disables KMS support in the DRM module gets past these issues as well ... so something is up with KMS/DRM

Well in my case the nomodeset on the kernel line does not resolve the issue

In my case "nomodeset" let me use X, but compiz crashes if I enable it. My machine is an HP 6730b laptop.

kernel-2.6.31.5-127.fc12.x86_64
kernel-2.6.31.6-134.fc12.x86_64
kernel-2.6.31.6-148.fc12.x86_64
xorg-x11-drv-intel-2.9.1-1.fc12.x86_64

Smolt profile at http://www.smolts.org/client/show/pub_484873bb-2045-4025-9f87-c221de679098

@RobinsonMaureira -- I have a 6930p and yes, compiz does crash if you use the Gnome compat pre-built F12 compiz.  What you can do if you want a compositing windows manager until the inherent problems are fixed (if ever) is use compiz-fusion or KDE.  KDE compositing is OK, and compiz-fusion works.  The errors I receive are:

Nov 24 21:44:07 localhost kernel: compiz[1779]: segfault at a928a0 ip 00a928a0 sp bfaa8f10 error 14 in libstartup-notification-1.so.0.0.0[aec000+9000]

@MihaiHarpau -- sorry to hear that, I noticed that the last sysfs call in your report is to the virtual bridge interface and KVM is loaded ... are you running virtualization?  What you can try is to remove the Virtaulization Group packages or reinstall without that option ... I also noticed issues when running KVM before the whole login problems started.

I see the same oops on HP6930p.

Mihai: Please attach the _full_ dmesg when you claim that 'nomodeset' doesn't fix the issue.

Just an FYI there is plenty online about the fix for intel_tv.c and the intel_tv_mode_set dereference ... in Fedora the i915 is responsible for this:

[root@hp-6930p i915]# strings -o i915.ko | grep intel_tv
 455170 intel_tv_detect_type

So perhaps this patch wasn't incorporated into this upstream kernel?

Unfortunately I don't have any log that could show that 'nomodeset' case does not resolve the issue for me (maybe was a hard crash without any log I don't know).

We're assigning KMS bugs to the driver components for now, even though the code is technically in the kernel; it's easier for the interested devs to track this way. Re-assigning to xorg-x11-drv-intel and ajax.

Can we get a /var/log/Xorg.0.log from the working case (nomodeset)? It may contain something interesting I guess, and also gives me an easy way to tag this bug with the exact hardware in use (yes, I'm lazy :>)

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

Created attachment 373815 [details]
Xorg log of the current session (nomodeset)

There you go.

Thanks.

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

*** Bug 540681 has been marked as a duplicate of this bug. ***

So something that may help ... company order a few of the HP 6930p elitebook laptops, identical in every way ... one F12 install doesn't require nomodeset and can boot just fine, a second requires nomodeset otherwise X crashes hard with the same problems noted above.

I am attached the Xorg log from the laptop that doesn't require nomodeset in order to boot and startx.

Again, both laptops are identical, identical installs, and identical media used and options choosen, yet one requires nomodeset and the other does not!!

Created attachment 373881 [details]
Xorg log from laptop withnot nomodeset but transitions to X just fine

Again, this is the Xorg logfile from a laptop that doesn't require nomodeset, but should ;-) as other identical laptops with identical hardware and BIOSes require it otherwise X crashes hard during transition to kdm/gdm from plymouth

Created attachment 373990 [details]
test patch

This makes it work with a simple hack to avoid the oops, and highlights what's going wrong...

[drm] TV-20: set mode NTSC 480i 0
Set video_levels to tv_mode->composite_levels ffffffffa007cf78 from mode NTSC-M
[drm] TV-20: set mode NTSC 480i 0
Set video_levels to component_levels ffffffffa007ce28
[drm] TV-20: set mode NTSC 480i 0
Set video_levels to tv_mode->composite_levels (null) from mode 480p
Eep, !video_levels
[drm] TV-20: set mode NTSC 480i 0
Set video_levels to tv_mode->composite_levels (null) from mode 480p
Eep, !video_levels
[drm] TV-20: set mode NTSC 480i 0
Set video_levels to tv_mode->composite_levels (null) from mode 480p
Eep, !video_levels
[drm] TV-20: set mode NTSC 480i 0
Set video_levels to tv_mode->composite_levels (null) from mode 480p
Eep, !video_levels

The 480p mode has the 'component_only' flag set.

[drm:drm_mode_getconnector], connector id 19:
[drm:drm_helper_probe_single_connector_modes], SVIDEO-1
[drm:intel_update_watermarks], plane A (pipe 0) clock: 107520
[drm:intel_update_watermarks], plane B (pipe 1) clock: 69290
[drm:drm_vblank_get], enabling vblank on crtc 0, ret: -22
[drm:intel_crtc_mode_set], Mode for pipe A:
[drm:drm_mode_debug_printmodeline], Modeline 0:"NTSC 480i" 0 107520 1280 1368 1496 1712 1024 1027 1034 1104 0x40 0x0
[drm:intel_crtc_mode_set], disabling CxSR downclocking
[drm:intel_pipe_set_base], No FB bound
[drm:intel_update_watermarks], plane A (pipe 0) clock: 107520
[drm:intel_update_watermarks], plane B (pipe 1) clock: 69290
[drm] TV-20: set mode NTSC 480i 0
Set video_levels to component_levels ffffffffa007ce28
[drm:intel_update_watermarks], plane A (pipe 0) clock: 107520
[drm:intel_update_watermarks], plane B (pipe 1) clock: 69290
[drm:intel_tv_detect_type], No TV connection detected
[drm:intel_update_watermarks], plane B (pipe 1) clock: 69290
[drm:drm_helper_probe_single_connector_modes], SVIDEO-1 is disconnected
[drm:drm_ioctl], pid=1446, cmd=0xc05064a7, nr=0xa7, dev 0xe200, auth=1
[drm:drm_mode_getconnector], connector id 19:
[drm:drm_helper_probe_single_connector_modes], SVIDEO-1
[drm:intel_update_watermarks], plane A (pipe 0) clock: 107520
[drm:intel_update_watermarks], plane B (pipe 1) clock: 69290
[drm:drm_vblank_get], enabling vblank on crtc 0, ret: -22
[drm:intel_crtc_mode_set], Mode for pipe A:
[drm:drm_mode_debug_printmodeline], Modeline 0:"NTSC 480i" 0 107520 1280 1368 1496 1712 1024 1027 1034 1104 0x40 0x0
[drm:intel_crtc_mode_set], disabling CxSR downclocking
[drm:intel_pipe_set_base], No FB bound
[drm:intel_update_watermarks], plane A (pipe 0) clock: 107520
[drm:intel_update_watermarks], plane B (pipe 1) clock: 69290
[drm] TV-20: set mode NTSC 480i 0
Set video_levels to tv_mode->composite_levels (null) from mode 480p
Eep, !video_levels
[drm:intel_update_watermarks], plane A (pipe 0) clock: 107520
[drm:intel_update_watermarks], plane B (pipe 1) clock: 69290
[drm:intel_tv_detect_type], No TV connection detected
[drm:intel_update_watermarks], plane B (pipe 1) clock: 69290
[drm:drm_helper_probe_single_connector_modes], SVIDEO-1 is disconnected
[drm:drm_ioctl], pid=1446, cmd=0xc05064a7, nr=0xa7, dev 0xe200, auth=1
[drm:drm_mode_getconnector], connector id 5:
[drm:drm_helper_probe_single_connector_modes], VGA-1

*** Bug 541332 has been marked as a duplicate of this bug. ***

*** Bug 541593 has been marked as a duplicate of this bug. ***

Should be fixed in 2.6.31.6-152.fc12, building at http://koji.fedoraproject.org/koji/taskinfo?taskID=1834553

It's working for me, I'm getting the usual "your BIOS is broken", but it doesn't crash at all.

@BradScalio: I tried compiz-fusion with no luck :-(

2.6.31.6-152.fc12 works for me, but Compiz crashes.

That's another BZ (https://bugzilla.redhat.com/show_bug.cgi?id=539789)

2.6.31.6-152.fc12 works for me too. Compiz is also working. (https://bugzilla.redhat.com/show_bug.cgi?id=541332)

The 2.6.32 problem is reported upstream at
https://bugs.freedesktop.org/show_bug.cgi?id=25369

After a few days of thorough testing I can confirm that kernel 2.6.31.6-152.fc12 completely fixed this bug. Many thanks!

Thank you for letting us know.

matej, 152 has not even been submitted as an update candidate yet. we can't close the bug.

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

Right you are, I am sorry.

but I guess we can call it modified, so, we don't have to be that much concerned with it.

I tried installing 152.  It didn't seem to solve it for me.  I still have to add nomodeset or the kernel crashes when it loads.

*** Bug 544205 has been marked as a duplicate of this bug. ***

It works a bit better now. I no longer get the Oops, but sometimes the system becomes very slow, with a jumpy mouse pointer, while logon screen is being displayed, and afterwards during login.

When I examine the logs later on, I notice that there are many (1000+)occurances of the line:

[drm] TV-21: set mode NTSC 480i 0

On normal boot, there about 10 lines like this, during a slow boot there are 1000+. This isn't really reproducible, it happens one in five times or so.

kernel is 2.6.31.6-166

Same problem as described in #34. No hdd or CPU activity during this.

We're well past the kernel update that fixed this issue, so we can close the bug now.