Yes, I'm still having problems installing the ATI drivers on my system. I am going to light a bloody bonfire and dance naked (apart from the war paint) around it if I ever get this working. (You DON'T have to be there :))

I've decided to start from the beginning and keep it simple. This is the first thing I need to get sorted. WHY am I getting this message?

Rav, you're the one with a recent SIS chipset, right?
Is it agp v3.0 [...agp 8x] compliant?

If so, look here for a patch that could fix your problem.
It's been written by a kt400 owner but it brings agp v3.0 compliance to the fglrx agpgart module and could probably work in your case too.
Definitely worth a try if all else failed.

Rav

05-17-2003 02:40 PM

Quote:

Rav, you're the one with a recent SIS chipset, right? Is it agp v3.0 [...agp 8x] compliant?

That's me :) I have a GA-8SQ800 Ultra mobo. The board uses the latest SiS chipset, the SiS655, which is an AGPx8 chipset.

Thanks for the link Untamed, but the page says the patch is for XFree86 4.2.0 which does me no good with Slack 9.0 (unless it's worth trying anyway). This does however sound like something I am going to have to investigate further.

I'm still wondering about the lib tree message though because I've successfully built the drivers before. Strangely enough the last time I got stuck here with this lib tree message (with a custom kernel) I decided to try rebooting using the default slack kernel and it suddenly worked. Now with the default slack kernel on a fresh install I am stuck again. All the files are in the right place. I've checked that so many times it's a little ridiculous.

Damn this. Maybe I'm just going to have to wait a little while for new and official ATI drivers that support my chipset properly if it is indeed an AGP issue.

UnTamed

05-17-2003 03:46 PM

IIANM, it patches the fglrx agpgart with kt400 code for the kernel-devel branch [...2.5.59 to be exact] which support agp v3.0.
The patch may very well apply without error on the fglrx agpgart for XFree-4.3.0, but again will it work on a SIS??? ...guess you'll have to try it to find out, worst that should happen is the patch will not apply cleanly, just backup /lib/modules/fglrx before you try and revert if it returns errors.

Your SIS chipset probably has better support through the 2.5.x kernel but the driver won't compile on that, the modules are dealt with differently in 2.5.x, so Ati will have to write specific drivers for that to work.

As far as the /lib error goes and from what you say you experienced with different kernels on different occasion, just a wild guess;
When you boot with a particular kernel and then try to compile something, do you make sure your /usr/src/linux symlink points to the right sources tree?

Rav

05-21-2003 10:05 AM

Round 3

Ok, I obviously missed something. Either that or Slack is just acting up. I copied all the driver files to the right location, again, overwriting everything that was already there. I paid attention and I really hadn't missed anything the first time. Nevertheless I had a quick go and using the Terminal Emulator in Konqueror to build the module and low and behold, it bloody worked. There is still something fishy going on here. Maybe it's just me, but I'm innocent I tell you! Oh, and the module installed too. Beautiful :)

I've been doing some more reading Untamed and it seems that there is an alternative to the patch you've mentioned so I've decided to give it a shot first. That alternative comes in the form of the built in agp support in the fglrx module. ATI suggest you use this is if "your distribution's kernel setup does not provide agpgart compatible services". That is not strictly true in my case however ATI presents the option as a default during the fglrxconfig process anyway. Basically you are asked if you want to use an external agpgart module instead of the internal one. This time I chose the option of using the internal functionality and disabled the external agpgart module. In this situation [when no agpgart module is loaded] "the FireGL built-in agpgart module will be used."

If Linux was more intuitive to me than it is at this stage this would have made sense to me at an earlier time :)

So, I've made progress and that makes me happy :) The fglrx module is built, installed and loaded, I've created the all important ATI friendly XFree86 config file via fglrxconfig and all that is left to do is startx.

As you can see I have made some important progress, but no cigar yet. Please help me win!

terminator

05-21-2003 09:24 PM

you may need to reconfig your kernel and rebuild it. when config kernel, go to "character devices", enable AGP and DRM for ATI.

Rav

05-22-2003 03:34 AM

I've actually tried that before. The drivers build and install fine (with the exception of a problem I had once, but didn't have the next time I tried) using a custom kernel. However I don't get any further that way. But I've realized (through the help of people here and some things I have read) that my problem is that the agpgart module doesn't properly support AGP8x chipsets. So I have 2 options. Apply a patch that someone developed for the KT400 chipset or follow ATI's suggestion and use the agpgart module that is included with thier drivers (this module apparantly supports AGPx8).

What I'm hoping to do is find out what causes the error message above. A few possibilities even so I've got something to go on.

DRM is enabled (you can see from the log) and agpgart is built as a module but NOT loaded for the reasons stated above. I don't expect everyone to read the ATI documentation just for me but if you want to verify what I'm saying it's all in there.

jailbait

05-22-2003 02:14 PM

SiS 655

Linux 2.4.21rc2-ac3 contains updated support for SiS IDE for 655/630 SET

Thanks jailbait, that definitely sounds promising, although it only mentions IDE updates. Nothing about AGP. I might give it a shot if all else fails.

I'd really rather try and bat this out. I've spent a few weeks so far learning to be patient and resilient because although I've been using Linux since Redhat 5.2, I've learned bugger all about it really. Windows is intuitive to me no matter how serious or difficult a problem might me. Linux isn't, but I'm learning. What I do know is that there has to be a way to fix this. If I upgrade the kernel and everything just works I haven't learned anything. However, if an upgrade is the only way I'm going to get a fully working system anytime soon I'll obviously do it.

Rav

05-22-2003 05:52 PM

Ok, a new development. I was messing around in my mobos BIOS when something occured to me. I had set the AGP to 4x. I changed it to Auto instead (which means it's running at 8x now. I checked.) I should have tried this earlier it's just that it was counter-intuitive since 4x is a more stable setting. I guess the drivers are expecting to find an AGP8x chipset running at AGP 8x :)

I don't understand this. X complains that there is no matching device section for BusID PCI:1:0:1 but when I make the neccesary modification to XF86Config-4 it complains that there is no matching device section for BusID PCI:1:0:0.

I have VGA and DVI outputs on my card. Is that relevant? Most cards do however.

Rav

05-22-2003 06:24 PM

Oh, btw. Here is a relevant section of my XF86Config-4 file. I've included a section above the ATI device section because I have a question about it.

# The chipset line is optional in most cases. It can be used to override
# the driver's chipset detection, and should not normally be specified.

# Chipset "generic"

# The Driver line must be present. When using run-time loadable driver
# modules, this line instructs the server to load the specified driver
# module. Even when not using loadable driver modules, this line
# indicates which driver should interpret the information in this section.
&nbsp;&nbsp;&nbsp;&nbsp; Driver "vga"

# The BusID line is used to specify which of possibly multiple devices
# this section is intended for. When this line isn't present, a device
# section can only match up with the primary video device. For PCI
# devices a line like the following could be used. This line should not
# normally be included unless there is more than one video device
# installed.