You are not logged in.
Hello,
I have installed archlinux32 on a compaq armada e500 laptop and am trying to run wine via xorg on it. I am having trouble getting my ATI Rage Mobility card to work under X
Things I have tried:
1. install the xf86-video-ati module (did not work).
2. Install xf86-video-mach64 from the aur
3. install xf86-video-r128 instead (I had to update the pkgbuild because it was out of date, but from my research the r128 driver is not the right driver for my card)
4. Remove those three packages and use fbdev/vesa
If useful, here are some logs:
lspci -v:
http://ix.io/1P6J
Xorg.0.log:
http://ix.io/1P6L
Could anyone point me in the right directions / next steps to take?
Thanks in advance!
Offline
My Travelmate 524 TEV has a Mach64 video card. I never to get it running with Xorg 1.20.
The module loads with some quirks but the display remains black...
Offline
Could you share your xorg log file as well? If they both have the same error, it's probably the AUR package that is broken. Debian has the mach64 package, so trying debian can tell us if it's an arch-related issue.
Offline
I think I found something promising in the pkgbuild for xf86-video-ati:
Here is a comment from that file:
# Since pacman 5.0.2-2, hardened flags are now enabled in makepkg.conf
# With them, module fail to load with undefined symbol.
# See https://bugs.archlinux.org/task/55102 / https://bugs.archlinux.org/task/54845
Checking out those tasks listed shows very similar issues to the one in my build log. So changing the C flags might be all that's needed.
Offline
I don't have access to the machine right now, but if I recall correctly I was merely adding "load module" directives
for "exa", "vesa". Just checking in Xorg.log what symbol could not be resolved and the guessed the module containing
the symbol.
For example:
[ 104.096] (EE) Failed to load /usr/lib/xorg/modules/drivers/mach64_drv.so: /usr/lib/xorg/modules/drivers/mach64_drv.so: undefined symbol: xf86int10Addr
xf86int10Addr is part of the int10 module, so you load that one explicitly.
Offline
You have first to find out whether you need MACH64, ATI or Radeon drivers..
Offline
The best I could find as configuration and explanation: https://bbs.archlinux.org/viewtopic.php?id=67837
Looks like MACH64 is the correct driver.
Offline
I don't remember how I compiled the MACH64 module, but I don't remember I had to fiddle with the CFLAGS, CXXFLAGS,
but it could easily be necessary in the meantime. :-)
Offline
Update:
After getting the sources for the xf86-video-ati driver, I changed the PKGBUILD to mach64 version and name and rebuilt. It gets much much further now, actually loads the module but fails with
MACH64(0): Unable to map linear aperture. Invalid argument (22)
This might also be the root cause of vesa not working. A debian mailing list discussion with the same issue resolved it by disabling CONFIG_IO_STRICT_DEVMEM in the kernel.
Will build a kustom kernel and will report back. Might be a while, I don't feel like setting up a cross compiler and the machine has 192 mb of ram and a very old slow hdd.
Offline
I can confirm that recompiling the kernel allows Xorg to run and fixes the issue.
Offline
So you rebuilt the kernel with CONFIG_IO_STRICT_DEVMEM enabled and the xf86-video-ati driver installed? That's all it took* to fix this?
* Conceptually it's simple, although it takes a good while especially on old hardware to achieve.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
No, I rebuilt the kernel with config_io_strict_devmem disabled, it's enabled by default. The mach64 module is also required, for testing purposes I got the PKGBUILD for xf86-video-ati, renamed the package name to xf86-video-mach64 and changed the version number (to 6.9.6), and installed the package with --skipinteg (url is determined with pkgname so works). Kernel used is 5.2.1. If many users are having this problem adding a kernel package with config_io_strict_devmem disabled would definitely be nice although for me at least it's mostly playing around with old hardware.
Offline
Okay, the config_io_strict_devmem sounds to me like a kernel hardening option against local users trashing the kernel's space. If you're careful about what you actually run on a system, that sounds unnecessary to me, although it's worth having if your system can support it for those of us running less trustworthy stuff, or being slow to patch priv escalation holes.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
Changing this setting in the default kernel might not be that useful though, especially because most systems with such a graphics card are so old anyway that they basically can't handle xorg. A separate kernel package would be a solution, but will put more stress on the build architecture.
Offline
Yes, we'll have to wait and see if more users of this old stuff come here looking for a solution. Having the solution documented fully should be a bigger help though going forward, if this does happen. According to wikipedia the Rage range of graphic chips came out in 1996 with the Mobile type coming out later. Persuamably judging by the name of the kernel module this also supports the ATi Mach chips which came out about five years earlier, although with our baseline microarchitecture being i686 == pentium pro and on, that limits it to running on machines made after about 1996. Unless users of old desktops are plugging in truly old graphics cards, we can probably ignore users of Mach chips.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
Well for me I'm using a compaq armada e500 with a pentium 3, introduced in the end of 1999. Will probably switch over to gentoo / funtoo because if you're doing the kernel from source that's already a lot and they don't have as many broken stuff for x86, many things in the aur don't really work.
Offline
I would not personally say I've found anything yet in AUR that I regularly use that can't be made to work. You need to do a little work on them because the authors have omitted to bother, but it's a short checklist of things to run through (1. Modify the arch variable, 2. Check if the pkgbuild actually builds source, or merely downloads a package 3. If the former, modify checksums or run makepkg with the -skipinteg option 3a. If the latter, select the best binary package and use that)
Edit: So I'd tend to say that perhaps some AUR packages can't be reasonably made to work, but certainly not many packages.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
Hello.
I recompiled the kernel with config_io_strict_devmem disabled.
But can't start Xorg. I got:
(EE) Failed to load /usr/lib/xorg/modules/drivers/mach64_drv.so: /usr/lib/xorg/modules/drivers/mach64_drv.so: undefined symbol: xf86int10Addr
- Kernel 5.8.11 i686
- Xorg 1.20.9
- VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Rage Mobility AGP 2x Series (rev 64)
I'm not sure do I have to do something (recompile with different flags) with xf86-video-ati and/or xf86-video-mach64 ?
Offline
Roelvdwal wrote:
I got the PKGBUILD for xf86-video-ati, renamed the package name to xf86-video-mach64 and changed the version number (to 6.9.6), and installed the package with --skipinteg (url is determined with pkgname so works).
I've no idea what this actually achieves, so don't know what it'll do for you, but it's recorded in this thread as a solution, so might be worth trying.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline