Page 5 of 5 FirstFirst ... 345
Results 41 to 50 of 50

Thread: AMD Catalyst Beats NVIDIA To Linux 3.12 Support

  1. #41
    Join Date
    Jun 2010
    Location
    ฿ 16LDJ6Hrd1oN3nCoFL7BypHSEYL84ca1JR
    Posts
    1,050

    Default

    Builds fine for me on 3.12-rc7

    On archlinux:
    /usr/src/linux-3.12.0-1-mainline/include/linux/seq_file.h:ssize_t seq_read(struct file *, char __user *, size_t, loff_t *);

  2. #42
    Join Date
    Jan 2013
    Location
    Ontario, Canada
    Posts
    91

    Default

    Yeah, I did add #include <linux/seq_file.h> and it got me past that part, but the next failure is:

    kcl_iommu.c:191:28: error: 'struct dev_archdata' has no member named 'iommu'

    which I have to figure out (perhaps it's a kernel config issue), but I have to go watch the programming on the back of my eyelids now.

  3. #43
    Join Date
    Aug 2012
    Posts
    391

    Default

    Quote Originally Posted by Grogan View Post
    Linux 3.12-rc7 and Catalyst 13.11 Beta 6 do not work for me.

    I can probably get around this, but perhaps this is only the first fatal error in the module build:

    firegl_public.c:618:17: error: 'seq_read' undeclared here (not in a function)

    I am PISSED right off, too. I'm sick of this shit, every fucking time. It doesn't help that I always start doing shit like this at 4 AM when I shouldn't be, but this damned beta release is only a few weeks old and ought to be tested on 3.12-rc. If indeed it did work before, nothing like that (that would affect this) should change in the kernel interfaces when it's in -rc stages. If it does, Linus is supposed to call those people rude names.

    I haven't tracked down any patches for this yet (still looking) so I may have to fiddle.
    It works fine in Ubuntu with 3.12-rc7.

  4. #44
    Join Date
    Jun 2010
    Location
    ฿ 16LDJ6Hrd1oN3nCoFL7BypHSEYL84ca1JR
    Posts
    1,050

    Default

    Quote Originally Posted by Grogan View Post
    Yeah, I did add #include <linux/seq_file.h> and it got me past that part, but
    Maybe it would be better to fix the cause of the problem (something in your system isn't right) and not the symptoms.
    (But I have no idea what could be wrong, so better wait for someone who does)

  5. #45
    Join Date
    Jan 2013
    Location
    Ontario, Canada
    Posts
    91

    Default

    Quote Originally Posted by ChrisXY View Post
    Maybe it would be better to fix the cause of the problem (something in your system isn't right) and not the symptoms.
    (But I have no idea what could be wrong, so better wait for someone who does)
    My good guess is (but I don't have time to try it yet) because I have "supported processor vendors" selected, and have only Intel enabled. When I enable AMD processor support (or disable the supported processor vendors option), the GART IOMMU config option is available and set, and then the #ifdef in kcl_iommu.c would include the amd_iommu.h. I am probably expected to have that set. It has not been a problem until this though (I've been configuring my kernels that way for a long time). I don't actually NEED that, I have no hardware that needs that 32 bit DMA access.

    This is for the iommu related failure... not sure why it wouldn't have gotten the sequential read definitions from my kernel headers but it could also be a configuration related problem. (something "expected" to be enabled, like debugfs which also defines the seq_read and seq_lseek file ops) I know including a header that's not really supposed to be included directly isn't really "fixing" the problem, but what the Hell... fglrx is a kludge that does things in strange ways anyway)

    How dare I configure my kernel my own way. fglrx has been the biggest pain for forcing unwanted system configurations on me over the years.

  6. #46
    Join Date
    Jan 2013
    Location
    Ontario, Canada
    Posts
    91

    Default

    Quote Originally Posted by Grogan View Post
    My good guess is (but I don't have time to try it yet) because I have "supported processor vendors" selected, and have only Intel enabled. When I enable AMD processor support (or disable the supported processor vendors option), the GART IOMMU config option is available and set, and then the #ifdef in kcl_iommu.c would include the amd_iommu.h. I am probably expected to have that set. It has not been a problem until this though (I've been configuring my kernels that way for a long time). I don't actually NEED that, I have no hardware that needs that 32 bit DMA access.
    That didn't solve the problem. There was a time when the iommu was actually needed for fglrx, but it hasn't been in some time. The reason I don't like it is, it wastes 64 Mb of RAM for the bounce buffer (iommu emulated by software on Intel) and I don't need otherwise it.

    My toolchain is otherwise OK. I compile a lot of stuff (everything I use) so I doubt my system is broken. Catalyst 13.4 with kernel 3.8.11 (laziness... I liked that kernel so I stuck with it a long time) builds without issue.

    Using gcc 4.8.1

    My system is Slackware(ish) and I'm using the slackware packaging script in the catalyst archive (--buildpkg Slackware). Perhaps there's something wrong with the build environment with that path.

    Strange that it's working for others. I guess I'll just have to figure out a workaround.

  7. #47
    Join Date
    Sep 2007
    Location
    Athens-Hellas
    Posts
    253

    Default

    Quote Originally Posted by mmstick View Post
    It works fine in Ubuntu with 3.12-rc7.
    Not working in openSUSE with Kernel 3.12rc7!

  8. #48
    Join Date
    Feb 2012
    Location
    Barcelona, Spain
    Posts
    299

    Default

    work perfectly with Ubuntu 13.10 and kernel 3.12 rc7

  9. #49
    Join Date
    Jan 2013
    Location
    Ontario, Canada
    Posts
    91

    Default

    This just isn't well enough tested if it doesn't work against perfectly valid system configurations. I even went through and reconfigured my whole kernel from scratch, in case there was something not getting defined when migrating an old config. I don't have trouble compiling other third party modules against that kernel source tree either.

    I couldn't figure it out, so I just made the "ATI_API_CALL KCL_IOMMU_CheckInfo" function in kcl_iommu.c return 0, which is what it would be doing for me anyway with no iommu support.

    The driver is happy with that.

  10. #50
    Join Date
    Jan 2013
    Location
    Ontario, Canada
    Posts
    91

    Default

    OK, I'm bad. I figured out the iommu thing. What it was looking for was HARDWARE iommu support (and Intel processors don't actually have that "hardware"). So the Intel IOMMU is a software one that uses DMA remapping (DMAR). I had to redo the kernel today (3.12 released) so I enabled that, and sure enough, the module build doesn't barf on kcl_iommu.c. Silly, for I've never used that, but it made the fglrx build happy having the right defines.

    (I still had to #include <linux/seq_file.h> *shrug*. But I'll bet that's some other kernel config option that I don't care about that's caused that)

    I dislike having kernel config options forced on me.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •