| Summary: | [BYT] WARNING: CPU: 1 PID: 16615 at drivers/gpu/drm/drm_debugfs_crc.c:185 crtc_crc_open+0x1d0/0x1f0 [drm] | ||
|---|---|---|---|
| Product: | DRI | Reporter: | Chris Wilson <chris> |
| Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
| Status: | CLOSED WORKSFORME | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
| Severity: | critical | ||
| Priority: | high | CC: | intel-gfx-bugs |
| Version: | XOrg git | Keywords: | bisected, regression |
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | PatchSubmitted | ||
| i915 platform: | BYT | i915 features: | display/Other |
|
Description
Chris Wilson
2017-04-07 11:02:06 UTC
Just beautiful it asks to be interrupted and then complains when it is:
crtc_crc_open():
/*
* Only return once we got a first frame, so userspace doesn't have to
* guess when this particular piece of HW will be ready to start
* generating CRCs.
*/
ret = wait_event_interruptible_lock_irq(crc->wq,
crtc_crc_data_count(crc),
crc->lock);
spin_unlock_irq(&crc->lock);
WARN_ON(ret);
Introduced by commit e8fa5671183c80342d520ad81d14fa79a9d4a680 Author: Tomeu Vizoso <tomeu.vizoso@collabora.com> Date: Mon Jan 2 13:59:10 2017 +0100 drm: crc: Wait for a frame before returning from open() Don't return from the open() call on the crc/data file until the HW has produced a first frame, as there's great variability in when the HW is able to do that and userspace shouldn't have to guess when this specific HW is ready to start giving frame CRCs. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170102125912.22305-3-tomeu.vizoso@collabora.com Hello Chris, Has this issue got any update? Thank you. Hi Tomeu, any word on this? Note that bug can be reproduced with igt@debugfs_test@read_all_entries Actually we have https://patchwork.freedesktop.org/patch/165548/ potential fix from Maarten. Currently testing this. Tested patch from Maarten. Improvement is cosmetic; at least the kernel crash disappeared (removal of WARN_ON). However opening the crc data file descriptor still takes forever. First of all. Sorry about spam. This is mass update for our bugs. Sorry if you feel this annoying but with this trying to understand if bug still valid or not. If bug investigation still in progress, please ignore this and I apologize! If you think this is not anymore valid, please comment to the bug that can be closed. If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug. Chris, Abdiel, is this still valid? I think we can close this. I can't reproduce the problem in drm-tip at least. |
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.