Bug 617809

Summary: [Cantiga] render error detected, EIR: 0x00000010; [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking
Product: [Fedora] Fedora Reporter: Tom London <selinux>
Component: xorg-x11-drv-intelAssignee: Dave Airlie <airlied>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 19CC: ajax, dougsland, gansalmon, itamar, jonathan, kai.kasurinen, kernel-maint, kmcmartin, madhu.chinakonda, mcepl, mishu, nobody, oppiet35, xgl-maint, zkabelac
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-02-17 13:18:13 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
dmesg output
none
/var/log/Xorg.0.log
none
/var/log/messages
none
Patch to skip check of drm_kms_helper_poll none

Description Tom London 2010-07-24 05:34:15 UTC 
Description of problem:
Noticed this in /var/log/messages:

Jul 23 18:03:59 tlondon kernel: render error detected, EIR: 0x00000010
Jul 23 18:03:59 tlondon kernel:  IPEIR: 0x00000000
Jul 23 18:03:59 tlondon kernel:  IPEHR: 0x01000000
Jul 23 18:03:59 tlondon kernel:  INSTDONE: 0xfffffffe
Jul 23 18:03:59 tlondon kernel:  INSTPS: 0x0001e000
Jul 23 18:03:59 tlondon kernel:  INSTDONE1: 0xffffffff
Jul 23 18:03:59 tlondon kernel:  ACTHD: 0x252106e8
Jul 23 18:03:59 tlondon kernel: page table error
Jul 23 18:03:59 tlondon kernel:  PGTBL_ER: 0x00000001
Jul 23 18:03:59 tlondon kernel: [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking

I'm running kernel-2.6.35-0.55.rc6.git0.fc14.x86_64

Version-Release number of selected component (if applicable):
kernel-2.6.35-0.55.rc6.git0.fc14.x86_64

How reproducible:
First time I've noticed this.....

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Tom London 2010-07-24 15:53:53 UTC 
Should have included this:

System is Thinkpad X200:

[root@tlondon ~]# lspci
00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:03.0 Communication controller: Intel Corporation Mobile 4 Series Chipset MEI Controller (rev 07)
00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03)
00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03)
00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03)
00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
00:1f.0 ISA bridge: Intel Corporation ICH9M-E LPC Interface Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03)
03:00.0 Network controller: Intel Corporation PRO/Wireless 5100 AGN [Shiloh] Network Connection
[root@tlondon ~]#
Comment 2 Tom London 2010-07-28 17:17:00 UTC 
Notice a few more of these:

Jul 25 15:24:24 tlondon kernel: render error detected, EIR: 0x00000010
Jul 25 15:24:24 tlondon kernel:  IPEIR: 0x00000000
Jul 25 15:24:24 tlondon kernel:  IPEHR: 0x01000000
Jul 25 15:24:24 tlondon kernel:  INSTDONE: 0xfffffffe
Jul 25 15:24:24 tlondon kernel:  INSTPS: 0x0001e000
Jul 25 15:24:24 tlondon kernel:  INSTDONE1: 0xffffffff
Jul 25 15:24:24 tlondon kernel:  ACTHD: 0x0de03fa8
Jul 25 15:24:24 tlondon kernel: page table error
Jul 25 15:24:24 tlondon kernel:  PGTBL_ER: 0x00000001
Jul 25 15:24:24 tlondon kernel: [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking


Jul 28 10:05:16 tlondon kernel: render error detected, EIR: 0x00000010
Jul 28 10:05:16 tlondon kernel:  IPEIR: 0x00000000
Jul 28 10:05:16 tlondon kernel:  IPEHR: 0x01000000
Jul 28 10:05:16 tlondon kernel:  INSTDONE: 0xfffffffe
Jul 28 10:05:16 tlondon kernel:  INSTPS: 0x0001e000
Jul 28 10:05:16 tlondon kernel:  INSTDONE1: 0xffffffff
Jul 28 10:05:16 tlondon kernel:  ACTHD: 0x05e1a6b8
Jul 28 10:05:16 tlondon kernel: page table error
Jul 28 10:05:16 tlondon kernel:  PGTBL_ER: 0x00000001
Jul 28 10:05:16 tlondon kernel: [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking
Comment 3 Bug Zapper 2010-07-30 12:48:46 UTC 
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 4 Tom London 2010-08-14 22:45:31 UTC 
Changing this back to rawhide, as I see this with 
kernel-2.6.36-0.0.rc0.git1.fc15.x86_64
xorg-x11-server-debuginfo-1.8.99.906-1.fc15.x86_64
xorg-x11-server-utils-7.4-20.fc15.x86_64
xorg-x11-server-common-1.8.99.906-1.fc15.x86_64
xorg-x11-server-devel-1.8.99.906-1.fc15.x86_64
xorg-x11-server-Xorg-1.8.99.906-1.fc15.x86_64
xorg-x11-drv-intel-2.12.0-4.fc14.x86_64


Aug 14 14:15:54 tlondon kernel: render error detected, EIR: 0x00000010
Aug 14 14:15:54 tlondon kernel:  IPEIR: 0x00000000
Aug 14 14:15:54 tlondon kernel:  IPEHR: 0x00000000
Aug 14 14:15:54 tlondon kernel:  INSTDONE: 0xfffffffe
Aug 14 14:15:54 tlondon kernel:  INSTPS: 0x0001e000
Aug 14 14:15:54 tlondon kernel:  INSTDONE1: 0xffffffff
Aug 14 14:15:54 tlondon kernel:  ACTHD: 0x13207cb8
Aug 14 14:15:54 tlondon kernel: page table error
Aug 14 14:15:54 tlondon kernel:  PGTBL_ER: 0x00000001
Aug 14 14:15:54 tlondon kernel: [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking
Comment 5 Tom London 2010-08-14 22:46:25 UTC 
BTW, this last spew occurred when the system was idle for several hours and with the screen "black"
Comment 6 Tom London 2010-10-15 13:16:43 UTC 
Saw this again with kernel-2.6.36-0.38.rc7.git5.fc15.x86_64


Oct 14 17:26:35 tlondon kernel: [41009.963035] render error detected, EIR: 0x00000010
Oct 14 17:26:35 tlondon kernel: [41009.963035]   IPEIR: 0x00000000
Oct 14 17:26:35 tlondon kernel: [41009.963035]   IPEHR: 0x00000000
Oct 14 17:26:35 tlondon kernel: [41009.963035]   INSTDONE: 0xfffffffe
Oct 14 17:26:35 tlondon kernel: [41009.963035]   INSTPS: 0x0001e000
Oct 14 17:26:35 tlondon kernel: [41009.963035]   INSTDONE1: 0xffffffff
Oct 14 17:26:35 tlondon kernel: [41009.963035]   ACTHD: 0x14c1fdd8
Oct 14 17:26:35 tlondon kernel: [41009.963035] page table error
Oct 14 17:26:35 tlondon kernel: [41009.963035]   PGTBL_ER: 0x00000001
Oct 14 17:26:35 tlondon kernel: [41009.963035] [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking
Comment 7 Matěj Cepl 2010-10-22 15:10:04 UTC 
Crashes are interesting, but I would probably like to see more of the context around them. Please add drm.debug=0x04 to the kernel command line, restart computer, and attach

* your X server config file (/etc/X11/xorg.conf, if available),
* X server log file (/var/log/Xorg.*.log)
* output of the dmesg command, and
* system log (/var/log/messages)

to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.
Comment 8 Tom London 2010-10-25 13:54:56 UTC 
Created attachment 455542 [details]
dmesg output

I've followed the above instructions.

Not sure if you wanted the attachments on the next reboot, or on a boot when the error occurred.

To be safe I'm providing attachments on the next reboot, before I see the 'render error'.  

I will repeat posting the attachments if/when I see the error again.

I have no xorg.conf.

System is Lenovo Thinkpad X200.  Here is output of lspci:


00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:03.0 Communication controller: Intel Corporation Mobile 4 Series Chipset MEI Controller (rev 07)
00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03)
00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03)
00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03)
00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
00:1f.0 ISA bridge: Intel Corporation ICH9M-E LPC Interface Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03)
03:00.0 Network controller: Intel Corporation PRO/Wireless 5100 AGN [Shiloh] Network Connection
Comment 9 Tom London 2010-10-25 13:55:54 UTC 
Created attachment 455543 [details]
/var/log/Xorg.0.log

/var/log/Xorg.0.log
Comment 10 Tom London 2010-10-25 13:57:15 UTC 
Created attachment 455544 [details]
/var/log/messages

/var/log/messages for current boot/session
Comment 11 Matěj Cepl 2010-10-25 15:48:01 UTC 
(In reply to comment #8)
> Not sure if you wanted the attachments on the next reboot, or on a boot when
> the error occurred.

For dmesg stdout I meant the latter, just after the error occurs (you may need to get to your computer via some alternative means .... ssh).

Thank you and sorry for not making myself clear the first time.
Comment 12 Zdenek Kabelac 2010-10-30 19:00:52 UTC 
Ok I'm experiencing this problem for quite some time already with upstream vanilla 2.6.36 - it's the main issue why my resume doesn't work reliably on my T61 anymore after 2.6.35 kernel.

I've been a bit hopping that this problem will go away with more recent  -rc kernel - but as it's still present even in 2.6.36 I think I'll need to look into more depth - though as Tom  points out  2.6.35-0.55.rc6.git0.fc14.x86_64
is the first  2.6.35 kernel which has this behaviour it might be especially much more simple to overview list of backported patches for this release.

I affraid that I'd had to bisect between those very early and unreliable -rc kernels - so having probably difficulties to even compile or run such kernel.

I think it's unrelated to Xorg and it's purely i915 kernel driver bug.
 
Tom - are you able to check for problematic patch yourself ?
Comment 13 Zdenek Kabelac 2010-10-30 19:05:38 UTC 
Also there is upstream kernel bugzilla:

https://bugzilla.kernel.org/show_bug.cgi?id=19052
Comment 14 Tom London 2010-10-31 19:07:45 UTC 
Perhaps, but the fault occurs infrequently (say, once every two weeks or so). Last time I saw it was on 14 Oct.

So bisecting may be a very long process.....

Any traction upstream?
Comment 15 Zdenek Kabelac 2010-11-01 08:59:10 UTC 
Yes - this also applies to me - I get this error usually once per 5 or 6 resumes - so it's hard to judge when to say good/bad in bisect - it's the reason why I haven't done this myself already.

I think for me it never happens with clean vanilla 2.6.35 (even with current rawhide Xorg packages) - while the bug seems to be present in your Fedora patched 2.6.35 kernel - so the patch should be present in extra patches compiled into Fedora kernel - I'll probably make a look on this during this week - if noone else has better proposal/idea what could be the problem.

Also it's probably one of those - which went upstream in merge window for 2.6.36 - as I'm almost sure it's been present in -rc1/-rc2 already.
Comment 16 Zdenek Kabelac 2010-11-05 10:21:10 UTC 
Ok - I've spend a lot of time trying to bisect this problem.

I'm not 100% sure that I've found the bug itself - but I think it could be at least some hint.

First I should say - I'm getting this "*ERROR* EIR stuck:" bug only during resume - if Tom is seeing this problem in other case - it could be slightly different issue.

First I've suspected commit: fc1caf6eafb30ea185720e29f7f5eccca61ecd60
(2.6.35-03797-gfc1caf6)- a big drm/kms/i915/radeon merge -  but on my machine this seems to work well and I've not seen any problem with the resume and this major merge.

So after some time - I've found that with commit: 3b7433b8a8a83c87972065b1852b7dcae691e464 (2.6.35-04864-g3b7433b)
(Tejun's  workqueue merge patch) - I'm getting this EIR resume problem.

The kernel which is before this merge: 2.6.35-04807-g4a386c3 - seems to work well - thought hard to be 100% sure, but at least I've not seen EIR bug - I've seen some other Ooopses with this one - but not black screen and EIR message in log.

So this leads me to conclusion - that Tejun's workqueue patch exposed some internal problem in the Intel driver scheduling:
(drm: use workqueue instead of slow-work)

I'm not sure I could pinpoint exactly which patch in this merge causes trouble - as the merge leads to compilation of 2.6.35-rc kernels - and the EIR problem might happen just with combination of those 2 large merges (drm/workqueue) - also the process is not very deterministic and very time consuming.
Comment 17 Tom London 2010-11-05 13:15:20 UTC 
Not obvious that my issue is the same....

Here is a snipper from /var/log/messages from the last time this happened to me:


Oct 14 15:31:25 tlondon NetworkManager[1038]: <info>   nameserver '68.87.76.182'
Oct 14 15:31:25 tlondon NetworkManager[1038]: <info>   nameserver '68.87.78.134'
Oct 14 15:31:25 tlondon NetworkManager[1038]: <info>   domain name 'hsd1.ca.comcast.net.'
Oct 14 17:26:35 tlondon kernel: [41009.963035] render error detected, EIR: 0x00000010
Oct 14 17:26:35 tlondon kernel: [41009.963035]   IPEIR: 0x00000000
Oct 14 17:26:35 tlondon kernel: [41009.963035]   IPEHR: 0x00000000
Oct 14 17:26:35 tlondon kernel: [41009.963035]   INSTDONE: 0xfffffffe
Oct 14 17:26:35 tlondon kernel: [41009.963035]   INSTPS: 0x0001e000
Oct 14 17:26:35 tlondon kernel: [41009.963035]   INSTDONE1: 0xffffffff
Oct 14 17:26:35 tlondon kernel: [41009.963035]   ACTHD: 0x14c1fdd8
Oct 14 17:26:35 tlondon kernel: [41009.963035] page table error
Oct 14 17:26:35 tlondon kernel: [41009.963035]   PGTBL_ER: 0x00000001
Oct 14 17:26:35 tlondon kernel: [41009.963035] [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking
Oct 14 19:56:33 tlondon yum[21541]: Updated: bash-4.1.9-1.fc15.x86_64
Oct 14 19:56:36 tlondon yum[21541]: Updated: setools-libs-3.3.7-8.fc15.x86_64
Oct 14 19:56:36 tlondon yum[21541]: Updated: libcurl-7.21.2-2.fc15.x86_64
Oct 14 19:56:45 tlondon yum[21541]: Updated: ghostscript-9.00-5.fc15.x86_64
Oct 14 19:56:48 tlondon yum[21541]: Updated: llvm-2.8-3.fc15.x86_64
Oct 14 19:56:49 tlondon yum[21541]: Updated: tomcat6-servlet-2.5-api-6.0.26-12.fc15.noarch

As you can see, my system was "running continuously" for some time (many hours), and as I recall, it was "idle" (that is, the screen was black (screensaver), etc.).

If I remember correctly, the other incidents were similar:  I don't resume my laptop.

Its been 3 weeks since the last reported incident, and I have not figured out a way to reproduce this, so not sure I am provided much support.
Comment 18 Zdenek Kabelac 2010-11-05 13:57:26 UTC 
Ok I'll need to figure out - when the Tejun's workqueue merge has been added to F14 kernel - it could have been the problem - different new scheduling.

My test case is to physically suspend & resume my hw (haven't been able to see this bug with pm_test yet) - which might not be very nice to hw itself - so that's why I'm so unhappy about doing this testing myself.

Anyway - it's always hard to tell if the problem is not present - as sometimes more then 15 resumes could be ok - so one has to try several times to repeat tests - but so far I'm convinced that workqueue change is the key problem.
Comment 19 Zdenek Kabelac 2010-11-06 02:24:52 UTC 
Ok

I've finished bisect - problems starts with  
991ea75cb1df7188d209274b3d51c105b4f18ffe
drm: use workqueue instead of slow-work

I've tried to revert that one together with 181a51f6e040d0ac006d6adaf4a031ffa440f41c.
And I've noticed small difference in reverting code for workqueue.

So after some testing and code comparing here is my small patch to vanilla 2.6.36 kernel  -  can you try whether this fixes your problem - I'm still not sure whether it's fix - or just I'm so far lucky to not hit 'black' screen with this one.....

BTW - I'm not saying it is fix - it's rather workaround for black screen - it's probably hack that hides other problem....

--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -932,7 +932,6 @@ void drm_helper_hpd_irq_event(struct drm_device *dev)
 
        /* kill timer and schedule immediate execution, this doesn't block */
        cancel_delayed_work(&dev->mode_config.output_poll_work);
-       if (drm_kms_helper_poll)
-               queue_delayed_work(system_nrt_wq, &dev->mode_config.output_poll_work, 0);
+       queue_delayed_work(system_nrt_wq, &dev->mode_config.output_poll_work, 0);
 }
 EXPORT_SYMBOL(drm_helper_hpd_irq_event);
Comment 20 Zdenek Kabelac 2010-11-06 02:25:59 UTC 
Created attachment 458265 [details]
Patch to skip check of drm_kms_helper_poll
Comment 21 Zdenek Kabelac 2010-11-06 11:57:43 UTC 
Ok I think I've made to fast judgement. The patch doesn't help - problem was back after few more test cycles.

But looking more into the code - there is nice modprobe config option:

options drm_kms_helper poll=0

I've tried already more cycles with this setting - and so far it looks good.
So no kernel patch is needed - on the other hand - I've no idea what I've disabled - probably periodical scan for new monitor or something like that.
Comment 22 Zdenek Kabelac 2010-11-07 22:45:34 UTC 
To add more details after a day of live without polling thread - it's sooooo much better ;) even hard to believe it's been so easy.

It's fixed my problem with closing laptop during suspend - and also youtube no longer plays weird sound with some videos.

And of course - no resume  EIR bug from that time....

There must be something seriously broken with polling thread.
Comment 23 Tom London 2010-11-08 00:10:42 UTC 
Wow..... 'poll=0' may be magic.....

After sticking 'options drm_kms_helper polli=0' into a file in /etc/modprobe.d/ and rebooting, all of a sudden compiz is working for the first time in weeks.....

Perhaps "There must be something seriously broken with polling thread." ......

I'll continue to run with compiz enabled and see if it continues to "just work".
Comment 24 Tom London 2010-11-08 00:11:12 UTC 
Oops... not 'polli=0' of course, but 'poll=0'.
Comment 25 Zdenek Kabelac 2010-11-08 08:30:17 UTC 
(In reply to comment #22)
> To add more details after a day of live without polling thread - it's sooooo
> much better ;) even hard to believe it's been so easy.
> 
> It's fixed my problem with closing laptop during suspend - and also youtube no
> longer plays weird sound with some videos.

Just to fix here myself - it seems that rather youtube is more and more switching to webm - so my sound flash problem is not so visible on this site any more - but otherwise the sound problem is still there - so disabled polling "fixes" only my suspend/resume problems for now.
Comment 26 Tom London 2010-11-08 15:15:28 UTC 
OK.  System booted again and compiz is running just fine.

No more screen artifacts, no more "lost lines of text" in terminal windows, no more ....

So should this be reassigned to kernel?
Comment 27 Matěj Cepl 2010-11-08 15:33:54 UTC 
(In reply to comment #26)
> So should this be reassigned to kernel?

No, please, don't ... we keep kernel graphic drivers in xorg-x11-* components so as to avoid even bigger mess in kernel bugs.

Plus was suggesting it is more Dave's issue. Reassigning.
Comment 28 Tom London 2010-11-08 15:41:34 UTC 
OK.

BTW, I've been running with 'drm.debug=0x04' for a while.

Let me know if any of the debug output would be useful.
Comment 29 Zdenek Kabelac 2010-11-11 11:21:39 UTC 
So I think I could happily say - from day of disabling helper thread - never had a single issue with suspend/resume with 2.6.36.

Also the sound bug is nicely described/resolved here: Bug 638477.

2Tom: I think you can drop drm debuging to speedup machine for now.

2Dave: Any progress, some patches to try?
Comment 30 Tom London 2010-11-11 14:51:02 UTC 
Thanks.  I'm dropping drm debugging for now.
Comment 31 Zdenek Kabelac 2010-11-26 13:15:46 UTC 
Dave - anything new?

I still need this for 2.6.37-rc3 to keep my resume stable and happy...
Comment 32 Robert Hinson 2010-12-22 21:16:04 UTC 
[   67.350009] render error detected, EIR: 0x00000010
[   67.350009] [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking
[   67.350009] render error detected, EIR: 0x00000010

This is with:
[oppie@fedora .gconf]$ uname -a
Linux fedora.linuxassistant.com 2.6.35.9-64.fc14.i686 #1 SMP Fri Dec 3 12:35:42 UTC 2010 i686 i686 i386 GNU/Linux
[oppie@fedora .gconf]$

[oppie@fedora .gconf]$ lspci
00:00.0 Host bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM Controller/Host-Hub Interface (rev 03)
00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 82)
00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 02)
00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 02)
01:01.0 Communication controller: Conexant Systems, Inc. HSF 56k Data/Fax Modem
01:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
[oppie@fedora .gconf]$

[oppie@fedora ~]$ more .xsession-errors
GNOME_KEYRING_CONTROL=/tmp/keyring-TyNFoK
GNOME_KEYRING_CONTROL=/tmp/keyring-TyNFoK
GNOME_KEYRING_CONTROL=/tmp/keyring-TyNFoK
SSH_AUTH_SOCK=/tmp/keyring-TyNFoK/ssh
GNOME_KEYRING_CONTROL=/tmp/keyring-TyNFoK
SSH_AUTH_SOCK=/tmp/keyring-TyNFoK/ssh
GPG_AGENT_INFO=/tmp/keyring-TyNFoK/gpg:0:1
Failed to play sound: File or data not found
beagled will run in the background.
Use beagle-status to check progress of beagled.
For log files check /home/oppie/.beagle/Log/current-Beagle.

Initializing nautilus-gdu extension
** Message: applet now removed from the notification area

(nautilus:3581): GdkPixbuf-CRITICAL **: gdk_pixbuf_format_get_name: assertion `f
ormat != NULL' failed
** Message: applet now embedded in the notification area
new binding F12
Got accel 65481, 0, 0
Got keycode 96
Got modmask 0
Warn: Inotify watches may be too low (8192) for some users!  Increase it to at l
east 65535 by setting fs.inotify.max_user_watches in /etc/sysctl.conf
Debug: Starting Inotify threads
Debug: Using utf8 encoding for filenames
Got Event! 33, -1
Got Event! 33, -1
** (deja-dup-monitor:3620): DEBUG: monitor.vala:273: Invalid next run date.  Not
 scheduling a backup.
[oppie@fedora ~]$

output from /var/log/Xorg.0.log
[   905.265] (II) intel(0): EDID for output VGA1
[   905.265] (II) intel(0): Manufacturer: EMA  Model: 309  Serial#: 24033
[   905.265] (II) intel(0): Year: 2004  Week: 21
[   905.265] (II) intel(0): EDID Version: 1.3
[   905.265] (II) intel(0): Analog Display Input,  Input Voltage Level: 0.700/0.300 V
[   905.265] (II) intel(0): Sync:  Separate
[   905.265] (II) intel(0): Max Image Size [cm]: horiz.: 32  vert.: 24
[   905.265] (II) intel(0): Gamma: 2.98
[   905.265] (II) intel(0): DPMS capabilities: StandBy Suspend Off; RGB/Color Display
[   905.265] (II) intel(0): First detailed timing is preferred mode
[   905.265] (II) intel(0): redX: 0.618 redY: 0.349   greenX: 0.280 greenY: 0.605
[   905.265] (II) intel(0): blueX: 0.152 blueY: 0.063   whiteX: 0.281 whiteY: 0.310
[   905.265] (II) intel(0): Supported established timings:
[   905.265] (II) intel(0): 720x400@70Hz
[   905.265] (II) intel(0): 640x480@60Hz
[   905.266] (II) intel(0): 800x600@60Hz
[   905.266] (II) intel(0): 800x600@75Hz
[   905.266] (II) intel(0): 1024x768@60Hz
[   905.266] (II) intel(0): 1024x768@75Hz
[   905.266] (II) intel(0): Manufacturer's mask: 0
[   905.266] (II) intel(0): Supported standard timings:
[   905.266] (II) intel(0): #0: hsize: 640  vsize 480  refresh: 85  vid: 22833
[   905.269] (II) intel(0): #1: hsize: 800  vsize 600  refresh: 85  vid: 22853
[   905.269] (II) intel(0): #2: hsize: 800  vsize 600  refresh: 100  vid: 26693
[   905.269] (II) intel(0): #3: hsize: 1024  vsize 768  refresh: 85  vid: 22881
[   905.269] (II) intel(0): #4: hsize: 1280  vsize 1024  refresh: 60  vid: 32897
[   905.269] (II) intel(0): Supported detailed timing:
[   905.269] (II) intel(0): clock: 94.5 MHz   Image Size:  320 x 240 mm
[   905.269] (II) intel(0): h_active: 1024  h_sync: 1072  h_sync_end 1168 h_blank_end 1376 h_border: 0
[   905.269] (II) intel(0): v_active: 768  v_sync: 769  v_sync_end 772 v_blanking: 808 v_border: 0
[   905.269] (II) intel(0): Monitor name: eView 17f3
[   905.269] (II) intel(0): Ranges: V min: 50 V max: 160 Hz, H min: 30 H max: 70 kHz, PixClock max 115 MHz
[   905.269] (II) intel(0): Serial No: MRG4550024033
[   905.269] (II) intel(0): EDID (in hex):
[   905.269] (II) intel(0): 	00ffffffffffff0015a10903e15d0000
[   905.269] (II) intel(0): 	150e0103082018c6ea5c119e59479b27
[   905.269] (II) intel(0): 	10484fa14a0031594559456861598180
[   905.269] (II) intel(0): 	010101010101ea240060410028303060
[   905.269] (II) intel(0): 	130040f01000001e000000fc00655669
[   905.269] (II) intel(0): 	657720313766330a2020000000fd0032
[   905.269] (II) intel(0): 	a01e460b000a202020202020000000ff
[   905.269] (II) intel(0): 	004d5247343535303032343033330004
[   905.269] (II) intel(0): EDID vendor "EMA", prod id 777
[   905.270] (II) intel(0): Using hsync ranges from config file
[   905.270] (II) intel(0): Using vrefresh ranges from config file
[   905.270] (II) intel(0): Printing DDC gathered Modelines:
[   905.270] (II) intel(0): Modeline "1024x768"x0.0   94.50  1024 1072 1168 1376  768 769 772 808 +hsync +vsync (68.7 kHz)
[   905.270] (II) intel(0): Modeline "800x600"x0.0   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz)
[   905.270] (II) intel(0): Modeline "640x480"x0.0   25.18  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz)
[   905.270] (II) intel(0): Modeline "720x400"x0.0   28.32  720 738 846 900  400 412 414 449 -hsync +vsync (31.5 kHz)
[   905.270] (II) intel(0): Modeline "1024x768"x0.0   78.75  1024 1040 1136 1312  768 769 772 800 +hsync +vsync (60.0 kHz)
[   905.270] (II) intel(0): Modeline "1024x768"x0.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz)
[   905.270] (II) intel(0): Modeline "800x600"x0.0   49.50  800 816 896 1056  600 601 604 625 +hsync +vsync (46.9 kHz)
[   905.270] (II) intel(0): Modeline "640x480"x0.0   36.00  640 696 752 832  480 481 484 509 -hsync -vsync (43.3 kHz)
[   905.270] (II) intel(0): Modeline "800x600"x0.0   56.25  800 832 896 1048  600 601 604 631 +hsync +vsync (53.7 kHz)
[   905.270] (II) intel(0): Modeline "800x600"x100.0   68.18  800 848 936 1072  600 601 604 636 -hsync +vsync (63.6 kHz)
[   905.270] (II) intel(0): Modeline "1280x1024"x0.0  108.00  1280 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz)
[   905.270] (II) intel(0): Printing probed modes for output VGA1
[   905.270] (II) intel(0): Modeline "1024x768"x85.0   94.50  1024 1072 1168 1376  768 769 772 808 +hsync +vsync (68.7 kHz)
[   905.270] (II) intel(0): Modeline "1280x1024"x60.0  108.00  1280 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz)
[   905.270] (II) intel(0): Modeline "1024x768"x75.1   78.80  1024 1040 1136 1312  768 769 772 800 +hsync +vsync (60.1 kHz)
[   905.270] (II) intel(0): Modeline "1024x768"x60.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz)
[   905.270] (II) intel(0): Modeline "800x600"x100.0   68.17  800 848 936 1072  600 601 604 636 -hsync +vsync (63.6 kHz)
[   905.270] (II) intel(0): Modeline "800x600"x85.1   56.25  800 832 896 1048  600 601 604 631 +hsync +vsync (53.7 kHz)
[   905.270] (II) intel(0): Modeline "800x600"x75.0   49.50  800 816 896 1056  600 601 604 625 +hsync +vsync (46.9 kHz)
[   905.270] (II) intel(0): Modeline "800x600"x60.3   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz)
[   905.270] (II) intel(0): Modeline "640x480"x85.0   36.00  640 696 752 832  480 481 484 509 -hsync -vsync (43.3 kHz)
[   905.270] (II) intel(0): Modeline "640x480"x60.0   25.20  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz)
[   905.271] (II) intel(0): Modeline "720x400"x70.1   28.32  720 738 846 900  400 412 414 449 -hsync +vsync (31.5 kHz)
[oppie@fedora ~]$ 

Any other info you might want...?
Comment 33 Robert Hinson 2010-12-22 21:19:20 UTC 
This is more info with last post.
eMachines W4685 with a VG33 motherboard.

 SPECIFICATIONS
 Processor 	 Intel Northwood Up to 2.26GHz to 3.06 GHz and above / Celeron up to 2.8G / Hyper-Threading support / Intel 400/533 MHz FSB
 Chipset 	 Intel 845GE / Intel® ICH4
 Memory 	 2 DIMM slot / DDR 266 / 333 SDRAM support / Non ECC support / Max. 2 GB total
 Audio 	 AC' 97 codec 5.1 Channel / Realtek ALC650
 Onboard Lan 	 Realtek 8100BL
 Expand Slots 	 3 PCI / 1 x AGP 4x slot
 Onboard IO 	 2 x PS2 Connectors / 1 x Audio connector: MIC-In, Line-In, Line-Out / 2 x COM port / 1 x VGA port / 1 x (1 x RJ45 + 2 x USB 2.0) / 1 x (2 x USB 2.0) / 1 x Parallel Port
 Onboard IDE 	 2 Dual - ChanneledEnhanced PCI Bus Master IDE Connectors Support Ultra DMA ATA 66/100
 System Bios 	 ACPI, APM, DMI, SMBIOS, PnP, USB, PC99, PC2001, Y2K Compliant
 Form Factor 	 uATX - 9.6" x 8.6"
 VGA 	 Integrated graphic
 IEEE 1394 	 3ports (1394_4PIN/1394_6PIN*2)
Comment 34 Zdenek Kabelac 2011-03-29 09:55:52 UTC 
Just an update - I think now with some 2.6.39 early kernel builds - I'm getting my plasma resume effect almost all the time - and the trick with:

 options drm_kms_helper poll=0

no longer helps either.

I'll try to create some upstream bugzilla with video attachment.
Comment 35 Zdenek Kabelac 2012-10-12 11:54:42 UTC 
Since I'm user of SNA acceleration (instead of UXA) - I no longer observe such problems.

Section "Device"
...
Option      "AccelMethod" "SNA"
...
EndSection
Comment 36 Fedora End Of Life 2013-04-03 18:25:26 UTC 
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 37 Fedora End Of Life 2015-01-09 16:16:55 UTC 
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 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, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

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.
Comment 38 Fedora End Of Life 2015-02-17 13:18:13 UTC 
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.