Re: Intel graphics CPU usage - SDVO detect bogosity?

[Linus Torvalds]

On Sun, Aug 15, 2010 at 8:30 PM, Dave Airlie <airlied@xxxxxxxxxx> wrote:
>
> At least we should replace mdelay with msleep in those functions.

How precise does the timing have to be? I think i2c is self-clocking,
so it's ok to see big skews? Becuase msleep() can be off by quite a
bit (mdelay can too, but it's _way_ more rare, and requires either a
preemptible kernel or serious interrupt activity).

> Can you get a boot with drm.debug=4?

Sure. That results in a truncated dmesg (with a 128k buffer). The
thing seems to spew out something every ten seconds:

  ...
  [  232.610044] [drm:intel_sdvo_debug_write], SDVOB: W: 0B
             (SDVO_CMD_GET_ATTACHED_DISPLAYS)
  [  232.624504] [drm:intel_sdvo_debug_response], SDVOB: R: 01 00
             (Success)
  [  232.624517] [drm:intel_sdvo_detect], SDVO response 1 0
  [  232.624524] [drm:intel_sdvo_debug_write], SDVOB: W: 7A 01
             (SDVO_CMD_SET_CONTROL_BUS_SWITCH)
  [  242.672044] [drm:intel_sdvo_debug_write], SDVOB: W: 0B
             (SDVO_CMD_GET_ATTACHED_DISPLAYS)
  [  242.686503] [drm:intel_sdvo_debug_response], SDVOB: R: 01 00
             (Success)
  [  242.686516] [drm:intel_sdvo_detect], SDVO response 1 0
  [  242.686523] [drm:intel_sdvo_debug_write], SDVOB: W: 7A 01
             (SDVO_CMD_SET_CONTROL_BUS_SWITCH)
  [  252.750044] [drm:intel_sdvo_debug_write], SDVOB: W: 0B
             (SDVO_CMD_GET_ATTACHED_DISPLAYS)
  [  252.764526] [drm:intel_sdvo_debug_response], SDVOB: R: 01 00
             (Success)
  [  252.764539] [drm:intel_sdvo_detect], SDVO response 1 0
  ...

It looks like it takes about 15 ms each time.  But 15 ms each 10s
doesn't seem to be enough to account for the load average. Maybe it
gets synchronized with the timer tick or something, causing the load
average to look artificially inflated (it also doesn't match up with
kworker using 1%+ CPU time).

So maybe there is something else going on. Maybe the load average
thing comes from some interaction with the new workqueue thing.

I'll send the whole dmesg to you in a private message, I don't think
we want 128kB of crud on lkml.

> I wonder are we picking up a bad SDVO, the insane code retries 50 times
> with a hard loop delay.

Well, I'm not seeing any failures, but maybe those don't get printed out?

                        Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/