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

  • #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; 06-01-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; 06-02-2008, 01:42 PM.

            Comment


            • #21
              oblivious_maximus, have you already tried removing all the mtrr and other changes and just limiting memory usage to 3.5GB or so with the "mem=" boot command ? I don't know the details but apparently this has worked for a few people here. Having the SBIOS properly remap RAM is best but that doesn't seem to be available to everyone on the current generation of motherboards ;(

              EDIT - just found your other post where you asked for details on how to use the mem= line, and of course now I can't find any of the original posts by other people who had success with it. Auggh.

              Anyways, I would start with something simple like "mem=3000M" and see how that works.
              Last edited by bridgman; 06-02-2008, 01:58 PM.

              Comment


              • #22
                Finally i've got a solution for me:
                I've gone to the store, have returned the ati card and i've got a new nvidia 8800 gt, that's it

                GL

                Comment


                • #23
                  Originally posted by bridgman View Post
                  oblivious_maximus, have you already tried removing all the mtrr and other changes and just limiting memory usage to 3.5GB or so with the "mem=" boot command ?
                  I removed the script I was using to alter the mtrr, and I tried booting with mem=3072. free reported the correct amount of limited RAM, but the mtrr was exactly the same as before. I'm not sure what you mean by 'other changes.'
                  Code:
                  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
                  
                               total       used       free     shared    buffers     cached
                  Mem:          3043        201       2842          0          1         95
                  -/+ buffers/cache:        103       2940
                  Swap:          509          0        509
                  I also tried specifying that vesafb not use the mtrr. These are the kernel options I've used:
                  video=vesafb:nomtrr vga=791
                  video=vesafb:mtrr:0 vga=791
                  video=vesafb:nomtrr vga=791 mem=3072
                  I'm going to post this and try just mem=3072 now.. will edit shortly.

                  Comment


                  • #24
                    I just wasn't sure if you made any other changes; all these threads are starting to blur together

                    Sorry if I missed something, but are you having trouble running vesafb as well, not just fglrx ?

                    Comment


                    • #25
                      no, I just read (in some probably way out of date google hits) that there have been issues with vesafb only allotting a bare minimum of the actual available memory for its register. It's supposed to be write-combining though and I've never seen anything but write-back registers listed. I'm grasping at straws basically. Before that post I had just been using vga=791 so I figured I would mention the difference.

                      Apart from patching authatieventsd.sh when I install fglrx I can't think of any other changes I've been making.

                      I'm just back from trying only the mem=3072M option, with no others (apart from ro). There was no change to my mtrr registers so I tried it with mem=2560M and it's still exactly the same:
                      Code:
                      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
                      
                                   total       used       free     shared    buffers     cached
                      Mem:          2535        200       2334          0          1         95
                      -/+ buffers/cache:        103       2432
                      Swap:          509          0        509
                      To be clear I haven't plugged my 3650 in again since the post you were originally replying to bridgman(#18). It's(the mtrr) wrong (it is isn't it??) in exactly the same way with both cards, only the Nvidia card doesn't seem to care (I also read on some google hit that Nvidia doesn't use the mtrr with their driver so I guess that's why).
                      Last edited by oblivious_maximus; 06-02-2008, 08:08 PM.

                      Comment


                      • #26
                        My thinking was more along the lines of "ignore the mtrr's, boot with everything stock except the mem= kernel option and see if the card works "

                        Let me go through the thread again. I came in part way through and thought you were just wrestling with the usual "64 bit, >3GB RAM, graphics unhappy, no BIOS upgrade" blues.

                        Comment


                        • #27
                          Oh OK. Sorry for the absence of details, they are certainly spread out over the forum. My system specs are detailed in the first post of this thread, apart from the kernel/OS and videocard.

                          I'm using an Asus 8600GT and trying to replace it with a Sapphire HD3650 w/512MB ddr3 (the blue one reviewed here back when it was hot off the fab). I'm running Debian Lenny i386 now (which I think I mention at the end of that thread), with a bigmem kernel I built from Debian sources, version 2.6.25-4 (I generally just build the newest linux-source version when apt updates it). I remove a lot of hardware I don't have and Infinniband -type stuff, but my kernel is pretty much Debian defaults. That thread is another reason I don't really trust my motherboard to be properly functional, but I don't think there'd be much use in you reading it past my system specs.

                          Short summary of my HD3650 woes:
                          I originally (with fglrx 8-3 when I first bought it) had trouble logging out of KDE or starting Xservers additional to my KDE session (KDE on display :0.0, empty Xserver on dispaly :1.0), which both result in a big lockup. And that's what I've been dealing with ever since. zappbrannigan pointed out my mtrr might be the issue over a month ago. That and editing authatieventsd.sh to point to /var/run/xauth are the only leads I've had, the atieventsd change has no effect and I haven't been able to sort out /fully understand the mtrr yet. The mtrr changes I detailed in post #18 produced the first change in behaviour using the HD3650, but they're not an improvement.

                          Another reason I'm chasing this mtrr now is because everything resembling a guide I've looked at suggests removing all the registers before building them back up. As I mentioned in post #18, when I try to remove the first register my system locks up almost as badly as when logging out with fglrx (I can resuce it with the SysReq key at least). edit: maybe this is because I removed register 02 and 01 first? I'll try this too I guess...

                          I'll try the HD3650 and fglrx with mem=3072 and no other boot options now...
                          Last edited by oblivious_maximus; 06-02-2008, 08:44 PM.

                          Comment


                          • #28
                            I originally (with fglrx 8-3 when I first bought it) had trouble logging out of KDE or starting Xservers additional to my KDE session (KDE on display :0.0, empty Xserver on dispaly :1.0), and that's what I've been dealing with ever since.
                            Ahh, OK that helps. I wouldn't have thought those issues were related to each other, and neither of them sounds like mtrr-related problems.

                            There seem to be a few issues related to atieventsd, where different distros have different issues with the file. In some cases the contents need to be changed, and in others the permissions need to be changed (at least that's what I've seen so far).

                            re: starting a second X server, I'm not sure but I kinda thought we like to support multiple displays with a single server instance not multiple servers on the same card. Let me check that.

                            Comment


                            • #29
                              The multiple display setup I use should be driver independent if I'm not mistaken. I just use X's ability to launch new dispalys to different display devices. My xorg.conf defines a default ServerLayout which uses my monitor for display :0.0, and another ServerLayout that doesn't get used unless called manually with "X :1.0 -layout layoutname". The device section for my TV uses Nvidia's xorg.conf options for tvout (this is the only involvement of the Nvidia driver), in my xorg.conf for use with the ATI card I believe I have ATI equivalents of those config options in the TV's device section, but since it keeps locking up I can't really tell. I make use of this setup with a script I set Konqueror to open video files with, it launches the new xserver and then MPlayer with the video, and when MPlayer quits it kills the second Xserver. My monitor shuts off when the second Xserver launches (I can VT-switch between them) and it comes back up when the second Xserver is killed.

                              I'm pretty sure I've tried launching that second Xserver without involving my TV (just running "X :1.0") and had it lock up(this was with 8-3 probably), I'll try it again next time.

                              I just tried runing the HD3650 with no kernel boot options apart from "ro mem=3072M", it still locked up when I logged out.

                              I have previously tried the 3650 with only 2GB of RAM installed and it locked up then too...
                              Last edited by oblivious_maximus; 06-02-2008, 09:41 PM.

                              Comment


                              • #30
                                Sorry to jump in. But I've got a similar/same problem. Thought I would mention what I've tried. I can post log files (or links to log files upon request).

                                My system setup
                                ===============
                                Intel Q9450 (Stock speeds)
                                Asus P5K-E/Wifi
                                4GB of PC2-8500 (G.Skill Memory)
                                HIS 3870 (512MB 3870 AMD/ATi Graphics Card)
                                ===========================================

                                The memory restriction option doesn't work if memory remapping is enabled (even if the amount of memory is less than the 32-bit maximum memory). I've tried using all the drivers from 8.3 till 8.5 and there is no improvement. Since it appears that the driver itself is crashing I can't produce a backtrace (or a core file).

                                Most of the information is documented here, https://bugs.launchpad.net/ubuntu/+s...24/+bug/224404

                                Originally posted by oblivious_maximus View Post
                                The multiple display setup I use should be driver independent if I'm not mistaken. I just use X's ability to launch new dispalys to different display devices. My xorg.conf defines a default ServerLayout which uses my monitor for display :0.0, and another ServerLayout that doesn't get used unless called manually with "X :1.0 -layout layoutname". The device section for my TV uses Nvidia's xorg.conf options for tvout (this is the only involvement of the Nvidia driver), in my xorg.conf for use with the ATI card I believe I have ATI equivalents of those config options in the TV's device section, but since it keeps locking up I can't really tell. I make use of this setup with a script I set Konqueror to open video files with, it launches the new xserver and then MPlayer with the video, and when MPlayer quits it kills the second Xserver. My monitor shuts off when the second Xserver launches (I can VT-switch between them) and it comes back up when the second Xserver is killed.

                                I'm pretty sure I've tried launching that second Xserver without involving my TV (just running "X :1.0") and had it lock up(this was with 8-3 probably), I'll try it again next time.

                                I just tried runing the HD3650 with no kernel boot options apart from "ro mem=3072M", it still locked up when I logged out.

                                I have previously tried the 3650 with only 2GB of RAM installed and it locked up then too...
                                Last edited by kingtaurus; 06-03-2008, 03:04 AM. Reason: Clarification and Additions

                                Comment

                                Working...
                                X