Is there a way to force the correct driver version (32 bit not 64 bit)?

I have an acer 6530 laptop with an ATI Radeon HD3200. The sgfxi script installs the ATI Catalyst driver 8-12 which is correct but It downloads the 64 bit version and completes ok but does not startx. I had to resort to my old xorg.conf file.

Any advice welcome...

Thanks,

...topcat
Back to top

there is only one fglrx driver run package, it's for 32 and 64 bit.

As for other issues with fglrx not working, those are common, repeated, and, sad to say, still not really resolved in fglrx driver development process of ATI.

When you say you 'had to resort to old xorg.conf file' do you mean you simply replaced your current one with the old one, and didn't do anything else?

Please paste, using paste.debian.net your old and new xorg.conf files so I can take a look at what differences there are between the two.
Back to top

Also, I'm seeing some issues with missing kernel header packages, can you show me the full output for your system, mepis kernels:


Don't worry if it's long, just paste it here.

Thanks. This will let me handle missing headers as well.

However, because missing headers aren't always available in apt, especially not for old kernels, I can't automate that install fully, although I can check if they are in apt currently.
Back to top

Thanks for responding...

What I meant about wondering whether it did not work (startx) because I believed it installed a 64 bit driver when I am using the 32 bit version of Mepis 8 rc1 as based from the following line from the sgfxi log file:

www2.ati.com/drivers/linux/ ati-driver-installer-8-12-x86.x86_64

In answer to your question "When you say you 'had to resort to old xorg.conf file' do you mean you simply replaced your current one with the old one, and didn't do anything else?" what I actually did was use the Mepis x-windows assistant to reinstall the current vesa driver from booting to the Mepis Live CD. That allowed me to boot from hard drive and reinstalled the fglrx driver using the Mepis x-windows assistant. This gives me the 8.51.3 driver as per the "ATI Catalyst Control Centre". Under the Mepis installed driver I am getting 575 fps with "fgl_glxgears -fbo". I understand this is very low and that is why I am trying to get the recommended 8-12 driver using sgfxi. Because the Mepis x-windows assistant overwrote the sgfxi generated xorg.conf, I ran sgfxi again to get the xorg.conf file generated from it. I backed up the mepis xorg.conf file before I started (xorg.conf_mepis) and made a copy of the sgfxi generated xorg.conf (xorg.conf_sgfxi) when done, and when it would not startx again, I copied xorg.conf_mepis to xorg.conf and I am back in Mepis using a mepis generated xorg.conf.

I pasted xorg.conf_sgfxi and xorg.conf_mepis as well as the sgfxi.log file as requested here:

paste.debian.net/24776

I am trying this on a new acer 6530 laptop and have a 14 day evaluation period to bring back if I am not happy with it. This is the last thing I need to get working.

I hope this gives you everything you need...

Regards,

...topcat
Back to top

Here is the info you requested:

tom@acerL:~$ dpkg -l | grep 'linux-headers'
ii linux-headers-2.6.27-1-common 2.6.27-10mepis1 Common header files for Linux 2.6.27-1
ii linux-headers-2.6.27-1-mepis-smp 2.6.27-10mepis1 Header files for Linux 2.6.27-1-mepis-smp
Back to top

You're xorg.conf is messed up, you have nvidia settings in it but you are using fglrx drivers.

So that's not something I'll try to deal with in sgfxi. Also I'm not sure about the way you're handling the dual monitor stuff, but I don't run fglrx + dual monitors at all so I don't know the proper syntax.

I do however see one issue, sgfxi after it completed the install of the debs it had created, then found and installed a mepis fglrx deb file which was also deposited in /usr/src, that could be the cause of hte problem, it's quite likely in fact that it was.

I'm going to filter out mepis there, and see if that helps.
Back to top

There are only a few tiny differences in the xorg.confs, but I'm not going to try to handle your xorg.conf because it's incorrect.

For me to debug this issue, you need to save your old xorg.conf, forget the dual monitors for a bit, run dpkg-reconfigure xserver-xorg, then start with clean new xorg.conf file that doesn't have so much mess on it.

You uncommented the nvidia dual monitor settings for example but you're running fglrx.

I assume fglrx probably ignores that, but it's still not a good thing to do.

There are only a few settings that actually matter:



Note a few things:

• - Option "Composite" "Disable"
  + Option "Composite" "0"
  are the same
  
• - #Option "MonitorLayout" "crt,crt"
  is commented out so doesn't matter
  
• + Option "UseInternalAGPGART" "no"
  + Option "TexturedXrender"
  are added to sgfxi xorg.conf so could matter
  
• - Option "UseEDID" "true"
  - Option "AddARGBGLXVisuals" "true"
  - Option "RenderAccel" "true"
  are removed from your old one so could matter
  
• + SubSection "extmod"
  + Option "omit xfree86-dga"
  + EndSubSection
  are added so could matter
  

but the core thing that's happening is that m-a install and m-a build are not building the newly built kernel driver packages from the installer, but are pulling in the mepis ones.



and I don't know if there's any way I can stop that from happening.

Again, start with a clean xorg.conf, not dual monitor setup, then after you have that, try this again, and confirm or deny that xorg.conf is actually an issue. Your present xorg.conf as it stands is not usable as a debugging source, although you can try adding or commenting out each of the above items where they appear and see which makes it not start.

You can also make a test of sgfxi alone by starting it with -C, which makes it skip the xorg.conf update and see if fglrx works, but since it's installing the mepis stuff anyway that shouldn't matter.
Back to top

again, just to clarify, ati ships only one driver run package, and it's for both 32 and 64 bit, that's why it's called x86.x86_64 , ie, x86 == 32 bit and x86_64 == 64 bit.
Back to top

By the way, I'm increasingly inclined to give up on creating installer generated deb files then installing them with dpkg, the method is unreliable at best, and broken at worst, it's tempting to just start using the direct install of the downloaded package and bypass completely any failing attempt to use the debs.

Though it would be interesting to see if this stuff actually worked as is, but in mepis it looks like it may not, unless there is some trick to handle this.
Back to top

I've added some debugger logging to that component so I can see what's going on better there, by the way, so the log files should show fairly clearly the error with installing the mepis fglrx after the deb built ones.

at least I think they should, if you feel like it, run sgfxi again and paste the log using paste.debian.net so I can see if my suspicion is correct.

fglrx has been a problem for sgfxi for a while now because the debian deb construction method is persistently broken in debian sid, but I see it works still in debian testing, aka mepis, which is good to know at least..
Back to top