Re: [gentoo-user] ati -- dreaded "xf86-ENOMEM" error

[Holly Bostick]

OK, now I have some time to look at this in detail:

maxim wexler schreef:
>
> --- Ryan Sims <rwsims@×××××.com> wrote:
>
>
>>On 8/23/05, Mark Knecht <markknecht@×××××.com>
>>wrote:
>>
>>>Hi Maxim,
>>>   An AGP support issue probably. Which kernel are
>>
>>you using?

Mark, I think you're right:

>>
>>I found that running with a 2.6.12 kernel gave me
>>this error;
>>downgrading to 2.6.11 fixed it.  here's a relevant
>>forum topic:
>
>
> Actually, I *was* using 2.6.11. Now I've compiled the
> 2.6.12 and re-emerged ati-drivers-8.12.10(Why so
> out-dated, I just did a -uD world a few days ago?). It
> seems to work OK but it fails to produce fglrx.ko.
>
>  Checking for MTRR support enabled ...
> (we really don't need the color codes, so I'm deleting them)
>  Checking for AGP support enabled ...
>
> Checking for DRM support disabled ...
>
> X11 implementation is xorg-x11.

OK, so this is what I was saying in my other mail; the install script
checks for certain kernel options to be enabled or disabled. The three
options, as you can now see, are

MTRR support must be enabled

AGP support (/dev/agpgart) must be enabled (can be a module)

DRM must be disabled

So we got that far, then we get to this:

>>>>Source unpacked.
>
>  Building the DRM module...
> make: Entering directory
> `/usr/src/linux-2.6.12-gentoo-r6'
>   CC [M]
> /var/tmp/portage/ati-drivers-8.12.10/work/lib/modules/fglrx/build_mod/agp3.o
>   CC [M]
> /var/tmp/portage/ati-drivers-8.12.10/work/lib/modules/fglrx/build_mod/nvidia-agp.o
>   CC [M]
> /var/tmp/portage/ati-drivers-8.12.10/work/lib/modules/fglrx/build_mod/agpgart_be.o
> /var/tmp/portage/ati-drivers-8.12.10/work/lib/modules/fglrx/build_mod/agpgart_be.c:
> In function `agp_find_supported_device':
> /var/tmp/portage/ati-drivers-8.12.10/work/lib/modules/fglrx/build_mod/agpgart_be.c:7150:
> error: structure has no member named `slot_name'
> /var/tmp/portage/ati-drivers-8.12.10/work/lib/modules/fglrx/build_mod/agpgart_be.c:7170:
> error: structure has no member named `slot_name'
> /var/tmp/portage/ati-drivers-8.12.10/work/lib/modules/fglrx/build_mod/agpgart_be.c:7175:
> error: structure has no member named `slot_name'
> /var/tmp/portage/ati-drivers-8.12.10/work/lib/modules/fglrx/build_mod/agpgart_be.c:7201:
> error: structure has no member named `slot_name'
> /var/tmp/portage/ati-drivers-8.12.10/work/lib/modules/fglrx/build_mod/agpgart_be.c:7221:
> error: structure has no member named `slot_name'
> /var/tmp/portage/ati-drivers-8.12.10/work/lib/modules/fglrx/build_mod/agpgart_be.c:7241:
> error: structure has no member named `slot_name'
> /var/tmp/portage/ati-drivers-8.12.10/work/lib/modules/fglrx/build_mod/agpgart_be.c:7246:
> error: structure has no member named `slot_name'
> /var/tmp/portage/ati-drivers-8.12.10/work/lib/modules/fglrx/build_mod/agpgart_be.c:6542:
> warning: unused variable `cap_ptr'
> /var/tmp/portage/ati-drivers-8.12.10/work/lib/modules/fglrx/build_mod/agpgart_be.c:
> At top level:
> /var/tmp/portage/ati-drivers-8.12.10/work/lib/modules/fglrx/build_mod/agpgart_be.c:6523:
> warning: `agp_check_supported_device' defined but not
> used
> make[1]: ***
> [/var/tmp/portage/ati-drivers-8.12.10/work/lib/modules/fglrx/build_mod/agpgart_be.o]
> Error 1
> make: ***
> [_module_/var/tmp/portage/ati-drivers-8.12.10/work/lib/modules/fglrx/build_mod]
> Error 2
> make: Leaving directory
> `/usr/src/linux-2.6.12-gentoo-r6'
>  DRM module not built

Now, I would first think the most likely cause of this error is that the
drivers don't support 2.6.12, and that could possibly well be involved.

But the error is totally in agpgart, and I suspect that it is due to an
incomplete kernel configuration.

What motherboard do you have?

You see, agpgart often doesn't exist on its own in the kernel. Many
motherboard chipsets 'speak their own language' as it were, and while
the kernel can speak to them, it needs to be told 'who' it is speaking
to so that it knows how to be understood by the motherboard.

So if I enable /dev/agpgart in my kernel (as I must), I also have to
enable one of the options that becomes available when I enable
/dev/agpgart-- the kernel will not be able to communicate with my VIA
KT266 chipset motherboard, if I do not also enable the VIA chipset
support option, which will compile the via-agp module.

And if the kernel can't talk to my motherboard, the ati-driver can't
talk to the kernel and ask it what kind of card is connected to that AGP
slot (because the kernel doesn't know, because it can't communicate with
the motherboard).

In fact, I can't use the internal agpgart compiled by the fglrx drivers
(I have to set UseInternalAGPGART to 'no' in my xorg.conf), because the
kernel needs its own module to talk to my mobo's AGP slot (and if the
kernel can't talk to the AGP slot, then the drivers for the card in that
slot are SOL).

It's possible that you did not compile support for your motherboard's
AGP chipset into the kernel (I find it works best as a module, loaded
with /etc/modules.autoload.d, but it might be doable either way). It's
very possible you need such support as well, especially if your chipset
is one of the following (as you'll see, it covers a lot of very common
motherboard chipsets):



ALI chipset support

ATI chipset support (this refers to ATI motherboards, not video cards)


AMD Irongate, 761, and 762 chipset support

AMD Opteron/Athlon64 on-CPU GART support

Intel 440LX/BX/GX, I8xx and E7x05 chipset support

NVIDIA nForce/nForce2 chipset support

SiS chipset support

Serverworks LE/HE chipset support


Perhaps you didn't select it (a lot of people make that mistake), or
perhaps the module isn't loaded for it (the driver install does, I
believe, probe the AGP slot for information about the card, so there is
a problem if it can't communicate with the slot because the necessary
module to allow such communication is not loaded. There are a very few
kernel modules that will fail to compile if the hardware that uses the
driver is not present/available on the system. I've had new kernel
compiles fail for that reason-- I was trying to 'plan for the future'
and compile for hardware I didn't have yet. The kernel wouldn't have it,
and I had to disable the modules until such time as I got the hardware,
if I ever did. Interestingly, this occurred with attempting to add
modules for TV cards, when I was thinking about getting one. Interesting
because it seems to be 'a video thing' where this tends to happen).
>
>
> But what's the best way to proceed? emerge seems happy
> with the older(?) drivers. Shouldn't it be attempting
> a download from somewhere, seeing as how I just did an
> emerge sync and emerge -uD world a few days ago(that's
> how I came by this 2.6.12 kernel)?


Have you possibly masked more recent versions of the driver? 8.12.10
isn't even the most recent stable:

eix ati-drivers
* media-video/ati-drivers
     Available versions:  8.8.25-r3 8.10.19 8.12.10 [M]8.13.3 [M]8.13.4
8.14.13 8.14.13-r1 8.14.13-r2 [M]8.14.13-r3 8.16.20
     Installed:           8.16.20


(yeah, I unmasked 8.16.20 again, to try an experiment. My hunch was
right; and they seem to be working. But that's another story; ask me if
you want to know what the trick was).

Anyway, you should at least be able to get 8.14.13-r2 (stable for x86
and amd64). So if all Portage will offer is 8.12.10, I would suspect
that it's because you told Portage not to offer you anything beyond
that. Check /etc/portage/package.mask.

I would recommend upgrading to 8.14.13, because it is patched to compile
against 2.6.12 kernels, and that patch actually works well now (the
driver was released with support only for 2.6.11 kernels, and the patch
for 2.6.12 was.... rough.... at the start, but it did get itself
together, and that's the patch used in 8.14.13-r2 (I speak from
experience :) ).

Anyway, hope this helps; the drivers are not good, exactly, but they're
better than this (have been since around 8.12.10, actually; that's when
I stopped having issues with installing them, though strictly speaking I
never really had issues with installing them under Gentoo, unlike SuSE
or Mandrake or Ubuntu. But then again, I've been installing these
drivers since 3.2.8 on various distributions; I know a lot more about
how my system needs to be configured to effectively interact with them
than a new user might).

'Course, that still doesn't get me textures in KotOR, but it ain't
because the drivers don't run ;) .

Holly
-- 
gentoo-user@g.o mailing list