<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body>
<p>
<div>
<b><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#c14">Comment # 14</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 <span class="vcard"><a class="email" href="mailto:pmenzel+bugs.freedesktop@molgen.mpg.de" title="Paul Menzel <pmenzel+bugs.freedesktop@molgen.mpg.de>"> <span class="fn">Paul Menzel</span></a>
</span></b>
<pre>(In reply to David Weinehall from <a href="show_bug.cgi?id=105622#c13">comment #13</a>)
<span class="quote">> 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.</span >
No idea, see below, though the system is up for some time already.
```
$ more /proc/interrupts
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5
CPU6 CPU7
0: 8 0 0 0 0 0
0 0 IR-IO-APIC 2-edge timer
1: 1203 0 0 0 43769 0
0 0 IR-IO-APIC 1-edge i8042
8: 0 0 0 0 0 1
0 0 IR-IO-APIC 8-edge rtc0
9: 116840 351381 0 0 0 0
0 0 IR-IO-APIC 9-fasteoi acpi
12: 13 0 0 211 0 0
0 0 IR-IO-APIC 12-edge i8042
14: 0 0 0 0 0 0
0 0 IR-IO-APIC 14-fasteoi INT344B:00
16: 66 0 0 0 0 0
1043 0 IR-IO-APIC 16-fasteoi i801_smbus, idma64.0,
i2c_designware.0
17: 1520683 0 12455901 0 0 0
0 0 IR-IO-APIC 17-fasteoi idma64.1, i2c_designware.1
39: 1 0 0 0 0 0
1140 0 IR-IO-APIC 39-fasteoi ELAN24EE:00
51: 23536 0 0 0 0 0
0 194638 IR-IO-APIC 51-fasteoi DELL07E6:00
120: 0 0 0 0 0 0
0 0 DMAR-MSI 0-edge dmar0
121: 0 0 0 0 0 0
0 0 DMAR-MSI 1-edge dmar1
122: 0 47 0 0 0 0
0 0 IR-PCI-MSI 360448-edge mei_me
123: 135 0 0 0 0 0
0 156 IR-PCI-MSI 327680-edge xhci_hcd
124: 9079 0 0 0 0 0
0 0 IR-PCI-MSI 57671680-edge nvme0q0, nvme0q1
125: 0 0 1074 0 0 0
0 0 IR-PCI-MSI 514048-edge snd_hda_intel:card0
126: 0 5656 0 0 0 0
0 0 IR-PCI-MSI 57671681-edge nvme0q2
127: 0 0 4660 0 0 0
0 0 IR-PCI-MSI 57671682-edge nvme0q3
128: 0 0 0 4991 0 0
0 0 IR-PCI-MSI 57671683-edge nvme0q4
129: 0 0 0 0 9248 0
0 0 IR-PCI-MSI 57671684-edge nvme0q5
130: 0 0 0 0 0 13829
0 0 IR-PCI-MSI 57671685-edge nvme0q6
131: 0 0 0 0 0 0
7052 0 IR-PCI-MSI 57671686-edge nvme0q7
132: 6272 2526 7172 3321 242857 250175
2310 25887 IR-PCI-MSI 32768-edge i915
133: 1658 2185 107 5064 4251 12859
9957 26498 IR-PCI-MSI 1048576-edge ath10k_pci
134: 0 0 0 0 0 0
0 9115 IR-PCI-MSI 57671687-edge nvme0q8
135: 0 0 0 38838 0 0
0 0 IR-PCI-MSI 2621440-edge thunderbolt
136: 0 0 0 0 38838 0
0 0 IR-PCI-MSI 2621441-edge thunderbolt
151: 0 6085 32871 0 1250 0
0 81341 IR-PCI-MSI 33030144-edge xhci_hcd
152: 0 0 0 0 0 0
0 0 IR-PCI-MSI 33030145-edge xhci_hcd
153: 0 0 0 0 0 0
0 0 IR-PCI-MSI 33030146-edge xhci_hcd
154: 0 0 0 0 0 0
0 0 IR-PCI-MSI 33030147-edge xhci_hcd
155: 0 0 0 0 0 0
0 0 IR-PCI-MSI 33030148-edge xhci_hcd
156: 0 0 0 0 0 0
0 0 IR-PCI-MSI 33030149-edge xhci_hcd
157: 0 0 0 0 0 0
0 0 IR-PCI-MSI 33030150-edge xhci_hcd
158: 0 0 0 0 0 0
0 0 IR-PCI-MSI 33030151-edge xhci_hcd
NMI: 47 219 231 222 216 230
221 218 Non-maskable interrupts
LOC: 804697 758024 826859 807491 982973 903341
808320 833069 Local timer interrupts
SPU: 0 0 0 0 0 0
0 0 Spurious interrupts
PMI: 47 219 231 222 216 230
221 218 Performance monitoring interrupts
IWI: 1161 544 1234 474 40990 24068
364 4518 IRQ work interrupts
RTR: 0 0 0 0 0 0
0 0 APIC ICR read retries
RES: 238447 120892 112676 67312 102441 90607
65695 71477 Rescheduling interrupts
CAL: 137795 144599 122801 128888 119471 214609
161160 126993 Function call interrupts
TLB: 111602 118338 95668 103951 93386 187914
135550 99271 TLB shootdowns
TRM: 20 20 20 20 20 20
20 20 Thermal event interrupts
THR: 0 0 0 0 0 0
0 0 Threshold APIC interrupts
DFR: 0 0 0 0 0 0
0 0 Deferred Error APIC interrupts
MCE: 0 0 0 0 0 0
0 0 Machine check exceptions
MCP: 37 37 37 37 37 37
37 37 Machine check polls
HYP: 0 0 0 0 0 0
0 0 Hypervisor callback interrupts
HRE: 0 0 0 0 0 0
0 0 Hyper-V reenlightenment interrupts
ERR: 2
MIS: 0
PIN: 0 0 0 0 0 0
0 0 Posted-interrupt notification event
NPI: 0 0 0 0 0 0
0 0 Nested posted-interrupt event
PIW: 0 0 0 0 0 0
0 0 Posted-interrupt wakeup event
```
<span class="quote">> 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</span >
When doing these experiments, nothing was connected to the laptop. And it only
has USB-C connectors.
<span class="quote">> 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.</span >
Where are the 35 ms spent on your system? What do you set maxdepth to?</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<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>