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



Hi!

On Sun, 2005-01-16 at 20:42 +0200, Ville Syrjälä wrote:
> On Sun, Jan 16, 2005 at 03:59:03PM +0100, Jan Gukelberger wrote:
[...]
> > > Secondly make sure the graphics card actually has an irq assigned to it. 
> > > BIOS usually has an option for it. lspci should tell you if the irq is 
> > > assigned.

Yes, it has:
0000:01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G550 AGP (rev 01) (prog-if 00 [VGA])
        Subsystem: Matrox Graphics, Inc. Millennium G550 Dual Head DDR 32Mb
        Flags: bus master, medium devsel, latency 128, IRQ 16


> You could try pci=noacpi or acpi=off kernel options.

This didn't seem to help.

However, there are some new observations and even a fix/workaround:

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?

Anyway, we have the setup working now, so this is quite a progress. Even
if it smells more like a workaround than a solution.

Thanks,
Jan





Home | Main Index | Thread Index


directfb.org / Development / Old Archives