Shortly after my eee 1000he (intel atom n280, intel gma graphics) has woken up from suspend to ram the screen starts to show short distortions or jitter several times until it locks up (this can take 10's of minutes) on a black screen or some other color (I have seen it lock on red also). The machine is still fully functional via SSH meaning the machine hasn't locked up. Restarting X does not help, only a reboot does, suggesting a driver problem? It sounds like a hardware problem but it never ever happens if the systems has not gone to sleep first which suggests it is software. Also a reboot always fixes is immediately. FYI: $ xdpyinfo | grep version version number: 11.0 X.Org version: 1.7.3.902
Will definitely need a lot more details on this bug before we can investigate further. Please see: http://intellinuxgraphics.org/how_to_report_bug.html and clear the NEEDINFO keyword when you add more details to this bug report. And we'll definitely do what we can to help. -Carl
This description matches my symptoms, so I will attempt to provide more information. Bug description: As described above... For me: Problem only occurs when kernel KMS is enabled. Also, switching to another virtual console and back, or suspend/resuming again (e.g. by closing/opening the lid), usually makes the screen look normal again... until the next time it starts looking wrong somehow again. Specific wrongness observed includes the following (in no particular order) : - The whole screen is black (but backlight is still on). - All of the screen is black except one of the GNOME side-bars on the top of the screen. - A window's, or a GNOME-terminal's tab's contents (not including title bar) go all white, and switching current window/tab sometimes helps but sometimes I need to change the content inside the window (e.g. by hitting a key when in a terminal). (Alternatively, suspend/resume fixes all this too.) - The screen shifts horizontally for a moment. Or for longer than a moment. Or the top third of the screen shifts horizontally. (so a part of what should have been on the left side of the screen might wrap around to the right side, or vice versa -- I'm not sure of the details.) - (Also whenever I resume, the screen jitters a little bit for a moment. I probably wouldn't call this a bug on its own. However it does not happen on no-KMS.) (A suspend-resume issue I have, I'm mentioning just on the off chance that it's related: whether KMS or no, with this software-version-configuration on my computer, the *first* time I suspend/resume takes a whole minute to resume, and subsequent resumes occur at normal quickness.) System environment: -- chipset: `lspci` says "Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)" -- system architecture: XX-bit x86_64 -- xf86-video-intel: 2.10.0 (also 2.9.1, which results in the same bugginess under KMS but works well under no-KMS. 2.10.0 doesn't support no-KMS, otherwise I wouldn't have to bother you with these details.) -- xserver: 1.7.5 -- mesa: 7.7 -- libdrm: 2.4.18 -- kernel: linux-2.6.32.8 -- Linux distribution: Arch Linux -- Machine or mobo model: Apple MacBook 2,1 (June 2007) -- Display connector: it's the laptop's screen. Reproducing steps: Boot (make sure via kernel-boot-options that KMS is enabled). Start X. Suspend to ram. Resume. Use the computer normally... Opening lots of windows might help (I always do). Playing video might help (but is definitely not necessary). Keep it up for 10-20 minutes (order-of-magnitude. It seems random. It might take an hour, or as little as a couple minutes.) Additional info: [not yet... Xorg.0.log and dmesg should be easy to get once I have time to go reproduce again; I'll see if I can snap a few photos too (Somehow I doubt that screenshots would match what I'm seeing... and are a bit hard to get when the screen's not showing anything... or is it easy to make a clever shortcut screenshot key?) I could include intel_reg_dumper output at several points (before suspend, after resume but before visible issues, and, after visible issues). Should I just test against the latest software (or would logs from the no-kms case be useful)? Any other logs? I'll just assume sensible answers if I don't get a reply before I reproduce (hopefully in the next few days).]
Indeed, you are descibing exactly my problem. I also just found out, I can regain the screen by another sleep-wakeup cycle. What logs would make sence to post here? (btw, chromium say the site security certificate has been revoked, is that a chromium problem? Works in Firefox)
Created attachment 33607 [details] Xorg.0.log
Created attachment 33608 [details] dmesg output
Created attachment 33609 [details] second dmesg The screen blanked again while I was submitting the bug report, on the off chance it's useful, I'm submitting another dmesg after the second screen blank, this time the screen blanked to blue instead of black.
Created attachment 33610 [details] second Xorg.0.log Here's also a second Xorg.0.log from after my screen blanked a second time (this time to blue instead of black).
Created attachment 33611 [details] xorg packages, kernel fred has installed This text file contains the versions of Xorg packages (as reported by pacman, the Arch Linux package manager) and the output of uname -a
I've removed the "NEEDEDINFO" keyword, because hopefully between me and the other commentors we've provided enough info to try and reproduce this bug, if not, please reply to request more info. Oh ... one more piece of info: I've got an atom system with 945GSE chipset (GMA 950 graphics))
I report the same issue with the 915GM chipset found in eeepc 900. On resume, black screen after some random flickering, and I finally have a mouse pointer now since two weeks or something like that (due to new versions of kernel/X, i'm running Arch Linux). Although the mouse pointer is able to move, the screen resolution is not correct so it disappears on the bottom and on the right, and there is no window manager or windows, just black screen. When I switch to ttys (ctrl-alt-F1), the mouse pointer disappears and the screen stays black. The Xorg log does not give much information. By the way, it was reported nearly one year ago: http://bugzilla.kernel.org/show_bug.cgi?id=13144
Carl, any progress with this? Should this be moved to the kernel / Jesse?
(In reply to comment #11) > Carl, any progress with this? Should this be moved to the kernel / Jesse? Since the bug is triggered by sleep/resume and only with KMS, the bug likely is in the kernel component of the driver. Jesse, seen any similar issue with sleep/resume killing a 945? -Carl
Yes, in fact one such issue was just fixed by disabling FBC on 945. Patch is on the mailing list, maybe it works for you? https://patchwork.kernel.org/patch/86999/
Actually on my Arch Linux install it seems to have fixed "itself", my kernel is: kernel26-2.6.32.10-1. With: xf86-video-intel-2.10.0-1 I haven't seen strangeness for a while now.
Well, I'll tentatively mark this as closed then.
It is still not working with the 915GM chipset, with the same versions (latest archlinux). I guess I have to create a new bug report.
Still experiencing the issue, with upgraded kernel(2.6.33.2)/libs: System environment: -- chipset: `lspci` says "Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)" -- system architecture: XX-bit x86_64 -- xf86-video-intel: 2.10.0 -- xserver: 1.7.6 -- mesa: 7.7.1 -- libdrm: 2.4.19 -- kernel: linux-2.6.33.2 -- Linux distribution: Arch Linux -- Machine or mobo model: Apple MacBook 2,1 (June 2007) -- Display connector: it's the laptop's screen.
Created attachment 35127 [details] Xorg log following suspend/resume, glitches, Ctrl-Alt-F2 & F7, and more glitches
Created attachment 35128 [details] dmesg following suspend/resume, glitches, Ctrl-Alt-F2 & F7, and more glitches I only switched VTs with Ctrl-Alt-F2 and back, because the glitches were getting so bad that I couldn't see my browser/commandline anymore (and switching improves matters temporarily).
I think that's all the info you've asked for, all in one place. Please ask me if you need more logs/info... the issue is a bit tricky to reproduce (in fact, when I tried following my own "reproduction steps" under a user-account that I don't usually use, I could not reproduce it before I lost patience after an hour. But every time I run my normal user account, the issue is certain to surface within a day.)
Oh! Odd thing I noticed: Moving the mouse-cursor to the top of the screen also temporarily fixes the problems (actually it works better than switching VTs. And possibly as well as suspend/resuming.). I'm not sure yet if the cursor has to reach the top pixel of the screen, or just to overlap my GNOME panel on the top side of the screen (which often starts to look funny at the same time as the rest of the screen is being glitchy in other ways).
update: all I have to do is mouse over the panel ...which hilights one of the icons I have in the panel (and the icon *does* touch the top of the screen...) ... mousing over some other part of the panel with no icons--even all the way to the top of the screen -- does NOT help. Mousing over the firefox icons (back, forward, etc.), which also appear to hilight, does not help. I haven't yet tested hilighting things in gnome panels on different sides of the screen than the top. Incidentally, I noticed that typing random bits into my Facebook-search-box (which brings up lots of in-web-page menus in quick succession) was sometimes a prelude to screen glitches. (But not reliably.) Similar for dragging the scroll-bar on long web pages (facebook homepage, or other) (As before, all this same user software, same versions etc., consistently works without any screen glitches ever, when in non-KMS mode.)
update: only the panel-icons at the *top* of the screen help, not the side or bottom. I noticed that the screen appeared (while glitching) shifted vertically, as if a bit of the top panel were cut off and the bottom panel extended downward a bit to be taller.
Can you attach a screenshot of the corruption? If the screenshot looks ok, please attach it along with a picture of your screen with a camera.
ok, I'd tried screenshots and they didn't seem to show anything wrong, so I've got someone's digital camera here... waiting to experience more glitches...
Here come pictures! (14 MB, and this Bugzilla's limit was 1 MB, so uploaded elsewhere) http://isaac.cedarswampstudios.org/a/2010/scrphotosnamed.tar.gz I tried to name directories to indicate what glitch I knew was in each group of images (each group is photographing the exact same glitch within a few seconds of each other). Some photos turned out better than others. You'll have to ignore where the screen has dirt/dust/fingerprints/keyboard-marks on it. And there are a few optical effects, reflection/refraction/Moire-patterns on the screen, to look out for (some of which aren't visible to the human eye, only showed up in the camera; and none of which have anything to do with software bugs). Also, sometimes the whole screen turned black, or white, or (once) green: I didn't bother photographing these. (The only way to recover from *this* glitch I found was that suspend/resume was needed).
Can you reproduce this with the for-linus branch of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel.git? The screen shots make it look like a possible FBC problem, but it could also be a tiling related bug.
(In reply to comment #27) > Can you reproduce this with the for-linus branch of > git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel.git? So far it's fine (just running it lightly for two days so far, so I'll report back if it glitches). Also it resumes from suspend really quickly!
Ok, optimistically closing then, thanks for the update.
Is that branch merged into 2.6.24 ? (Because if so I'd like to move to an actually released kernel for further testing.)
(In reply to comment #30) > Is that branch merged into 2.6.24 ? (Because if so I'd like to move to an > actually released kernel for further testing.) If it was FBC related then yes, that fix was merged in around the 2.6.34-rc5 timeframe.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.