| Summary: | x11-base/x11-drm-20060608 failed with >= kernel-2.6.20 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Pedroleouf <pedroleouf> |
| Component: | New packages | Assignee: | Bryan Stine (RETIRED) <battousai> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | baby.lueshi, belgix_oz, cbm, chrschmitt, david.morgan, email, eskobar.esko, jaak, markir, matrixhax0r, mdoughty, mmokrejs, portage, quiltro, quintasan.gentoobugs, reddrik, roberto.castagnola, sgala, torsten, x11-drivers |
| Priority: | High | ||
| Version: | 2006.1 | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 163825 | ||
| Attachments: | Kernel Patch | ||
|
Description
Pedroleouf
2007-02-06 02:59:31 UTC
Same Problem on both of my computers, also, can we bump the version? there seems to be a new version, there seems to have been from 2.1 to 2.3 versions since June, when this version was built. thx I am also getting the same result using gentoo-2.6.20 sources. (In reply to comment #2) > I am also getting the same result using gentoo-2.6.20 sources. > Same problem here. I've fixed this using a git snapshot of drm. greets but this works OK on 2.6.19? the summary field indicates otherwise (In reply to comment #4) > but this works OK on 2.6.19? the summary field indicates otherwise > Yes, this was working for me on 2.16.19, someone changes the summary, but it was working on 2.16.19[-r{2,3,4,5}]. Worked for me on 2.6.19-r3 and it isn't working on 2.6.20 Hello: This is not the solution how to solve the problem to install x11-drm-20060608 on 2.6.20 kernel. But reading from the kernel change log, during 2.6.20-rc1, there are new drm patches merged into the kernel. (http://www2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9b3a89f8b052f2a6193a9691e053f986144a65a0) And I am sure they are newer and better then x11-drm 20060608. Also reading for x11-drm from freedesktop.org, (http://gitweb.freedesktop.org/?p=mesa/drm.git;a=summary), it seems they dont make any more drm packages and instead they maintain them within the main kernel tree. I have install the libdrm 2.3.0, and it does not make the drm kernel module. If I pull the git codes from their git tree, often it just lock up my machine. So maybe we could try the drm module from the kernel 2.6.20, (which I am using now without any problems or performance regressions.) I hope those information could make some points. (In reply to comment #7) > And I am sure they are newer and better then x11-drm 20060608. I have a big problem with this statement. Since kernel 2.6.19 and/or Xorg 7.1, direct rendering is simply not working with S3 Savage cards without x11-drm. Prior to this versions, I ran with modules built in the kernel w/o any problem. > Also reading for x11-drm from freedesktop.org, it seems they dont > make any more drm packages and instead they maintain them within the main > kernel tree. I have install the libdrm 2.3.0, and it does not make the drm > kernel module. If I pull the git codes from their git tree, often it just lock > up my machine. I should tell wake up (Linus & Xorg) guys. I don't exacly remember why X11 is reverting to (slow) indirect rendering when I start glxgears but it look like an imcompatibility coming from an recent API change in kernel and/or Xorg packages. > > So maybe we could try the drm module from the kernel 2.6.20, (which I am using > now without any problems or performance regressions.) I hope those information > could make some points. > I will more than happy to remove x11-drm package from my computer but now I stuck with with kernel 2.6.19.2 & x11-drm-20060808 to get direct rendering working on my laptop. The package compile and seems to work fine with vanilla-sources-2.6.20 when I remove offending line 51 in /drm/linux-core/drm_stub.c of x11-drm sources. // module_param_named(debug, drm_debug, int, S_IRUGO|S_IWUGO); Hope my help !!! I tried building the drm within the kernel as a module, and just ignored the x11-drm package all together. After rebuilding the kernel and booting into it, I was surprised to see that my little Radeon IGP 320M was able to run with DRI enabled, AND have the Composite extension enabled. This was previously not possible when using the x11-drm package on the 2.6.19-r5 gentoo-sources kernel. I confirmed that DRI was infact running with "glxinfo | grep rendering", with the output being "Direct rendering: yes". Using "xdpyinfo | grep -i composite", it showed that the Composite extension was indeed installed and running. I was able to use the built-in composite effects of the new XFCE4-4.4 desktop environment under these conditions. As I said, this was not possible when using the x11-drm package on the older kernels. It was either use DRI, or use the Composite extensions. I did nothing special to the setup with using the built-in kernel modules for drm and radeon. Perhaps the version in the kernel is newer, and should be used instead of the x11-drm packages. Just my thoughts. I will continue running the built-in kernel modules for the moment, as they appear to be the better choice as far as support for now. (In reply to comment #10) > > Just my thoughts. I will continue running the built-in kernel modules for the > moment, as they appear to be the better choice as far as support for now. > It was the way it was working (with DRI enabled) for S3 Savage cards for at least kernels 2.6.{16,17 and unsure for 18}. I performed a lot of tests this arvo and my patched package x11-drm-20060808 runs perfectly with 2.6.20. As far as I can tell, the kernel is using libdrm-2.1.0, which is much older than the current 2.3.0. The in-kernel trees seem to get a bit of driver-love from the maintainers, but not as much as we'd get if there were a current ebuild based on the latest sources (available at: http://dri.freedesktop.org/wiki/Download ). I opened a bug to bump up to the latest version several weeks ago, but it's getting no traction. This is a VERY important package to anyone who uses open-source-only drivers for their Radeon cards (since r300 support landed AFTER 2.1.0), and anyone who has an Intel integrated graphics chipset like the i945 or i965. Kernel 2.6.19 broke a lot of out-of-kernel modules (including x11-drm), but the fix for that seemed to be more of a workaround than bumping the x11-drm sources to a more current version. I think this is the wake-up call that the real path forward might be to track the DRM sources instead of continually hacking an old release to work on new kernels. I have a brandy-new Intel GMA3000 graphics chipset and here's my dmesg output for DRM while using in-kernel modules from 2.6.20: [drm] Initialized drm 1.1.0 20060810 [drm] Initialized i915 1.6.0 20060119 on minor 0 So it's pretty clear that the kernel is NOT maintaining the latest-and-greatest DRM modules. I've got another problem in the place. Error:The ‘type name’ array size is negative. /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_stub.c:51: Error: размер массива ‘type name’ отрицательный make[2]: *** [/var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_stub.o] Ошибка 1 make[1]: *** [_module_/var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.20-gentoo(In reply to comment #0) > Just finished compilation of the new 2.16.20 kernel without including hard or > video related new features, and after running > # module-rebuild -X rebuild > the x11-drm package fails to emerge > > > Reproducible: Always > > Steps to Reproduce: > 1.emerge --sync && emerge -u gentoo-sources > 2.configure kernel with default values for new features after copying .config > (from a 2.16.19-r5 for me) > 3.emerge x11-drm (or module-rebuild -X rebuild) > Actual Results: > ... > + ln -s ../shared-core/savage_bci.c savage_bci.c > + ln -s ../shared-core/savage_state.c savage_state.c > + ln -s ../shared-core/nv_drv.h nv_drv.h > sh ../scripts/create_linux_pci_lists.sh < ../shared-core/drm_pciids.txt > rm -f linux > ln -s . linux > make -C /usr/src/linux SUBDIRS=`pwd` DRMSRCDIR=`pwd` modules > make[1]: entrant dans le répertoire « /usr/src/linux-2.6.20-gentoo » > CC [M] > /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_auth.o > CC [M] > /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_bufs.o > CC [M] > /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_context.o > CC [M] > /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_dma.o > CC [M] > /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_drawable.o > CC [M] > /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_drv.o > /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_drv.c: In > function ‘drm_init’: > /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_drv.c:304: > attention : ignoring return value of ‘pci_register_driver’, declared with > attribute warn_unused_result > CC [M] > /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_fops.o > /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_fops.c: In > function ‘drm_stub_open’: > /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_fops.c:189: > attention : assignment discards qualifiers from pointer target type > CC [M] > /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_ioctl.o > CC [M] > /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_irq.o > /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_irq.c: In > function ‘drm_irq_install’: > /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_irq.c:135: > attention : passing argument 2 of ‘request_irq’ from incompatible pointer > type > CC [M] > /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_lock.o > CC [M] > /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_memory.o > CC [M] > /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_proc.o > CC [M] > /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_stub.o > /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_stub.c:51: > erreur: size of array ‘type name’ is negative > /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_stub.c: In > function ‘drm_get_dev’: > /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_stub.c:216: > attention : ignoring return value of ‘pci_request_regions’, declared with > attribute warn_unused_result > /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_stub.c:219: > attention : ignoring return value of ‘pci_enable_device’, declared with > attribute warn_unused_result > make[2]: *** > [/var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_stub.o] > Erreur 1 > make[1]: *** > [_module_/var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core] Erreur > 2 > make[1]: quittant le répertoire « /usr/src/linux-2.6.20-gentoo » > make: *** [modules] Erreur 2 > * Portage could not build the DRM modules. If you see an ACCESS DENIED error, > * this could mean that you were using an unsupported kernel build system. All > * 2.4 kernels are supported, but only 2.6 kernels at least as new as 2.6.6 > * are supported. > > !!! ERROR: x11-base/x11-drm-20060608 failed. > Call stack: > ebuild.sh, line 1613: Called dyn_compile > ebuild.sh, line 970: Called qa_call 'src_compile' > environment, line 4124: Called src_compile > x11-drm-20060608.ebuild, line 111: Called die_error > x11-drm-20060608.ebuild, line 235: Called die > I have same problem :( CC [M] /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_stub.o /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_stub.c:51: error: size of array ‘type name’ is negative make[2]: *** [/var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_stub.o] Error 1 make[1]: *** [_module_/var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.20-gentoo-r1' make: *** [modules] Error 2 Give the tree a little while to propagate and the new 20070314 snapshot will be rockin your casbah. It works for me with 2.6.19 and 2.6.20. This new snapshot no longer has kernel 2.4 support, but I doubt anyone on this bug cares about that. ;) Additionally, the nouveau module is now installed alongside nv. You can choose whichever one you want to load, but I'm betting most people are interested in nouveau. Last but not least, my apologies for taking so long. Actually, I'll leave this open for keywording. (In reply to comment #15) > Give the tree a little while to propagate and the new 20070314 snapshot will be > rockin your casbah. Thank You 2.03x10^23 times! the new 20070314 snapshot does not work with gentoo-sources-2.6.20-r*, as it requires MINOR 102: sr/src/linux-2.6.20-gentoo-r3/drivers/char/agp/backend.c:#define AGPGART_VERSION_MINOR 101 it works, tough, with mm-sources, which offer their own set of problems here (freezing on suspend/hibernate, etc.) I'll try to get the agp patch isolated, and propose if for inclusion in gentoo-sources-2.6.20*. I wonder if it is in 21_pre... gentoo-sources-2.6.20-r3 plus the relevant parts (char/agp* + include/agp*) of mm-sources-2.6.20-r2 crashes X every so and so with: [drm:drm_fence_lazy_wait] *ERROR* Fence timeout. GPU lockup or fence driver was taken down. This happens with composite manager (beryl) and aiglx, does not happen with plain metacity unless glx apps stress it. mm-sources-2.6.20-r2 works with x11-drm, but has problems with suspend/hibernate here (freezes half way). So I'll stay clear of x11-drm-20070314 until a working kernel can take it Pity, because it is way faster than kernel one with intel i915. Update: updating xorg-server to 1.2.99.902 + xf86-video-i810 to 1.9.92 makes it work again, and fairly well. I "backported" enough agp changes from mm-sources to make it compile, and I'm yet to see the error since I upgrades the three things. (In reply to comment #18) > the new 20070314 snapshot does not work with gentoo-sources-2.6.20-r*, as it > requires MINOR 102: Santiago, just for clarity, can you post the full error message here? Bryan's earlier comments seem to indicate that it works against 2.6.20... The requirement for 102 seemed not be coming from x11-drm, but from a combination of it with the i810 driver and xorg-server. As I said, bumping both xorg-server to 1.9.99.902 (and the driver to 1.9.92) dropped the requirement of MINOR==102. I am able now to run those versions using x11-drm with stock 2.6.20-r4 (which has 101 minor version) with no problem. I guess having 102 will enable the texture based i915tex driver again, but for the moment this version is stable and performant enough for me to wait, again with a working modesetting (able to project external video for my classes) :) So: any MINOR version problem will come through the xorg-server/driver requirements, not directly because of x11-drm/kernel interaction. In any case, we have kernels (gentoo-sources) using #define AGPGART_VERSION_MINOR 101 and 102 (gentoo-sources/mm-srouces), and drivers that complain that they need 101 Created attachment 115652 [details, diff]
Kernel Patch
This seems to fix the problem for me.
I can confirm this bug. Another possible solution is adding "x11-base/x11-drm ~x86" to package.keywords (which will emerge a more recent version of x11-drm) and emerging this package again solves the problem. So, if this package doesn't compile with a stable-marked kernel, we should mark a newer version of it as stable. Any objections? Or should we use the (old) kernel DRM? (In reply to comment #25) Just FYI, DRM stuff has been updated in kernel 2.6.22 (at least for vanilla sources). For S3 Savage cards, hardware accelerations are working again w/o this package. (In reply to comment #26) That's great news. I'm currently running 2.6.21. Maybe I will stop using the extra x11-drm package. *** Bug 180404 has been marked as a duplicate of this bug. *** I've bumped into this with r128. Currently glxinfo reports direct rendering =no kernel version is 2.6.21-gentoo-r4 running stable everything and recieving the negative array errror posted above xorg.conf has the dri Section as posted in the ati faq Question: is x11-drm required for direct rendering now? or is it supplied by the kernel? The status is vague for the current gentoo-sources. Thanks PBKBAC kernel config direct rendering now works and x11-drm was not needed What is the status of the gatos drivers? Are they also merged into xorg-current? Documentation needs to be updated The severity of this bug should be bumped up to "Major" as it affects a stable kernel (2.6.21-gentoo-r4) with a stable x11-drm (20060608). i can confirm this bug happens for me. i have gentoo-sources 2.6.21-r4 and x11-drm do not compile with 20060608. my card is i810. please fix. Same here: CC [M] /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_stub.o /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_stub.c:51: error: size of array `type name' is negative make[2]: *** [/var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_stub.o] Error 1 make[1]: *** [_module_/var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.22.6' Anyway, why there is no update for this package when current stable kernel on x86 is sys-kernel/gentoo-sources-2.6.24-r7 ? (In reply to comment #24) > I can confirm this bug. Another possible solution is adding "x11-base/x11-drm > ~x86" to package.keywords (which will emerge a more recent version of x11-drm) > and emerging this package again solves the problem. > It doesn't work for me with 2.6.24-r4. Simone, I have x11-base/x11-drm-20071019 on my 2.6.24.7-based system (~x86). Try to install it. I have the same problem on AMD64 ... can somebody change the "Hardware" flag? make[1]: Entering directory `/usr/src/linux-2.6.25-gentoo-r6' CC [M] /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_auth.o CC [M] /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_bufs.o CC [M] /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_context.o CC [M] /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_dma.o CC [M] /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_drawable.o CC [M] /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_drv.o /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_drv.c: In function ‘drm_init’: /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_drv.c:304: warning: ignoring return value of ‘pci_register_driver’, declared with attribute warn_unused_result CC [M] /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_fops.o /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_fops.c: In function ‘drm_stub_open’: /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_fops.c:189: warning: assignment discards qualifiers from pointer target type CC [M] /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_ioctl.o CC [M] /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_irq.o /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_irq.c: In function ‘drm_irq_install’: /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_irq.c:132: error: ‘SA_SHIRQ’ undeclared (first use in this function) /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_irq.c:132: error: (Each undeclared identifier is reported only once /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_irq.c:132: error: for each function it appears in.) /var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_irq.c:135: warning: passing argument 2 of ‘request_irq’ from incompatible pointer type make[2]: *** [/var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core/drm_irq.o] Error 1 make[1]: *** [_module_/var/tmp/portage/x11-base/x11-drm-20060608/work/drm/linux-core] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.25-gentoo-r6' make: *** [modules] Error 2 * Portage could not build the DRM modules. If you see an ACCESS DENIED error, * this could mean that you were using an unsupported kernel build system. All * 2.4 kernels are supported, but only 2.6 kernels at least as new as 2.6.6 * are supported. ... and the newer version does not compile too, see bug #218419 :-( All set with patchball 0.4. It now builds against latest stable. |
