Announcement

Collapse
No announcement yet.

AMD Catalyst Beats NVIDIA To Linux 3.12 Support

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

  • #41
    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 *);

    Comment


    • #42
      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.

      Comment


      • #43
        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.

        Comment


        • #44
          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)

          Comment


          • #45
            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.

            Comment


            • #46
              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.

              Comment


              • #47
                Originally posted by mmstick View Post
                It works fine in Ubuntu with 3.12-rc7.
                Not working in openSUSE with Kernel 3.12rc7!

                Comment


                • #48
                  work perfectly with Ubuntu 13.10 and kernel 3.12 rc7

                  Comment


                  • #49
                    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.

                    Comment


                    • #50
                      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.

                      Comment

                      Working...
                      X