You are not logged in.
just FTR, the remove render reclock support patch is in linus tree since 2.6.32.4 (actual merge of the commit you linked)
http://git.kernel.org/?p=linux/kernel/g … 23acc2127a
I stand corrected
I hadn't realised it was a commit to the main branch, and thanks for the original patch/link.
====* -- Joke
O
\|/ --- Me
/ \ Whooooosh
Offline
You should try this patch, which was mentioned in the forums here.
Does this now solve this issue?
I have this flickering/blackout very seldom, so I cannot reliable confirm that it works here.
Offline
@DonVla
It works for me; the combination of that patch, and the kernel line addition means I have no problems (945GME).
====* -- Joke
O
\|/ --- Me
/ \ Whooooosh
Offline
I hadn't realised it was a commit to the main branch
well, actually, the commit you linked was indeed from the drm-intel branch. it's just that it has been merged.
and thanks for the original patch/link.
you are very much welcome. git bisect is really a great tool (even if I had to melt my CPU to find the guilty commit ).
Offline
@makimaki
It seems that only adding i915.powersave=0 to the kernel boot line is sufficient to avoid the flicker/blackout.
http://www.gossamer-threads.com/lists/l … ?page=last
Offline
Same problem on my eeepc 1005HA, kernel 2.6.32.4-1. Problem starts with a brief flicker, followed soon by a black screen. Computer then is completely unresponsive and I have to reboot. Like the earler posts here though, it is somewhat random. My eeepc has been freshly booted for 1 hour now and there's been no flickering or black screen lockups.
I have not tried the i915.modeset=0 grub option yet. I kinda want to see if the problem is triggered by any particular event. I see there's a new kernel in testing - 2.6.32.5-1. Perhaps there's a fix there.
On my eeepc 1005HA, the flickering/lockup does not occur until the computer is suspended to ram and then is woken up again. Example - I booted it yesterday, without any grub boot options, and used it for several hours (while plugged into the power supply) without any flickering or lockup. Today, I again booted without any grub boot options and used it for 20 minutes or so on battery power - no problems seen. But then I locked the screen and left the pc for about 30 minutes. When I came back I had to wake up the pc (my powersaving setting is to suspend to ram after 15 minutes if on battery), Immediately upon waking up, the flickering started. I'm running kernel26 2.6.32.5-1 now, btw.
Offline
Using the grub boot option i915.modeset=0 seems to stop the flickering and lockups for me, even following a suspend to ram which is when I've had the problem.
asus eeepc 1005HA
kernel26 2.6.32.5-1
Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
Offline
@qpeius: yes that will stop the flickering, It turns KMS off, which is probably fine, but if you do want to keep KMS turned on you could try "i915.modeset=1 i915.powersave=0".
Offline
@DonVla
Thanks for that I must check it on the vanilla kernel.
====* -- Joke
O
\|/ --- Me
/ \ Whooooosh
Offline
Thanks, Aedit. I tried the i915.powersave=0 option. Flickering does stop, but I don't like that hibernate/suspend don't work. I think I'd rather disable KMS using i915.modeset=0 and keep the powersave on. I don't see any need for KMS for me right now. I've run the netbook with and without KMS, and I can't see any difference in appearance or function. Is there any significant benefits to leaving KMS enabled?
Offline
I thought hibernate and suspend should work -- they do for me (but I have different hardware). What happens if you do "sudo /usr/sbin/pm-suspend" and "sudo /usr/sbin/pm-hibernate" (with "resume=<yourswappartition>" in the kernel GRUB line) ?
Offline
@Aedit - yep, I was wrong. Looks like hibernate/suspend work ok.
Offline