Description of problem: After 10-20 min, the new window and menus will black rectangle. Version-Release number of selected component (if applicable): x11-driver-video-intel-2.21.2-1.mga3.src.rpm How reproducible: Always. Steps to Reproduce: 1. Boot the Mageia 2. Use the system 10-20 min. 3. Open a new windows or program, and see the black window.
I see this line in Xorg.0.log: [ 1114.882] (EE) intel(0): Failed to submit batch buffer, expect rendering corruption: Resource deadlock avoided. And see this: https://bugs.freedesktop.org/show_bug.cgi?id=59771
Source RPM: (none) => x11-driver-video-intel-2.21.5-1.mga3.x86_64
I too have installed M3RC _64 on two differnet HW platforms with Intel video controllers. And both show the same error when rendering. Starting with programme menus drop downs going black/invisible, the (bottom) panel going invisible and windows going totally black. This occurs quite soon after login, so that the system is only operational 5 to 10 min. at most. Then I have to leave my session escaping by using the desktop toolbox menu and login again.
Priority: Normal => release_blockerCC: (none) => reneHardware: i586 => x86_64Version: Cauldron => 3Target Milestone: --- => Mageia 3
Today it seems that if I start FF (installed from the install DVD)the problem arises with dop downs and the the (bottom) panel. The blackening seems to hit new windows only ...
Do you see this error in Xorg.0.log file after "black window syndrome", but don't see before? [gergo@p762 ~]$ grep "(EE)" /var/log/Xorg.0.log (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 10573.638] (EE) intel(0): Failed to submit batch buffer, expect rendering corruption: Resource deadlock avoided.
I shall look it up during the evening. And - beware - I use KDE 4 (not Gnome) - should I start another tier on "my" bug ?
This is an Intel bug, and not depend your display environment.
Finally I got hold of the messeage requested (I had to remember to start a konsole before the error occurred :-) - here it is: [ 10220.923] (EE) intel(0): Failed to submit batch buffer, expect rendering corruption: Resource deadlock avoided. It seem to be almost the same as yours. Hope it helps ..
I do not know why, but when I add it to the Section "Device" is the symptom disappears: Option "AccelMethod" "sna" My new section of "device": Section "Device" Identifier "device1" VendorName "Intel Corporation" BoardName "Intel 810 and later" Driver "intel" Option "DPMS" Option "AccelMethod" "sna" EndSection
Sorry for my lack of knowledge. But where do you add the "AccelMethod" "sna" option ? I really would like to try if it helps too on my M3RC THX so much in advance.
Find this section in /etc/X11/xorg.conf file.
THX A LOT ! I've tried the alteration and my system too has been working just fine for almost half an hour now. This really seems to be a work-around - or the solution even ! And the fine thing about this, in fact, is, that it is "just" a configuration ... So now remains only to understand why it helps and if this ticket can be closed.
I'm not a Mageia contributor. I wait the fix of package on distrib. :-( But nobody have reaction from Mageia - and my mageia account doesn't login to forum.
CC: (none) => tmbVersion: 3 => Cauldron
CC: (none) => thierry.vignaud
Thomas, Colin: What do you think? It's bit late in the cycle to switch from UXA to SNA acceleration. But I guess it's more tested than UXA by Intel. Also I think this is what Unbuntu now uses. So WDYT? @René, Gergely: have you tried x11-driver-video-intel-2.21.6?
CC: (none) => mageiaSource RPM: x11-driver-video-intel-2.21.5-1.mga3.x86_64 => x11-driver-video-intel-2.21.5-1.mga3.x86_64, kernel; ldetect-lst
I added 'Option "AccelMethod" "sna"' too. It was working fine before too. But it's working fine with sna as well. Intel i5 CPU M 520 (first generation if I'm not wrong) (vendor:8086 device:0046 subv:1028 subd:043f).
CC: (none) => sander.lepik
(In reply to Thierry Vignaud from comment #13) > Thomas, Colin: What do you think? > It's bit late in the cycle to switch from UXA to SNA acceleration. > But I guess it's more tested than UXA by Intel. > Also I think this is what Unbuntu now uses. > So WDYT? > > @René, Gergely: have you tried x11-driver-video-intel-2.21.6? @Thierry - Hi, I use the driver from the downloaded DVD: 2.21.6-1.mga3
I've also just switched to SNA by dropping a file in /etc/X11/xorg.conf.d/20-intel.conf: Section "Device" Identifier "Intel Graphics" Driver "intel" Option "AccelMethod" "sna" EndSection I've not been keeping too up-to-date with things in Intel land, but it's working fine at the moment on my machine. Will test on my other (much older) machine later tonight. I'm not sure if will just fall back to UXA or if SNA works on older chips too (I would have thought that because S=Sandybridge in SNA that it would only work on newer architectures, but I've not looked into it). And yes, according to the https://launchpadlibrarian.net/137808997/xserver-xorg-video-intel_2.21.6-0ubuntu4.diff.gz file, Ubuntu is defaulting to sna now by passing --with-default-accel=sna
I grabbed an old atom netbook from work yesterday, and will see how it behaves...
Yes, I "try" it in my workplace day by day.
Still not tried on my older machine, but I just had an odd graphical issue on Gnome. It feels more like a compositing hiccup but it could easily be graphic driver releated. When resuming from suspend at home last night (going from a dual monitor setup before suspend to just the built in display on resume) the bottom half of my screen showed the lock screen and the upper half contained all my desktop but squashed - seems like every 5 or 10 lines were just removed. It was fixed by switching rotation and back again (switching VT was not enough - although the text console looked fine). Will see if it happens again. Might not be related to SNA, but worth noting all the same.
(In reply to René Lagoni Neukirch from comment #15) > (In reply to Thierry Vignaud from comment #13) > > Thomas, Colin: What do you think? > > It's bit late in the cycle to switch from UXA to SNA acceleration. > > But I guess it's more tested than UXA by Intel. > > Also I think this is what Unbuntu now uses. > > So WDYT? > > > > @René, Gergely: have you tried x11-driver-video-intel-2.21.6? > > @Thierry - Hi, > I use the driver from the downloaded DVD: 2.21.6-1.mga3 Today the system updated the x11-driver-video-intel-2.21.6-1.mga3 with x11-driver-video-intel-2.21.6-2.mga3. I then tried to comment out the ' Option "AccelMethod" "sna" ' and ended up having the original rendering problems. I re-entered the option and the systems works OK.
Added observation: Now videos in FF have started flickering after installing the x11-driver-video-intel-2.21.6-2.mga3
I don't understand what is your problems. The default rendering method is total bad. The SNA renderer method might experimental but work.
"Default UXA not working but SNA working for 3 users" is not the same as "experimental SNA safe for everybody" ==> hence the testing
As mentioned earlier, I saw the same problem again when going from a "suspend in two monitor env" to a "restore in single monitor env". I'm pretty sure it's down to the accel method used, so it's still buggy IMO. FWIW, I didn't really have any problem with the old method so for me this is a net loss for SNA. Stuff that used to work fine for me no longer does. This is why we test... (I'll do some more tests with latest kernel and speak to some upstream intel guys).
Source RPM: x11-driver-video-intel-2.21.5-1.mga3.x86_64, kernel; ldetect-lst => x11-driver-video-intel-2.21.6-1.mga3.x86_64, kernel; ldetect-lst
(In reply to René Lagoni Neukirch from comment #21) > Added observation: Now videos in FF have started flickering after installing > the x11-driver-video-intel-2.21.6-2.mga3 I don't know if this is of some help ? But the flickering can be seen here, just scroll some of the video area outside the FF window. I usually scroll it out of the top. Then the flickering starts. And it stops again if you scroll the full video area down again. pls see: http://www.b.dk/tech/droppede-net-i-et-aar-som-eksperiment The video should be understandable, but maybe not the newspaper text. Also the new driver allows you to choose some EXA option. once set, the radio button for this disappears.
Confirmed, I also see this flickering. I will double check again with the old default method.
Might also be a mesa-9.1.2 regression
A fixed libdrm-2.4.43-4.mga3 (using the fdo fence count fix in comment 1) is submitted to cauldron, please test. If there still are some problems with intel, can you test theese 2 kernels and see if any of them helps: kernel-desktop-3.8.11-1.2.mga3: http://tmb.mine.nu/Mageia/Cauldron/bugs/intel/test1/ http://tmb2.mine.nu/Mageia/Cauldron/bugs/intel/test1/ kernel-desktop-3.8.11-1.3.mga3: http://tmb.mine.nu/Mageia/Cauldron/bugs/intel/test2/ http://tmb2.mine.nu/Mageia/Cauldron/bugs/intel/test2/
(In reply to Thomas Backlund from comment #28) > A fixed libdrm-2.4.43-4.mga3 (using the fdo fence count fix in comment 1) is > submitted to cauldron, please test. > > > If there still are some problems with intel, can you test theese 2 kernels > and see if any of them helps: > > > kernel-desktop-3.8.11-1.2.mga3: > http://tmb.mine.nu/Mageia/Cauldron/bugs/intel/test1/ > http://tmb2.mine.nu/Mageia/Cauldron/bugs/intel/test1/ > > kernel-desktop-3.8.11-1.3.mga3: > http://tmb.mine.nu/Mageia/Cauldron/bugs/intel/test2/ > http://tmb2.mine.nu/Mageia/Cauldron/bugs/intel/test2/ Very good. So, you most likely want the test WITHOUT the setting of ' Option "AccelMethod" "sna" ' ?! The repo just upgraded libdrm today. I shall be very observant of various versions ... my kernel as of now is 3.8.11-server-1.mga3, libdrm-intel1 is 2.4.43-4.mga3 (but 586) and libdrm-common is of same version (but x86_64). No changes to x11-driver-video-intel-2.21.6-2.mga3.
It seems, that the problem is now solved. I have been running since this morning (withOUT the Option "AccelMethod" "sna"). Rendering has been working just fine. My setup (versioning) as of previous comment.
I tested with all kernel and work fine.
Just for the record: Today I used the "sna" option - everything have been working just fine.
Just for the record: Today I used the "sna" option - everything has been working just fine.
I test without "sna" option.
I have one problem. [gergo@p752 ~]$ uname -r 3.8.11-desktop-1.mga3 [gergo@p752 ~]$ grep "(EE)" /var/log/Xorg.0.log (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 66954.369] (EE) intel(0): Failed to submit batch buffer, expect rendering corruption: Resource deadlock avoided. [gergo@p752 ~]$ uptime 10:36:13 up 18:41, 13 users, load average: 0.39, 0.70, 0.68
Perhaps worth trying with the 3.8.12 kernel now available. Also there were a few test kernels after 3.8.11 that Thomas posted about on the ML so maybe worth trying those too. However this message appears to be the driver doing sensible stuff to avoid deadlocks. I'm fairly sure I've seen that message on occasion.
(In reply to Colin Guthrie from comment #36) > Perhaps worth trying with the 3.8.12 kernel now available. Also there were a > few test kernels after 3.8.11 that Thomas posted about on the ML so maybe > worth trying those too. > > However this message appears to be the driver doing sensible stuff to avoid > deadlocks. I'm fairly sure I've seen that message on occasion. I've been running the kernel 3.8.12-server-1.mga3 without any problems. I run it withOUT the "sna" option. I've tried the: grep "(EE)" /var/log/Xorg.0.log and se no errors on my two systems.
I try the 3.8.11-desktop-1.2.mga3 kernel without sna option. The Youtube flash is not show in fullscreen. The video show with sna option in fullscreen.
@Gergely: did you try 3.8.12-desktop kernel yet? this bug report is a bit of a mix, it seems to me like that this is fixed for most people, but not everyone. (or is it?) if it isn't, it might be interesting to add this to errata
CC: (none) => alien
It looks like all the work with 3.8.12-desktop-2.mga3 kernel
The "black window" problem is on without sna option. :-( [gergo@p752 ~]$ uptime 14:57:18 up 1:51, 13 users, load average: 0.75, 0.62, 0.42 [gergo@p752 ~]$ grep "(EE)" /var/log/Xorg.0.log (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 6702.613] (EE) intel(0): Failed to submit batch buffer, expect rendering corruption: Resource deadlock avoided.
CC: (none) => olav
What's the status of this bug with the current stack? We couldn't do anything for mga3, but we're now on track for mga4. We default to SNA now.
Target Milestone: Mageia 3 => Mageia 4
Closing as old. Please reopen if you can reproduce.
Status: NEW => RESOLVEDResolution: (none) => OLD