black screen with kubuntu 8.04 x86_64 and fglrx 8.5

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.

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

Quote:

---

Originally Posted by bridgman

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.

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 ?

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).

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.

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...

Quote:

---

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.

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...

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

Quote:

---

Originally Posted by oblivious_maximus

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...

---