Announcement

Collapse
No announcement yet.

Radeon HD 3870 + fglrx + 64 bit linux = crash

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

  • #21
    Just quick point, this isn't just an AMD/ATI problem because according to this bug report: https://bugs.launchpad.net/linux/+bug/210780 this also will cause problems with intel cards (not an outright crash).

    Originally posted by alec View Post
    https://bugs.launchpad.net/ubuntu/+s...24/+bug/224404

    And same problem here
    Gigabyte EX38 mobo, 4GB DDR2 and 3870 radeon. Works fine except with fglrx in 64bit linux.
    Who is to blame? Kernel? AMD? Intel?

    I hoped I could switch to linux 100%

    Comment


    • #22
      Originally posted by kingtaurus View Post
      Just quick point, this isn't just an AMD/ATI problem because according to this bug report: https://bugs.launchpad.net/linux/+bug/210780 this also will cause problems with intel cards (not an outright crash).
      Those bug reports lead me to think its either a 64-bit kernel issue, or a driver for recent intel chipsets (p35, x38, x48, maybe integrated versions too)
      I hope somebody is doing something

      Comment


      • #23
        My system has a Radeon HD3870 + fglrx + 64 bit on a gigabyte ga-ma790fx-ds5 & 4GB ram woks well with multiple boot fedora9/suse10.3/ubuntu8.4/windows-xp suse10.3 is default. I'm new to the linux scene maybe someone can advise what tests or info I can pass on to help.

        Comment


        • #24
          Originally posted by laurie View Post
          My system has a Radeon HD3870 + fglrx + 64 bit on a gigabyte ga-ma790fx-ds5 & 4GB ram woks well with multiple boot fedora9/suse10.3/ubuntu8.4/windows-xp suse10.3 is default. I'm new to the linux scene maybe someone can advise what tests or info I can pass on to help.
          Yes, your difference is AMD chipset. So far all reports have been on intel new chipsets

          Comment


          • #25
            Thank you SO MUCH for the information on this 4 GB problem. I was driving myself crazy trying to find a configuration that would work on my new system, but vesa, radeonhd, and fglrx all gave me varying degrees of graphics corruption when switching between X and console. More importantly, fglrx would crash my system unless I put Option NoAccel in my xorg.conf, for exactly the reasons described in this thread. Disabling the memory remapping feature in my BIOS solved the problem, and does indeed appear that Asus's bios is at fault.

            Specs:
            Intel Q6600
            Asus P5K Deluxe
            Mushkin 4GB RAM @ 1066Mhz
            Asus EAH3650 (ATI 3650)
            Gentoo Linux, amd64 architecture
            Driver version 8.493
            Kernel 22.6.24-r8
            Xorg X11 7.2

            When I had mtrr enabled in the kernel, I did in fact get a message at boot indicating that the bios's information was incorrect and was therefore ignored. The Option NoMTRR line I had in my xorg.conf apparently wasn't enough, or was ignored by all but the vesa driver.

            The MTRR table in /proc before I disabled remapping was identical to the one provided earlier by zappbrannigan.

            As an afterthought, I'd like to take this opportunity to embarass Asus by reminding everyone how awful their webpage is. The bios update download page is literally an unprofessional blank containing no information, as if someone forgot to administer their CMS.

            I was on the verge of ditching this card. Thank you again.

            Comment


            • #26
              Did I understand correctly? If I fix mtrr tables there will be no performance loss or usable memory size loss?

              I already went on to search a good x86 distro. But I like to have the most out of my rig, so x64 is always preferred.

              Comment


              • #27
                I have a gigabyte X48-DQ6 board, and my mtrr is as follows:
                reg00: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
                reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
                reg02: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
                reg03: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
                reg04: base=0x130000000 (4864MB), size= 256MB: uncachable, count=1
                reg05: base=0xcff00000 (3327MB), size= 1MB: uncachable, count=1
                if i use the "nv" driver, i get this kernel message when starting X: "mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining"

                I actually do have a slight problem. It appears my graphics card (a quadro fx 3400m) Doesent properly work, as in, untill the nvidia drivers are loaded, all output is completely garbled (this goes during POST and grub and stuff aswell). I figured this is just the card being weird, since it works with other nvidia cards..

                I am planing to throw in a radeon hd card at some very near point..

                Should i expect these problems?

                Comment


                • #28
                  I would think so. I don't know if this bug affects the radeonhd (open source driver), but if you are planning on using the fglrx driver.

                  Originally posted by Redeeman View Post
                  I have a gigabyte X48-DQ6 board, and my mtrr is as follows:


                  if i use the "nv" driver, i get this kernel message when starting X: "mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining"

                  I actually do have a slight problem. It appears my graphics card (a quadro fx 3400m) Doesent properly work, as in, untill the nvidia drivers are loaded, all output is completely garbled (this goes during POST and grub and stuff aswell). I figured this is just the card being weird, since it works with other nvidia cards..

                  I am planing to throw in a radeon hd card at some very near point..

                  Should i expect these problems?
                  Last edited by kingtaurus; 17 June 2008, 05:58 PM.

                  Comment

                  Working...
                  X