SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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?
ATI module generator V 2.0
probing for VMA API version...
patching file drmP.h
Hunk #1 succeeded at 283 (offset 28 lines).
linking of fglrx kernel module...
duplication skipped - generator was not called from regular lib tree
"generator was not called from regular lib tree"
This is driving me mental. I am attempting to build this module from the "regular lib tree". There is only one /lib tree.
I'm using the default Slack kernel atm (another fresh install). Please humour me The same thing happens with a fancy P4 kernel anyway. agpgart is loaded, kernel sources are present.
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, 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.
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?
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.
startx and I get this:
(II) fglrx(0): [drm] loaded kernel module for "fglrx" driver
(II) fglrx(0): [drm] created "fglrx" driver at busid "PCI:1:0:0"
(II) fglrx(0): [drm] added 8192 byte SAREA at 0xf89e9000
(II) fglrx(0): [drm] mapped SAREA 0xf89e9000 to 0x401e0000
(II) fglrx(0): [drm] framebuffer handle = 0xe0000000
(II) fglrx(0): [drm] added 1 reserved context for kernel
(II) fglrx(0): DRIScreenInit done
(II) fglrx(0): Kernel Module Version Information:
(II) fglrx(0): Name: fglrx
(II) fglrx(0): Version: 2.9.12
(II) fglrx(0): Date: May 9 2003
(II) fglrx(0): Desc: ATI Fire GL DRM kernel module
(II) fglrx(0): Kernel Module version matches driver.
(II) fglrx(0): Kernel Module Build Time Information:
(II) fglrx(0): Build-Kernel UTS_RELEASE: 2.4.20
(II) fglrx(0): Build-Kernel MODVERSIONS: no
(II) fglrx(0): Build-Kernel __SMP__: no
(II) fglrx(0): Build-Kernel PAGE_SIZE: 0x1000
(II) fglrx(0): [drm] register handle = 0xf5000000
(EE) fglrx(0): [agp] unable to acquire AGP, error "xf86_ENODEV"
(EE) fglrx(0): cannot init AGP
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.
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.
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
Here's what I get when I try to startx now. Different is good!
(WW) fglrx: No matching Device section for instance (BusID PCI:1:0:1) found
(EE) fglrx(0): board is third party board
(EE) fglrx(0): [agp] unable to acquire AGP, error "xf86_ENODEV"
(EE) fglrx(0): cannot init AGP
I did cat proc/pci and found that my cards BusID is actually is PCI:1:0:1 so I went into XF86Config-4 and edited the relevant section (the BusID in there was PCI:1:0:0).
When I startx now I get this:
(II) Primary Device is: PCI 01:00:0
(WW) fglrx: No matching Device section for instance (BusID PCI:1:0:0) found
(EE) No devices detected.
Fatal server error:
no screens found
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.
# 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.
# 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