The X lockups are my priority concern, as they should simply not be occuring, and I've found no work around for those.
The screen corruption is workaroundable by forcing a screen refresh. [EDIT2] This doesn't seem to be heat related as aticonfig --odgt was reporting 52.0C which roughly agrees with reports by ATITool under windows w/similar room temps @ idle. [/EDIT2]
PPAs: I've resorted to that for wine to get GW running, maybe I should try that PPA xorg. Which one is it BTW? [EDIT3] The ppa wine 1.1.25 while it allows running of GW, the char selection screen is a garbled mess, while the winehq 1.1.25 release the char select screen is fine, but GW crashes at loading an area. Apparently a regression in ntdll under wine. It's also what causes the downloads to fail CRC checks apparently. [/EDIT3]
I suppose that the video freeze problem could be that fglrx is leaving X.org in an incosistent state when waking from sleep as I presume that like nVidia, ATI replaces a chunk of the xserver or renderer. I could be entirely wrong and my original idea of the GPU itself being in an inconsistent state could also be the case, but something is definitely being overlooked there somewhere in the suspend/resume code. (Might even be a kernel/X.org bug for all I know that nVidia/Intel work around.)
Last edited by cutterjohn; 07-14-2009 at 10:10 AM.
This won't work cause find_task_by_vpid needs pid_t as parameter whereas pid_task takes a pointer to a struct pid. AMD has to fix this inside the binary blob an move to struct pid instead of pid_t.
This won't work cause
Well it just made it start for a while, then it crashed I just looked how this is used in current kernel, but i have no idea how to fix it correctly. Hopefully ati does for next driver.
The right (and only) way to fix this, is to move to struct pid instead pid_t. There is no other solution since non GPL-code can't map pid_t to struct pid. The responsible function (find_pid_ns) is EXPORT_SYMBOL_GPL.