From: Andy Lutomirski <luto@mit.edu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org,
DRI mailing list <dri-devel@lists.freedesktop.org>,
intel-gfx@lists.freedesktop.org
Subject: Re: Intel graphics CPU usage - SDVO detect bogosity?
Date: Mon, 16 Aug 2010 10:27:11 -0400 [thread overview]
Message-ID: <4C694ABF.6020505@mit.edu> (raw)
In-Reply-To: <AANLkTinfYBC0=DOzWaGD0DrGH8+M_rFRtuzHrM4yjRxx@mail.gmail.com>
[cc: intel-gfx]
Linus Torvalds wrote:
> On Sun, Aug 15, 2010 at 9:06 PM, Andy Lutomirski <luto@myrealbox.com> wrote:
>> You might be hitting the infamous hotplug storm [1]. The symptoms vary by
>> kernel version.
>
> Hmm. I don't think it's a storm. The drm.debug=4 thing shows things
> just every 10 seconds. That seems pretty controlled.
OK, probably not the hotplug storm. That's always been at least once per
second and sometimes several for me.
>
> Of course, it seems to be several milliseconds worth of work then, so
> it's not _too_ controlled. I must be missing some detail.
>
>> If I'm right, the outputs of intel_bios_dumper and intel_bios_reader could
>> be instructive (both are in intel-gpu-tools).
>
> My version of intel-gpu-tools must be old (fedora 12). It has
> intel_gpu_dump and intel_reg_write and some other apps, but not the
> bios-dumper/reader.
>
> Not that I could read the output of them anyway, I bet ;)
>
>> You could also try intel_reg_write 0x61110 0x0 and see if the problem stops
>> (at least until a suspend/resume cycle). That command turns off output
>> hotplug on the card, which has the side effect that the kernel will stop
>> acting on bogus interrupts.
>
> # intel_reg_write 0x61110 0x0
> Value before: 0x4000220
> Value after: 0x0
>
> but it doesn't seem to change any behavior. Still that sdvo probe
> every 10 s, and still 1% of CPU for kworker in top. But that kworker
> thing definitely has to be separate from the 10-second sdvo probe,
> because it shows up all the time (ie top updates every second).
Almost certainly not the hotplug storm bug.
The 10 seconds is probably the timer in output_poll_execute (drm_crtc_helper.c):
#define DRM_OUTPUT_POLL_PERIOD (10*HZ)
The code in output_poll_execute (which is in your perf output) looks wrong:
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
/* if this is HPD or polled don't check it -
TV out for instance */
if (!connector->polled)
continue;
else if (connector->polled & (DRM_CONNECTOR_POLL_CONNECT | DRM_CONNECTOR_POLL_DISCONNECT))
repoll = true;
[ so if we have DRM_CONNECTOR_POLL_CONNECT set we requeue the *entire*
work item. or if we have DRM_CONNECTOR_POLL_DISCONNECT and it's not
even connected, we still poll. ]
old_status = connector->status;
/* if we are connected and don't want to poll for disconnect
skip it */
if (old_status == connector_status_connected &&
!(connector->polled & DRM_CONNECTOR_POLL_DISCONNECT) &&
!(connector->polled & DRM_CONNECTOR_POLL_HPD))
continue;
[ but if the status isn't connector_status_connected, we poll it even if we're
only in here due to a *different* connector ]
status = connector->funcs->detect(connector);
[ ->detect is the expensive part ]
if (old_status != status)
changed = true;
}
But that's really the problem, because intel_sdvo_dvi_init contains:
connector->polled = DRM_CONNECTOR_POLL_CONNECT | DRM_CONNECTOR_POLL_DISCONNECT;
I don't know if SDVO is supposed to send hotplug interrupts because that section of the docs is incomplete.
--Andy
next prev parent reply other threads:[~2010-08-16 14:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-16 2:32 Intel graphics CPU usage - SDVO detect bogosity? Linus Torvalds
2010-08-16 2:51 ` Markus Trippelsdorf
2010-08-16 2:51 ` Markus Trippelsdorf
2010-08-16 3:30 ` Dave Airlie
2010-08-16 3:30 ` Dave Airlie
2010-08-16 4:01 ` Linus Torvalds
2010-08-16 4:29 ` Dave Airlie
2010-08-16 4:06 ` Andy Lutomirski
2010-08-16 4:27 ` Linus Torvalds
2010-08-16 4:27 ` Linus Torvalds
2010-08-16 14:27 ` Andy Lutomirski [this message]
2010-08-16 15:13 ` [Intel-gfx] " Adam Jackson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C694ABF.6020505@mit.edu \
--to=luto@mit.edu \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.