Bug 2556

Created attachment 1914 [details]
My xorg.conf file

This should show the Synaptics mouse driver information within this file. I'm
not sure if this is relevent, but this was not used in FC2, where the lockup
was not present.

Created attachment 1915 [details]
X log when not switching to terminal

This is the Xorg.0.log file when I boot into runlevel 3 and use startx from my
user account. There are no lockups until Tuxracer played, swithching screen
resolution or returning from a terminal.

Created attachment 1916 [details]
glxinfo-dri-disabled-because

GLX gears says that I have no DRM also. I believe that there was DRM before FC3
and the server lockup that is now encountered.

 glxgears
libGL error: open DRM failed (Operation not permitted)
libGL error: reverting to (slow) indirect rendering
771 frames in 5.0 seconds = 154.200 FPS
1300 frames in 5.0 seconds = 260.000 FPS
1240 frames in 5.0 seconds = 248.000 FPS

With additional testing and adding the Option "NoAccel" to the xorg.conf file,
there is no problem encountered with changing from GUI to terminal then back to GUI.
Anyway, this problem seems to be effecting a lot of users with various versions
of  ati or radeon cards.

Most people seem to be adding the option to their xorg.conf files to prevent
repeatable server respawning from X failing without the option.

Basically, I believe this problem is effecting a lot of users for later versions
of X. (post FC3)

Adding Mike Harris to CC: for this bug. Conversations on fedora-list leads to
the problem effecting more users. Most have opted to add the NoAccel option to
the xorg.conf file. Busted it seems to be.

Though this is not a conventional fix. I have been able to download the latest
radeon-20050225-linux.i386.tar.bz2 file and extracted it. I then tried to run
the install.sh script and got this error in the dri.log - Makefile:163: ***
Cannot find a kernel config file.  Stop. 
Not really knowing how to overcome this error, I placed the drivers in the
following directories.
ati_drv.o and radeon_drv.o placed in /usr/X11R6/lib/modules/drivers and changed
the permissions to 444.
The radeon_dri.so was placed in /usr/X11R6/lib/modules/dri and the file
permission was set to 444 also.

Anyway, the problem with GUI to VTY to GUI has gone away and I can change to a
vt and back to X without the lockup.

Created attachment 1990 [details]
Xorg.0.log file with changes

This is with the drivers listed above installed.

Created attachment 1991 [details]
Xorg.0.log before changing the drivers

I'm not sure if this has any information in it, but here is the log before
restarting X on a reboot from the hard lockup.

Created attachment 1992 [details]
Here is glxinfo - comparison from prior submitted

This is with the drivers in place.

Done

Created attachment 2015 [details]
The drivers extracted and relocated to server

Until the radeon driver is fixed in FC3, these drivers can be used successfully
to overcome the problem with crashes.
The .so file goes in dri and the .o drivers go in the drivers directory

I have tryed these drivers now, and for me it is not working.
I have a ATI Radeon IGP320M on a fujitsu siemens Amilo a7600 laptop.
With xorg 6.8.1 the startx would freeze my computer and a black screen and I
added the Option "NoAccel" to get it started. Then it started but everytime i
try to play avi, mpeg or similar the xserver shuts down.
Tryed to update to xorg 6.8.2 and still the Option "NoAccel" was needed.
Tryed to experiment and put in those driver from the attachement.
If i then try to startx without the Option.... I got the stripe paterns
mentioned in comment 1., and then my laptop freezes.
Tryed also with the Option.. X would then start but video playback still shuts
down xserver.
Another funny thing here is that if i even try to play mp3 files in one of the
movieplayer it shutsdown x.
I have tryed Totem, mplayer, kaffeine & xine under both kde & gnome.
Attached is the xorg log before the new driver & after & the messages log before
& after the driver experiment.

Created attachment 2039 [details]
Messages, xorg.log & xorg config file from Tor Harald

(In reply to comment #13)
> Created an attachment (id=2039) [edit]
> Messages, xorg.log & xorg config file from Tor Harald
> 
Looking through the messages, it is probably related to a buggy BIOS as this
excerpt.
Mar  6 11:38:54 localhost kernel: ACPI: Unable to set IRQ for PCI Interrupt Link
[LNKU] (likely buggy ACPI BIOS).
Mar  6 11:38:54 localhost kernel: Try pci=noacpi or acpi=off

or SELinux - try running 'setenforce 0' as root and try again.

or the below advice from the mesages that you provided.

Mar  6 15:06:25 localhost kernel: ali15x3_smbus 0000:00:06.0: ALI15X3_smb region
uninitialized - upgrade BIOS or use force_addr=0xaddr

Another factor could be related to pnp enabled in your bios.

After using the drivers provided in the attachments, I personally did not have
any crashes due to switching to terminals. I think that I stumbled across my
problem from reading a message regarding the 2.6.11 kernel and it setting the
/dev/dri/card0 to 660 permission instead of 666 permission as was the behavior
using earlier kernels.
I am installing the latest version from todays development tree and this should
wipe out the hack tries earlier. I'll try this before and after assuring the
permissions for dri.
I changed the permissions to 666 and ran glxinfo and did not get the problem
that was happening before when running glxinfo.

Sorry no help with the drivers. Bad hacks, though they work can be hard to undo.

You might want to try the development version of xorg-x11 to see if you see any
improvements. The hack should be overwritten with installing the new X version.

Jim

Created attachment 2042 [details]
This is glxinfo after changing permissions to 666 /dev/dri/card0

The speed doubled when changing the permissions of /dev/dri/card0 to 666.
Without these permissions, the dri does not work.

Created attachment 2043 [details]
/var/log/Xorg.0.log w/ upgraded xorg-x11

After installing xorg-x11-6.8.2-7 which undid the hacking drivers that did not
have the problem described in the original report, the problem is again
present.
I changed /dev/dri/card0 to permission 666 and then ctl-alt-Fn to a terminal,
then did an alt-F7 to return to X. I eneded up getting a lockup of X server as
is described in the attachment.

Created attachment 2044 [details]
/var/log/Xorg.0.old

This is the xorg.0.log.old file that represents my hacked version of X with the
drivers in the above gzipped file. I did not reapply the hack. I am running in
runlevel 3 and not ctl-alt-Fn changing. X is fine with the limit imposed by
this bug. I would however like to be able to return to older practices.
Changing  /dev/dri/card0 had no effect on the crashing but does allow dri with
this borken driver for the radeon/ati driver duo.

good:
(II) RADEON(0): [drm] removed 1 reserved context for kernel
(II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xcca64000 at 0xb3e06000

bad:
II) RADEON(0): [RESUME] Attempting to re-init Radeon hardware.
(II) RADEON(0): [agp] Mode 0x0f000207 [AGP 0x1002/0xcab0; Card 0x1002/0x4336]

I'm confused as to what is going on here. I know that the listing marked as bad
seemed to lockup the x server.

Created attachment 2045 [details]
log when launching tux

I decided to try tuxracer to test 3D with the latest drivers. The computer
froze and ended up having dr-0 or some other dr-* as having an inode problem.
This is the log from that attempt.

Created attachment 2046 [details]
tux with drivers applied with permissions 444 for each driver

This is with the latest version of X and reapplying the drivers in the
/usr/X11R6/lib/modules/dri for the .so file and /usr/X11R6/lib/modules/drivers
for the .o files.
They work and tux plays well, switching terminals does not crash X and we're
set for the next test xorg-x11 release.
file permissions are set to 444 for these files.

(In reply to comment #14)
> (In reply to comment #13)
> > Created an attachment (id=2039) [edit] [edit]
> > Messages, xorg.log & xorg config file from Tor Harald
> > 
> Looking through the messages, it is probably related to a buggy BIOS as this
> excerpt.
> Mar  6 11:38:54 localhost kernel: ACPI: Unable to set IRQ for PCI Interrupt Link
> [LNKU] (likely buggy ACPI BIOS).
> Mar  6 11:38:54 localhost kernel: Try pci=noacpi or acpi=off
> 
> or SELinux - try running 'setenforce 0' as root and try again.
> 
> or the below advice from the mesages that you provided.
> 
> Mar  6 15:06:25 localhost kernel: ali15x3_smbus 0000:00:06.0: ALI15X3_smb region
> uninitialized - upgrade BIOS or use force_addr=0xaddr
> 
> Another factor could be related to pnp enabled in your bios.
> 
> After using the drivers provided in the attachments, I personally did not have
> any crashes due to switching to terminals. I think that I stumbled across my
> problem from reading a message regarding the 2.6.11 kernel and it setting the
> /dev/dri/card0 to 660 permission instead of 666 permission as was the behavior
> using earlier kernels.
> I am installing the latest version from todays development tree and this should
> wipe out the hack tries earlier. I'll try this before and after assuring the
> permissions for dri.
> I changed the permissions to 666 and ran glxinfo and did not get the problem
> that was happening before when running glxinfo.
> 
> Sorry no help with the drivers. Bad hacks, though they work can be hard to undo.
> 
> You might want to try the development version of xorg-x11 to see if you see any
> improvements. The hack should be overwritten with installing the new X version.
> 
> Jim
> 
> 

:-) Bios is the second newest and the change to the newest was nothing to do
with this. (only 1 specific network card that wont work)
Have already tryed ACPI=off noirq option pci=nopci but no difference if they are
there or not. In the bios it is no option for setting pnp os.. :-)
Im left alone now... Think I might install FC2 instead since it worked perfect.

Created attachment 2171 [details]
Xorg.0.log w/ xorg-x11-6.8.2-1.FC3.10test - and binary drivers

On a newly installed system (FC3). I tried the version of X from the testing
repository. With the original drivers, I still get a lockup when switching to
terminals. With the driver transplant, I get garbage on startup but the
performance of X and switching to terminals is at an acceptable level.

Trying with the newly released xorg-x11-6.8.2-1.FC3.13 from todays updates, the
same problem exists. I still get a system lockup when changing resolutions,
switching to a virtual terminal and then back to the GUI or launching tuxracer.
To get thingsup to a decent working level, replacing the drivers overcomes the
problem.

Created attachment 2248 [details]
dmesgs after booting back up from crash in runlevel 1

This is the messages that were included in dmesg after booting into runlevel 1
after the system crashed.

Created attachment 2249 [details]
/var/log/messages post crash

Created attachment 2250 [details]
/var/log/Xorg.0.log post crash, before X restarted

Created attachment 2251 [details]
Xorg.0.log with binary drivers from freedesktop.org

When changing fron GUI to virtual terminal and back, the first time switching
back does not show any distortion and works pretty reliably. The second switch
from virtual terminal and back to GUI shows some distortion as described
initially in the report. The system recovers from the distortion and does not
freeze. Tuxracer (test) works decent and does not render any distortion.
This is the logs with the binaries installed in /uxr/X11R6/lib/drivers and
../dri

Pulling the below version from CVS and running make World on the source with no
config changes, I tried the ati and radeon drivers and the dri driver also. The
symptoms for the crashing when switching from GUI to a VT and back are the same
as with the binaries available in the latest FC3 released version.

2005-02-09 Roland Mainz <roland.mainz@nrubsig.org>
        * xc/Makefile
        * xc/config/cf/xorgversion.def
        Bugzilla #2514 (https://bugs.freedesktop.org/show_bug.cgi?id=2514)
        attachment #1879 [details] [review] (https://bugs.freedesktop.org/attachment.cgi?id=1879):
        Bumping version to 6.8.2

Created attachment 2265 [details]
CVS compile - install - same problem

I pulled in the CVS build, then compiled the source with make World as user
followed by make install to install the cvs version. The tests and resolution
is the same.
I compiled the src.rpm and it failed in the same manner. Compiling cvs fails
the same but the fonts are better. Replacing the dri and drivers for ati/radeon
allows things to work correctly.
The log is from the CVS build with no hacks.

xorg-x11-6.8.2-20 has the same problem. Replacing the rpm binary drivers with
the snapshot driver versions rids me of this bug until xorg-x11 is updated
again. then the drivers are replaced and testing fails, then I revert the drives
with the snpshot version and it works again. 

Testing with the latest binaries on http://dri.freedesktop.org/snapshots/ I was
able to keep the latest version of xorg-x11 (Fedora Development) running without
erroring out when either switching from terminals or testing with tuxracer. Both
gave me a hard lockup with the stock Fedora Development binaries. With the atest
snapshot versions, I do get a flicker in the shap of a square when tuxracer is
first launched. After a few flickers in the center of the screen (outside video
seems normal), everything seems alright for the rest of the session.

Created attachment 2405 [details]
todays snapshot drivers and xorg-x11-6.8.2-20

Just FYI with permissions set for the files to 444 and the owner as root.

Running a pure xorg-x11 version - xorg-x11-6.8.2-22, there is no lockups with
switching to terminals and then back. I did not need to convert drivers and
tested in runlevel 5 with rhgb and also in my preferred level 3, using startx.
Both worked fine and the contrast and crispness of the display "look" better.

I think it is resolved, tuxracer died (development). {It must have been the tree}

Many thanks! and I hope it keeps on working. (X, not tuxracer as much)

Jim

Created attachment 2420 [details]
Just for comparative checks against the other logs. Stock and working!

Great Job! ( I hope)

I believe this bug was fixed by the patch we just applied to rawhide
xorg-x11, which is nominated for 6.8.3 in:

    https://bugs.freedesktop.org/show_bug.cgi?id=2698

If someone can confirm that, we can close this bug as a duplicate
of bug #2698

Presumably fixed.

Presumably fixed.

The problem was fixed and was related to a patch which was applied improperly
which had errors for the Fedora Core version.
Fixed!
Thanks!