Announcement

Collapse
No announcement yet.

Support for kernel 2.6.29?

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

  • #21
    Interesting way, can you create a better 2.6.29 patch too without new includes?

    Comment


    • #22
      Originally posted by sobkas View Post
      I think you are talking about "pci_enable_msi".
      I just make small place holder function like this:
      #undef pci_enable_msi
      int pci_enable_msi(struct pci_dev *pdev)
      {
      int pci_out;
      pci_out=pci_enable_msi_block(pdev, 1);
      return pci_out;
      }
      and add it somewhere in fglrx module.
      I don't guarantee that it will actually work because last time I checked this, I was on 2.6.30-rc2 and since then I deleted my patch.
      Hmm, I don't essentially see why the '#define pci_enable_msi(pdev) pci_enable_msi_block(pdev, 1)' from the kernel sources should work different from the code you gave. That is, as far as I can see your code is the same as

      #undef pci_enable_msi
      int pci_enable_msi(struct pci_dev *pdev)
      {
      return pci_enable_msi_block(pdev, 1);
      }

      which should be the same as the macro, no?
      ps. The macro was checked from linux-2.6.30-rc5
      Edit: Btw, make sure you have CONFIG_PCI_MSI in kernel enabled or none of this will work. Iirc Catalyst warned about it at one point.
      Last edited by nanonyme; 09 May 2009, 03:18 PM.

      Comment


      • #23
        Originally posted by nanonyme View Post
        Hmm, I don't essentially see why the '#define pci_enable_msi(pdev) pci_enable_msi_block(pdev, 1)' from the kernel sources should work different from the code you gave. That is, as far as I can see your code is the same as

        #undef pci_enable_msi
        int pci_enable_msi(struct pci_dev *pdev)
        {
        return pci_enable_msi_block(pdev, 1);
        }

        which should be the same as the macro, no?
        ps. The macro was checked from linux-2.6.30-rc5
        Edit: Btw, make sure you have CONFIG_PCI_MSI in kernel enabled or none of this will work. Iirc Catalyst warned about it at one point.
        A macro is just a macro. It's instruction for preprocessor to replace one text with another and preprocessor only works on source code.
        It wasn't meant to even touch binaries.

        With fglrx the main problem is that the pci_enable_msi is used by binary only module:
        nm libfglrx_ip.a.GCC4|grep pci_enable_msi
        U pci_enable_msi
        There must be function called pci_enable_msi or module wont work.

        In short macro is provided to keep API backward compatible while changing ABI.
        Essentially preprocessor just replace text "pci_enable_msi(pdev)" with "pci_enable_msi_block(pdev, 1)".
        RBEU #1000000000 - Registered Bad English User

        Comment


        • #24
          Originally posted by sobkas View Post
          A macro is just a macro. It's instruction for preprocessor to replace one text with another and preprocessor only works on source code.
          It wasn't meant to even touch binaries.

          With fglrx the main problem is that the pci_enable_msi is used by binary only module:
          nm libfglrx_ip.a.GCC4|grep pci_enable_msi
          U pci_enable_msi
          There must be function called pci_enable_msi or module wont work.

          In short macro is provided to keep API backward compatible while changing ABI.
          Essentially preprocessor just replace text "pci_enable_msi(pdev)" with "pci_enable_msi_block(pdev, 1)".
          Point taken. You don't still need the integer though, right?

          Comment


          • #25
            Originally posted by nanonyme View Post
            Point taken. You don't still need the integer though, right?
            What integer?
            You are talking about "int pci_out;"?
            Not really, I just like this way of writing functions(debugging and all).
            RBEU #1000000000 - Registered Bad English User

            Comment


            • #26
              Originally posted by energyman View Post
              why? is there someone forcing you the latest kernels? Or is it just a bad case of versionitis?
              I think they should support a new kernel as soon as it is stable. They have to do it anyway sooner or later. Why not just do it sooner? When there is a newer kernel I want to use it, there is no good reason except that I want to use the latest kernel without using unofficial patches. If people can make their own patches for newer kernels it should be very easy for AMD devs to do it.

              Comment


              • #27
                Originally posted by sobkas View Post
                What integer?
                You are talking about "int pci_out;"?
                Not really, I just like this way of writing functions(debugging and all).
                Fair enough, I guess I was just being a prick. Nice work. (Another question, could this also be done with an inline function? I never got to test since I didn't get my sources to compile. Will try again later in a week)

                Comment


                • #28
                  Originally posted by nanonyme View Post
                  Nice work. (Another question, could this also be done with an inline function? I never got to test since I didn't get my sources to compile. Will try again later in a week)
                  Inline is used to insert body of the function in place where it's called to reduce amount of jumps(more or less).
                  It would be really hard to do it within a pre-compiled binary.

                  BTW. If there is no pressing need I allow compiler to choose whatever to inline or not a function.
                  RBEU #1000000000 - Registered Bad English User

                  Comment


                  • #29
                    In order to run fglrx i had to patch the kernel:

                    Code:
                    diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
                    index 61ddfa0..3d26c0b 100644
                    --- a/arch/x86/mm/tlb.c
                    +++ b/arch/x86/mm/tlb.c
                    @@ -279,6 +279,7 @@ void flush_tlb_page(struct vm_area_struct *vma, unsigned long va)
                    
                            preempt_enable();
                     }
                    +EXPORT_SYMBOL(flush_tlb_page);
                    
                     static void do_flush_tlb_all(void *info)
                     {
                    if somebody knows a better solution let me know. I still get errors in dmesg - 2 on start of any 3d app, 1 on close. Like:

                    Code:
                    [fglrx:firegl_find_any_map] *ERROR* Invalid map handle!<3>[fglrx:drm_vm_open] *ERROR* map not found -> inconsistent kernel data!!! vma_start:0xadbce000,handle:0xebcba000
                    No idea how to fix that.
                    Last edited by Kano; 11 May 2009, 08:27 AM.

                    Comment


                    • #30
                      ugh I need some help here, downgrading my kernel/xorg just leaves me with a broken archbox (lots of broken dependencies).

                      Also my worst problem right now is that my fans are constantly spinning at full speed (cant regulate - sony vaio here), yes i'm talking about the GPU fan. Also running any video in full screen with vlc/mplayer crashes my entire computer, have to shutdown usin the power button

                      Any ideas?

                      Linux archbox 2.6.29-ARCH #1 SMP PREEMPT Wed Apr 29 15:36:46 CEST 2009 x86_64 Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz GenuineIntel GNU/Linux

                      Comment

                      Working...
                      X