I posted this under Hardware, because it is in connection with getting an ATI Radeon Mobility M6 adapter which is giving me endless hours of excitment to work.

These questions are the offspring of the following: http://www.linuxquestions.org/questi...threadid=37554

I wrote to someone at XFree who directed me to someone at DRI who said I needed to "remove the GATOS drivers" and "Compile the DRM kernel"

I know nothing about compiling a drm kernel and can not find a step by step guide anywhere. I also know nothing about programming and kernel compilation have no idea how to remove the gatos drivers.

Can anyone help me, it has almost been a month that I am battling with this thing? Unfortunately I am a particularly busy individual at the moment and do not have time to learn about compiling the Linux kernel and rubbing out my "newbie" status. What I need now is a quick fix so I can worry about the higher grade stuff later.

You might not need to compile DRM right into the kernel... its probably a module you can load before starting X. As root:

init 3
/sbin/modprobe radeon
init 5

And see if GL works at that point. If it doesn't try:

/sbin/lsmod

and see if radeon is listed as "unused"

Cheers,

Finegan

Ok, I did all that. GL does work after the first step (with the regular problem, of course).

However, if I lsmod there is nothing next to Radeon. It doesn't say unused or nuttin'

I honestly don't know what I'd do without your help at this stage, you are the first person I have spoken to thus far who has any clue how to tackle this prob! Thank you.

Interestingly enough, the message is now sometimes: drmRadeonClear: return = -16 instead of the whole SwapBuffers thingy....

I'm no expert [...especially with laptops] but here's what I'd try

Comment out "Load v4l" [...in your XF86Config-4] unless you really need it. [I've read about issues with that].

And if that don't solve anything I'd try the latest stable snapshot of the radeon driver @
http://dri.sourceforge.net/snapshots...x.i386.tar.bz2
or for something newer [...as in bleeding-edge, with all it implies] @
http://dri.sourceforge.net/snapshots/bleeding-edge/ ...pick the latest

Those will update your drm kernel module too [...provided it's compiled as a module into your kernel]

You can also search the dri-devel mailing list archives for your m6, I've seen numerous references to it in the past ...
http://sourceforge.net/mailarchive/f...?forum_id=7177

...if you haven't already
HTH

I already tried dropping v4l with no result.

I did install the latest stuff from DRI - which screwed up X so bad that I had to re-install (got a lovely black screen which alteranted with a login prompt on a secondly basis).

So I wrote to DRI and they said "remove the Gatos drivers and make sure you explicitly compile the drm kernel."

Sources don't get more reliable than that.
People who can tell you how to do these things, though...

I have asked this a few times, no one has responded, but I need to know: COULD THIS BE A HARDWARE PROBLEM?!?

No, its not bad hardware, or at least I'm willing to bet not... it makes sense now why this isn't seen too much. Okay, the GATOS drivers are an extension added into the normal XFree tree for ATI cards by this seperate group. That's why I hadn't seen it too often as this seems to be added by only a few distros... and is exactly the sort of thing Mandrake likes to do.

This looks like a mess to try and rip free.

I'll check back after I figure out more about Gatos.

Cheers,

Finegan

Ok, then just give me an address to send the beer to. I'm serious, if this works, I'll send a bunch a good-time girls to go with it.

Plonk.

No matter what it looks like you're going to have to do a complete kernel recompile to try and get DRM in there unpatched...

To do this properly check out the kernel compiling how-to over at linuxdoc's www.linuxdoc.org

For decent GL you're going to need to remember to compile in MTRR support, that's near the top, also enable Incomplete or experimental code, that's the first level option on a make menuconfig, remember to enable vesa framebuffering under console devices... then instead of leaving agpgart and radeon as modules, compile them directly into the bizitch. This may all seem like greek right now, but don't worry, it'll make sense.

A couple of things they don't warn you about when you compile a new kernel about the default aspects of the .config file:

1. its set for optimized P3, if you've got better, optimize for better...
2. its set for SMP, go Uni if you only have 1 chip.
3. DOS is not default checked under the FS support, you'll need that if you've got a floppy drive :-P
4. the cooler fs like reiser and ext3 aren't checked by default either, you'll want to compile those in or the kernel will panic because it doesn't even know how to mount the root filesystem on start.

That's about it for now... if you get bogged down I can send you an alright .config to start with. Its more fun then it seems, trust me, when I got bored of looking at Gatos goop (I've got a Rage 128 on a shelf so I was self-motivated somewhat thinking I may put that back in a machine one day), I went and compiled a few options into my kernel and saw my fps launch from 350 to 543... well, after I fixed an error in my XF86Config file too.

Cheers,

Finegan

Well, I was planning to become a "serious" Linux user... just not quite yet.

*gulp*

Ok, so off I go to compile my first kernel ever (can you believe I opted NOT to do Computer Science at School *sigh* even knowledge of Pascal would be better then what I have now).

In a way this is a good thing. cus I wanted to try out Gentoo but was to chicken s**t to commit.

So I'll be back with the results... (3 years, 4 years? who knows....)

Thanks for all the help until now =D

The first time I got a kernel to compile correctly was about my 20th attempt, my big mistake up until then: using the source that came with the distros... pristine kernel source from kernel.org is the only way.

Don't worry, might take a few tries.

Cheers,

Finegan

Well, I must be very lucky because my first kernel compiled without a problem and booted.

I then tried loading the latest DRI snapshot and, once again, it f**ked up X.

When I try to start X after installing DRI, it says it cannot load the radeon module and crashes out. As far as I can tell, I setup the radeon part of the kernel correctly (still crashed glxgears with the same error when rendering directly, though). Should I be re-installing XFree after my new kernel compile?

I also still do not get this Gatos problem. When I did my new kernel I didn't see any reference to it. I also made the kernel very streamlined.

I suppose my next step is to get the latest source from kernel.org (as you suggested). This shouldn't muck up Mandrake at all (I know they sometimes have their own way of doing things)?

I'm just glad this whole kernel compile went well, I still need to get up to speed with optimization though.

Right, Mandrake will run fine under a stock kernel. 2.4.20 has some agp fixes in it over the 2.4.19 prerelease they shipped with.

Cheers,

Finegan

Did the snapshot install w/o errors?
Which one exactly did you use?
I just remembered that, with XFree getting closer to the 4.3.0 release, module compatibility with 4.2.x is broken.
IIANM the pkg from the 1st link is the last one before the break, so anything after that [...bleeding-edge/ folder @ dri] should require that you rebuild X from cvs to make it work.
Even that last one [...20020920] may require the libxaa.a, found in the extra/ folder on the dri d/l page [see README.libxaa]
Even if X crashes before it completely loads, it still writes to /var/log/XFree86.0.log, if the problem is with libxaa, you may see it there.

Also I realize I phrased something in a very confusing manner when I implied the drm needs to be "as a module inside the kernel", it's obviously one *or* the other .
Unless Finegan has very good reason to make you compile it *into the kernel*, I would suggest you build it as a *module* ...if you want to update it with the dri snapshot. ...as in, you need it to be a module if you want to update the module.
The snapshot's install.sh script will build a new
/lib/modules/2.4.20/kernel/drivers/char/drm/radeon.o and automatically backup the existing one to dri-old.radeon.o

I noticed, from your XF86Config [...and your .0.log] you should change your "AGPMode "true" to an integer 1,2 or 4. Mine's "AGPMode "2" since 4 is not stable with my chipset ...but that shouldn't be what's causing you problems.

Again, sorry for the confusion

Ok, to keep this thread relevent:

I am starting to think that the problem is most definately the patching of the DRM module. I am going to try once again to recompile with clean kernel source to see if that leaves DRM un-patched.

Should that fail, I will then switch to Gentoo to insure a clean module for DRM (and take up the rest of my holidays ).

I am also taking care to use the last stable snapshot of DRI (10 October, I think).

POI: When I install the DRI, it says something about GLU GL can't find the directory or something, but it is definately not reported as an error. I have both libraries installed, so I'm assuming this is not a problem? Reading that back to myself, it looks like a dumb question. Clarity: It compiles and updates the module without any errors, but I notice that line.

Ok - I have managed to get the package from DRI installed and the DRM module compiled and X running.

The problem: X is screwed! Pixels shifting, freezing. Only works if I disable direct rendering.

I loaded windows just to run analysis programs and there are no problems there.

So I guess I have to sit and wait until DRI release drivers supporting this chipset. I will write to them and request it.

What is freaking me out though is that these cards are in a hell of a lot of laptops. Why am I the only one having this problem? I have pretty much concluded convincingly that this card is not yet supported under Linux with Direct Rendering (works fine without DR). Or is it this specific laptop's configuration of the card?