| Summary: | intel_powerclamp: Start idle injection to reduce power with [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe B | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Chris Murphy <bugzilla> | ||||||
| Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||
| Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||
| Severity: | normal | ||||||||
| Priority: | medium | CC: | intel-gfx-bugs | ||||||
| Version: | unspecified | ||||||||
| Hardware: | Other | ||||||||
| OS: | All | ||||||||
| Whiteboard: | Triaged | ||||||||
| i915 platform: | SKL | i915 features: | |||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 105981 | ||||||||
| Attachments: |
|
||||||||
|
Description
Chris Murphy
2018-06-02 04:36:10 UTC
Created attachment 139961 [details]
lspci vvnn
Created attachment 139962 [details]
dmesg
Could you also try with drm-tip? (In reply to bugzilla from comment #0) > This is a recent problem and > could be one of: > a. kernel 4.16, I didn't experience it with 4.15 > b. use of external display, which approximately coincides with a. Please rule out b. After that, please bisect between v4.15 and v4.16. Reporter, is this issue still? Try using https://cgit.freedesktop.org/drm-tip and send dmesg with drm.debug=0x1e log_buf_len=4M? (In reply to Jani Saarinen from comment #5) > Reporter, is this issue still? > Try using https://cgit.freedesktop.org/drm-tip and send dmesg with > drm.debug=0x1e log_buf_len=4M? And try to bisect as suggested by Jani Nikula I haven't been able to reproduce the intel_pipe_update_end error since the original report. But I am able to fairly easily reproduce the kinject slowing the whole system down to a crawl with any kernel version, with Firefox and an external display. It happens no where near as easily without external display connected. Since the original report I've only been using normal Fedora kernels (without extra debug options) and only stable versions of 4.17x. I'll retest soon with 4.18rc+debug kernels, and include the additional debug options you've recommended. ok, thanks. I would say the kinject is the real root cause here. It injects idle time because your system is overheating, and atomic updates are really time sensitive. If we throttle during atomic updates then we won't finish in time and you get the failure. Marking not our bug, because it probably isn't. :) I can reliably induce 4x kinject threads soaking up 200% CPU, just by pointing Firefox or Chrome to Comedy Central's web site (oh the irony) with an external display attached. The problem never happens if an external display is not attached. And always happens with the external display is attached. Also, the system basically becomes unusable. Video playback is jerky, audio stutters, the whole UI and even the mouse arrow becomes unresponsive. So I think there's something wrong with the video driver when it comes to external display support, that then induces the kinject to calm things down, which then causes the atomic update failure. For sure this is not happening when I reboot and use Windows 10 with the external display attached. Is it even remotely plausible the problem is induced by Wayland or Mutter (this is GNOME)? I could try to reproduce with X. And then try to reproduce with KDE. I'll reopen it for now so it doesn't get lost. The system is getting hotter, why I don't know. That hotness is the real issue, and it's likely something is using all the cpu before kinject happens. That would help you narrowing down what is going on. So is there anything using a lot of cpu before? There is no workload change built-in vs external. The only difference is the fact the rendering of video is happening on an external display and that almost immediately is unworkable (too hot, fans, kinject, stuttered video and audio). built-in is 1920x1080 external is 1920x1200 So it's not radically more pixels being rendered on the external. Reporter, can you try using latest https://cgit.freedesktop.org/drm-tip and send dmesg with drm.debug=0x1e log_buf_len=4M? Is git f91e654474d4 from Linux next close enough or is there newer stuff in drm-tip? drm-tip is always newest Reporter, were you able reproduce this issue with the latest drm-tip? I haven't seen the reported problem "Atomic update failure" with any kernel-4.18.x. And with 4.16 and 4.17 kernels, it was a transient problem that wasn't readily reproducible. So I think this can be closed. Thankyou Chris. Closing the bug as this issue doesn't occur with latest kernel. |
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.