Disabling polling in drm_helper

Disabling polling in drm_helper

[Mike Verstegen]

I'm troubleshooting an interesting problem where the i915_hotplug_work_func is eating up a lot of time in a couple of kworker threads. The interesting part of the problem is that this only happens with one particular model of monitor which I haven't gotten to the bottom of yet. But that's not the problem I'm trying  to resolve. 

One band-aid for this trouble is to disable the polling in the irq_event
# echo "N" > /sys/module/drm_kms_helper/parameters/poll

That quiets down the kworker threads. Good

To make this survive across boots, I added the following to /etc/modprobe/local.conf
options drm_kms_helper poll=N

On reboot, the poll is still enabled
[root@localhost ~]# cat /sys/module/drm_kms_helper/parameters/poll
Y

Looking at the drm_crtc_helper.c I see
void drm_kms_helper_poll_init(struct drm_device *dev)
{
        INIT_DELAYED_WORK(&dev->mode_config.output_poll_work, output_poll_execute);
        dev->mode_config.poll_enabled = true;

        drm_kms_helper_poll_enable(dev);
}

If I'm reading that correctly, poll_enable is set to true on initialization unconditionally.

Questions:
- Am I using "options drm_kms_helper poll=N" correctly
- Is there a better way to have this option set to false on initialization?

Thanks

Mike

Re: Disabling polling in drm_helper

[Daniel Vetter]

On Tue, Apr 23, 2013 at 01:16:16AM +0000, Mike Verstegen wrote:
> I'm troubleshooting an interesting problem where the
> i915_hotplug_work_func is eating up a lot of time in a couple of kworker
> threads. The interesting part of the problem is that this only happens
> with one particular model of monitor which I haven't gotten to the
> bottom of yet. But that's not the problem I'm trying  to resolve. 

This should be fixed in latest drm-next. Can you please test that?

> One band-aid for this trouble is to disable the polling in the irq_event
> # echo "N" > /sys/module/drm_kms_helper/parameters/poll
> 
> That quiets down the kworker threads. Good
> 
> To make this survive across boots, I added the following to /etc/modprobe/local.conf
> options drm_kms_helper poll=N
> 
> On reboot, the poll is still enabled
> [root@localhost ~]# cat /sys/module/drm_kms_helper/parameters/poll
> Y
> 
> Looking at the drm_crtc_helper.c I see
> void drm_kms_helper_poll_init(struct drm_device *dev)
> {
>         INIT_DELAYED_WORK(&dev->mode_config.output_poll_work, output_poll_execute);
>         dev->mode_config.poll_enabled = true;
> 
>         drm_kms_helper_poll_enable(dev);
> }
> 
> If I'm reading that correctly, poll_enable is set to true on initialization unconditionally.
> 
> Questions:
> - Am I using "options drm_kms_helper poll=N" correctly
> - Is there a better way to have this option set to false on initialization?

You probably need to rebuild your initrd with your distro tools since
drm_kms_helper is loaded really early.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

RE: Disabling polling in drm_helper

[Mike Verstegen]

> -----Original Message-----
> From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel Vetter
> On Tue, Apr 23, 2013 at 01:16:16AM +0000, Mike Verstegen wrote:
> > I'm troubleshooting an interesting problem where the
> > i915_hotplug_work_func is eating up a lot of time in a couple of
> > kworker threads. The interesting part of the problem is that this only
> > happens with one particular model of monitor which I haven't gotten to
> > the bottom of yet. But that's not the problem I'm trying  to resolve.
> 
> This should be fixed in latest drm-next. Can you please test that?
> 
I'd be glad to test, but that may be a bit over my skill level.  How could I help with testing drm-next?
In my original message, I forgot to include that this is a Centos 6.4 system with a 3.5.3 kernel.

> > One band-aid for this trouble is to disable the polling in the
> > irq_event # echo "N" > /sys/module/drm_kms_helper/parameters/poll
> >
> > That quiets down the kworker threads. Good
> >
> > To make this survive across boots, I added the following to
> > /etc/modprobe/local.conf options drm_kms_helper poll=N
> >
> > On reboot, the poll is still enabled
> > [root@localhost ~]# cat /sys/module/drm_kms_helper/parameters/poll
> > Y
> > Questions:
> > - Am I using "options drm_kms_helper poll=N" correctly
> > - Is there a better way to have this option set to false on initialization?
> 
> You probably need to rebuild your initrd with your distro tools since
> drm_kms_helper is loaded really early.

Great suggestion and a good learning point for me. I rebuilt the initramfs and the option is now recognized at boot.

Thanks

Mike

Re: Disabling polling in drm_helper

[Daniel Vetter]

On Tue, Apr 23, 2013 at 8:47 PM, Mike Verstegen
<mikev@athletesperformance.com> wrote:
>> -----Original Message-----
>> From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel Vetter
>> On Tue, Apr 23, 2013 at 01:16:16AM +0000, Mike Verstegen wrote:
>> > I'm troubleshooting an interesting problem where the
>> > i915_hotplug_work_func is eating up a lot of time in a couple of
>> > kworker threads. The interesting part of the problem is that this only
>> > happens with one particular model of monitor which I haven't gotten to
>> > the bottom of yet. But that's not the problem I'm trying  to resolve.
>>
>> This should be fixed in latest drm-next. Can you please test that?
>>
> I'd be glad to test, but that may be a bit over my skill level.  How could I help with testing drm-next?
> In my original message, I forgot to include that this is a Centos 6.4 system with a 3.5.3 kernel.

Google a good howto for installing a kernel from source for your
distro (I suggest using something which creates a real rpm for easy
un-installing). Then check out the below howto for git:

http://blog.ffwll.ch/2012/05/git-for-bug-reporters.html

And use that to download&install the drm-next branch from
git://people.freedesktop.org/~airlied/linux

Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch