Bug 69808

Summary: [Baytrail-M Regression Bisected] testdisplay cause "Call Trace"
Product: DRI Reporter: shui yangwei <yangweix.shui>
Component: DRM/IntelAssignee: Jesse Barnes <jbarnes>
Status: CLOSED DUPLICATE QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: major    
Priority: medium CC: intel-gfx-bugs
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
dmesg: testdisplay cause call trace none

Description shui yangwei 2013-09-25 12:41:35 UTC
Created attachment 86557 [details]
dmesg: testdisplay cause call trace

Description:
-------------------------
After running testdisplay cases(include -a,-d,-p,-t,-f), there's call trace come up in console. No matter we use which kind pipe(VGA or eDP), each of them exists. It's a regression and been bisected.

Bisect result:
-------------------------
f1f644dc66cbaf5a4c7dcde683361536b41885b9 is the first bad commit
commit f1f644dc66cbaf5a4c7dcde683361536b41885b9
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Thu Jun 27 00:39:25 2013 +0300

    drm/i915: get mode clock when reading the pipe config v9

    We need this for comparing modes between configuration changes.

    The tricky part is to allow us to reuse the new get_clock stuff to
    recover the lvds clock on gen2/3 when neither the vbt has an lvds mode
    nor the panel a (useful) EDID.

    v2: try harder to calulate non-simple pixel clocks (Daniel)
        call get_clock after getting the encoder config, needed for pixel multiply
        (Jesse)
    v3: drop get_clock now that the pixel_multiply has been moved into
        get_pipe_config
    v4: re-add get_clock; we need to get the pixel multiplier in the
        encoder, so need to calculate the clock value after the encoder's
        get_config is called
    v5: drop hsw clock_get, still needs to be written



Reproduce Steps:
------------------------
1. boot up machine
2. run testdisplay
3. checkout dmesg
Comment 1 Daniel Vetter 2013-09-25 15:54:30 UTC
Please consult the bug filing BKM section about how to properly file "call trace in dmesg" - we already have this one here ...

*** This bug has been marked as a duplicate of bug 69248 ***
Comment 2 shui yangwei 2013-09-26 02:46:31 UTC
(In reply to comment #1)
> Please consult the bug filing BKM section about how to properly file "call
> trace in dmesg" - we already have this one here ...
> 
> *** This bug has been marked as a duplicate of bug 69248 ***

OK, Call trace disappeared on latest -next-queued kernel after testing display. Verified here.
Comment 3 Elizabeth 2017-10-06 14:42:52 UTC
Closing old verified.

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.