DirectFB - Home of the pragmatist Roadmap

[directfb-users] Re: WAITFORSYNC sleeps too long
Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[directfb-users] Re: WAITFORSYNC sleeps too long

On Thu, 2005-01-20 at 21:31 +0200, Ville Syrjälä wrote:
> On Thu, Jan 20, 2005 at 07:42:08PM +0100, Jan Gukelberger wrote:
> > Running the DFB app straight after reboot from tty, everything works
> > nicely, frame length ~13.3ms. This holds even true if X is running on
> > the second graphics card.
> > But when the DFB app is started from an xterm running on the second
> > card, syslog says "kernel: Disabling IRQ #16.". Though this first run is
> > still ok, subsequent runs (from xterm as well as tty) will have a frame
> > length of 113ms, i.e. the IRQ has indeed vanished.
> > 
> > At last, we have found that the bootparam "noirqdebug" will fix this
> > problem, so the IRQ is never getting disabled.
> > 
> > All this seems absolutely weird to me, so does anybody have any clue
> > what's going on here?
> > How can it make a difference whether the app is launched from xterm or
> > tty? And what could actually cause the interrupt to be disabled?
> It looks like some other interrupt source besides vsync got enabled on the 
> card, or maybe some other device on the same interrupt went nuts and since 
> matroxfb doesn't handle the interrupts the kernel disabled it.

Well, according to lspci there is only a USB controller on the same IRQ
as the Matrox. I can't really imagine that the USB controller goes crazy
exactly at the moment when the DFB app is started while it runs without
problems for days as long the DFB app isn't started. (Admitted, I
couldn't imagine this whole problem before I heard about it. ;)

Is there a chance the mga module from your Mesa-embedded-2-branch is
involved into this? 
Btw, what does this message indicate:
"[drm:mga_dma_init] *ERROR* mga_dma_init called without lock held"

> As far as the xterm vs. tty thing is concerned, I have no idea why it 
> happens.
> You could print the status register in matrox_irq() to see if it's the 
> matrox card that is generating the unwanted interrupts.

Hmm yeah, when we see no other chance to understand this, I may in fact
ask my colleagues to do this. Quite a PITA I can't play around with this
machine directly.

Thank you very much for your assistence

Home | Main Index | Thread Index / Development / Old Archives