Daniel Vetter writes: > On Sun, Jul 21, 2013 at 10:23 PM, Jan Niggemann <jn@xxxxxx> wrote: > >> But every time this happens we only let through a few interrupts, so this > >> shouldn't affect you badly. Can you please check whether those slowdowns > >> line up with 2 minute intervalls? > > > > I observed these slowdowns for a couple of weeks now. On my machine, they > > only happen once, some minutes after a cold boot. > > They last for a minute or two, and then they are gone. > > I'd have guessed that the storm detection kicks in pretty quickly after a > > storm is detected and that it would go unnoticed. > > Hm, that sounds like something doesn't quite work as expected. We > should kill things once we get 5 interrupts or so in 1 second. So if > it's bad enough that it slows your machine down it really should only > be barely noticeable. > The logs show that the disable mechanism got triggered, so there was a storm that got detected. The respective message is generated by the worker, everything up to there (detection and marking disabled) seems to be fine. I bet we are still getting interrupts but the respective bit in hpd_event_bits doesn't get set any more. Since we unconditionally queue the worker on interrupt there is surprise it is so busy. Then this points to the call to hpd_irq_setup() in intel_hpd_irq_handler() not doing what is expected, ie masking out the stormy interrupt. Could it be that we can't mask/disable an interrupt before ACKing it? @Jan, could you also specify what hardware you are using (ie give us an output of lspci -n)? Cheers, Egbert. _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
