Rob escribió:

Hi,

My OS is an up-to-date version of Fedora 7 on a Intel based PC.

I use a particular academic/scientific video rendering software VMD ( http://www.ks.uiuc.edu/Research/vmd/ ). This software uses GLX/Mesa heavily.

My day-to-day window manager is XFCE. When I use VMD, it immediately freezes keyboard/mouse on my console as soon as any video rendering activity occurs. The typical error message in /var/log/messages is:

kernel: [drm:i915_wait_irq] *ERROR* i915_wait_irq: EBUSY --
           rec: 147447 emitted: 147473

However, when I switch to KDE window manager, all this does not occur.

Obviously I first blamed XFCE, but the developers there are convinced that the Xorg and/or related X11-video drivers are to be blamed.

Eventually I solved the problem: I disabled XFree86-DRI in the file /etc/X11/xorg.conf.

Is there anybody who knows about this matter and can help me understand what's going on? I'd like to report this problem somewhere, but who is to be blamed? XFCE ? (they deny) Xorg ? Fedora ? XFree86-DRI ?

Thanks, Rob.

The kernel error message printed to /var/log/messages and the fact that it does show on XFCE only (and not KDE or presumably other window manager), indeed suggests that the driver is to blame. It's been a while since Xorg substituted XFree86 in Linux distributions, however the DRI method for rendering 3D graphics was kept from it. At any rate, the breakdown of the problem seems to be that XFWM4 the actual "window manager" in XFCE, does include a compositor engine. Do you have it enabled? Do you have the Composite extension enabled in /etc/X11/xorg.conf? Do you have AIGLX enabled in xorg.conf? Do you run another compositing manager in XFCE (say, Compiz or Beryl)? I'd be inclined to think that it is indeed the driver which is at fault, this hints it out:

kernel: [drm:i915_wait_irq] *ERROR* i915_wait_irq: EBUSY -- rec: 147447 emitted: 147473

DRM is kernel-side component for DRI to work. DRI stands for Direct Rendering Infrastructure, and DRM (unlike Digital Restrictions Management) stands for Direct Rendering Manager. Are you running 32 or 64-bits? I know it is a shot in the dark, but maybe there is a problem with the IRQ table, maybe adding 'noapic' as a kernel command line argument at boot might solve this? Or maybe checking the IRQ table in the BIOS might also help? Is this a dual core/HT CPU? Are you running the IRQ balance system service? (check with system-config-services)

Sorry to have many more questions than answers for you, but the information you provide is scarce... Bottom line, I'd be inclined to think about an IRQ table/balance problem or a driver problem, rather than anything else.