[ the xorg@fdo list requires subscription, so perhaps someone might forward it
there. It would be nice if those lists had a 'quiet' subscription
mode, ie. without
any mails. ]
Hi,
using the latest git checkout of the xf86 intel driver
(f1e9ca4e4fb3ddb083252aea79c67c5e5e71f29c),
xorg 1.5.3 and kernel 2.6.28 git head
(3d14bdad40315b54470cb7812293d14c8af2bf7d), both from
10/January, the inteldrmfb module correctly initializes the display to
its native mode (1440x900),
Lenovo X300, but X fails to start with the following error:
(WW) xf86AcquireGART: AGPIOC_ACQUIRE failed (Device or resource busy)
(EE) GARTInit: AGPIOC_INFO failed (Invalid argument)
(WW) intel(0): /dev/agpgart is either not available, or no memory is available
for allocation. Using pre-allocated memory only.
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 10, (OK)
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 10, (OK)
drmOpenByBusid: Searching for BusID pci:0000:00:02.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 10, (OK)
drmOpenByBusid: drmOpenMinor returns 10
drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
(II) [drm] DRM interface version 1.3
(II) [drm] DRM open master succeeded.
(II) intel(0): [drm] Using the DRM lock SAREA also for drawables.
(II) intel(0): [drm] framebuffer mapped by ddx driver
(II) intel(0): [drm] added 1 reserved context for kernel
(II) intel(0): X context handle = 0x1
(II) intel(0): [drm] installed DRM signal handler
(**) intel(0): Framebuffer compression disabled
(**) intel(0): Tiling enabled
(EE) intel(0): Failed to allocate space for kernel memory manager
(==) intel(0): VideoRam: 7676 KB
(II) intel(0): Attempting memory allocation with tiled buffers.
(EE) intel(0): Failed to allocate framebuffer. Is your VideoRAM set too low?
(II) intel(0): Tiled allocation failed.
(II) intel(0): Attempting memory allocation with untiled buffers.
(EE) intel(0): Failed to allocate framebuffer. Is your VideoRAM set too low?
(II) intel(0): Untiled allocation failed.
(II) intel(0): Couldn't allocate 3D memory, disabling DRI.
(II) intel(0): Attempting memory allocation with untiled buffers.
(EE) intel(0): Failed to allocate framebuffer. Is your VideoRAM set too low?
(II) intel(0): Untiled allocation failed.
(EE) intel(0): Couldn't allocate video memory
The complete log and dmesg is attached.
Relevant xorg.conf entry:
Section "Device"
Identifier "Configured Video Device"
Option "RenderAccel" "on"
Option "XvMCSurface" "7"
Option "XvMC" "on"
Option "Legacy3D" "off"
EndSection
How can I fix this? As I said, the hardware is a Lenovo X300, GM965
graphics. Is this a kernel or xorg driver bug?
Thanks,
Jan
ps: Kernel Mode Setting severly lacks documentation...
--
Jan Dittmer <[email protected]>
I also have a failure with KMS, it's different than yours but I'll post it
in this thread...xserver-xorg-video-intel version 2.5.1 (whatever there is
in ubuntu unstable repositories)
-----------------------------------------------
(II) [drm] DRM interface version 1.3
(II) [drm] DRM open master succeeded.
(II) intel(0): [drm] Using the DRM lock SAREA also for drawables.
(II) intel(0): [drm] framebuffer mapped by ddx driver
(II) intel(0): [drm] added 1 reserved context for kernel
(II) intel(0): X context handle = 0x1
(II) intel(0): [drm] installed DRM signal handler
(**) intel(0): Framebuffer compression disabled
(**) intel(0): Tiling enabled
(==) intel(0): VideoRam: 262144 KB
(II) intel(0): Attempting memory allocation with tiled buffers.
(II) intel(0): Tiled allocation successful.
Fatal server error:
AddScreen/ScreenInit failed for driver 0
-----------------------------------------------
Full X.org log attached.
On Mon, Jan 12, 2009 at 7:21 AM, Diego Calleja <[email protected]> wrote:
> I also have a failure with KMS, it's different than yours but I'll post it
> in this thread...xserver-xorg-video-intel version 2.5.1 (whatever there is
> in ubuntu unstable repositories)
Read the kconfig option before you enabled kms by default?
if not, you cannot just enable kms and have old userspace drivers
work, there is no
released userspace for this yet, as that would put the chicken before the egg.
Dave.
>
> -----------------------------------------------
> (II) [drm] DRM interface version 1.3
> (II) [drm] DRM open master succeeded.
> (II) intel(0): [drm] Using the DRM lock SAREA also for drawables.
> (II) intel(0): [drm] framebuffer mapped by ddx driver
> (II) intel(0): [drm] added 1 reserved context for kernel
> (II) intel(0): X context handle = 0x1
> (II) intel(0): [drm] installed DRM signal handler
> (**) intel(0): Framebuffer compression disabled
> (**) intel(0): Tiling enabled
> (==) intel(0): VideoRam: 262144 KB
> (II) intel(0): Attempting memory allocation with tiled buffers.
> (II) intel(0): Tiled allocation successful.
>
> Fatal server error:
> AddScreen/ScreenInit failed for driver 0
> -----------------------------------------------
>
> Full X.org log attached.
El Mon, 12 Jan 2009 07:39:29 +1000, "Dave Airlie" <[email protected]> escribió:
> On Mon, Jan 12, 2009 at 7:21 AM, Diego Calleja <[email protected]> wrote:
> > I also have a failure with KMS, it's different than yours but I'll post it
> > in this thread...xserver-xorg-video-intel version 2.5.1 (whatever there is
> > in ubuntu unstable repositories)
>
> Read the kconfig option before you enabled kms by default?
>
> if not, you cannot just enable kms and have old userspace drivers
> work, there is no
> released userspace for this yet, as that would put the chicken before
> the egg.
Yes, that's why I bothered installing the version 2.5.x of the intel
driver, which is supposed to have such support.
Anyway, I just realized that Ubuntu does not turn on the option that
according to git you added to the driver to disable KMS by default.
Duh :(
On Sun, Jan 11, 2009 at 10:39 PM, Dave Airlie <[email protected]> wrote:
> On Mon, Jan 12, 2009 at 7:21 AM, Diego Calleja <[email protected]> wrote:
>> I also have a failure with KMS, it's different than yours but I'll post it
>> in this thread...xserver-xorg-video-intel version 2.5.1 (whatever there is
>> in ubuntu unstable repositories)
>
> Read the kconfig option before you enabled kms by default?
>
> if not, you cannot just enable kms and have old userspace drivers
> work, there is no
> released userspace for this yet, as that would put the chicken before the egg.
But latest xf86-intel-video git tree should work, shouldn't it? An explicit
VideoRam line in xorg.conf is ignored btw.
Thanks,
Jan
--
Jan Dittmer <[email protected]>
On Mon, Jan 12, 2009 at 5:42 PM, Jan Dittmer <[email protected]> wrote:
> On Sun, Jan 11, 2009 at 10:39 PM, Dave Airlie <[email protected]> wrote:
>> On Mon, Jan 12, 2009 at 7:21 AM, Diego Calleja <[email protected]> wrote:
>>> I also have a failure with KMS, it's different than yours but I'll post it
>>> in this thread...xserver-xorg-video-intel version 2.5.1 (whatever there is
>>> in ubuntu unstable repositories)
>>
>> Read the kconfig option before you enabled kms by default?
>>
>> if not, you cannot just enable kms and have old userspace drivers
>> work, there is no
>> released userspace for this yet, as that would put the chicken before the egg.
>
> But latest xf86-intel-video git tree should work, shouldn't it? An explicit
> VideoRam line in xorg.conf is ignored btw.
explicit VideoRAM is most likely ignored by xorg as well for Intel
chipsets with the latest driver,
the latest git should work with kms on most chipsets, we are still
chasing down some issues on some chipsets,
its still development code, its mainly upstream to get the API stable
and find the corner cases.
Dave.
>
> Thanks,
>
> Jan
>
> --
> Jan Dittmer <[email protected]>
>
On Mon, Jan 12, 2009 at 9:04 AM, Dave Airlie <[email protected]> wrote:
> the latest git should work with kms on most chipsets, we are still
> chasing down some issues on some chipsets,
So is there anything I can test to help you get it going on 'my' chipset
(GM965, Lenovo X300)?
Jan
On Mon, Jan 12, 2009 at 06:04:19PM +1000, Dave Airlie wrote:
> explicit VideoRAM is most likely ignored by xorg as well for Intel
> chipsets with the latest driver,
I'm going on a tangeant, but it would be nice if video drivers, intel
first among them, would stop ignoring user-provided configurations in
favour of firmwares, bioses, in-display roms and other things like
that that can be incorrect and not user-modifiable. VideoRAM is one,
but there's also modeline, DPI...
OG.
On Monday, January 12, 2009 5:03 am Olivier Galibert wrote:
> On Mon, Jan 12, 2009 at 06:04:19PM +1000, Dave Airlie wrote:
> > explicit VideoRAM is most likely ignored by xorg as well for Intel
> > chipsets with the latest driver,
>
> I'm going on a tangeant, but it would be nice if video drivers, intel
> first among them, would stop ignoring user-provided configurations in
> favour of firmwares, bioses, in-display roms and other things like
> that that can be incorrect and not user-modifiable. VideoRAM is one,
> but there's also modeline, DPI...
On the contrary, I think we have way too many options and configuration
possibilities. The more we have, the more likely some combination of them
will be broken.
That said, modes are generally pretty easy to handle, so users can provide
them through xrandr and xorg.conf; I don't see that changing. VideoRAM OTOH
was broken by design. A user really has no way of knowing how much memory is
available to the GPU, so providing a configurable value was causing way more
problems than it solved.
But I suspect what you want it something else entirely, like a limit on the
amount of RAM that will be used by the GPU. I think that's a valid concern
and something like that could probably be added to GEM w/o too much trouble,
maybe through a new ulimit or system wide tunable.
--
Jesse Barnes, Intel Open Source Technology Center
On Monday, January 12, 2009 12:37 am Jan Dittmer wrote:
> On Mon, Jan 12, 2009 at 9:04 AM, Dave Airlie <[email protected]> wrote:
> > the latest git should work with kms on most chipsets, we are still
> > chasing down some issues on some chipsets,
>
> So is there anything I can test to help you get it going on 'my' chipset
> (GM965, Lenovo X300)?
I do much of my testing on GM965, so you should be able to get it to work with
the latest bits:
- libdrm from git master of mesa/drm
- mesa from git master of mesa/mesa
- xf86-video-intel from git master
- drm-intel-next from anholt's kernel tree
(git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel)
You'll need to use UXA as your AccelMethod. If you run into issues with the
above, please file bugs (if you don't already see your issue filed) at
bugs.freedesktop.org.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
El Mon, 12 Jan 2009 09:56:30 -0800, Jesse Barnes <[email protected]> escribió:
> I do much of my testing on GM965, so you should be able to get it to work with
> the latest bits:
> - libdrm from git master of mesa/drm
> - mesa from git master of mesa/mesa
> - xf86-video-intel from git master
> - drm-intel-next from anholt's kernel tree
> (git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel)
Users ARE going to try modesetting when 2.6.29 is released (there's
people already trying to test it in -rcs ;), so I think it's better
to put as much detailed documentation as possible somewhere.
I've created http://xorg.freedesktop.org/wiki/ModeSettingHowTo
with the quoted instructions for that.
On Mon, Jan 12, 2009 at 6:56 PM, Jesse Barnes <[email protected]> wrote:
> On Monday, January 12, 2009 12:37 am Jan Dittmer wrote:
>> On Mon, Jan 12, 2009 at 9:04 AM, Dave Airlie <[email protected]> wrote:
>> > the latest git should work with kms on most chipsets, we are still
>> > chasing down some issues on some chipsets,
>>
>> So is there anything I can test to help you get it going on 'my' chipset
>> (GM965, Lenovo X300)?
>
> I do much of my testing on GM965, so you should be able to get it to work with
> the latest bits:
> - libdrm from git master of mesa/drm
> - mesa from git master of mesa/mesa
> - xf86-video-intel from git master
> - drm-intel-next from anholt's kernel tree
> (git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel)
>
> You'll need to use UXA as your AccelMethod. If you run into issues with the
> above, please file bugs (if you don't already see your issue filed) at
> bugs.freedesktop.org.
Thanks, at least X starts now, though dri is still broken. Is there
any quick fix to:
name of display: :0.0
libGL: XF86DRIGetClientDriverName: 1.9.0 i965 (screen 0)
libGL: OpenDriver: trying /usr/local/lib/dri/i965_dri.so
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 4, (OK)
drmOpenByBusid: Searching for BusID pci:0000:00:02.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 4, (OK)
drmOpenByBusid: drmOpenMinor returns 4
drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
libGL error: drmMap of framebuffer failed (Resource temporarily unavailable)
libGL error: reverting to software direct rendering
?
This is with latest mesa git libGL. Any special compilation options for mesa?
Thanks,
Jan
On Mon, Jan 12, 2009 at 09:53:49AM -0800, Jesse Barnes wrote:
> On the contrary, I think we have way too many options and configuration
> possibilities. The more we have, the more likely some combination of them
> will be broken.
You need to be able to fix wrong data coming from the bios or other roms.
> That said, modes are generally pretty easy to handle, so users can provide
> them through xrandr and xorg.conf; I don't see that changing.
The intel driver ignores modelines if a bios mode is present, at least
for lvds. Check i830_lvds_mode_fixup.
OG.
On Mon, Jan 12, 2009 at 10:19 PM, Jan Dittmer <[email protected]> wrote:
> On Mon, Jan 12, 2009 at 6:56 PM, Jesse Barnes <[email protected]> wrote:
>> On Monday, January 12, 2009 12:37 am Jan Dittmer wrote:
>>> On Mon, Jan 12, 2009 at 9:04 AM, Dave Airlie <[email protected]> wrote:
>>> > the latest git should work with kms on most chipsets, we are still
>>> > chasing down some issues on some chipsets,
>>>
>>> So is there anything I can test to help you get it going on 'my' chipset
>>> (GM965, Lenovo X300)?
>>
>> I do much of my testing on GM965, so you should be able to get it to work with
>> the latest bits:
>> - libdrm from git master of mesa/drm
>> - mesa from git master of mesa/mesa
>> - xf86-video-intel from git master
>> - drm-intel-next from anholt's kernel tree
>> (git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel)
>>
>> You'll need to use UXA as your AccelMethod. If you run into issues with the
>> above, please file bugs (if you don't already see your issue filed) at
>> bugs.freedesktop.org.
>
> Thanks, at least X starts now, though dri is still broken. Is there
> any quick fix to:
>
> name of display: :0.0
> libGL: XF86DRIGetClientDriverName: 1.9.0 i965 (screen 0)
> libGL: OpenDriver: trying /usr/local/lib/dri/i965_dri.so
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is 4, (OK)
> drmOpenByBusid: Searching for BusID pci:0000:00:02.0
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is 4, (OK)
> drmOpenByBusid: drmOpenMinor returns 4
> drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
> libGL error: drmMap of framebuffer failed (Resource temporarily unavailable)
> libGL error: reverting to software direct rendering
For each call to glxinfo (or any other libgl program) I get
[ 93.768928] glxinfo:3071 map pfn expected mapping type write-back
for e5720000-e5f90000, got uncached
[ 93.769760] glxinfo:3071 freeing invalid memtype e5720000-e5f90000
written in my kernel log buffer.
Jan
On Monday, January 12, 2009 1:19 pm Jan Dittmer wrote:
> On Mon, Jan 12, 2009 at 6:56 PM, Jesse Barnes <[email protected]>
wrote:
> > On Monday, January 12, 2009 12:37 am Jan Dittmer wrote:
> >> On Mon, Jan 12, 2009 at 9:04 AM, Dave Airlie <[email protected]> wrote:
> >> > the latest git should work with kms on most chipsets, we are still
> >> > chasing down some issues on some chipsets,
> >>
> >> So is there anything I can test to help you get it going on 'my' chipset
> >> (GM965, Lenovo X300)?
> >
> > I do much of my testing on GM965, so you should be able to get it to work
> > with the latest bits:
> > - libdrm from git master of mesa/drm
> > - mesa from git master of mesa/mesa
> > - xf86-video-intel from git master
> > - drm-intel-next from anholt's kernel tree
> > (git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel)
> >
> > You'll need to use UXA as your AccelMethod. If you run into issues with
> > the above, please file bugs (if you don't already see your issue filed)
> > at bugs.freedesktop.org.
>
> Thanks, at least X starts now, though dri is still broken. Is there
> any quick fix to:
>
> name of display: :0.0
> libGL: XF86DRIGetClientDriverName: 1.9.0 i965 (screen 0)
> libGL: OpenDriver: trying /usr/local/lib/dri/i965_dri.so
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is 4, (OK)
> drmOpenByBusid: Searching for BusID pci:0000:00:02.0
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is 4, (OK)
> drmOpenByBusid: drmOpenMinor returns 4
> drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
> libGL error: drmMap of framebuffer failed (Resource temporarily
> unavailable) libGL error: reverting to software direct rendering
>
> ?
> This is with latest mesa git libGL. Any special compilation options for
> mesa?
Nope, not afaik. Are you sure UXA is enabled? And that Mesa was built
against the same libdrm bits as your 2D driver? If so, then I guess it's
time to file a bug. :)
--
Jesse Barnes, Intel Open Source Technology Center
On Monday, January 12, 2009 1:32 pm Olivier Galibert wrote:
> On Mon, Jan 12, 2009 at 09:53:49AM -0800, Jesse Barnes wrote:
> > On the contrary, I think we have way too many options and configuration
> > possibilities. The more we have, the more likely some combination of
> > them will be broken.
>
> You need to be able to fix wrong data coming from the bios or other roms.
>
> > That said, modes are generally pretty easy to handle, so users can
> > provide them through xrandr and xorg.conf; I don't see that changing.
>
> The intel driver ignores modelines if a bios mode is present, at least
> for lvds. Check i830_lvds_mode_fixup.
We have an LVDSFixedMode option though; afaik it should allow you to override
any VBT info. If not you should file a bug.
--
Jesse Barnes, Intel Open Source Technology Center
On Mon, Jan 12, 2009 at 10:53 PM, Jesse Barnes <[email protected]> wrote:
>> name of display: :0.0
>> libGL: XF86DRIGetClientDriverName: 1.9.0 i965 (screen 0)
>> libGL: OpenDriver: trying /usr/local/lib/dri/i965_dri.so
>> drmOpenDevice: node name is /dev/dri/card0
>> drmOpenDevice: open result is 4, (OK)
>> drmOpenByBusid: Searching for BusID pci:0000:00:02.0
>> drmOpenDevice: node name is /dev/dri/card0
>> drmOpenDevice: open result is 4, (OK)
>> drmOpenByBusid: drmOpenMinor returns 4
>> drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
>> libGL error: drmMap of framebuffer failed (Resource temporarily
>> unavailable) libGL error: reverting to software direct rendering
>>
>> ?
>> This is with latest mesa git libGL. Any special compilation options for
>> mesa?
>
> Nope, not afaik. Are you sure UXA is enabled? And that Mesa was built
> against the same libdrm bits as your 2D driver? If so, then I guess it's
> time to file a bug. :)
With the patches againg 29-rc1 from here
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=3a03ac1a0223f779a3de313523408ddb099e5679;hp=dc1336ff4fe08ae7cfe8301bfd7f0b2cfd31d20a
and here
http://groups.google.com/group/linux.kernel/msg/26aa0471cfb54b06?dmode=source&output=gplain
at least glxinfo works.
Anyways thanks for your help, time to get some sleep,
Jan
On Mon, Jan 12, 2009 at 11:08 PM, Jan Dittmer <[email protected]> wrote:
> On Mon, Jan 12, 2009 at 10:53 PM, Jesse Barnes <[email protected]> wrote:
>>> name of display: :0.0
>>> libGL: XF86DRIGetClientDriverName: 1.9.0 i965 (screen 0)
>>> libGL: OpenDriver: trying /usr/local/lib/dri/i965_dri.so
>>> drmOpenDevice: node name is /dev/dri/card0
>>> drmOpenDevice: open result is 4, (OK)
>>> drmOpenByBusid: Searching for BusID pci:0000:00:02.0
>>> drmOpenDevice: node name is /dev/dri/card0
>>> drmOpenDevice: open result is 4, (OK)
>>> drmOpenByBusid: drmOpenMinor returns 4
>>> drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
>>> libGL error: drmMap of framebuffer failed (Resource temporarily
>>> unavailable) libGL error: reverting to software direct rendering
>>>
>>> ?
>>> This is with latest mesa git libGL. Any special compilation options for
>>> mesa?
>>
>> Nope, not afaik. Are you sure UXA is enabled? And that Mesa was built
>> against the same libdrm bits as your 2D driver? If so, then I guess it's
>> time to file a bug. :)
>
> With the patches againg 29-rc1 from here
> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=3a03ac1a0223f779a3de313523408ddb099e5679;hp=dc1336ff4fe08ae7cfe8301bfd7f0b2cfd31d20a
> and here
> http://groups.google.com/group/linux.kernel/msg/26aa0471cfb54b06?dmode=source&output=gplain
> at least glxinfo works.
Using drm-intel-next from anholt on top, I've working GL (yeah!) but
get millions of
[ 649.472172] [drm:drm_wait_vblank] *ERROR* failed to acquire vblank
counter, -22
[ 649.512429] [drm:drm_wait_vblank] *ERROR* failed to acquire vblank
counter, -22
[ 649.554513] [drm:drm_wait_vblank] *ERROR* failed to acquire vblank
counter, -22
[ 649.596972] [drm:drm_wait_vblank] *ERROR* failed to acquire vblank
counter, -22
[ 649.638744] [drm:drm_wait_vblank] *ERROR* failed to acquire vblank
counter, -22
entries in my log. libGL says
do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Try adjusting the vblank_mode configuration parameter.
?
Jan
On Monday, January 12, 2009 2:29 pm Jan Dittmer wrote:
> On Mon, Jan 12, 2009 at 11:08 PM, Jan Dittmer <[email protected]> wrote:
> > On Mon, Jan 12, 2009 at 10:53 PM, Jesse Barnes <[email protected]>
wrote:
> >>> name of display: :0.0
> >>> libGL: XF86DRIGetClientDriverName: 1.9.0 i965 (screen 0)
> >>> libGL: OpenDriver: trying /usr/local/lib/dri/i965_dri.so
> >>> drmOpenDevice: node name is /dev/dri/card0
> >>> drmOpenDevice: open result is 4, (OK)
> >>> drmOpenByBusid: Searching for BusID pci:0000:00:02.0
> >>> drmOpenDevice: node name is /dev/dri/card0
> >>> drmOpenDevice: open result is 4, (OK)
> >>> drmOpenByBusid: drmOpenMinor returns 4
> >>> drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
> >>> libGL error: drmMap of framebuffer failed (Resource temporarily
> >>> unavailable) libGL error: reverting to software direct rendering
> >>>
> >>> ?
> >>> This is with latest mesa git libGL. Any special compilation options for
> >>> mesa?
> >>
> >> Nope, not afaik. Are you sure UXA is enabled? And that Mesa was built
> >> against the same libdrm bits as your 2D driver? If so, then I guess
> >> it's time to file a bug. :)
> >
> > With the patches againg 29-rc1 from here
> > http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdif
> >f;h=3a03ac1a0223f779a3de313523408ddb099e5679;hp=dc1336ff4fe08ae7cfe8301bfd
> >7f0b2cfd31d20a and here
> > http://groups.google.com/group/linux.kernel/msg/26aa0471cfb54b06?dmode=so
> >urce&output=gplain at least glxinfo works.
>
> Using drm-intel-next from anholt on top, I've working GL (yeah!) but
> get millions of
> [ 649.472172] [drm:drm_wait_vblank] *ERROR* failed to acquire vblank
> counter, -22
> [ 649.512429] [drm:drm_wait_vblank] *ERROR* failed to acquire vblank
> counter, -22
> [ 649.554513] [drm:drm_wait_vblank] *ERROR* failed to acquire vblank
> counter, -22
> [ 649.596972] [drm:drm_wait_vblank] *ERROR* failed to acquire vblank
> counter, -22
> [ 649.638744] [drm:drm_wait_vblank] *ERROR* failed to acquire vblank
> counter, -22
>
> entries in my log. libGL says
>
> do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working
> correctly. Try adjusting the vblank_mode configuration parameter.
Those errors indicate that Mesa is trying to wait on a vblank event from a
disabled pipe. Interrupts should work fine on the other pipe though
(assuming you have at least *one* display going! :).
If you can get a backtrace of what's calling this, we should be able to fix
Mesa to prevent it.
--
Jesse Barnes, Intel Open Source Technology Center