Since FC3 was installed, I get a lockup of the server when changing from X that was started in runlevel 3 via startx. To get the problem, you would ctl-alt-Fn to a terminal, then change back to the loaded X. (alt-F7). What happens is there is striped paterns on the top of the display, my computer fan starts to race and there is no way to shut down or halt X. I also noticed that this problem is effected when I would change my screen resolution or try to start the game tuxracer. Below is lspci -vvv information. 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility U1 (prog-if 00 [VGA]) Subsystem: Hewlett-Packard Company Pavilion ze4400 builtin Video Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B+ Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 66 (2000ns min), Cache Line Size 10 Interrupt: pin A routed to IRQ 10 Region 0: Memory at e0000000 (32-bit, prefetchable) [size=256M] Region 1: I/O ports at 9000 [size=256] Region 2: Memory at d0100000 (32-bit, non-prefetchable) [size=64K] Capabilities: [58] AGP version 2.0 Status: RQ=48 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2,x4 Command: RQ=16 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x4 Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME-
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.
The problem was fixed and was related to a patch which was applied improperly which had errors for the Fedora Core version. Fixed! Thanks!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.