Here is where find_task_by_vpid stopped being exported incase it helps anyone find a workaround. This is sorely needed for 2.6.31 support.
http://git.kernel.org/?p=linux/kerne...ce77d3dc2685c3
Short version: cannot install ATI catalyst without modifying the distributed driver package by adding the MSI vendor ID and part # plus optionally what appear to be some setting strings. Alternatively it is also possible to directly install the driver portion only(sans CCC) apparently, but I got derailed on that by a dead link last time I though of trying that out. The second method also involves jumping through hoops as well, and I'm not at all certain if the driver will still look for a card mfg ID or not.
This is just really way offtopic though as it was a nitpick for the windows driver side as well, and I don't really think that we can directly compare the windows catalyst drivers to linux as it sounds like the linux ones are more closely related to the firegl "pro" drivers while the windows drivers are specifically for the radeon retail massmarket line with a separate driver for the "pro" firegl line.
Here is where find_task_by_vpid stopped being exported incase it helps anyone find a workaround. This is sorely needed for 2.6.31 support.
http://git.kernel.org/?p=linux/kerne...ce77d3dc2685c3
Try this (for dkms):
Code:diff -Nru fglrx-8.620.orig/firegl_public.c fglrx-8.620/firegl_public.c --- fglrx-8.620.orig/firegl_public.c 2009-07-07 23:35:39.000000000 +0200 +++ fglrx-8.620/firegl_public.c 2009-07-08 00:54:08.155793160 +0200 @@ -165,6 +165,7 @@ #include <linux/string.h> #include <linux/gfp.h> #include <linux/swap.h> +#include <linux/pid.h> #include "firegl_public.h" #include "kcl_osconfig.h" @@ -1292,7 +1293,7 @@ #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,26) p = find_task_by_pid( pid ); #else - p = find_task_by_vpid( pid ); + p = pid_task( pid, PIDTYPE_PID ); #endif if (p) {
A user with a Radeon 4890 is complaining of an "unsupported hardware" watermark with these drivers on Ubuntu 9.04. Is that normal or did the user foobar the install?
That can occur if the user is using a driver that had the hardware changes "in development", but not released and supported.
It means that it _might_ work, but the user should update to a driver that came out after the hardware was purchased.
(Note that there may be lots of variants of a piece of hardware, the variants may be supported after the original release, so don't always go by the original 4890 release date).
Regards,
Matthew
Thanks, Matthew. I understand what it means, but I was wondering if it was normal with Catalyst 9.6 and a 4890. I guess if it is, the user will have to wait for the next Catalyst.
Originally posted in the open source section;
Same problem occurs here with new 9.6 catalyst driver.
uname -a
Linux 2.6.29-sabayon #1 SMP Thu Jun 11 13:33:04 UTC 2009 x86_64 AMD Phenom(tm) II X4 955 Processor AuthenticAMD GNU/Linux
lspci on http://www.sabayonlinux.org/pastie/1249
xorg.log on http://www.sabayonlinux.org/pastie/1247
xorg.conf on http://www.sabayonlinux.org/pastie/1248
When playing a matroska-containered high definition video of the film "microcosmos" (haven't tried any others yet) exactly the same symptoms occur; system freezes.
Occasionally i can ssh to the box, but at other times even that is not possible anymore.
Hope this is of use to the developers.
I will be happy to give more information or test things.
The black rectangle corruption has now also been observed in other applications, e.g. Gnome Terminal and random appearance of black rectangles in empty desktop shells.
Video playback still consistently locks at least X on awake from sleep. (Black rectangle corruption related? I honestly haven't paid attention enough to remember if it also only occurs AFTER wake from sleep.)
Seems like some things may not be properly restored for the GPU after wake from sleep, given that video is OK BEFORE sleep, but after it consistently freezes at least X. Also the freeze is still there IF compiz/beryl is enabled and then the machine is put to sleep.
I'd suggest possibly that monthly releases be dropped in favor of more tangible goals, e.g. some serious bug squashing.
The monthly releases more or less come for free along with the other OSes since the drivers make heavy use of common code. Keeping the code regression-free is the expensive part, and that needs to be done whether we release or not. Dropping monthly releases would not really allow the allocation of more resources to bug fixing etc...
I can confirm the corruption, I also have it on my Ubuntu/Kubuntu hybrid machine (currently running/bugtesting kde 4.3RC2 but still using some gtk apps like FF3, OO.o and transmission). While it is quite annoying (and it would be nice if this got fixed), in honesty, there are more serious bugs I'm worried about, like the slow unminimizing bug, which, for now, I've worked around by updating my xorg to a PPA version for instance.