I've just tried again with my HD3650 and only 2GB of RAM installed. I pointed authatieventsd.sh to /var/run/xauth/ and rebooted, but when I logout of KDE it still locks up so completely that even raising elephants with the magic sysreq key doesn't help. This was still with fglrx 8.3 btw.
I read most of this... I've been having the same issues myself on both 8.3 and 8.4, of course i lock terminal when i'm not at the computer. The lockups usually happen when the system is left running while logged in after well over 48 hours... should be worth nothing i am running on a Radeon X1900GT.
I'll be trying the 3650 again sometime soon, now that I'm using i386 Debian and not amd64. Reading the recent fglrx threads has me feeling less than enthused about getting the Radeon working though.
I am seeing the same problem with Fedora 8 x86_64 on a Tyan Tomcat K8E-SLI with ATI Radeon X1650 Pro. The monitor will randomly go blank and the machine will freeze until it is rebooted (although it sometime reboots on its on). The messages log shows the following errors before this happens...
May 1 16:26:40 bromo kernel: BUG: soft lockup - CPU#1 stuck for 11s! [X:2977]
May 1 16:26:40 bromo kernel: CPU 1:
May 1 16:26:40 bromo kernel: Modules linked in: rfcomm l2cap bluetooth autofs4 fuse sunrpc nf_conntrack_netbios_ns nf_conntrack_ipv4 ipt_REJECT iptable_filter ip_tables nf_conntrack_ipv6 xt_state nf_conntrack xt_tcpudp ip6t_REJECT ip6table_filter ip6_tables x_tables dm_mirror dm_multipath dm_mod ipv6 floppy pcspkr e100 k8temp forcedeth hwmon tg3 serio_raw mii fglrx(P)(U) i2c_nforce2 i2c_core button sr_mod sg cdrom pata_amd sata_nv ata_generic pata_acpi libata sd_mod scsi_mod raid456 async_xor async_memcpy async_tx xor raid1 ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd
May 1 16:26:40 bromo kernel: Pid: 2977, comm: X Tainted: P 184.108.40.206-85.fc8 #1
May 1 16:26:40 bromo kernel: RIP: 0010:[<ffffffff88198af0>] [<ffffffff88198af0>] :fglrx:_ZN4Asic16Is_WPTR_equ_RPTR19ConditionSucces sfulEv+0x0/0x60
May 1 16:26:40 bromo kernel: RSP: 0018:ffff81013d5d1c80 EFLAGS: 00200206
May 1 16:26:40 bromo kernel: RAX: ffffffff881f0670 RBX: 00000000007ffff9 RCX: 0000000000000000
May 1 16:26:40 bromo kernel: RDX: ffffc200013f14c0 RSI: ffffc200013f1020 RDI: ffff81013d5d1cf8
May 1 16:26:40 bromo kernel: RBP: 0000000000000043 R08: ffffffff881f0670 R09: 0000000000000043
May 1 16:26:40 bromo kernel: R10: ffff8100bf124ba0 R11: ffffffff810f9fec R12: ffff8100bf124ba0
May 1 16:26:40 bromo kernel: R13: ffffffff810f9fec R14: 00000000007ffff9 R15: 0000000000200282
May 1 16:26:40 bromo kernel: FS: 00002aaaaaad17b0(0000) GS:ffff81013fc01780(0000) knlGS:00000000f6f7aa50
May 1 16:26:40 bromo kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
May 1 16:26:40 bromo kernel: CR2: 0000003853aba380 CR3: 000000012a577000 CR4: 00000000000006a0
May 1 16:26:40 bromo kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
May 1 16:26:40 bromo kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
May 1 16:26:40 bromo kernel:
May 1 16:26:40 bromo kernel: Call Trace:
May 1 16:26:40 bromo kernel: [<ffffffff88197e3f>] :fglrx:_ZN4Asic9WaitUntil15WaitForCompleteEv+0x1f/0xa0
May 1 16:26:40 bromo kernel: [<ffffffff8819ba72>] :fglrx:_ZN6AsicR616ASICIdleInternalEN4Asic15idle_W aitMethodE+0xa2/0x1e0
May 1 16:26:40 bromo kernel: [<ffffffff881806fb>] :fglrx:_ZN10QS_PRIVATE10submitListEP9CMMDriverP10_ QS_PARAM_+0xfb/0x460
May 1 16:26:40 bromo kernel: [<ffffffff88196945>] :fglrx:_ZN4Asic7PM4idleENS_15idle_WaitMethodE+0x55/0x90
May 1 16:26:40 bromo kernel: [<ffffffff88191526>] :fglrx:_ZN15QS_PRIVATE_CORE7PM4idleEN4Asic15idle_W aitMethodE+0x26/0x50
May 1 16:26:40 bromo kernel: [<ffffffff88180a8a>] :fglrx:_ZN10QS_PRIVATE11synchronizeEv+0x2a/0x30
May 1 16:26:40 bromo kernel: [<ffffffff881888e3>] :fglrx:_Z8uCWDDEQCmjjPvjS_+0x363/0xf80
May 1 16:26:40 bromo kernel: [<ffffffff88145f4a>] :fglrx:firegl_cmmqs_CWDDE_32+0x20a/0x310
May 1 16:26:40 bromo kernel: [<ffffffff88145037>] :fglrx:firegl_cmmqs_CWDDE32+0x67/0xf0
May 1 16:26:40 bromo kernel: [<ffffffff88144fd0>] :fglrx:firegl_cmmqs_CWDDE32+0x0/0xf0
May 1 16:26:40 bromo kernel: [<ffffffff88138d26>] :fglrx:firegl_ioctl+0x1b6/0x230
May 1 16:26:40 bromo kernel: [<ffffffff810abe61>] do_ioctl+0x55/0x6b
May 1 16:26:40 bromo kernel: [<ffffffff810ac0ba>] vfs_ioctl+0x243/0x25c
May 1 16:26:40 bromo kernel: [<ffffffff810ac124>] sys_ioctl+0x51/0x71
May 1 16:26:40 bromo kernel: [<ffffffff8100c005>] tracesys+0xd5/0xda
May 1 16:26:40 bromo kernel:
May 1 16:26:52 bromo kernel: BUG: soft lockup - CPU#1 stuck for 11s! [X:2977]
May 1 16:26:52 bromo kernel: CPU 1:
I've tried using noacpi, noapictimer and acpi_use_timer_override but none of those help. What are the other folks here seeing in there message logs from just before the blank screen/reboot?
Sorry guys, I'm not seeing the black screen or the auto reboot, but I do have these problems persisting.
Hard Lockup when I play something like quake3 engine. ( probably anything with 3D accel ) The lockup happens in several situations, and I must hard reboot (using restart button on tower) system is non responsive. the cases are as follows:
I always use XFCE and gdm
1. I have been working for hours as my dev user in standard X session, and I have probably watched a ton of flash videos ( I mention this because I think it is related somehow ) Then I log out of that X session and login as my game user, again standard X XFCE session. After I start a game, like UrbanTerror, I will usually get a lockup within 10 minutes. After I restart and login as my game user, I have no problems playing the game for hours. There is something about that reboot that resets something, maybe onboard the card itself. I have tried rmmod fglrx and then modprobe to reload it, but that doesn't make the game stable like a fresh reboot.
2. I'm playing UrbanTerror and have just changed game system settings, like fps, compress textures, or vertical sync. The game will start to jitter and then the system will lockup. Again its definitely the card and the driver right?
3. I have seen your black screen that causes me to reboot, but that happens when I move between virtual consoles. I will go to console 1 and put the machine in init 3, but then if I go to virtual console 7 ( where X was spawning ) I get a black screen, and I'm not able to do anything but reboot (ctrl+alt+del)
I was hoping that this latest April driver would solve problems for us IGP guys, but I guess not. I'm using
Gigabyte ga-ma69G-s3h using the IGP ati x1250 and all other integrated devices.
I definitely had to remove pulseaudio, it was causing all kinds of weird problems, but the ATI driver is the culprit.
I'm waiting for radeonHD driver with 3D support, I bet it destroys ATI proprietary. Gotta have hope
Oh yeah, most importantly. If you are having a lot of problems with fedora 8 x86_64 I recommend this especially if you did an upgrade from fc7 to fc8
go to init 2 or 3 ( get out of X )
Then do a yum groupremove "X Window System" "KDE" whatever else you have related to X.
Then do a yum groupinstall "X Window System" "KDE" "XFCE" whatever.
Thanks to jwhowarth for setting me straight on fc7 packages that still apply to fc8. I had gotten rid of almost all fc7 packages, but he pointed out that a lot of them are still used.
I know this takes a long time and it seems like overkill, but trust me, it fixed a bunch of my problems. Granted my upgrade from fc7 to fc8 was eventful to say the least, but doing the above you are certain to reload all the latest libs and binaries.
Last edited by c247; 05-03-2008 at 11:22 AM.
I hope you made a list of the fc7 rpms that you deleted. There are quite a few packages in Fedora 8 that still have the fc7 suffix. Critical things like grep for instance. You really should use 'yum list extras' to find those packages that aren't part of the current release of fedora.
Wow you are right, a bunch of core fc7 packages made it back into my fc8 when I did the X related group installs. Crazy! I had gotten rid of all but a few fc7 packages and my system was stable. How Odd Where did I find an fc8 grep ? I'm totally confused now
Look at the list of packages in the Fedora 8 distribution...
Basically, the fedora developers didn't bump the fc version on those packages that didn't change versions or revisions for Fedora 8. You can generally assume that after upgrading Fedora and doing a yum update that all of the current packages will be installed. You then can use 'yum list extras' to identify those packages that are either depreciated out of the current fedora release or those that you installed yourself outside of the normal yum repos.
If you try
and get something likeCode:$ modprobe -vf fglrx
the solution is to modify the file "/etc/modprobe.d/lrm-video". Comment out the line with fglrx so it looks likeCode:install /sbin/lrm-video fglrx
and reboot.Code:#install fglrx /sbin/lrm-video fglrx $CMDLINE_OPTS
I hope it works for you too