kernel lockup with all kernel versions tested. System has two AMD 32 bit processors, 3GB ram and AGP video cards. 9250 crashes with either text mode or X server. 7000 crashes with X only (so far, I have about two days uptime so far without any kernel error messages). I have attached debug files and Xorg.log files. Cheers, Fred
Created attachment 96571 [details] dmesg-3.8.4_R7000
Created attachment 96581 [details] Xorg.log
Created attachment 96591 [details] Radeon 9250 3.7.10
Created attachment 96601 [details] 9250 in 1x mode
Does it work if you disable AGP? Boot with radeon.agpmode=-1 on the kernel command line in grub.
(In reply to Alex Deucher from comment #5) > Does it work if you disable AGP? Boot with radeon.agpmode=-1 on the kernel > command line in grub. It's working so far. I did try X and it didn't crash with the usual sequences (windowmaker wm, firefox, xterm, use wm to modify a "docked" applications settings). I'm using kernel 3.10.17-i586 from Slackware-14.1 (happens to be Slackware-Current right now). My next check, which is being done presently, is to compile TeXLive from SlackBuild. This will crash the kernel when the compressed package is built (larger than 1GB). I am attaching a current dmesg with the radeon.agp=-1 passed to grub. Cheers, Fred
Created attachment 114661 [details] dmesg output from kernel 3.10.17-i586, radeon.agp=-1
(In reply to Fred Stevens from comment #6) > (In reply to Alex Deucher from comment #5) > > Does it work if you disable AGP? Boot with radeon.agpmode=-1 on the kernel > > command line in grub. > > It's working so far. I did try X and it didn't crash with the usual > sequences (windowmaker wm, firefox, xterm, use wm to modify a "docked" > applications settings). I'm using kernel 3.10.17-i586 from Slackware-14.1 > (happens to be Slackware-Current right now). My next check, which is being > done presently, is to compile TeXLive from SlackBuild. This will crash the > kernel when the compressed package is built (larger than 1GB). > > I am attaching a current dmesg with the radeon.agp=-1 passed to grub. It's radeon.agpmode=-1 not radeon.agp=-1. You are preventing the radeon kernel module from loading due to an invalid parameter name: [ 32.781722] radeon: `-1' invalid for parameter `agp' Alternatively, you can try adjusting the agpmode. E.g., radeon.agpmode=1 or 2 or 4. to force the agpmode to something other than what the bios set up.
Oops! I'll try radeon.agpmode=-1 instead. Still compiling TeXLive as there has always been an issue with large files, ide, etc with this motherboard and 3x kernels. When I have something significant I will post here again. Cheers, Fred
Still locks up hard with radeon.agpmode=-1 or radeon.agpmode=1. Haven't tried anything else yet. The build of TeXLive failed as before with radeon module disabled. I'm uploading a dmesg output from a "normal" boot to runlevel 3 which works, at least for a while. Cheers, Fred
Created attachment 114691 [details] Normal Boot with radeon module loaded
Created attachment 114761 [details] Latest - radeon.agpmode=-1
Everything seems to be working now. I reset the agp aperature to 256Mb (same as card) and booted as you suggested (radeon.agpmode=-1). I am rebuilding about 4 or 5 different packages and using both cpus. It still crashes with files larger than 1GB though. Cheers, Fred
(In reply to Fred Stevens from comment #13) > Everything seems to be working now. I reset the agp aperature to 256Mb > (same as card) and booted as you suggested (radeon.agpmode=-1). I am > rebuilding about 4 or 5 different packages and using both cpus. It still > crashes with files larger than 1GB though. What do you mean by "crashes with files larger than 1GB"?
If one tries to copy or manipulate a file (compress with gzip, xz, bz2) larger than 1GB. There was a fix for this issue back with earlier 2.6 kernels but it re-surfaced sometime around the release of 2.6.34 and later. The kernel will lock up if I try to compile, for example, texlive from a SlackBuild or even try to copy the prebuilt binary from another hard disk or usb disk, etc. There seems to be a hardware pci bridge bug and appropriate work around associated with this but I would have to check the kernel archives to make sure.