Bug 7208 - EBUSY on DRI ioctl when running native google earth
Summary: EBUSY on DRI ioctl when running native google earth
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: 7.0.0
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Alan Hourihane
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-06-13 07:11 UTC by Ricardo Cerqueira
Modified: 2007-10-31 13:09 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ricardo Cerqueira 2006-06-13 07:11:43 UTC
This is happening on a i945 chip; I don't use much GL here, but the little
things I do with it (like 3ddesk) have been working fine, even though I always
had these warnings whenever I run something that uses libGL:

libGL warning: 3D driver claims to not support visual 0x23
libGL warning: 3D driver claims to not support visual 0x25
libGL warning: 3D driver claims to not support visual 0x27
libGL warning: 3D driver claims to not support visual 0x29
libGL warning: 3D driver claims to not support visual 0x2b
libGL warning: 3D driver claims to not support visual 0x2d
libGL warning: 3D driver claims to not support visual 0x2f
libGL warning: 3D driver claims to not support visual 0x31

glxinfo reports Direct rendering is enabled, glxgears gives me over 700 fps, and
everything seems to be working.
However, Google Earth is _very_ slow on this computer. I tried stracing it, and
noticed it was looping on a specific ioctl:

ioctl(8, 0xc010643a, 0xbfb1a140)        = -1 EBUSY (Device or resource busy)

(fd 8 is /dev/dri/card0)

I'm running the modesetting branch of the i810 driver, (because this laptop has
a widescreen panel), but I've also tried the git head and had the same results.
Comment 1 Ricardo Cerqueira 2006-06-13 07:16:41 UTC
Sorry, I forgot to add the version details; this is on a FC5 install, using it's
stock xorg version (7.0.0)
Comment 2 Alan Hourihane 2006-06-14 12:28:16 UTC
I think Brian Paul has fixed this in Mesa CVS. You should try getting the latest
code and building.
Comment 3 Ricardo Cerqueira 2006-06-14 17:16:00 UTC
OK... Mesa CVS took care of the libGL warnings, but the ioctl loop is still
here... One thing I hadn't noticed before... It looks like the app is doing the
same ioctl twice: the first time works, the second time it fails:

gettimeofday({1150330306, 387209}, NULL) = 0
sched_yield()                           = 0
ioctl(8, 0xc0046444, 0xbfdf42c4)        = 0
ioctl(8, 0x40046445, 0xb4ffb288)        = 0
ioctl(8, 0x40046445, 0xb4ffb288)        = 0
gettimeofday({1150330306, 388262}, NULL) = 0
ioctl(8, 0xc0086446, 0xbfdf428c)        = 0
ioctl(8, 0xc010643a, 0xbfdf427c)        = 0
ioctl(8, 0xc010643a, 0xbfdf427c)        = -1 EBUSY (Device or resource busy)
ioctl(8, 0x4008642a, 0xbfdf4254)        = 0
ioctl(8, 0xc0046444, 0xbfdf41f4)        = 0
gettimeofday({1150330309, 394087}, NULL) = 0
sched_yield()                           = 0
ioctl(8, 0xc0046444, 0xbfdf42c4)        = 0
ioctl(8, 0x40046445, 0xb4ffb288)        = 0
ioctl(8, 0x40046445, 0xb4ffb288)        = 0
gettimeofday({1150330309, 394523}, NULL) = 0
ioctl(8, 0xc0086446, 0xbfdf428c)        = 0
ioctl(8, 0xc010643a, 0xbfdf427c)        = 0
ioctl(8, 0xc010643a, 0xbfdf427c)        = -1 EBUSY (Device or resource busy)
ioctl(8, 0x4008642a, 0xbfdf4254)        = 0
ioctl(8, 0xc0046444, 0xbfdf41f4)        = 0
gettimeofday({1150330312, 398179}, NULL) = 0
sched_yield()                           = 0
ioctl(8, 0xc0046444, 0xbfdf42c4)        = 0
Comment 4 Michel Dänzer 2006-08-16 02:03:50 UTC
Looks like the wait for vblank ioctl is timing out... Are you setting
vblank_mode in ~/.drirc or /etc/drirc? Does it work if setting the environment
variable vblank_mode=0?
Comment 5 Ricardo Cerqueira 2006-08-16 06:57:12 UTC
I didn't have a drirc. After creating one and setting vblank_mode to 0, the
problem remains.

$ cat .drirc
<driconf>
    <device screen="0" driver="i915">
        <application name="Default">
            <option name="force_s3tc_enable" value="false" />
            <option name="fthrottle_mode" value="2" />
            <option name="vblank_mode" value="0" />
            <option name="allow_large_textures" value="1" />
        </application>
    </device>
</driconf>
$ LIBGL_DEBUG=all googleearth
libGL warning: 3D driver claims to not support visual 0x4b
Mesa: CPU vendor: GenuineIntel
Mesa: CPU name: Genuine Intel(R) CPU           T2300  @ 1.66GHz
Mesa: MMX cpu detected.
Mesa: SSE cpu detected.
Mesa: Not testing OS support for SSE, leaving enabled.
libGL error:
Can't open configuration file /etc/drirc: No such file or directory.
do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Try running with LIBGL_THROTTLE_REFRESH and LIBL_SYNC_REFRESH unset.
Comment 6 Alan Hourihane 2006-08-16 11:13:42 UTC
I guess you have a laptop ?

If so, then the irq's are not configured correctly.

You need to get the latest 1.6.5 driver as well as the latest DRM sources for
the kernel driver i915.ko.
Comment 7 Ricardo Cerqueira 2006-08-16 12:29:01 UTC
(In reply to comment #6)
> I guess you have a laptop ?
> 

Yeah.

> If so, then the irq's are not configured correctly.
> 
> You need to get the latest 1.6.5 driver as well as the latest DRM sources for
> the kernel driver i915.ko.


OK, that did it. No more errors, and googleearth now loads fine. Great, thanks!
Comment 8 Walter Ribeiro 2007-10-30 04:44:26 UTC
(In reply to comment #6)
> I guess you have a laptop ?
> 
> If so, then the irq's are not configured correctly.
> 
> You need to get the latest 1.6.5 driver as well as the latest DRM sources for
> the kernel driver i915.ko.

Hello, 
Can you please explain how to do this step by step?
I have installed Ubuntu only a few weeks ago and I have not much experience.
Thank you!
Comment 9 Jesse Barnes 2007-10-31 13:09:56 UTC
Whoa, this is an *old* bug.  I think it's fixed too.  Ricardo or Walter, please reopen if you still see this issue with recent versions of the driver.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.