| Summary: | [GTK] WebProcess from WebKitGtk+ 2.13.91 hangs my Intel GPU | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Andres Gomez Garcia <agomez> | ||||
| Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> | ||||
| Status: | RESOLVED CONFIGURATION CHANGED | ||||||
| Severity: | Normal | CC: | bugs-noreply, cgarcia, magomez | ||||
| Priority: | P2 | ||||||
| Version: | WebKit Nightly Build | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| See Also: | https://bugs.freedesktop.org/show_bug.cgi?id=97785 | ||||||
| Attachments: |
|
||||||
|
Description
Andres Gomez Garcia
2016-09-12 08:16:09 PDT
Created attachment 288571 [details]
GPU dump error at /sys/class/drm/card0/error
Have you tried filing a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel? GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. (In reply to comment #2) > Have you tried filing a _new_ bug report on bugs.freedesktop.org against DRI > -> DRM/Intel? GPU hangs can indicate a bug anywhere in the entire gfx stack, > including userspace. I can do that, of course but, since this is happening only from 2.12.5 to 2.13.91, there seems that WKGTK is also doing something differently ... (In reply to comment #3) > (In reply to comment #2) > > Have you tried filing a _new_ bug report on bugs.freedesktop.org against DRI > > -> DRM/Intel? GPU hangs can indicate a bug anywhere in the entire gfx stack, > > including userspace. > > I can do that, of course but, since this is happening only from 2.12.5 to > 2.13.91, there seems that WKGTK is also doing something differently ... Yes, but we are doing too many things differently from 2.12 to 2.14. We have switched to use the threaded compositor which also implies we use now coordinated graphics, so too many things are different. On top of that there are 6 months of WebKit development :-) (In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > Have you tried filing a _new_ bug report on bugs.freedesktop.org against DRI > > > -> DRM/Intel? GPU hangs can indicate a bug anywhere in the entire gfx stack, > > > including userspace. > > > > I can do that, of course but, since this is happening only from 2.12.5 to > > 2.13.91, there seems that WKGTK is also doing something differently ... > > Yes, but we are doing too many things differently from 2.12 to 2.14. We have > switched to use the threaded compositor which also implies we use now > coordinated graphics, so too many things are different. On top of that there > are 6 months of WebKit development :-) Maybe I explained myself wrong. This is not just happening from 2.12 to 2.14, it is happening from a former 2.13.x to the latest 2.13.x I will look for the version in which this started happening but I think it was from 2.13.4 to 2.13.90 ... I'll keep you posted :) (In reply to comment #5) > I will look for the version in which this started happening but I think it > was from 2.13.4 to 2.13.90 ... Yes, I think this was the case. In bug 160389 I commented that, using the patch proposed, my whole desktop was getting frozen. I didn't research much further but I suspect that the GPU hang was introduced by that patch. Then, the patch was committed and I moved back to the 2.12.x series in my daily use because 2.13.x was not usable in my box any more ... (In reply to comment #6) > (In reply to comment #5) > > > I will look for the version in which this started happening but I think it > > was from 2.13.4 to 2.13.90 ... > > Yes, I think this was the case. > > In bug 160389 I commented that, using the patch proposed, my whole desktop > was getting frozen. I didn't research much further but I suspect that the > GPU hang was introduced by that patch. > > Then, the patch was committed and I moved back to the 2.12.x series in my > daily use because 2.13.x was not usable in my box any more ... FTR, I'm now testing 2.13.4 from Debian experimental and I've already gotten this: $ cat /var/log/kern.log [snip] Sep 13 13:58:15 pomeron kernel: [11660.199863] [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun Sep 13 13:58:15 pomeron kernel: [11660.200645] [drm:intel_set_pch_fifo_underrun_reporting [i915]] *ERROR* uncleared pch fifo underrun on pch transcoder A Sep 13 13:58:15 pomeron kernel: [11660.200671] [drm:cpt_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun Sep 13 13:58:15 pomeron kernel: [11660.202018] [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Sep 13 13:58:16 pomeron kernel: [11660.223535] [drm:intel_set_pch_fifo_underrun_reporting [i915]] *ERROR* uncleared pch fifo underrun on pch transcoder B Sep 13 13:58:16 pomeron kernel: [11660.689752] [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Sep 13 13:58:16 pomeron kernel: [11660.722393] [drm:intel_check_pch_fifo_underruns [i915]] *ERROR* pch fifo underrun on pch transcoder B However, after this small hiccup, I could keep using the desktop/browser without problems ... (In reply to comment #7) > $ cat /var/log/kern.log > > [snip] > > Sep 13 13:58:15 pomeron kernel: [11660.199863] [drm:ironlake_irq_handler > [i915]] *ERROR* CPU pipe A FIFO underrun > Sep 13 13:58:15 pomeron kernel: [11660.200645] > [drm:intel_set_pch_fifo_underrun_reporting [i915]] *ERROR* uncleared pch > fifo underrun on pch transcoder A > Sep 13 13:58:15 pomeron kernel: [11660.200671] [drm:cpt_irq_handler [i915]] > *ERROR* PCH transcoder A FIFO underrun > Sep 13 13:58:15 pomeron kernel: [11660.202018] [drm:ironlake_irq_handler > [i915]] *ERROR* CPU pipe B FIFO underrun > Sep 13 13:58:16 pomeron kernel: [11660.223535] > [drm:intel_set_pch_fifo_underrun_reporting [i915]] *ERROR* uncleared pch > fifo underrun on pch transcoder B > Sep 13 13:58:16 pomeron kernel: [11660.689752] [drm:ironlake_irq_handler > [i915]] *ERROR* CPU pipe B FIFO underrun > Sep 13 13:58:16 pomeron kernel: [11660.722393] > [drm:intel_check_pch_fifo_underruns [i915]] *ERROR* pch fifo underrun on pch > transcoder B This doesn't seem related. It happens every time I change from the X session to a terminal ... Is this still an issue? Or can we close it? Many things changed since this was reported so I guess it's obsolete. (In reply to Miguel Gomez from comment #9) > Is this still an issue? Or can we close it? Many things changed since this > was reported so I guess it's obsolete. This is already closed in b.f.o so I suppose there is not much we can do any more. |