You are not logged in.
I do not use dri, but have glx. Maybe I shall try and comment that out as well?
Offline
I'm on a machine at work at the mo, so cannot do further checks (this is also running Arch, but I am loath to update it in case this starts freezing as well - wouldn't be good :shock: )
I don't think disabling glx would make much difference unless the freeze is happening running OpenGL - which it's not.
In the past, absolute hard-locks for me have generally been caused by drivers either on the video card or the AGP slot, but I don't want to change from the xorg ati driver to the fglrx because of the 'black screen' issue with kernel 2.6.15 which has been around. It's also odd that my lockups (so far) have only happened when running Tbird (gtk based) - now I've done it, I'll have nothing but trouble tonight :twisted:
Offline
I have asked a couple of times here but have not gotten any answers ... is it possible to downgrade the system using pacman? I guess it wont help only installing an older version of xorg since oll the other packages needs to be reinstalled as well...
Offline
Same for me. I have an ATI card, too, and I think that this is the problem. I just bugreported to the dev team, and I already have one comment: https://bugs.freedesktop.org/show_bug.cgi?id=5997
So I'm trying to build my xf86-video-ati-cvs package starting from the original one, with this PKGBUILD:
# $Id: PKGBUILD,v 1.2 2006/02/18 14:19:19 jgc Exp $
#Maintainer: Jan de Groot <jgc@archlinux.org>
pkgname=xf86-video-ati-cvs
pkgver=20060222
pkgrel=1
pkgdesc="X.org ati video driver"
url="http://xorg.freedesktop.org/"
depends=(libdrm expat)
makedepends=(pkgconfig xorg-server)
conflicts=(xf86-video-ati)
provides=(xf86-video-ati)
groups=(xorg-video-drivers)
_xorg=X11R7.0
_relname=xf86-video-ati
_mesaver=6.4.2
source=(http://dl.sourceforge.net/mesa3d/MesaLib-${_mesaver}.tar.bz2)
md5sums=(7674d2c603b5834259e4e5a820cefd5b)
_cvsroot=":pserver:anoncvs:@cvs.freedesktop.org:/cvs/xorg"
_cvsmod="driver/xf86-video-ati"
build() {
cd ${startdir}/src
msg "Connecting to cvs.freedesktop.org CVS server..."
cvs -z3 -d ${_cvsroot} co -D ${pkgver} -f ${_cvsmod}
cd ${_cvsmod}
./autogen.sh
msg "CVS checkout done or server timeout"
msg "Starting make..."
cp -r ../${_cvsmod} ../${_cvsmod}-build
cd ../${_cvsmod}-build
#cd ${startdir}/src/${_relname}-${_xorg}-${pkgver}
./configure --prefix=/usr
--enable-dri
--build=${CHOST} --host=${CHOST}
make || return 1
make DESTDIR=${startdir}/pkg install || return 1
cd ${startdir}/src/Mesa-${_mesaver}/configs
CONFIG="linux-dri-x86"
echo "EXTRA_LIB_PATH =" >> ${CONFIG}
echo "OPT_FLAGS = ${CFLAGS}" >> ${CONFIG}
echo "SRC_DIRS = glx/x11 mesa" >> ${CONFIG}
echo "USING_EGL = 0" >> ${CONFIG}
echo "PROGRAM_DIRS =" >> ${CONFIG}
echo "MKDEP = makedepend" >> ${CONFIG}
echo "DRI_DIRS = mach64 r128 radeon r200 r300" >> ${CONFIG}
ln -s ${CONFIG} current
cd ${startdir}/src/Mesa-${_mesaver}/src/mesa/x86
make
cd ..
make mesa.a
cd drivers/dri
mkdir -p ${startdir}/pkg/usr/lib/xorg/modules/dri
make
install -m 755 */*_dri.so ${startdir}/pkg/usr/lib/xorg/modules/dri/
find ${startdir}/pkg -name '*.la' -exec rm {} ;
}
But I get an error message:
[...]
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for XORG... yes
checking for ANSI C header files... (cached) yes
checking for /usr/include/xorg/dri.h... yes
checking for /usr/include/xorg/sarea.h... yes
checking for /usr/include/xorg/dristruct.h... yes
checking whether to include DRI support... yes
checking for DRI... configure: error: Package requirements (libdrm >= 2.0 xf86driproto) were not met.
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively you may set the DRI_CFLAGS and DRI_LIBS environment variables
to avoid the need to call pkg-config. See the pkg-config man page for
more details.
Obviously the above stated packages are installed, I think it's a path problem (see L0cutus post, I think the two problems are related).
dreaming in digital / living in realtime / thinking in binary / talking in ip / welcome to our world
Offline
Oh yeah, I also have an ATI card (Radeon Mobility 9600). I'd be willing to bet that it could be interaction between the "radeon" xorg driver and the "glx" module. I haven't experienced any crashes since disabling glx and dri. I did experienc 4 crashes before doing so. I'll keep you posted as to whether I experience any more crashes.
Russ
Offline
I fired Thunderbird out of curiosity, nothing evil happened...
After RTFM, transition to xorg 7 was suprisingly smooth here, I expected way worse... the only thing not mentioned in the wiki was that after upgrading xterm was removed, and so startx failed. By simply doing from CLI
pacman -S xterm
and then starting the xserver evrything is running great! Hats off to the Arch devel team.
Off topic (probably): Nvidia FX 5200, using the stock Arch "nvidia" package.
Microshaft delenda est
Offline
Talk about missing the obvious. I couldn't understand for the life of me why xterm was missing. Thanks! Still no crashes.
Russ
Offline
Off topic (probably): Nvidia FX 5200, using the stock Arch "nvidia" package.
Possibly not, from what I can tell, all the problems are with ATI owners (someone will probably tell me different now!)
I'll probably give the CVS driver a go when I get back, and see how it goes. Although, if it is only GTK based apps for some nutty reason, I wouldn't be too bothered as I hardly use any.
Offline
I have an ATI Mobility Fire GL T2 and I use the ati driver in xorg.conf. Is there some other driver I could test? I tested the vesa driver yesteday, but the same thing happened.
Offline
You could try the fglrx driver, but last I tried it had issues with kernel 2.6.15. Don't know if they are solved yet. (Issues being unable to swtch to a console, and complete loss of video after logging out of X)
I never had chance to try the CVS driver, so if anybody else has it would be good to hear if it solves this freeze problem
Offline
It seems this is a known problem.
https://bugs.freedesktop.org/show_bug.cgi?id=4847
There are a couple of suggestions in there that might help until a new driver is out, or you are able to try the CVS driver at least.[/url]
I'm unable to try anything at the moment, so cannot comment on effectiveness.
Offline
What would happen if I took an older PKGBUILD file for xorg < 7? I guess there are loads of other packages that would go bananas if they had an older version of xorg?
Offline
I imagine that as anything that needs X will have been rebuilt/packaged against the new libraries, there would be a lot of failures (!) and you would effectively have to build everything yourself against the old libraries.
Did you try disabling both dri and glx as Infracephas suggested?
Originally I didn't see how removing glx would help, but it seemingly does in some cases.
The other thing to try is forcing down the AGPMode (to 2 or 1) as suggested in the link above.
Offline
I tried disabling glx but that did not help. Have not tried the AGPMode fix yet. Will try in a few minutes.
Offline
Setting AGPMode to 2 or 1 did not help.
I was just wondering about one thing ... since I tried the vesa driver, and it still hung ... is it sure that this is a problem with ati? Maybe I'm asking a stupid question here, but I do that all the time anyways so...
Offline
At least you get to ssh to your computer after it hangs ... I can't do that either. Everythings dead...
If this isnt fixed soon the only solution for me is to switch to another distro. I cant afford to wait much longer for this...
Offline
Any news about this? My system is still hanging.
Offline
try the official ati drivers?
KISS = "It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience." - Albert Einstein
Offline
On ati.com I find drivers for Xorg 6.8, and that is only an .rpm file. If someone could guide me on how to install from .rpm, I can try that one.
Offline
The ati drivers are in the repositories:
pacman -S ati-drivers ati-drivers-arch
or use ati-drivers-archck if you're using the ck kernel release.
I have trouble with these and kernel 2.6.15, but you may have more luck.
Offline
I don't use the arch kernels as I have compiled one myself. Do I have to do things differently then?
Offline
Probably the best method would be to take the PKGBUILD from ABS, create a directory for local builds (assuming you don't have one already) and edit the PKGBUILD to remove the dependency on 'kernel26', and change the pkgname option so a new update doesn't automatically overwrite this install (assuming it works!)
Then run 'makepkg' as root, or install 'fakeroot'.
Assuming all goes ok, you will be left with a package you can install manually with 'pacman -A pkgname'
I've only done this a couple of times and it is fairly easy if you are only slightly modifying an existing build. Hopefully if I've left anything out somebody will chime in
Offline
I will try this soon. Just have to finish some schoolwork ... in Windows.
Offline
I made a package of ati-drivers and ati-drivers-arch making the necessary changes to the PKGBUILD files. I also added fglrx to the MODULES part of /etc/rc.conf. When I rebooted I got "operation not permitted" when trying to load the fglrx module.
Offline
cogo: You'll get that if you try to modprobe fglrx as a non-root user, or if there's already a video module loaded (like 'radeon'). Check the output of lsmod or lsmod|grep agp and see what's loaded already.
Offline