Announcement

Collapse
No announcement yet.

request: patch for catalyst (10.7) to get 2.6.36-rc* working

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • request: patch for catalyst (10.7) to get 2.6.36-rc* working

    Hi guys,

    anyone has already a patch to get the fglrx / catalyst drivers to work with 2.6.36-rc* kernels ?

  • xming
    replied
    Originally posted by Kano View Post
    My script has this patch now included:

    http://launchpadlibrarian.net/561998...010-3081.patch
    Thanks for the patch, it works here on gentoo, for other gentoo users, please see ebuild here.

    Leave a comment:


  • Kano
    replied
    My script has this patch now included:

    http://launchpadlibrarian.net/561998...010-3081.patch

    Leave a comment:


  • RemcoL
    replied
    Originally posted by bridgman View Post
    I don't think there is a good way to do that (at least nothing yet). The patch that caused problems wrapped the arch-specific compat_alloc_user_space calls with a new, common call which included a security fix (yay !), but that new call was then marked GPL-only so we can't use it from fglrx (boo !).

    If the routine that "everyone thinks we should be using" has been marked GPL-only there may not be a better solution than what Evan implemented, which is continuing to use the arch_ call but implementing a similar security fix. A number of other options have been discussed but right now all of them seem worse.
    Since CVE-2010-3081 is a high impact vulnerability, it's now getting into pretty much every kernel, not just the experimental ones. With the difference between the arch and non-arch version being a non-working fglrx, what are the implications of changing it?

    From your reply it looks like there is no way to get it working 'the right way' at the moment. With the fglrx release cycle of multiple months and the fact that *all* previous releases are also affected, will we really have to wait until next year for acceleration without this gaping security hole? Or is a security release of fglrx a real possibility?

    Leave a comment:


  • nanonyme
    replied
    Originally posted by hdas View Post
    Argh, looks like they did this to 2.6.35.5 too. Why do they do such stuff in stable kernels. It is stupid to keep up with these kind of changes for 3rd party software in general.
    Because while apparently at least some developers accept the reality that binary drivers exist, most of them don't feel feel responsibility to keep the kernel API's from breaking things for out-of-tree stuff, let alone binary drivers?

    Leave a comment:


  • hdas
    replied
    Argh, looks like they did this to 2.6.35.5 too. Why do they do such stuff in stable kernels. It is stupid to keep up with these kind of changes for 3rd party software in general.

    Anyway, thanks for all the help here .

    Leave a comment:


  • kernelOfTruth
    replied
    Originally posted by bridgman View Post
    I don't think there is a good way to do that (at least nothing yet). The patch that caused problems wrapped the arch-specific compat_alloc_user_space calls with a new, common call which included a security fix (yay !), but that new call was then marked GPL-only so we can't use it from fglrx (boo !).

    If the routine that "everyone thinks we should be using" has been marked GPL-only there may not be a better solution than what Evan implemented, which is continuing to use the arch_ call but implementing a similar security fix. A number of other options have been discussed but right now all of them seem worse.
    you're right,

    IMO it's pretty user-unfriendly to do this kind of stuff: this also effectively prevents using lock tracking:

    [ ] Lock debugging: detect incorrect freeing of live locks
    [ ] Lock debugging: prove locking correctness
    [ ] Lock usage statistics

    why is there no problem with nvidia and their binary blob ?

    in the past when I had this enabled it nevertheless worked

    do they mark parts of their driver GPL or some other kind of black magic ?

    anyways: if that's the only (best of all) way(s) to do it - then leave it at that ...

    Thanks !

    Leave a comment:


  • bridgman
    replied
    I don't think there is a good way to do that (at least nothing yet). The patch that caused problems wrapped the arch-specific compat_alloc_user_space calls with a new, common call which included a security fix (yay !), but that new call was then marked GPL-only so we can't use it from fglrx (boo !).

    If the routine that "everyone thinks we should be using" has been marked GPL-only there may not be a better solution than what Evan implemented, which is continuing to use the arch_ call but implementing a similar security fix. A number of other options have been discussed but right now all of them seem worse.

    Leave a comment:


  • kernelOfTruth
    replied
    New compat_alloc_user_space() GPLness and fglrx
    <--

    @bridgman:

    could you please tell the devs for the proprietary driver / fglrx to fix it that it won't leave a security-hole open in the kernel with versions newer than 2.6.36-rc4-git2+ ?

    thanks !

    Leave a comment:


  • Apfelkuchen
    replied
    Hi all,

    I have had the same problem as descriped in the first post.
    The patch later on worked for me an 2.6.36-rc3.

    But now I have the following issu.
    My system looks like this
    - one installation on internel hdd - as working system
    - and the same at an externel hdd (copied via cp -a) - as experimental system

    The above things worked well on the external system and I could start X, so I wanted to get the same one the internal installation.

    Build and install with dkms worked well but when starting X I get the following error
    "fglrx incompatible kernel module detected"

    (as mentioned both systems run the same kernel-image 2.6.36-rc3)

    I found another forum where this issue is discriped but the final answer is missing and I can't get behind it.(http://www.linux-club.de/viewtopic.p...107085&start=0)

    Would be great if anyone could give me a hint :-)

    bye

    Leave a comment:

Working...
X