<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - i915_init takes over 100 ms" href="https://bugs.freedesktop.org/show_bug.cgi?id=105622#c13">Comment # 13</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - i915_init takes over 100 ms" href="https://bugs.freedesktop.org/show_bug.cgi?id=105622">bug 105622</a> from <a class="email" href="mailto:david.weinehall@intel.com" title="David Weinehall <david.weinehall@intel.com>"> David Weinehall</a> <pre>Can you check whether /proc/interrupts indicate some surprisingly high interrupt count? I've experienced some cases of very slow suspend times that turned out to be because of interrupt storms; due to the nature of interrupts is that they interrupt the normal program flow they got accounted to different modules at different times, and thus sometimes showed up as slowing down our driver, sometimes other drivers. It *might* be something similar, though it seems less likely. As far as HDMI-probing goes, a few things that could slow down the probing: * Bad cable * Display connected via KVM * HDMI-port routed through an LSPCON * BIOS bugs If the time is spent in snd_hda_codec_hdmi(), then the issue might be in the hda driver rather than the i915 driver. But you mention that the overhead seems to move around. To me that sounds like some externally imposed delay. Do any of these components need to wait for the random number generator to refill, for instance? One suspicion I had was that it's something generic to HW probing, but if things sometimes slow down in fuse that couldn't be the case, since fuse shouldn't rely on hardware probing. Hmmm. Tricky.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>