Announcement

Collapse
No announcement yet.

black screen with kubuntu 8.04 x86_64 and fglrx 8.5

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

  • #11
    Originally posted by zappbrannigan View Post
    Try this:
    - boot system without framebuffer
    - remove every mtrr entry with "echo disable ...."
    - start x-server with "X" or "startx" witch takes hours
    If this works your mainboard has the mtrr issue.
    I've tried this, and after a looot of time X server has been able to launch, but many processes have failed (such as kicker or kdesktop).

    At startx's output i've seen a pair of messages:
    - FATAL: could not open /lib/modules/2.6.24-17-generic/volatile/fglrx.ko: no such file or directory. Kernel was updated a few days ago and i've not reinstalled the driver, so i think this makes sense.
    - fglrx(0): firegl_SetSuspendResumeState FAILED -1003. (i don't know xD)

    Some messages at Xorg.log:

    ...

    drmOpenDevice: node name is /dev/dri/card0
    drmOpenDevice: open result is -1, (No such device or address)
    drmOpenDevice: open result is -1, (No such device or address)
    drmOpenDevice: Open failed

    ...

    (WW) fglrx(0): Failed to open DRM connection
    (II) fglrx(0): [FB] Find the MC FB aperturs range(MCFBBase = 0xc0000000, MCFBSize = 0x20000000)
    (--) fglrx(0): VideoRAM: 262144 kByte, Type: DDR4
    (II) fglrx(0): PCIE card detected

    ... (hmm 256 MB again??)

    (**) fglrx(0): ATI GART size: 255 MB
    (WW) fglrx(0): No DRM connection for driver fglrx.
    (II) fglrx(0): [drm] DRM buffer queue setup: nbufs = 100 bufsize = 65536

    ...

    (II) fglrx(0): driver needs X.org 7.1.x.y with x.y >= 0.0
    (II) fglrx(0): detected X.org 7.1.0.90
    (EE) fglrx(0): atiddxDriScreenInit failed, GPS not been initialized.
    (WW) fglrx(0): ***********************************************
    (WW) fglrx(0): * DRI initialization failed! *
    (WW) fglrx(0): * (maybe driver kernel module missing or bad) *
    (WW) fglrx(0): * 2D acceleraton available (MMIO) *
    (WW) fglrx(0): * no 3D acceleration available *
    (WW) fglrx(0): ********************************************* *

    ...

    (WW) fglrx(0): Textured Video not supported without DRI enabled.
    (WW) fglrx(0): Video Overlay not supported on AVIVO based graphics cards. For XVideo support use Option "TexturedVideo".

    ...


    So, what can i do? 256 MB card?? probably MTRR issue here, with gigabyte x48-dq6 (bios F6)? what config values must be used for it? (considering that i don't know the meaning of some entries at my /proc/mtrr file)

    Regards

    Comment


    • #12
      Here we can see the contents of /proc/mtrr on a computer that is EXACTLY the same as mine, but having ubuntu 8.04 x86_64 (gnome instead of kde) and with a nvidia card 8800gt w 512 mb of RAM (his installation has no known problems related to the card or the nvidia driver, even having also the same bios version, that is, F6):

      reg00: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
      reg01: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
      reg02: base=0x100000000 (4096MB), size=4096MB: write-back, count=1
      reg03: base=0x200000000 (8192MB), size=1024MB: write-back, count=1
      reg04: base=0xbff00000 (3071MB), size= 1MB: uncachable, count=1

      And that's the card's related info from lspci -v:

      01:00.0 VGA compatible controller: nVidia Corporation GeForce 8800 GT (rev a2) (prog-if 00 [VGA controller])
      Subsystem: ASUSTeK Computer Inc. Unknown device 8267
      Flags: bus master, fast devsel, latency 0, IRQ 16
      Memory at de000000 (32-bit, non-prefetchable) [size=16M]
      Memory at c0000000 (64-bit, prefetchable) [size=256M]
      Memory at dc000000 (64-bit, non-prefetchable) [size=32M]
      I/O ports at 9000 [size=128]
      [virtual] Expansion ROM at df000000 [disabled] [size=128K]
      Capabilities: <access denied>

      Why is also showing a 256 mb card? maybe a problem with the bios (or its config)? Anyway we both can see 512 mb cards on windows.

      Regards

      Comment


      • #13
        Here we can see a screenshot at the other computer:


        The ram that appears looks fine, so probably nvidia somehow ignores the info from lspci, because at mtrr it's defining a 1 GB range, while the card has only 512 mb (maybe it's reserving extra directions for some ports).
        Anyway, it's working, and seems to use all the card's memory.

        Regards
        Last edited by Mamonetti; 29 May 2008, 04:34 PM.

        Comment


        • #14
          Originally posted by Mamonetti View Post
          I've tried this, and after a looot of time X server has been able to launch, ...
          In other words: the driver works with a modified mtrr table.

          Originally posted by Mamonetti View Post
          - FATAL: could not open /lib/modules/2.6.24-17-generic/volatile/fglrx.ko: no such file or directory. Kernel was updated a few days ago and i've not reinstalled the driver, so i think this makes sense.

          Originally posted by Mamonetti View Post
          ... (hmm 256 MB again??)
          The 256 mb doesn't matter. Don't waste your time with other systems. You need to change your mtrr from:

          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=4096MB: write-back, count=1
          reg04: base=0x200000000 (8192MB), size=1024MB: write-back, count=1
          reg05: base=0x230000000 (8960MB), size= 256MB: uncachable, count=1
          reg06: base=0xcff00000 (3327MB), size= 1MB: uncachable, count=1

          into:
          base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
          base=0x80000000 (2048MB), size=1024MB: write-back, count=1
          base=0xc0000000 (3072MB), size= 128MB: write-back, count=1
          base=0x__000000 (3___MB), size= 64MB: write-back, count=1
          base=0x__000000 (3___MB), size= 32MB: write-back, count=1
          base=0x100000000 (4096MB), size=4096MB: write-back, count=1
          base=0x200000000 (8192MB), size=512MB: write-back, count=1
          base=0x___000000 (8___MB), size=256MB: write-back, count=1

          You need to calculate and replace the underlines.

          Comment


          • #15
            Hmm in my config you can see overlapping ranges, while at the one you provide it doesn't happen. What's the meaning of this?

            All ranges should sum at least 8 GB?

            Why there's no range at base=0xd0000000 of at least 512 MB of the card's ram?

            How did you get those values for every range length?

            Why are you adding 8 entries instead of the original 7?

            I'm sorry, but i don't get the key. I believe every entry is representing an address
            range for a "device". 2 ranges of 4 GB may be for system's RAM, 512 MB for vga RAM,
            and i don't know who is putting there the other entries. Is this only used for
            system RAM and vga RAM? or info of other devices also appears at this file?

            Thx and regards
            Last edited by Mamonetti; 30 May 2008, 05:40 PM.

            Comment


            • #16
              I've tried with this values:
              reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
              reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
              reg02: base=0xc0000000 (3072MB), size= 128MB: write-back, count=1
              reg03: base=0xc8000000 (3200MB), size= 64MB: write-back, count=1
              reg04: base=0xcc000000 (3264MB), size= 32MB: write-back, count=1
              reg05: base=0x100000000 (4096MB), size=4096MB: write-back, count=1
              reg06: base=0x200000000 (8192MB), size= 512MB: write-back, count=1
              reg07: base=0x220000000 (8704MB), size= 256MB: write-back, count=1

              The X server starts, but for some time i can see a few fuzzy boxes..
              After some time a rectangle of close to 40 pixels having all the width
              of the screen at the bottom of the screen can be shown. This area seems
              to be bad repainted, and almost every time is showing garbage.

              Besides the computer freezes when going to reboot, and i haven't found
              any "important" warning message at Xorg.log.

              What do you think?

              Regards

              Comment


              • #17
                Well, another test:

                My /proc/mtrr file looks like:

                reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
                reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
                reg02: base=0x100000000 (4096MB), size=4096MB: write-back, count=1
                reg03: base=0x200000000 (8192MB), size=1024MB: write-back, count=1

                X server starts, but as previously i have a 40 pixels height rectangle that doesn't update fine at the bottom of the screen

                What do you think? it seems the last part of the vga ram is not being updated as it should, or "someone" is writing there (i don't think that's it).

                Any idea?

                In the meantime i believe MTRR indicates the CPU not only th caching strategy, but also the virtual address range for each region. So the idea is to reserve a hole for I/O direct device mapping, that also includes the screen ram mapping. The bigger of your card's ram the bigger the hole you need, so in this config i'm reserving a full gb hole, which should be big enough for all the card memory and every direct I/O mapping of my computer. If that's true the sum of the ranges sizes must match the amount of your system ram. According to this config i'm scrolling the 5 top gbs of system ram from 3 gb offset to 4 gb offset in order to get the 1 gb hole. It that's true you could even take those 5 gbs to an offset bigger than 4 gb (maybe 8 gb if you prefer).

                Of course correct me if i'm wrong.

                Regads

                Comment


                • #18
                  You might want to now try the 8-4 driver. There seems to some corruption issues with 8-5 that weren't there before.

                  edit:
                  Can someone please help me with this mtrr stuff? I can't for the life of me figure where you guys are getting the values for these ranges. I have 4GB of memory and 512MB on my video card, by default my mtrr looks like this:

                  reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
                  reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
                  reg02: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1

                  I can disable reg02 and reg01, but if I try to disable reg00 my computer locks up. That's in single user mode with no framebuffer. I figured I would try to work with it so I created a new reg01 of 2048MB, like so:

                  echo "disable=02" > /proc/mtrr
                  echo "disable=01" > /proc/mtrr
                  echo "base=0x0080000000 size=0x0080000000 type=write-back" > /proc/mtrr

                  I put that in an init script (well, just those commands only, in a bourne script) which gave me an mtrr like this on boot:

                  reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
                  reg01: base=0x80000000 (2048MB), size=2048MB: write-back, count=1

                  I then decided it was time to try plugging in my HD3650 again. Instead of a big lockup when logging out, I got what seems to be the same black screen on X startup as Mamonetti, with a flashing cursor in the top left corner. VT-switching doesn't work, but at least the Magic Sys Request key does. I rebooted into single user mode again, and added a register of 512MB for the video card and continued the boot process. I got the same blank screen as before. This is the command I used for reg02:

                  echo "base=0x100000000 size=0x0020000000 type=write-combining" > /proc/mtrr

                  It looked correct afterward when I ran 'cat /proc/mtrr' (reg02 had a base@4096MB and was 512MB), but then I only just barely understand this thing. In the end it made no difference and I still got the same black screen instead of KDM. I wanted to try sticking the 512MB register in between the two 2048MB registers, but since I needed to login to X to find out the hexadecimal translation of 2560(x1024x1024), I just plugged in my 8600GT again (sigh) and hoped posting here would prove more fruitful than my thusfar useless attempts to figure this out.

                  My 8600GT doesn't seem to care either way, it's always ran pretty swimmingly with the default mtrr at the top, and it seems to be doing the same right now with the dual 2048MB register mtrr too.

                  -Where do I get the correct base/size numbers appropriate for my system?
                  -Can lspci or hwinfo tell me this stuff?
                  -Why can't I remove reg00 without my system locking?
                  -Should I not remove any registers and instead just add(to the default mtrr at the top) another 256MB register and 2 512MB registers (one for the remaining 512MB of my RAM and the other for the video card)??
                  -Should all the registers be write-back only?
                  -How do I know when it's correct? - is there a way to know without swapping out my video card first?
                  Last edited by oblivious_maximus; 01 June 2008, 09:30 PM.

                  Comment


                  • #19
                    From what I hear mtrr fiddling gives a performance hit, maybe worse than memory remap in bios. That is not a solution, really.

                    Comment


                    • #20
                      Well it's not like I want to be fiddling with it. Without fiddling(while using my ATI card), I can't log out without a massive lockup. With the fiddling I detailed above, I can't even log in(again, while using my ATI card). Seems like a decent indicator that if I can get a less-completely-incorrect mtrr going, I might be able to login AND logout without issue when using my ATI card.

                      If Asus hadn't decided to remove the memore hole remapping option from the BIOS of my motherboard, I'd certainly prefer tweaking that option instead... but in their infinite wisdom about what people don't need, they removed it.

                      edit: Asus has Linux tech support department! Unfortunately they're not very helpful.
                      Last edited by oblivious_maximus; 02 June 2008, 01:42 PM.

                      Comment

                      Working...
                      X