Bug 489907

Created attachment 334933 [details]
Xorg.0.log

Created attachment 334934 [details]
/var/log/messages

Created attachment 334935 [details]
~/.xsession-errors

(In reply to comment #0)
> Additional info:
> Test https://fedoraproject.org/wiki/QA:Testcase_intelvideo_nokms

kernel options nomodeset was *NOT* set. That should say:

https://fedoraproject.org/wiki/QA:Testcase_intelvideo_dpms

This bug has been triaged

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

Upstream bug at: http://bugs.freedesktop.org/show_bug.cgi?id=21230

Confirming that this is a problem on an X41t with the last Fedora preview release. Makes F11 unusable on that hardware, obviously. :/

(And thanks for taking the bullet and testing this issue earlier than I did, Saikat.)

saikat: you added this to the KMS blocker list - does this mean it only happens with KMS enabled? it works if you boot with 'nomodeset'?

Correct; LVDS dies only with KMS enabled. FYI, there might be a kernel patch that fixes upstream shortly.


Btw, with KMS disabled (and EXA) the LVDS comes back on but X crashes periodically (bug 473347). With KMS disabled and UXA, GDM doesn't start (bug 489892). I assume the default is KMS and UXA; if not, one of 473347 or 489892 should probably be on the KMS blocker list.

Yes, KMS is the default. Thanks for the info. Luis, may help you.

I'm following the upstream bug Saikat mentioned, since as long as 473347 is around with KMS off the upgrade isn't terribly appealing. But thanks for thinking of me :)

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

There are patches in the works to fix this properly, but they aren't finished yet.

In the meantime I've cooked up an awful workaround. jbarnes correctly pointed out that xrandr can bring the display back. I created a script, /home/wwoods/bin/xrandr-reset:

#!/bin/bash
xrandr --output LVDS1 --off
xrandr --output LVDS1 --auto

And I added a custom keyboard shortcut to run that script when I hit Ctrl-Alt-Shift-S. So now, when I open the laptop, I can hit that key combo to bring the display back.

It's a pretty gross hack but it's good enough for 5pm on a Friday.

unfortunately this script does not restore the brightness level on my thinkpad x40.

$ lspci | grep -i vga
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)

after reopening lid, i can see something on the screen (like the password prompt) or the desktop after entering the password but the brightness is almost zero, and stays zero even after running the script.

It doesn't look like this is going to get fixed in the next day, so reluctantly we're going to drop it from the blocker list.  We hope to have a 0-day update for this issue.

That's unfortunate.

<rant>
I don't want to rant, but considering this bug has crippled my laptop for nearly 4 months, I find it disheartening both as a Fedora user and a Rawhide tester that this bug is going live.

A blocker, by definition, is supposed to block releases until fixed. Declassifying bugs to clear the blocker board is cheating. If you have an argument for why this should not be a F11Blocker (other than "it would delay the release") I'd love to hear it.

I don't want to dig up the Fedora being alpha issue (well, obviously I do), but I really wonder if Windows or MacOS (or for that matter, RHEL) would have been released with such a bug.
</rant>

On a more constructive note, can we disable modesetting for the affected models and risk the non-deterministic freezes that hit every few days rather than the deterministic black screen of comatose every lid event.

This isn't the right forum for this but.

Fedora is a mostly time based release cycle, and we'll never be bug free, that's why we have an update system.  Sometimes we have to decide to ship with some known bugs in order to meet our prearranged time deadlines, with the expectation of fixing the remaining issues in updates.  For situations with easy workarounds, such as using 'nomodeset' we're more able to use the update system to resolve the issue.

Given that Windows, or MacOS or RHEL are for profit operating systems, and consumers are paying money for them, they likely wouldn't release with a bug that would be fixed in updates.  Fedora is Free and that freedom does cost something.

As to your second note, if we had a clear idea of what chips cause this (since not all of your model number do) we might be able to disable it.  But from what I gather from the X team, we don't have that info as of yet, and are having a tough time reproducing in order to debug/fix.

cornel panceac: yours sounds like a different bug; that sounds like something to do with the controlled brightness of the backlight, rather than the panel simply not being turned on at all, as in this case. The fact that the workaround does not work for you, and that you have a rather different chipset (855 vs. 915), would both seem to support this interpretation.

Please file a separate report, with all the usual info (X logs &c). Thanks!

on the blocker-ness of this issue: it was always a borderline one (we actually have equally or more severe bugs that affect other specific types of hardware that haven't been marked as blockers; practically speaking, we'd never have time to fix them all if we wanted to release before 2010). the fact that there's a working - ugly, but working - workaround available also contributed, so I agreed with Jesse that on balance it makes more sense to downgrade it and ship the release than delay and hope we can fix it.

adam williamson: i will gladly open a new bug but i'll wait a little more, because, first i've thought my screen was black too. only when i've seen that the script doesn't restore the display, i looked more carefully and see that i can see somethings on the screen only the brightness was almost zero. it probably helped it was night outside and the light in the room was low. so _maybe_ , if somebody who has this problem can look again and see something there too. thank you.

otoh, if anybdoy knows a command i can add to that script wich can restore the brightness, that's all i need for now, since i can see (if i look very carefully) the script turning off and back on the screen...

it sounds like, in your case, the panel is on but the backlight is turned off. I'm not sure if that's the case for the other reporters or not.

It's not. With this bug the backlight comes back on (as expected) but the display doesn't show anything. 

cornel has a different problem.

there you have it. :) please file a new bug, cornel.

done

https://bugzilla.redhat.com/show_bug.cgi?id=502976

i have no idea if any logs will be relevant in this case, since the bug hits before the logger starts.

thank you.

with 2.6.29.4-162 (wich i understand that it disables kms for some intel chipsets) i get the error in this report, and the script from #13 restores the display.

@Jesse, Adam: Fair enough; thanks for responding. 

@Will: Regarding the workaround, it works for me (thanks!), but I get the following kernel warning. Also, the shortcut key used to trigger the workaround stays in key_pressed state generating stray characters until something else is pressed. (i.e. if bound to Ctrl-Alt-Shift-s, and focus is in a terminal window when the lvds is off, coming out of it the terminal is filled with sssssssssssssssss...)


WARNING: at drivers/gpu/drm/i915/i915_gem_tiling.c:328 i915_gem_set_tiling+0x4b1/0x516 [i915]()
Hardware name: 18695CU
failed to unbind object for tiling switchModules linked in: vfat fat fuse sco bridge stp llc bnep l2cap bluetooth autofs4 sunrpc nf_conntrack_netbios_ns cpufreq_ondemand acpi_cpufreq dm_multipath uinput mmc_block ppdev snd_intel8x0m snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm yenta_socket snd_timer sdhci_pci snd sdhci i2c_i801 rsrc_nonstatic mmc_core soundcore ipw2200 iTCO_wdt snd_page_alloc pcspkr thinkpad_acpi iTCO_vendor_support parport_pc libipw lib80211 nsc_ircc irda rfkill parport hwmon crc_ccitt tg3 ata_generic pata_acpi i915 drm i2c_algo_bit video output i2c_core [last unloaded: microcode]
Pid: 1837, comm: Xorg Not tainted 2.6.30-0.97.rc8.fc12.i586 #1
Call Trace:
 [<c043c696>] warn_slowpath_common+0x75/0x9d
 [<f7de786a>] ? i915_gem_set_tiling+0x4b1/0x516 [i915]
 [<c043c727>] warn_slowpath_fmt+0x34/0x48
 [<f7de786a>] i915_gem_set_tiling+0x4b1/0x516 [i915]
 [<f7d86211>] drm_ioctl+0x222/0x2cd [drm]
 [<f7de73b9>] ? i915_gem_set_tiling+0x0/0x516 [i915]
 [<c0532822>] ? ext3_file_write+0x3c/0xc2
 [<c050a54a>] ? dnotify_parent+0x30/0x83
 [<c046565f>] ? print_lock_contention_bug+0x1f/0xd1
 [<c04ec46b>] vfs_ioctl+0x66/0x91
 [<c04ec92c>] do_vfs_ioctl+0x496/0x4e3
 [<c07e51d1>] ? _spin_unlock+0x30/0x45
 [<c04df0c0>] ? fsnotify_modify+0x67/0x83
 [<c0487b62>] ? audit_syscall_entry+0x135/0x168
 [<c04ec9ce>] sys_ioctl+0x55/0x86
 [<c040c6a3>] ? syscall_trace_enter+0xea/0x10f
 [<c040417c>] syscall_call+0x7/0xb
---[ end trace 6d5f0a08752e68a8 ]---

This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Just upgraded to Fedora 11 in my X40 and suspend/resume broke similarly to what was described above: suspend works fine, resume left me with a virtually dark screen. One low light conditions you can almost see the screen saver login box. Trying to login blind and running the xrandr script shown earlier in this thread did not work for me.

 The solution was to turn kernel modeseting off. In /boot/grub/grub.conf append nomodeset at the kernel line.

   kernel /vmlinuz-2.6.29.4-167.fc11.i586 ro root=/dev/VolGroup00/LogVol00 rhgb quiet hpet=force nomodeset

Now the machine resumes fine from suspend. If anyone wants to add this to a database the model type is 2382.

On Rawhide; not fixed yet.
Worse, even the workaround stopped working
 kernel-2.6.31-0.24.rc0.git18.fc12.i586
 xorg-x11-drv-intel-2.8.0-0.1.fc12.i586

$ xrandr --output LVDS1 --off
$ xrandr --output LVDS1 --auto
xrandr: Configure crtc 1 invalid time

Following up on my own comment, the fix I posted is not reliable. Every third or so suspend/resume cycle, results in a kernel crash. Here is the kernel message reported back:

Kernel failure message 1:
------------[ cut here ]------------
WARNING: at kernel/hrtimer.c:625 hres_timers_resume+0x34/0x4a() (Not tainted)
Hardware name: 2382RFU
hres_timers_resume() called with IRQs enabled!Modules linked in: michael_mic arc
4 ecb lib80211_crypt_tkip aes_i586 aes_generic lib80211_crypt_ccmp fuse rfcomm b
ridge stp llc bnep sco l2cap sunrpc ip6t_REJECT nf_conntrack_ipv6 ip6table_filte
r ip6_tables ipv6 cpufreq_ondemand acpi_cpufreq dm_multipath uinput snd_intel8x0
 snd_intel8x0m snd_ac97_codec ac97_bus snd_pcm iTCO_wdt ipw2200 thinkpad_acpi sd
hci_pci iTCO_vendor_support snd_timer yenta_socket sdhci snd i2c_i801 libipw rsr
c_nonstatic hwmon lib80211 btusb bluetooth e1000 mmc_core joydev soundcore snd_p
age_alloc nsc_ircc irda crc_ccitt pcspkr ata_generic pata_acpi i915 drm i2c_algo
_bit i2c_core video output [last unloaded: microcode]
Pid: 3761, comm: pm-suspend Not tainted 2.6.29.5-191.fc11.i586 #1
Call Trace:
[<c042ebc6>] warn_slowpath+0x7c/0xa4
[<c0443042>] ? ktime_get_ts+0x4f/0x53
[<c0414063>] ? lapic_next_event+0x18/0x1c
[<c0448cd3>] ? clockevents_program_event+0xe6/0xf5
[<c0449b5d>] ? tick_dev_program_event+0x47/0xb4
[<c0449c2a>] ? tick_program_event+0x26/0x2e
[<c044917d>] ? tick_notify+0x2e5/0x2f4
[<c0709b07>] ? notifier_call_chain+0x26/0x48
[<c04429a2>] hres_timers_resume+0x34/0x4a
[<c0446d39>] timekeeping_resume+0x130/0x137
[<c05ddad5>] __sysdev_resume+0x19/0x3d
[<c05ddb1f>] sysdev_resume+0x26/0x59
[<c04518c9>] suspend_devices_and_enter+0x112/0x186
[<c0451aa0>] enter_state+0x13c/0x197
[<c0451b94>] state_store+0x99/0xae
[<c0451afb>] ? state_store+0x0/0xae
[<c055a9f5>] kobj_attr_store+0x16/0x22
[<c04de44e>] sysfs_write_file+0xca/0xf5
[<c04de384>] ? sysfs_write_file+0x0/0xf5
[<c04a09a0>] vfs_write+0x95/0xf4
[<c04a0abb>] sys_write+0x4c/0x70
[<c0403f72>] syscall_call+0x7/0xb
---[ end trace 9f6d2b8ff1500853 ]---

Yet another followup to my own comment. Disabling hi-res timers by adding highres=off to grub.conf seems to fix the problem. I have gone through several successful suspend/resume cycles, certainly more than any other time before the change. (Thinkpad X40 with Intel graphics card)

This has F11 duplicate in bug 507416.

You didn't think it would be magically fixed between late F10 rawhide and F11, did you? :(

Sorry to be bitter, but it's frustrating that (1) I've been forced to switch back to XP (for other reasons) and (2) I'm actually almost *happy* about that because the combination of problems in comment 9 make F10 and F11 so crappy on this box- a box I bought in large part because Intel X drivers are supposed to be the best! :/

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

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

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

Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command

yum upgrade --enablerepo='*-updates-testing'

Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD .

Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.

If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]

With the latest F11 packages, I still often see the following kernel barf upon suspend/resume or external display xrandr enable/disable cycles. I have not seen instability for a long time (since 2009-09-08, my last update to Bug 507416 which has been marked as duplicate). I've briefly tried the F12 Beta live media, but seeing as it also requires a massive amount of updates, and I can't destabilize this laptop with an actual install, I'll have to wait with that data..

kernel-2.6.30.8-64.fc11.x86_64
kernel-2.6.30.9-90.fc11.x86_64
xorg-x11-server-common-1.6.4-0.1.fc11.x86_64
kernel-2.6.30.5-43.fc11.x86_64
xorg-x11-drv-intel-2.7.0-7.fc11.x86_64
xorg-x11-server-utils-7.4-7.1.fc11.x86_64
xorg-x11-server-Xorg-1.6.4-0.1.fc11.x86_64

[drm:i915_gem_object_unbind] *ERROR* Attempting to unbind pinned buffer
------------[ cut here ]------------
WARNING: at drivers/gpu/drm/i915/i915_gem_tiling.c:473 i915_gem_set_tiling+0x4ba/0x52c [i915]() (Tainted: G        W )
Hardware name: TravelMate 6292 
failed to unbind object for tiling switchModules linked in: vfat fat mmc_block fuse rfcomm bridge stp llc bnep sco l2cap vboxnetadp vboxnetflt vboxdrv sunrpc ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand acpi_cpufreq freq_table dm_multipath sha256_generic cryptd aes_x86_64 aes_generic cbc dm_crypt uinput arc4 ecb snd_hda_codec_realtek iwlagn iwlcore snd_hda_intel sdhci_pci acer_wmi sdhci snd_hda_codec rfkill uvcvideo firewire_ohci snd_hwdep lib80211 firewire_core mac80211 pcspkr mmc_core crc_itu_t i2c_i801 snd_pcm btusb yenta_socket videodev serio_raw rsrc_nonstatic bluetooth joydev iTCO_wdt snd_timer v4l1_compat iTCO_vendor_support v4l2_compat_ioctl32 cfg80211 irda wmi snd soundcore tg3 snd_page_alloc crc_ccitt i915 drm i2c_algo_bit video output i2c_core [last unloaded: microcode]
Pid: 2544, comm: Xorg Tainted: G        W  2.6.30.9-90.fc11.x86_64 #1
Call Trace:
 [<ffffffff81057098>] warn_slowpath_common+0x95/0xc3
 [<ffffffff81057153>] warn_slowpath_fmt+0x50/0x66
 [<ffffffffa006ddcc>] i915_gem_set_tiling+0x4ba/0x52c [i915]
 [<ffffffffa006d912>] ? i915_gem_set_tiling+0x0/0x52c [i915]
 [<ffffffffa00289cc>] drm_ioctl+0x21d/0x2e9 [drm]
 [<ffffffff811e6682>] ? avc_has_perm+0x6b/0x91
 [<ffffffff81112b33>] ? do_sync_write+0xfa/0x14b
 [<ffffffff811219c4>] vfs_ioctl+0x7e/0xaa
 [<ffffffff81121e5c>] do_vfs_ioctl+0x46c/0x4c3
 [<ffffffff81121f18>] sys_ioctl+0x65/0x9c
 [<ffffffff81012082>] system_call_fastpath+0x16/0x1b
---[ end trace ecd1aca64ea9e754 ]---

osma: you can get nightly live builds of f12 here:

http://alt.fedoraproject.org/pub/alt/nightly-composes/

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

on latest rawhide (20091106), the problem is still present.
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)

man, we really should've put this back on the blocker list for f12. I kept meaning to go searching for i8xx bugs but never quite got the time. sigh.

sorry to abuse Bugzilla, but how does f12 behave with 'nomodeset'? Usable, or does it have other problems?

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

with nomdeset machine gets locked. unfortunately, removing rhgb quiet was not enough since the lock occurs while the screen gets black (when i expect gdm to show-up). i'll take a look at /var/log/messages and report back.

Created attachment 368016 [details]
the nomdeset lock logs

i haven't seen anything on logs. amore educated eye may find something interesting in. the date is around 9:36 8 Nov 2009 (log time).

meanwhile, booting mepis on this notebook, i've seen this message:

"
thinkpad_acpi: CMOS NVRAM (7) and EC (0) do not agree on display brightness level
"

could be related? mepis uses linux 2.6.27 and does resume from suspend.

(In reply to comment #42)
> man, we really should've put this back on the blocker list for f12. I kept
> meaning to go searching for i8xx bugs but never quite got the time. sigh.

It's certainly too late, but if anything tracking bug 487202 is the one. I am
putting it at least on bug 432388 so it doesn't get lost again.

(In reply to comment #45)
> meanwhile, booting mepis on this notebook, i've seen this message:
> 
> "
> thinkpad_acpi: CMOS NVRAM (7) and EC (0) do not agree on display brightness
> level
> "
> 
> could be related? mepis uses linux 2.6.27 and does resume from suspend.  

Probably it is realted, but kernel 2.6.27 uses completely different Xorg (almost no kernel in Xorg), and we should be able to work around the brokenness of BIOS as we do in many other cases.

Loaded up and player a while with the nightly live image desktop-x86_64-20091106.16.iso (thanks for the link Adam). Absolutely stable and no kernel complaints on my TravelMate 6292 hardware during that time. Of course, a live image test isn't REALLY the same thing as working with it for a while, but it does semm stronger than it was before. 

http://www.smolts.org/client/show/pub_dc0ecb64-9a76-4bcc-becd-ffbb06da7a5a

Thanks. I'll close this for now; if you experience the same problem in the end after installing F12, please do re-open!

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

The original problem is *NOT* fixed in the latest rawhide --- closing the lid still kills the LVDS and it doesn't come back on reopening the lid.

kernel-2.6.31.5-122.fc12.i686
xorg-x11-server-Xorg-1.7.1-7.fc12.i686
xorg-x11-drv-intel-2.9.1-1.fc12.i686

The hack in comment 13 is working again though.

> The hack in comment 13 is working again though.

With one quirk ... the mouse pointer doesn't come back until something is typed on the keyboard.

right.. I'm commenting here because Bug 507416 has been marked as a duplicate. However, looks like it is not a real dupe. My Santa Rosa/GM965/GL960 graphics no longer experience any issues with F12, but Saikat's 915GM chipset behaves differently.

(In reply to comment #52)
> > The hack in comment 13 is working again though.
> 
> With one quirk ... the mouse pointer doesn't come back until something is typed
> on the keyboard.  

The same thing on Intel 855GME(Thinkpad X40). dmesg and xorg log from today attached to Bug 521714.

This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This has been marked fixed in upstream kernel, a fix committed in September as commit c1c7af60892070e4b82ad63bbfb95ae745056de0  - can we backport it for an F12 kernel update?

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

00:02.0 VGA compatible controller [0300]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02)

A couple of weird things about this... I have gnome-power-manager set to blank the screen on lid close.  When the lid opens, it's blank but with the backlight on, as described in this bug.  If I switch away to another VT and back, suddenly the top-left rectangle of about 720x400 of the screen appears.  Everything else remains black.  The workaround in comment 13 does fix this - thanks for that.

It's possible to use gconftool-2 to set gnome-power-manager to do nothing on lid close.  If I then press the hardware switch that simulates a lid-close, the screen still goes off.  When I release it, the screen comes back for a second before going blank again, as if something is unnecessarily trying to reset the graphics mode.  VT switch now only brings back the mouse pointer - everything else stays blank until the workaround is applied.

Though if it's already fixed then all that is probably irrelevant. :-)

Can this bug also be fixed in the F11 kernel as well?

I see this warning regularly when trying to log in on an T500 thinkpad on its
docking station with external display attached.  Sometimes I struggle like hell
to get the external display working again.  I normally end up with a random set of symptoms, normally one of:

- monitor goes into power saving after logging in
  - normally requires laptop lid to be opened, wait, then shut, wait, hit some
    keys and hope it unblanks
  - blindly typing 'xrandr --output VGA1 --off' followed by 'xrandr --output VGA1 --auto' (the second of which invariably seems to get corrupted despite typing up-arrow, ^w, --auto)
- a mouse pointer which is fixed at one position on an otherwise black screen, and it changes shape as I move the mouse
  - this seems to require an entire shutdown (as in power off) and reboot to resolve.

I have many and regular submissions of this problem into kerneloops.

Sorry, wrong bug - meant Bug 507416

I see this in F12. Workaround in comment 13 still works.

Created attachment 377770 [details]
ACPI buttons: provide lid status functions (needed for git patches that fix this issue)

I am currently running kernel-2.6.31.6-166.fc12.i686 patched with the attached ACPI buttons patch together with the following four patches from git (in this order):
http://gitorious.org/usb/usb/commit/c1c7af60892070e4b82ad63bbfb95ae745056de0.patch
http://gitorious.org/usb/usb/commit/06324194eee97a51b5f172270df49ec39192d6cc.patch
http://gitorious.org/usb/usb/commit/06891e27a9b5dba5268bb80e41a283f51335afe7.patch
http://gitorious.org/usb/usb/commit/c9354c85c1c7bac788ce57d3c17f2016c1c45b1d.patch

... and the screen now comes back on when I open the lid.

If you want the workaround to be performed automatically wen the lid is opened, you can use acpid. Instructions about how I did it for a X41 thinkpad are added to the common bugs page:
https://fedoraproject.org/wiki/Common_F12_bugs#intel-lid-dpms

Insisting on uid=500 is a bit of a hack - why not look in /var/run/console/console.lock to find out who is logged in?  (Actually, does this even work?  I'd have thought you would need the X11 auth info from /var/run/gdm, at which point you don't need the su.)

I'm surprised no one has commented on the above kernel patches; I'm still running them and haven't once needed to use the xrandr workaround.  Would be nice to get them into the F12 kernel.

(In reply to comment #63)
> Insisting on uid=500 is a bit of a hack - why not look in
> /var/run/console/console.lock to find out who is logged in?  (Actually, does
> this even work?  I'd have thought you would need the X11 auth info from
> /var/run/gdm, at which point you don't need the su.)

I did not know about /var/run/console/console.lock. Probably this can be used, too, but then there are still some issues left, e.g. when there is more than one X-server running. Nevertheless, the describe approach works here on my system.

> I'm surprised no one has commented on the above kernel patches; I'm still
> running them and haven't once needed to use the xrandr workaround.  Would be
> nice to get them into the F12 kernel.

Yeah, that would be nice, given how old the bug already is.

Can you still suspend/resume with those kernel patches? c9354c85.... commitlog contains a reference to http://bugzilla.kernel.org/show_bug.cgi?id=14484 [no video output after suspend]

I have never been able to suspend/resume properly since I upgraded from FC6 (see bug 539367) so someone else will need to test that.

I included c9354c85 because it seemed to be the best fix at the time for some issues which a few people had raised with c1c7af6 (mentioned in comment 56 as possibly fixing this bug here).  It mentions 14484 in the context of claiming to fix that bug.  I don't know if there have been any developments since; I did my research mostly using Google. ;-)

It looks like the patches in Comment 61 fix this bug.  Are they included in kernel-2.6.32.7-37.fc12, which is the current release for F12?  If so, I'd like to update the Common Bugs entry and note this update as the fix (and of course close this bug).

This bug is gone for me. Kernel is 2.6.31.12-174.2.3.fc12.i686.PAE, Fedora 12. Hardware is Thinkpad X40 with the Intel 855GM card. Laptop suspends and resumes fine, with KMS enabled. I even tried suspend resume with compiz enabled, and it works fine.

(In reply to comment #68)
> This bug is gone for me. Kernel is 2.6.31.12-174.2.3.fc12.i686.PAE, Fedora 12.
> Hardware is Thinkpad X40 with the Intel 855GM card. Laptop suspends and resumes
> fine, with KMS enabled. I even tried suspend resume with compiz enabled, and it
> works fine.    

On an X41 the bug is not fixed with that kernel. Btw. the bug is not abour suspend or resume, but about closing and opening the lid, which still breaks the screen. I don't know about kernel-2.6.32.7-37.fc12, it does not seem to be in updates-testing yet.

That's odd; we seem to be in flux between 2.6.31 and 2.6.32.  In any case, you can download the latest test kernels directly from: http://koji.fedoraproject.org/koji/packageinfo?packageID=8

(In reply to comment #70)
> That's odd; we seem to be in flux between 2.6.31 and 2.6.32.  In any case, you
> can download the latest test kernels directly from:
> http://koji.fedoraproject.org/koji/packageinfo?packageID=8    

I guess this happens becasue the latest update contains security fixes:
https://admin.fedoraproject.org/updates/F12/FEDORA-2010-1787

I've been running 2.6.32.9-70.fc12 for a while now and haven't needed either the xrandr workaround or the kernel patches.  The screen does come back on when the lid is opened.

The discussion here seems to be about F12.  Removing from F13Blocker; please re-add to F13Blocker if this is reproducible there.

I have a Dell D420, running F12 with:

2.6.32.10-90.fc12.i686.PAE
xorg-x11-drv-intel-2.9.1-1.fc12.i686

And if I close the lid on AC, so that the laptop stays on, when I re-open the lid the display does not come back. I have to ctrl-alt-fx to a text console and then go back to the X11 console to get my display back.

Weirdly, screensaver blanking and suspend/resume work just fine.

On an X41 with F12 this is fixed for me. I am currently using these packages:
2.6.32.11-99.fc12.i686.PAE
xorg-x11-drv-intel-2.9.1-1.fc12

I have been hitting this bug for a while on my Asus U3S laptop with Intel graphics. Previously the workaround (screenfix.sh) didn't help. Recently after some kernel updates the behavior changed such that the backlight comes back on but the display stays on the Fedora logo no matter what I press. I still have to hard reset it. I am sorry I don't have more information but I wanted to get that out there if it helps. I can provide more information if requested (I would now but the laptop is at home).

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  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 '12'.

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 12'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 12 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

The particular problem described here (namely: close laptop lid; open laptop lid; screen is completely blank) hasn't happened for me since I upgraded from F12 to F13 (and now F14).

Very similar symptoms with a different cause did routinely happen for me on F13 (leave machine idle; xscreensaver activates; 5-10% of the time come back to find the screen completely blank).  But this may or may not be fixed in F14 and I guess would deserve its own bugzilla entry if it turns out to be still present.

let's close it, then.



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