| Summary: | x11-drivers/xf86-video-intel-2.5.1-r1: (EE) intel(0): Failed to pin back buffer: Cannot allocate memory | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Andrey Batyiev <generatorglukoff> |
| Component: | Current packages | Assignee: | Gentoo X packagers <x11> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | major | CC: | arthapex, jrmalaq, julian, konstantin, nick.hadaway, opensource, ralf, theblackpeter |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
xorg.conf
Xorg.0.log Xorg.log LIBGL_DEBUG=1 glxinfo Xorg.0.log containing error message(s) |
||
|
Description
Andrey Batyiev
2008-12-25 15:48:00 UTC
Created attachment 176355 [details]
xorg.conf
Created attachment 176357 [details]
Xorg.0.log
Created attachment 176442 [details]
Xorg.log
Same problem here: Intel 855GM.
No xorg.conf, only hal based system.
xorg-server: 1.5.3
xf86-video-intel: 2.5.1-r1
media-libs/mesa: 7.2
x11-libs/libdrm: 2.4.1
gentoo-sources: 2.6.28
System is complete new builded with emere --emptytree world
Bug is also known by Xorg devs: https://bugs.freedesktop.org/show_bug.cgi?id=18974 Possible solutions from https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/304871 - Downgrade to kernel to 2.6.27 - Add NoAccel to your xorg.com As I have no accel with 2.6.27 also, I think this is only a help to use the system, not to solve this issue I ran into a similar problem. I found that intelfb.ko was no loading automatically. After modprobing it Xorg starts normally. (In reply to comment #6) > I ran into a similar problem. I found that intelfb.ko was no loading > automatically. After modprobing it Xorg starts normally. > I'm not completly sure, but in my knowledge intelfb is the module for the intel framebuffer. But most people will use the stable vesa framebuffer as far as I know. Can you check, if you have hardware accelerated opengl? Please don't use intelfb. For the moment, it competes with the intel driver. In future kernel, it will be fixed to use the DRM driver if available. vesafb or uvesafb should be safer to use as they only bang on "standard" VGA registers. But for now, it's best not to use any if you don't need a framebuffer console. Please try to disable all framebuffer drivers (at least temporarily). Thanks I have upgraded kernel to lastest git (nearly 2.6.29-rc1). Now X server works, glxinfo says "direct rendering: Yes", but glxgears shows 280 fps, 4 times slower than default (1100 fps). glxgears is *not* a benchmarking tool. Its *only* use is to see if direct rendering works or not, no more, no less. Please test with *real* applications to compare frame rates. Closing fixed then. Thanks (In reply to comment #10) > Please test with *real* applications to compare frame rates. Ok, I tried to run Tremulous game and got huge fps drop: from 90 to 1, even game's menu moves sharply. Could you please attach the full output of `LIBGL_DEBUG=1 glxinfo`? Thanks To clear this up: I guess this bug is still about the intel issue where the only solution would be to add Option "NoAccel" "true" to the Driver section. So, please open a new bug for any frame buffer issue. (In reply to comment #13) > To clear this up: > > I guess this bug is still about the intel issue where the > only solution would be to add Option "NoAccel" "true" to > the Driver section. > > So, please open a new bug for any frame buffer issue. > To disable the direct rendering is no solution. In kernel 2.6.29 the graphics infrastructur is improved. Therefore, let us wait for tests with the git kernel. You might want to try set the "Legacy3D" option to "false" in your Device section. Please don't try 2.6.29-rc* yet, if there's a bug with 2.6.28, it needs to be identified and fixed. Thanks > if there's a bug with 2.6.28, it needs to be
> identified and fixed.
Problem may be, that the infrastructur, mainly the memory manager and kernel mode line settings are not implemented completly in 2.6.28.
I'm not sure if it's worth the effort to backport these patches.
(In reply to comment #16) > > if there's a bug with 2.6.28, it needs to be > > identified and fixed. > > Problem may be, that the infrastructur, mainly the memory manager and kernel > mode line settings are not implemented completly in 2.6.28. The memory manager is complete and should work on all supported chips. KMS is a whole other issue, one that is far from being ready. Let's stick with the bug at hand before fixing the rest of the world. Thanks Created attachment 178335 [details] LIBGL_DEBUG=1 glxinfo (In reply to comment #12) > Could you please attach the full output of `LIBGL_DEBUG=1 glxinfo`? (In reply to comment #15) > You might want to try set the "Legacy3D" option to "false" in your Device > section. > > Please don't try 2.6.29-rc* yet, if there's a bug with 2.6.28, it needs to be > identified and fixed. Setting "Legacy3D" option to "false" doesn't help on 2.6.28. "Doesn't help", guys, I'm lost. I have no idea what bug you guys are having. Please explain again what bug you guys are having. Thanks (In reply to comment #20) > Please explain again what bug you guys are having. Ok, it's bug in connection between xf86-video-intel and kernel. x11-drivers/xf86-video-intel-2.5.1-r1 (lastest stable) simply doesn't work with 2.6.28 kernel (also lastest stable). Lastest git kernel sources (2.6.29-rc1) can be used as workaround for this bug, but there is huge performance loss either. (In reply to comment #21) > (In reply to comment #20) > > Please explain again what bug you guys are having. > > Ok, it's bug in connection between xf86-video-intel and kernel. > x11-drivers/xf86-video-intel-2.5.1-r1 (lastest stable) simply doesn't work with > 2.6.28 kernel (also lastest stable). It should, have you tried the Legacy3D option like I suggested earlier? If you do use it, mesa 7.2 won't be able to do any sort of acceleration (it's a known limitation, I should have pointed that out) > Lastest git kernel sources (2.6.29-rc1) can be used as workaround for this bug, > but there is huge performance loss either. Again, if you somehow end up using the software renderer (even if glxinfo says you're using direct rendering), then it'll be of course very slow. Now, if you want/need opengl acceleration, you should use the x11 overlay (available through layman). With this overlay, you'll get release candidates for -intel 2.6 and mesa 7.4 which have been tested and fixed for GEM operation. Those packages will hit portage within the next couple of weeks, but the sooner you test them, the sooner you can report bugs. Phew :) Thanks (In reply to comment #22) > (In reply to comment #21) > > (In reply to comment #20) > > > Please explain again what bug you guys are having. > > > > Ok, it's bug in connection between xf86-video-intel and kernel. > > x11-drivers/xf86-video-intel-2.5.1-r1 (lastest stable) simply doesn't work with > > 2.6.28 kernel (also lastest stable). > > It should, have you tried the Legacy3D option like I suggested earlier? If you > do use it, mesa 7.2 won't be able to do any sort of acceleration (it's a known > limitation, I should have pointed that out) Option "Legacy3D" "false" > > Lastest git kernel sources (2.6.29-rc1) can be used as workaround for this bug, > > but there is huge performance loss either. > > Again, if you somehow end up using the software renderer (even if glxinfo says > you're using direct rendering), then it'll be of course very slow. > > Now, if you want/need opengl acceleration, you should use the x11 overlay > (available through layman). > > With this overlay, you'll get release candidates for -intel 2.6 and mesa 7.4 > which have been tested and fixed for GEM operation. Those packages will hit > portage within the next couple of weeks, but the sooner you test them, the > sooner you can report bugs. Ok, should i update mesa too? > Phew :) :) (In reply to comment #23) > Ok, should i update mesa too? Yes, please update all unmasked packages provided by the x11 overlay. Thanks http://intellinuxgraphics.org/2008Q4.html After adding ebuilds for the mesa, libdrm, and xf86-video-intel packages referenced on this page, my 855GM started working much better. I can play doom3 (albeit slowly) on this laptop for the first time ever. It seems to be that the display problems in 2D mode and 3D mode have been addressed in a very positive way and the display anomalies that I had noticed before seem to be gone. (In reply to comment #25) > After adding ebuilds for the mesa, libdrm, and xf86-video-intel packages > referenced on this page, Could you please try the ebuilds we provide in the x11 overlay instead? Thanks > Could you please try the ebuilds we provide in the x11 overlay instead?
I'm not the person you asked but I want to report that your ebuilds solve
the problems with my 855GM card (Centrino mainboard). I've tested DOOM2, other games, Firefox with flash and videos using xine, and no crash so far. Needless to say it's faster than with NoAccel. And this is all with a 2.6.22 kernel, so I'm looking forward to my first GEM kernel, with further speed gains, I guess.
Finally, this old but fine hardware is used optimally. A shame otherwise. Thanks!
PS: you said get mesa-7.4 but the overlay shows only 7.3_rc2 which was what I tested
I went to making my own ebuilds and following the suggested package versions mentioned on intellinuxgraphics.org for the 2008Q4 driver package because I could not get a working xserver from the x11 overlay. I was utilizing the git builds to attempt to get a working configuration out of my 855GM. After trying for a day or 2 with various combinations of git builds and point releases I got frustrated and made my own. Nothing special needed to be done, just account for different file names/versions as suggested on the web intel web page. I will happily test x11 overlay builds if you need verification. I need to know what builds of what packages you specifically would like me to use as git builds crash my system with no logging output at all. Don't use any of the -9999 ebuilds. Just add the x11 overlay and emerge -DuN @world. Thanks Created attachment 179476 [details]
Xorg.0.log containing error message(s)
Just tried x11 overlay and it does not work with vanilla-sources-2.6.28.1. With 2.6.27.8 X starts and glxgears works the same as with xf86-video-intel-2.5.1-r1. The needed/installed packages out of the overlay were only these:
x11-drivers/xf86-video-intel-2.6.1
x11-libs/libdrm-2.4.4
x11-proto/dri2proto-1.99.3
Do I need to take some more out of the overlay or to re-emerge something?
@all, 1) please add the x11 overlay using "layman" 2) please emerge or reemerge _in_that_order_ - dri2proto - libdrm - mesa - xorg-server - xf86-video-intel The order *really* matters. If you still have issues with all that and a stable kernel, please use this kernel instead : - cd /usr/src - git clone git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel - cd drm-intel - git checkout -t origin/drm-intel-2.6.28 -b drm-intel-2.6.28 And if with that kernel, you still have issues, please read this document (http://intellinuxgraphics.org/how_to_report_bug.html) on how to file a bug over at FreeDesktop to Intel devs. If you do open bugs there, please add "remi@gentoo.org" as a CC on them so I can keep track of the problems. Thanks (In reply to comment #31) > 1) please add the x11 overlay using "layman" > 2) please emerge or reemerge _in_that_order_ wow, it's not perfect (nearly 30fps in Tremulous, was 90fps), but it's at least starting up and hardware 3D is online. (In reply to comment #31) Here my status report. This made no difference. The resulting Xorg.0.log was (almost) identical to the one I already uploaded. > 2) please emerge or reemerge _in_that_order_ > - dri2proto > - libdrm > - mesa > - xorg-server > - xf86-video-intel > > The order *really* matters. The versions I now have are: x11-proto/dri2proto-1.99.3 x11-libs/libdrm-2.4.4 media-libs/mesa-7.3 x11-base/xorg-server-1.5.3-r1 x11-drivers/xf86-video-intel-2.6.1 where only mesa and xf86-video-intel are out of the overlay. The others (like dri2proto were the masked 9999-versions as said in comment #31) are out of regular portage. They were reemerged (mesa-7.3 was an upgrade) exactly in the specified order. > If you still have issues with all that and a stable kernel, please use this > kernel instead : > - cd /usr/src > - git clone git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel > - cd drm-intel > - git checkout -t origin/drm-intel-2.6.28 -b drm-intel-2.6.28 I'll try this kernel sometime later and will report the results. Again the remaining details in short, I tried vanilla kernel 2.6.28.1, it's working with 2.6.27.8, am using no framebuffer and the error message is: (EE) intel(0): Failed to pin front buffer: Cannot allocate memory Fatal server error: Couldn't bind memory for BO front buffer (In reply to comment #33) > The versions I now have are: > > x11-proto/dri2proto-1.99.3 > x11-libs/libdrm-2.4.4 > media-libs/mesa-7.3 > x11-base/xorg-server-1.5.3-r1 > x11-drivers/xf86-video-intel-2.6.1 > My case differs from yours only in x11-libs/libdrm-2.4.3 and x11-base/xorg-server-1.5.99.901. Try to upgrade xorg-server. I followed comment #31 (http://bugs.gentoo.org/show_bug.cgi?id=252486#c31) as well, but I only had a major diference in performance (according to glxgears) after using the different kernel. I have a 945GM, it was around 170fps and now it's ~340fps. However, this is still far from what is expected from this card, I think. Anyone got any more ideas? (In reply to comment #34) > My case differs from yours only in x11-libs/libdrm-2.4.3 and > x11-base/xorg-server-1.5.99.901. Try to upgrade xorg-server. Upgrading xorg-server did not make a difference. But I think I found the reason for the failure. Kernel module i915 has some problem, as seen in kernel messages: [drm:i915_gem_object_bind_to_gtt] *ERROR* GTT full, but LRU list empty and later but I think unrelated to the primary faulure of X: [drm:i915_gem_object_pin] *ERROR* Failure to bind: -12 I tried the git-kernel but there was no difference - same error message. So something is wrong with the i915 kernel module on my hardware. Where to report this bug? (In reply to comment #36) > So something is wrong with the i915 kernel module on my hardware. Where to > report this bug? I've explained that bit back in comment #31 Thanks (In reply to comment #37) I think the bug I encounter is this one: http://bugs.freedesktop.org/show_bug.cgi?id=18974 I will post there. Rémi, should I add "remi@gentoo.org" to the Cc list or are you going to do this yourself? For some odd reason, I issued again the glxgears last night and it was back to the poorest performance (~180fps). I haven't changed anything, so I found it very weird. I recompiled the packages in the order after activating the new kernel, but had no success either. Lastly, I tried to use EXA instead of UXA. Then I found the fps count growing a bit unstable (floating between 180 - 270). Then I looked at dmesg: ------------[ cut here ]----------- WARNING: at drivers/gpu/drm/i915/i915_gem.c:2475 i915_gem_idle+0x15e/0x305 [i915]() Modules linked in: coretemp i915 drm rfcomm bnep l2cap snd_hda_intel rt73 i2c_i801 hci_usb Pid: 9602, comm: X Not tainted 2.6.28-00006-ge1a6fce #1 Call Trace: [<c011fa9f>] warn_on_slowpath+0x40/0x59 [<c0126e00>] lock_timer_base+0xa/0x35 [<c0126e6f>] try_to_del_timer_sync+0x44/0x4a [<c0126e7f>] del_timer_sync+0xa/0x14 [<c0447f76>] schedule_timeout+0x72/0x86 [<f82b6e3b>] i915_gem_retire_requests+0xe9/0x100 [i915] [<f82b74a9>] i915_gem_idle+0x15e/0x305 [i915] [<f82b7676>] i915_gem_leavevt_ioctl+0x9/0x17 [i915] [<f8291714>] drm_ioctl+0x1a6/0x21e [drm] [<f82b766d>] i915_gem_leavevt_ioctl+0x0/0x17 [i915] [<c016f4b0>] vfs_ioctl+0x47/0x5d [<c016f929>] do_vfs_ioctl+0x38b/0x3c1 [<c01268ab>] run_timer_softirq+0x30/0x18d [<c0123574>] __do_softirq+0x83/0x11e [<c016f98b>] sys_ioctl+0x2c/0x42 [<c0102ce9>] sysenter_do_call+0x12/0x25 ---[ end trace 3f8ce497d15f4da7 ]--- After examining the Xorg log, I realize I couldn't use DRI2 with EXA. Anyways, I got the warnings: (WW) intel(0): libpciaccess reported 0 rom size, guessing 64kB (WW) intel(0): Register 0x61200 (PP_STATUS) changed from 0xc0000008 to 0xd0000009 (WW) intel(0): PP_STATUS before: on, ready, sequencing idle (WW) intel(0): PP_STATUS after: on, ready, sequencing on (WW) intel(0): Register 0x70024 (PIPEASTAT) changed from 0x00000000 to 0x00000203 (WW) intel(0): PIPEASTAT before: status: (WW) intel(0): PIPEASTAT after: status: VSYNC_INT_STATUS VBLANK_INT_STATUS OREG_UPDATE_STATUS (WW) intel(0): Register 0x71024 (PIPEBSTAT) changed from 0x00000202 to 0x80000202 (WW) intel(0): PIPEBSTAT before: status: VSYNC_INT_STATUS VBLANK_INT_STATUS (WW) intel(0): PIPEBSTAT after: status: FIFO_UNDERRUN VSYNC_INT_STATUS VBLANK_INT_STATUS (WW) intel(0): DRI2 requires UXA (WW) intel(0): ESR is 0x00000001, instruction error (WW) intel(0): Existing errors found in hardware state. (In reply to comment #38) > I will post there. Rémi, should I add "remi@gentoo.org" to the Cc list or are > you going to do this yourself? I've added myself directly. Thanks. (In reply to comment #39) > Lastly, I tried to use EXA instead of UXA. Then I found the fps count growing a > bit unstable (floating between 180 - 270). Then I looked at dmesg: Please file another bug at FreeDesktop, this is beyond my current knowledge. To the rest of you, if you still have issues after rebuilding the packages in the correct order, please file bugs over at FreeDesktop too. There's little else I can do. Thanks |
