Upon further investigation, it seems that the problem is caused by GPU lockup when using that driver.
As far as I'm aware, this happens only on UEFI machines and only on relatively new machines. My test machine can boot either in UEFI or BIOS mode (CSM = Compatibility Support Module), the problem only happens when I boot using UEFI - same machine, same version of Fatdog64, but different outcome.
Some possible workarounds (from forum member JustGreg - thank you!):
- Boot using BIOS mode
- Use the "coldplug" boot parameter
- Use "loadmodules=radeon" boot parameter
- Use Catalyst proprietary driver.
The 2nd and 3rd workaround forces radeon module to be loaded earlier than other modules. For some unknown reasons, this would prevent the problem from happening .
Anyway, kirk has just compiled a newer kernel - 3.8.3 and in our (limited) experiment it seems that the problem is now gone (although 3.8.3 brings a problem of its own ). So there is hope that the workarounds are no longer necessary for the next release of Fatdog.
Edit - Delete
Comments:Posted on 22 Mar 2013, 8:47 by GCMartin
"Similar symtoms with nVidia"
I have had FATDOG beta lockup with a scrambled screen after running for several days. It seems to occur without warning and seemingly has occurred when I am not paying attention to turning on SWAP partition with swapon /dev/sdax
At the time of lockup, I have no way of getting to the desktop or to the console. No keyboard commands work nor any other means will clear screen to allow discover of problem....except reboot.
I will await the upcoming release for it may provide relief. If not, maybe use of the HDD for save-session will allow some tool to run which can display on reboot the cause of "desktop screen explosion".
Posted on 22 Mar 2013, 20:09 by jamesbond
"Looks different to me"
I think what you describe is a totally different problem. The radeon crash / lockup is immediate, it happens straight after booting. Your nvidia crash seems to happen after running the system for several days, so I would say it is probably caused by other things (it well could be because the system is running out of memory - which can happen if you use virtualisation heavily).
If you need to turn on swap automatically, you can always edit /etc/rc.d/rc.local and include the appropriate swapon commands.
Posted on 27 Mar 2013, 0:39 by jamesbond
"3.8.4 doesn't fix it"
We have moved to kernel 3.8.4, and it still doesn't solve the problem. Initially I thought 3.8.3 fixed it, but I only tested it once and when we move to 3.8.4, the problem re-appear
I can't seem to find what difference it does anyway (between coldplugging and udev), the only suspicion is that there are some other kernel modules which somehow steal the resources which should be made available for the radeon module. To add to the confusion, this ordering seems to be important only when GPU acceleration is used - if I used "fbdev" or "modesetting" driver, it works
As a workaround, I have added "loadmodules=radeon" as one of the troubleshooting options in Fatdog bootmenu for now. We will keep looking ... and anyone with ideas is welcome to share. Remember, this only happens when booting in UEFI mode. In BIOS mode, same machine, same radeon card, same Fatdog64, same kernel, same radeon module - it works flawlessly. What gives?