Re: ati X300 support?

[Martin Drab <drab@kepler.fjfi.cvut.cz>]

On Tue, 27 Dec 2005, Gerhard Mack wrote:

> On Wed, 28 Dec 2005, Martin Drab wrote:
> 
> > Date: Wed, 28 Dec 2005 01:20:42 +0100 (CET)
> > From: Martin Drab <drab@kepler.fjfi.cvut.cz>
> > To: Gerhard Mack <gmack@innerfire.net>
> > Cc: Alistair John Strachan <s0348365@sms.ed.ac.uk>,
> >     linux-kernel@vger.kernel.org
> > Subject: Re: ati X300 support?
> > 
> > On Tue, 27 Dec 2005, Gerhard Mack wrote:
> > 
> > > I have it working in X.org with no problem.  I just can't get the drm
> > > module working in the kernel.  Last time I tried to just add my PCI ids 
> > > the problem was a lack of PCIE support in the drm drivers. 
> > > 
> > > FYI the fglrx drivers suck badly.  ATI hasn't bothered to keep their 
> > > drivers up to date at all and the result is that they finally have  
> > > working 2.6.14 drivers but only for 32 bit machines.  x86_64 is still 
> > > broken on any recent kernel and it's been that way for months.  ATI's tech 
> > > support basically gave up after several days and just informed me it 
> > > wasn't really supported and there is nothing they could do for me.
> > 
> > I don't want to defend ATI here or anything, but I use the 64-bit fglrx 
> > 8.19.10 with 2.6.15-rc5 and it works (except for the minor patch for 
> > 2.6.15-rc2-git3 and later that we came out with with Hugh Dickins and that 
> > was sent to the list not long ago).
...
> Where is this patch? does it re add the obsolete interfaces dropped by the 
> kernel?  On my system it won't even compile.

Here:

------------------------------------------------------------------------------------
diff -Napur fglrx64.orig/build_mod/firegl_public.c fglrx64/build_mod/firegl_public.c
--- fglrx64.orig/build_mod/firegl_public.c      2005-11-14 02:35:45.000000000 +0100
+++ fglrx64/build_mod/firegl_public.c   2005-12-08 01:25:27.000000000 +0100
@@ -2586,7 +2586,7 @@ static __inline__ vm_nopage_ret_t do_vm_

     pMmPage = virt_to_page(kaddr);

-#if 0
+#if LINUX_VERSION_CODE >= 0x02060f
     // WARNING WARNINIG WARNNING WARNNING WARNNING WARNNING WARNNING WARNNING
     // Don't increment page usage count, cause ctx pages are allocated
     // with drm_alloc_pages, which marks all pages as reserved. Reserved
-------------------------------------------------------------------------------------

And no, this one doesn't add the missing interfaces, but the attached 
ones do.

I'm resending what I sent to Hugh. The above patch (which is the one I 
was talking about) is not included there, so you need to apply afterwards. 
Also it's made for the fglrx 8.19.20. I haven't had time to experiment 
with 8.20.8, yet.

---

The script that extracts the kernel module sources and the user space 
binaries is attached in the fglrx64-assemble_scripts.tar.bz2 archive. Just 
copy the 64-bit ATI Driver Installer from the link above to the
fglrx64-assemble_scripts directory and run the "assemble" script. It will
extract the kernel module sources into the 
"./fglrx-8.19.10-x86_64-kernel-module" directory and the user space
binaries into the "./fglrx-8.19.10-x86_64-userspace" directory.

The kernel module sources while extracted are also patched by the three
patches that I've placed into the "patched" subdirectory.

The first patch is necessary in order to compile the 64-bit fglrx cleanly
using the GCC 4.x. There's nothing intrusive, as you can see for
yourself. It also adds the script "c" and "b" to its top directory. Using
"c" you compile the module (resulting "fglrx.ko" should be created in the
"build_mod/2.6.x" subdirectory). Using the "b" script you do the cleanup
(kind of a "make mrproper" equivalent). (Simple and easy, just what I
like! :)

The second patch fixes the ATI's wrong SMP detection in their compilation
script "make.sh" (which is called by my "c" script). They are using lots
of different approaches to try to detect an SMP kernel, which I guess is
pointless, wrong, and not working (it detects my UP notebook with
old single core Athlon64 3000+ that is using a UP configured kernel as an
SMP ;). I think the only reliable way to detect an SMP kernel is to look
at its linux/autoconf.h and search for the "#define CONFIG_SMP" (right? -
the kernel sources have to be present for the compilation anyway, so why
all the other fuss?). So the patch removes all the other approaches from
the script and only does this. It's only influence is on either generating
or not generating the SMP=1 macro on the gcc command-line. So you may
safely ignore it with respect to the bug.

The third patch also influences the gcc command-line generated by the
"make.sh" script. It defines the PAGE_ATTR_FIX as 1 if it is undefined. I
kind of don't know what exactly is this good for. It seems to fix some
AMD AthlonXP page attributes releated bug. By default the value is not
defined anywhere, and gcc preprocessor is unable to handle it due to the
incomplete condition (in)equations. So I set it to 1. If you look at the
sources, it is not used on x86_64 anyway.

I hope it helps,
Martin

Attachment: fglrx64-assemble_scripts.tar.bz2
Description: Scripts for extracting files out of ATI Driver Installer