ATI Radeon 9200 / 9250 PCI black screen and console freeze with DRI

[Mike Agnew]

Binary package hint: xserver-xorg-video-ati

I have a (Club 3d) ATI Radeon 9250 PCI 128MB (in an old Dell Optiplex GX1 with 384MB so PCI was the only option). Am running feisty with xserver-xorg-video-ati 1:6.6.3 installed.
Vesa driver works OK; ati driver gives a black screen and console freeze every time I try.
If I disable "dri" in xorg.conf then I can use the ati driver but then I guess that's almost the same as vesa. So not good performance of any kind since driver is not writing directly to the Radeon 9250 card.

I can attach the xorg.cong that I am using which has "dri" disabled if required. Also, I did look at my /var/log/Xorg.0.log and really did not see any errors when I had the back screen. Can append this too.

PS I did try using 'fglrx' but was not successful due to version incompatibilities. (Could not really install the last ATI Radeon driver 8.28.8 that works for the 9250 in feisty - the new ATI Radeon driver is too new for the 9250). Ended up re-installing feisty to get back to where I am now to make sure all my libraries were OK.

[AdeDidou (adelineenileda)]

My configuration :
HP dx200MT with ATI Radeon 9250 PCI (Screen :Daewoo Sensy)

OS : Ubuntu Feisty

$ uname -a
Linux didou-pentium 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 GNU/Linux

$ dmesg | grep drm
[ 53.230050] [drm] Initialized drm 1.1.0 20060810
[ 53.255885] [drm] Initialized radeon 1.25.0 20060524 on minor 0
[ 58.215199] [drm] Setting GART location based on new memory map
[ 58.215867] [drm] Loading R200 Microcode
[ 58.215938] [drm] writeback test succeeded in 2 usecs
[ 761.673810] [drm] Setting GART location based on new memory map
[ 761.674712] [drm] Loading R200 Microcode
[ 761.674779] [drm] writeback test succeeded in 2 usecs
[ 806.227550] [drm] Setting GART location based on new memory map
[ 806.228481] [drm] Loading R200 Microcode
[ 806.228549] [drm] writeback test succeeded in 2 usecs
[ 1479.968053] [drm] Setting GART location based on new memory map
[ 1479.969205] [drm] Loading R200 Microcode
[ 1479.969275] [drm] writeback test succeeded in 1 usecs
[ 1613.605317] [drm] Setting GART location based on new memory map
[ 1613.606414] [drm] Loading R200 Microcode
[ 1613.606485] [drm] writeback test succeeded in 1 usecs

$ sudo scanpci
pci bus 0x0000 cardnum 0x00 function 0x00: vendor 0x8086 device 0x2570
 Intel Corporation 82865G/PE/P DRAM Controller/Host-Hub Interface
pci bus 0x0000 cardnum 0x02 function 0x00: vendor 0x8086 device 0x2572
 Intel Corporation 82865G Integrated Graphics Controller
pci bus 0x0000 cardnum 0x1d function 0x00: vendor 0x8086 device 0x24d2
 Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1
pci bus 0x0000 cardnum 0x1d function 0x01: vendor 0x8086 device 0x24d4
 Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2
pci bus 0x0000 cardnum 0x1d function 0x02: vendor 0x8086 device 0x24d7
 Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #3
pci bus 0x0000 cardnum 0x1d function 0x03: vendor 0x8086 device 0x24de
 Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #4
pci bus 0x0000 cardnum 0x1d function 0x07: vendor 0x8086 device 0x24dd
 Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller
pci bus 0x0000 cardnum 0x1e function 0x00: vendor 0x8086 device 0x244e
 Intel Corporation 82801 PCI Bridge
pci bus 0x0000 cardnum 0x1f function 0x00: vendor 0x8086 device 0x24d0
 Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge
pci bus 0x0000 cardnum 0x1f function 0x01: vendor 0x8086 device 0x24db
 Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller
pci bus 0x0000 cardnum 0x1f function 0x03: vendor 0x8086 device 0x24d3
 Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller
pci bus 0x0001 cardnum 0x00 function 0x00: vendor 0x1002 device 0x5960
 ATI Technologies Inc RV280 [Radeon 9200 PRO]
pci bus 0x0001 cardnum 0x00 function 0x01: vendor 0x1002 device 0x5940
 ATI Technologies Inc RV280 [Radeon 9200 PRO] (Secondary)
pci bus 0x0001 cardnum 0x01 function 0x00: vendor 0x13f6 device 0x0111
 C-Media Electronics Inc CM8738
pci bus 0x0001 cardnum 0x02 function 0x00: vendor 0x14f1 device 0x2f01
 Conexant Device unknown
pci bus 0x0001 cardnum 0x08 function 0x00: vendor 0x8086 device 0x1050
 Intel Corporation 82562EZ 10/100 Ether...

[AdeDidou (adelineenileda)]

Created an attachment (id=9885)
xorg.conf

[AdeDidou (adelineenileda)]

Created an attachment (id=9886)
Xorg.0.log.old (with a crash)

[AdeDidou (adelineenileda)]

Thanks for your help...

Adeline

[Timo Jyrinki (timo-jyrinki-hut)]

Not sure if it helps in this particular problem, but you might try to edit your xorg.conf and comment out / remove the line that says 'Load "dri"'. Then you don't have accelerated 3D, but it'd be worth trying out if it helps in this.

This might be a duplicate of bug 6111, but there's a lot of noise (unrelated to the original reporter's problem) there. A hint from there, which is probably unrelated to you since you already have a PCI card, is to add Option "BusType" "PCI" to the Driver-section.

[Glisse (glisse)]

What driver do you want to use ? Your log say you use radeon open source driver,
your message say you want to use fglrx. We do not provide support for fglrx.
Because we can't and don't want to. If you want to try with the open source
driver please try to strip down your card configuration to the following:

Section "Device"
 Identifier "HIS (Ati) Radeon 9250 PCI"
 BusID "PCI:1:0:0"
 Driver "radeon"
 Option "GARTSize" "64"
 Option "EnablePageFlip" "1"
 Option "ColorTiling" "1"
EndSection

[Timo Jyrinki (timo-jyrinki-hut)]

(In reply to comment #6)
> What driver do you want to use ? Your log say you use radeon open source
> driver,

Like it was said, she was using fglrx before because the hang problems. Now that ATI dropped support for 8500-9250 series of cards, it's again being tried to use open source drivers, but the old hanging/blackscreen problem persists.

So, despite the fglrx mentions, this report is about the open source driver and wishes for instructions how to get it not to hang.

Anyway, indeed in addition to my hint, it might be worthwhile to "clean" the driver section to just include the Identifier, Driver and BusID, which are the only ones that should be really needed. Just in case some of the options cause any trouble.

Also, Driver can be just "ati" instead of "radeon", though it should not matter.

[AdeDidou (adelineenileda)]

(In reply to comment #5)
> add Option "BusType"
> "PCI" to the Driver-section.
>
I add it :
Section "Device"
 Identifier "HIS (Ati) Radeon 9250 PCI"
 BusID "PCI:1:0:0"
 Driver "radeon"
 Option "BusType" "PCI"
 Option "AccelMethod" "XAA" # Use XFree86 Acceleration Architecture
 Option "AccelDFS" "1" # mettez à 0 si vous avez une carte AGP
 Option "GARTSize" "64"
#Fait sauter mon ordinateur Option "RingSize" "8"
 Option "BufferSize" "2"
 Option "EnablePageFlip" "1" # Enable page flipping for 3D apps
 Option "ColorTiling" "1"
 Option "EnableDepthMoves" "yes"
 Option "UseFBDev" "false"
 Option "RenderAccel" "true" # Enable the hardware render acceleration
 Option "mtrr" "on"
 Option "SubPixelOrder" "none"
 Option "DPMS"
 Option "DynamicClocks" "on"
# Option "VideoOverlay" "on"
# Option "OpenGLOverlay" "off"
EndSection

For the moment it's good but I need to try more time

Thanks

And sorry for my bad English... Yes I want to use the oepn driver ;)

[AdeDidou (adelineenileda)]

> For the moment it's good but I need to try more time
>
>
No it's not the solution, I have the same problem even if I add Option "BusType" "PCI"...

Have you a other proposition ?

When I see the xorg.log.0, I see that the driver radeon support the 9250 (AGP) but I don't see that it support the 9250 (PCI) it's wright or not ?

Thanks

[Glisse (glisse)]

Did you try with device section as proposed in comment 6 ?
Please try this, you really have too much options; so it's
hard to understand from where the issue likely come.

Btw i am not sure i fully understand your issue, you have
a black screen after some times, is this after some times
of inactivity ? If so then this likely somethings related
to dpms and failing to wake up the card or the screen.

Anyway the fact that ctr-alt-backspace restart properly your
xserver likely mean that the isn't lockup at all.

[Timo Jyrinki (timo-jyrinki-hut)]

(In reply to comment #9)
> Have you a other proposition ?

1. Did you try to comment out the Option "dri" line from Section "Module"?

2. Also, if it would be a problem with some screen power saver, you could, depending on a bit on the environment you are using, disable display power management. In GNOME, it's System->Preferences->Power Manager. There set the "Put display to sleep when inactive for:" to "Never". Though as it seems it happens while you're working (?) this is probably not the reason.

3. Cleaning the amount of options, like stated.

But really, I'd guess only the option 1 has the real possibility to fix the problem at the moment, but all are worth trying anyway.

There's a somewhat similar case at https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/58448 , though there ctrl-alt-backspace does not work.

[AdeDidou (adelineenileda)]

(In reply to comment #10)
> Did you try with device section as proposed in comment 6 ?

Oki, now I have :

Section "Device"
 Identifier "HIS (Ati) Radeon 9250 PCI"
 BusID "PCI:1:0:0"
 Driver "radeon"
 Option "BusType" "PCI"
 Option "GARTSize" "64"
 Option "EnablePageFlip" "1" # Enable page flipping for 3D apps
 Option "ColorTiling" "1"
#Fait sauter mon ordinateur Option "RingSize" "8"
# Option "AccelMethod" "XAA" # Use XFree86 Acceleration Architecture
# Option "AccelDFS" "1" # mettez à 0 si vous avez une carte AGP
# Option "BufferSize" "2"
# Option "EnablePageFlip" "1" # Enable page flipping for 3D apps
# Option "ColorTiling" "1"
# Option "EnableDepthMoves" "yes"
# Option "UseFBDev" "false"
# Option "RenderAccel" "true" # Enable the hardware render acceleration
# Option "mtrr" "on"
# Option "SubPixelOrder" "none"
# Option "DPMS"
# Option "DynamicClocks" "on"
# Option "VideoOverlay" "on"
# Option "OpenGLOverlay" "off"
EndSection

> Btw i am not sure i fully understand your issue, you have
> a black screen after some times, is this after some times
> of inactivity ?

This is after some times of activity OR inactivity...

[AdeDidou (adelineenileda)]

(In reply to comment #11)
> (In reply to comment #9)
> > Have you a other proposition ?
>
> 1. Did you try to comment out the Option "dri" line from Section "Module"?
>

When I comment this line I have not crash... but not 3D too.

> 2. Also, if it would be a problem with some screen power saver, you could,
> depending on a bit on the environment you are using, disable display power
> management. In GNOME, it's System->Preferences->Power Manager. There set the
> "Put display to sleep when inactive for:" to "Never". Though as it seems it
> happens while you're working (?) this is probably not the reason.
>

I have already this configuration.

> 3. Cleaning the amount of options, like stated.
>

I have clean the amount of options but if I load dri I have still crashes...

> There's a somewhat similar case at
> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/58448 ,
> though there ctrl-alt-backspace does not work.
>

I don't understand all of this repport (I am french...)

[Timo Jyrinki (timo-jyrinki-hut)]

Changing summary to include the information that this is DRI related.

> When I comment this line I have not crash... but not 3D too.

Ok, then it is DRI related definitely.

> > https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/58448 > > I don't understand all of this repport (I am french...)

No worries, there is really no new information there, except that someone claims that with some older drivers it works for him. It's rather uncertain if it's the same problem, though, as most people complaining about this are using AGP card.

I don't know further options other than to leave the 3D disabled or try the latest development versions in case you want to provide further information on whether the problem has been finally fixed or not. Basically the git repositories from git://anongit.freedesktop.org/git/mesa/drm , git://anongit.freedesktop.org/git/mesa/mesa and git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati contain the latest kernel DRM module, DRI modules and the video driver. For the first two, there are some compilation + installation instructions at http://dri.freedesktop.org/wiki/Building which I just updated a bit. I would guess that the third one (the normal DDX video driver) is not needed since this is DRI related.

[Michel-tungstengraphics (michel-tungstengraphics)]

(In reply to comment #14)
> I would guess that the third one (the normal DDX video driver) is not needed
> since this is DRI related.

DRI issues can be caused by the DDX driver.

Does the problem also happen without Option "GARTSize"?

[AdeDidou (adelineenileda)]

> Does the problem also happen without Option "GARTSize"?
>

I have try to uncomment Option "GARTSize" but I have a crash too....

[AdeDidou (adelineenileda)]

> I don't know further options other than to leave the 3D disabled or try the
> latest development versions in case you want to provide further information on
> whether the problem has been finally fixed or not. Basically the git
> repositories from git://anongit.freedesktop.org/git/mesa/drm ,
> git://anongit.freedesktop.org/git/mesa/mesa and
> git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati contain the latest
> kernel DRM module, DRI modules and the video driver. For the first two, there
> are some compilation + installation instructions at
> http://dri.freedesktop.org/wiki/Building which I just updated a bit.

I try to do this but T have a problem whith the compilation of 3D Mesa : see the attachement please....

[AdeDidou (adelineenileda)]

Created an attachment (id=9932)
Error Make Mesa 3D

[Mike Agnew (magnew-euronet)]

Binary package hint: xserver-xorg-video-ati

I have a (Club 3d) ATI Radeon 9250 PCI 128MB (in an old Dell Optiplex GX1 with 384MB so PCI was the only option). Am running feisty with xserver-xorg-video-ati 1:6.6.3 installed.
Vesa driver works OK; ati driver gives a black screen and console freeze every time I try.
If I disable "dri" in xorg.conf then I can use the ati driver but then I guess that's almost the same as vesa. So not good performance of any kind since driver is not writing directly to the Radeon 9250 card.

I can attach the xorg.cong that I am using which has "dri" disabled if required. Also, I did look at my /var/log/Xorg.0.log and really did not see any errors when I had the back screen. Can append this too.

PS I did try using 'fglrx' but was not successful due to version incompatibilities. (Could not really install the last ATI Radeon driver 8.28.8 that works for the 9250 in feisty - the new ATI Radeon driver is too new for the 9250). Ended up re-installing feisty to get back to where I am now to make sure all my libraries were OK.

[Tormod Volden (tormodvolden)]

Please attach xorg.conf and Xorg.0.log

[Mike Agnew (magnew-euronet)]

xorg.conf and Xorg.0.log attached

[Tormod Volden (tormodvolden)]

Did it work fine in Edgy? I am attaching the ati driver from Edgy, rebuilt for Feisty. Can you try it?

[Tormod Volden (tormodvolden)]

Sorry, that driver was built for Xorg7.3 (xserver-xorg 1.3). This one loads on pure Feisty.

[w4ett (w4ett)]

Ok...managed to get X back up with the ported driver. 3D still not working,,,glx gears locking up system again, but 2D performance is OK.

Working on this in UBF Thread http://ubuntuforums.org/showthread.php?t=446462&page=2

[Tormod Volden (tormodvolden)]

FYI, w4ett has an "8X AGP RV280 64MB 9200SE", not PCI.

w4ett, was the 2D performance worse with the original feisty ati driver?

[w4ett (w4ett)]

Success...at last 3d is operational. Device info as follows:

Section "Device"
 Identifier "ATI Radeon 9200SE"
 Driver "ati"
 BusID "PCI:1:0:0"
 VideoRam 65536
 Option "UseFBDev" "true"
        Option "BusType" "PCI"
EndSection

Section "Monitor"
 Identifier "Dell E773c"
 Option "DPMS"
 HorizSync 30-67
 VertRefresh 30-60

don@don-desktop:~$ glxgears
3075 frames in 5.0 seconds = 614.817 FPS
3070 frames in 5.0 seconds = 613.835 FPS
3069 frames in 5.0 seconds = 613.695 FPS
3069 frames in 5.0 seconds = 613.772 FPS
3070 frames in 5.0 seconds = 613.808 FPS
3070 frames in 5.0 seconds = 613.807 FPS
3069 frames in 5.0 seconds = 613.745 FPS
3069 frames in 5.0 seconds = 613.778 FPS
3070 frames in 5.0 seconds = 613.841 FPS
3068 frames in 5.0 seconds = 613.593 FPS
3069 frames in 5.0 seconds = 613.767 FPS
3070 frames in 5.0 seconds = 613.832 FPS
3067 frames in 5.0 seconds = 613.218 FPS

[Mike Agnew (magnew-euronet)]

I cannot say if it worked in Edgy since I started with Feisty (am new to Ubuntu having not used Unix for 10 or so years).

Downloaded the driver package from link. Did a sudo dpkg -i on it.
It seemed to install OK. Did not need to do any --configure on Xserver-xorg - said it was already configured.

Then edited my xorg.conf to enable the commented out line:
    Load "dri"

Re-booted and still got black screen.
Tried w4ett tweaks:
    VideoRam 131072
    Option "UseFBDev" "true"
    Option "BusType" "PCI"

Did not help either. Still black screen.
Will attach Xorg.0.log and xorg.conf again.

[w4ett (w4ett)]

Mike try without:
Option "UseFBDev" "true"
My 3d is stable now with this toggle deleted/ fps rate is better in glxgears

[Mike Agnew (magnew-euronet)]

w4ett - I tried without Option "UseFBDev" "true" - did not help.
Still black screen.

[Tormod Volden (tormodvolden)]

Since the Edgy driver didn't help, please upgrade to the Feisty driver again (you can use Update Manager).

Mike, if you can find an Edgy live CD to try, it would be interesting to know if it's a regression. w4ett tweaks would not help since 1) memory detection works fine 2) FBDev usually makes things worse (it's off by default) 3) You have a PCI card, so it can not run AGP .

[w4ett (w4ett)]

I opened an IRC channel: irc://freenode/ubuntu-radeon9200

[w4ett (w4ett)]

Mike: does the card work ok on any other OS?. i.e: M$ Windows or any other flavor of *nix?.

Just curious.

[Mike Agnew (magnew-euronet)]

Tried a few of the suggestions.
I am actually using the PCI card at present to drive my monitor on my Feisty system but in this non Load "dri" mode. So "ati" but "dri" not loaded.
It works reasonably well in this mode but is a bit slow. 10% to 15% of the speed w4ett is quoting.
So I guess the card is OK?

1. Got hold of an Edgy Live CD ... could not get the card to work via the options "Load or Install Ubuntu" or "Start Ubuntu in safe graphics mode".
Black screen on both.

2. Tried my Feisty Live CD ... it fails to work via the option "Load or Install Ubuntu". Black screen.
BUT "Start Ubuntu in safe graphics mode" option does work and when I look at the /etc/X11/xorg.conf it has used the "vesa" option.

[Patrick R. (trackwh0re)]

i've tried everything i can think of to fix these intermittent freezes and black screens, so i think i am also affected by this bug. sometimes my display and keyboard will freeze, but my mouse cursor can move (though i cannot use the buttons on it), sometimes it will freeze and go to the background color and input devices don't work, sometimes it will black out completely and input devices don't work, and oddly enough sometimes it even goes to "power saving mode" and input devices don't work.
i've tried both i686 and i386 kernel images resulting with the same problem. i've tried everything i could find in the forums and or the wiki to fix this problem via manual configuration of xorg.conf, including commenting out dri and glx and it results in the same problems and the ones suggested in this bug report. i also receive absolutely no errors in any log files.
everything is perfectly fine if i use the vesa driver, except the fact i cannot play games that need dri (which is a big deal to me).
i have tried using other distros and unfortunately windows to test and i am only affected by this problem in ubuntu. i've been using ubuntu since hoary and i'm not going to switch distros because i love where this project is headed and the goals set forth.
i hope the previous comments and the following information has been helpful, minus my own personal feelings/comments of course (please tell me to provide more if this is not enough).

system information: Linux <hostname> 2.6.20-15-386 #2 Sun Apr 15 07:34:00 UTC 2007 i686 GNU/Linux
binary package: xserver-xorg-video-ati (6.6.3-2ubuntu6)
excerpts from xorg.conf:
Section "Module"
        Load "bitmap"
        Load "ddc"
        Load "dri"
        Load "extmod"
        Load "freetype"
        Load "glx"
        Load "int10"
        Load "vbe"
EndSection

Section "Device"
        Identifier "ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE]"
        Driver "ati"
        BusID "PCI:1:0:0"
EndSection

"Section "Monitor"
        Identifier "eView 17f3"
        Option "DPMS"
        HorizSync 30-70
        VertRefresh 50-160
EndSection

Section "Screen"
        Identifier "Default Screen"
        Device "ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE]"
        Monitor "eView 17f3"
        DefaultDepth 24
        SubSection "Display"
                Depth 1
                Modes "1024x768" "800x600" "640x480"
        EndSubSection
        SubSection "Display"
                Depth 4
                Modes "1024x768" "800x600" "640x480"
        EndSubSection
        SubSection "Display"
                Depth 8
                Modes "1024x768" "800x600" "640x480"
        EndSubSection
        SubSection "Display"
                Depth 15
                Modes "1024x768" "800x600" "640x480"
        EndSubSection
        SubSection "Display"
                Depth 16
                Modes "1024x768" "800x600" "640x480"
        EndSubSection
        SubSection "Display"
                Depth 24
               ...

[Oliver Paulus (oliver-webprojekt)]

I have the same issue with fglrx on Feisty and ATI X1300. This seems to be a problem of the fglrx drivers from ATI. I have found the following in the ATI bugtracker: http://ati.cchtml.com/show_bug.cgi?id=567. If I use the fglrx driver with DRI so errors in xorg.conf appear - but a black screen lock is the result.

[w4ett (w4ett)]

Patrick, Sometime you need to tell the kernel to use pci, even though you have a PCI card. so for giggles and grins change this:

Section "Device"
        Identifier "ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE]"
        Driver "ati"
        BusID "PCI:1:0:0"
EndSection

to this:

Section "Device"
        Identifier "ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE]"
        Driver "ati"
        BusID "PCI:1:0:0"
        Option "BusType" "PCI"

EndSection

See if it makes a difference.

[Patrick R. (trackwh0re)]

w4ett i've tried using both PCI and AGP options previously, among many other tweaks. my card is not a PCI card, it's AGP.
i just tried it again and it resulted in a black screen and no inputs just before the gdm login screen, as per usual.
i think it's honestly a bug with the open source ati/radeon driver and or dri, because vesa works just fine.

[Tormod Volden (tormodvolden)]

General question to all of you:
Does the machine hang completely, or are just the screen and keyboard locked up? Can you try to ssh in from another machine, before starting X with dri enabled? You might try running "sudo cat proc/kmsg" in the ssh session to see if any error messages appear before/while the machine hangs/crashes. You can also (before starting X) unload the radeon and drm kernel modules, and reload the drm module with "modprobe drm debug=1" which should give a lot more debug messages.

[Patrick R. (trackwh0re)]

i don't have access to another machine on this network at this moment in time. i'll try to get my friends laptop for testing purposes and i'll get back to you ASAP.
from what i can tell you right now it seems the screen, keyboard, and mouse (sometimes if it doesn't result in a black screen if i'm already in the desktop by some amazing chance of fate) are the only things locked up, because i've been doing ftp/http transfers during a hang. they have seemingly have progress past the moment of the lock-up and i can see my nic led's rx/tx lights still blinking on the back of my case and my modems activity led is showing heavy traffic still during these hangs... but at the sametime my hdd led's show virtually no activity, so i'm not exactly sure.

[Mike Agnew (magnew-euronet)]

In my case the machine hangs completely as far as I can tell. (I don't have another UNIX machine on my network).

Did try booting in 'recovery mode' and unloading radeon and drm with 'dri' loaded.
Did the following

cd /etc/init.d
modprobe -r radeon
modprobe -r drm
modprobe drm debug=1
modprobe radeon
./gdm start

Have attached the log file but it does not seem to have much more debug.

[Tormod Volden (tormodvolden)]

The debug output from the drm module will be in /var/log/kern.log (and in syslog as well). But sometimes the machine crashes so fast that the interesting information doesn't have time to be written to the disk. Using ssh, more last-second information can be obtained.

[Tormod Volden (tormodvolden)]

Sorry I forgot, you can also enable the drm debug flag without unloading and reloading it:
echo 1 | sudo tee /sys/module/drm/parameters/debug
And to turn it off again, if the machine hasn't crashed yet :)
echo 0 | sudo tee /sys/module/drm/parameters/debug

(For those interested in debugging, I added this to https://wiki.ubuntu.com/Bugs/AtiDriver)

[Mike Agnew (magnew-euronet)]

Mmm .. I did not have under /sys/module a drm folder. Other devices were there but not drm.

Any ideas?

[Tormod Volden (tormodvolden)]

If you haven't started X yet, the module has not been loaded and the /sys/module entry does not exist. After "modprobe drm" you should see it.

[Mike Agnew (magnew-euronet)]

Think both kern.log and syslog are not being updated based on the timestamps - I would have started X around the 10.50 my time. Attached them anyway.

There does not seem to be much additional, if any, debug for drm in Xorg.0.log.

[Tormod Volden (tormodvolden)]

No there's nothing in those logs. You should have seen messages prefixed by [drm], like this:
[178126.720000] [drm:drm_ioctl] pid=2861, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1
[178126.720000] [drm:radeon_cp_indirect] indirect: idx=15 s=24680 e=24696 d=1
[178126.720000] [drm:radeon_cp_dispatch_indirect] indirect: buf=15 s=0x6068 e=0x6078

[w2vy (tom-moulton)]

I am also having the blanks screen problem.

my System: eMachines T1120 (w/160gb disk 512mb ram) dual boot with XP Home

I was a little surprised there were video problems I previously had FC6 running with no _apparent_ problems.

Just for Grins I dropped in the FC6 install disk and it reported detecting the card and loading the RV280 driver and stating X ok.
(and I still have video)

In my searching I also saw a strong warning from Redhat about installing 3rd party drivers with poor install/uninstall scripts.

They would not store their version of some tools/libs in an alternate location thereby overwriting the well known (debuged) versions of some of the frame tools/libraries and cause a lot of (unsupported) issues.

That said... I will try to load both on my system (triple boot? never tried that) or will load FC6 and save xorg.conf and Xorg.0.log (anything else?)

tom

[Mike Agnew (magnew-euronet)]

Think I managed to get some debug - started my PC with dri disabled. Then stopped X server and then set debug on drm. Set dri to load in xorg.conf and and restarted X server. My PC seemed to write a large kern.log and syslog - I could hear the disc a couple of times during black screen - attached in zip file.

[w2vy (tom-moulton)]

Well I may have achieved success with ATI 9250 (radeon) on Feisty Fawn!
(I am trying to be as specific as possible)

When I looked at the FC6 xserver log (attached) I saw a 'radeon' driver loaded.

I then added

Load "radeon"

In Section Module

And replaced the Device section with

Section "Device"
        Identifier "ATI Radeon 9250"
        Driver "radeon"
        BusID "PCI:1:14:0"
EndSection

I am not sure if the BusID is really needed, but thought it could not hurt.

I attached xorg.conf and my current Xorg.0.log as well (For Feisty Fawn)

If there is anything I should remove let me know

Oh Yes with glxgears I get about 490 FPS and with the onboard video I as getting about 100FPS

I hope this helps someone else

tom

[w2vy (tom-moulton)]

Rats only 1 attachement per post. sorry

[w2vy (tom-moulton)]

I guess I should have uploaded a tarball

This is th xorg.conf file that worked for me on Feisty Fawn with ATI Radeon 9250

[w2vy (tom-moulton)]

And finally my server log of the working xorg.conf

next time a tarball, honest

Tom

[Tormod Volden (tormodvolden)]

Thanks for the logs. Please just attach small (~1MB) files one by one, without any compression or archives. It much easier to have a look at them that way. Canonical's disk space is nothing to worry about :) Really large files makes firefox unhappy when viewed directly, but we can always check the size before clicking on an attachment. For huge files, use gzip, or think twice whether it's useful to upload everything or take out something.

Can you all try with "radeon"? Normally it is correct to specify "ati" which then loads the sub-module "radeon". However, it does make a difference sometimes, for instance in some cases DRI will be disabled when using "radeon" (bug #28925). This is of course a bug and it should be possible to track it down.

[Patrick R. (trackwh0re)]

i was finally able to ssh in and i didn't see any errors produced during the hang, it must not have time to write them to the hard drive.
tormod, yes i've used both ati and radeon.
i was messing around with the framebuffer modules and by using fbcon with my custom kernel image i was able to get into my desktop and was able to switch tty's (which is normally where i hang if i'm fortunate enough to make it into the desktop), but when i rebooted it was back to the same old blank screen.
the locking up inside the desktop was happening in edgy after roughly april 13th, but no blank/black screens like this. i didn't have time to make a report due to finals.

[Patrick R. (trackwh0re)]

here's the "debug" log.

[Patrick R. (trackwh0re)]

here's the "broken" xorg.conf

[Mike Agnew (magnew-euronet)]

Tormod - I also tried Load "radeon" around 21.00 my time last night - did not help. I have used tail -2000 on both logs which are attached.

[Tormod Volden (tormodvolden)]

Patrick, you don't have a 9200/9250 PCI card, so your comments complicate this bug report. Please read https://wiki.ubuntu.com/Bugs/AtiDriver and open a new bug for your card.

[Tormod Volden (tormodvolden)]

Mike, note that you don't need another linux machine to run a ssh client, see https://help.ubuntu.com/community/DebuggingSystemCrash

[Mike Agnew (magnew-euronet)]

Tormod, thanks for the Putty tip. I was able to log in and will try some of the ideas above.

[Mike Agnew (magnew-euronet)]

Ok - did try sudo cat /proc/kmsg

Got 1 message as below ... will also try with debug on too.

<6>[ 339.180682] [drm] Setting GART location based on new memory map

[Mike Agnew (magnew-euronet)]

Still black screen, still cannot use keyboard and mouse but Putty worked well.

With debug i.e. modprobe drm debug=1 and writing the output to kmsg which is attached.

[Tormod Volden (tormodvolden)]

Mike, do you mean that your machine is still running, only screen/keyboard/mouse is blocked? In this case, the drm output is not so interesting, because there is no system crash. It's just the X server going nuts. We should try to find out what the X server is doing, for instance using strace, ltrace or gdb.

I am not saying that this is gonna be easy, but if you're interested, look at https://wiki.ubuntu.com/DebuggingProgramCrash and install the package xorg-server/xserver-xorg-core-dbgsym. Getting a backtrace would be useful.

[Tormod Volden (tormodvolden)]

I wrote up a more detailed debugging guide on https://wiki.ubuntu.com/DebuggingXorg

[Mike Agnew (magnew-euronet)]

Tormod, I gave it a go with xserver-xorg-core-dbgsym!

Yes my machine is still running and screen/keyboard/mouse are all blocked.
Xorg is running and with a high CPU usage.

I tried with gdb and attach-ed ok to Xorg BUT I could not stop it with ctrl-C. The gdb prompt never came back which meant I could not do the backtrace.

Will try tracing next.

[Mike Agnew (magnew-euronet)]

Neither sudo strace -p nor sudo ltrace -p with Xorg process ID produced any terminal output.

So I tried gdb again ... and kill-ed Xorg but that did not help either as gdb said it had encountered an error. So could not backtrace.

(I think I am doing this all reasonably correctly)

[Tormod Volden (tormodvolden)]

Mike, thanks for the testing. Yes, you are doing everything correctly. I guess Xorg is so messed up already that it doesn't want to play with gdb. Can you try (without starting gdb) to kill the X server with kill -SEGV ? This sometimes forces a core dump. It might be that "apport" interferes with the core dumping, so try disabling it in /etc/default/apport.

You can also try to start X from within gdb, but I don't know if that's gonna work better.

[Mike Agnew (magnew-euronet)]

Tormod, will try with the new ideas. I had a question too - when you use 'gdm restart' - does it keep the same Process ID? Or is a new process spawned?

[Tormod Volden (tormodvolden)]

No, "gdm restart" will kill the old process and spawn a new one.

You can also try this, from https://help.ubuntu.com/community/DebuggingSystemCrash
echo t | sudo tee /proc/sysrq-trigger
It will spew out a lot of messages about all running processes. The output will also end up in /var/log/kern.

See also the new section "Post-mortem backtrace" in https://wiki.ubuntu.com/DebuggingXorg for tips on how to get a core dump.

[Mike Agnew (magnew-euronet)]

Tried many ideas to get debug but none successful:

1. kill -SEGV never managed to stop Xorg
2. In gdb, managed to start X but again could not get the (gdb) prompt back to do the 'backtrace'
3. Ctrl C inside gdb always gives : gdb internal error

(PS did disable apport OK.)

Any other ideas to get a core dump of Xorg?

[Mike Agnew (magnew-euronet)]

Regarding (2) previously, I killed the Xorg program run under gdb from another terminal using sudo kill -SEGV since Ctrl C did not work and I never got the 'backtrace to work.
Here's a full trace of the gdb session. Somehow I don't think it helps.

[Tormod Volden (tormodvolden)]

I think Xorg and gdb in general are not the best friends. I have the same trouble as you when I try to debug my savage driver issues, although I have got some backtraces in the past. In http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=423775 with similar troubles one suggestion is to use an older gdb...

If one could get gdb to work, and knew Xorg well, one could also put in some breakpoints to see how far it gets before something goes wrong, but this is not easy.

Did sysrq-trigger work?

[Mike Agnew (magnew-euronet)]

I did get output from sysrq-trigger (I misread the part about the echo 1 and missed this first line before doing the echo t).
Attached is what I got just before 'gdm start' and the aftermath.

Next attach has the tail of kern.log which has as its last line: "Jun 4 00:21:54 magnew-ubuntu kernel: [ 1912.840978] [drm] writeback test failed"

[Mike Agnew (magnew-euronet)]

Tail of kern.log

[Tormod Volden (tormodvolden)]

Are the two logs from the same incident? Anyway, the attached logs are not complete enough, can you look for a "Xorg" or "X" section in the trace output in kern.log? You may localize it with: less +/'] X' /var/log/kern.log

[Mike Agnew (magnew-euronet)]

Here are the all the logs I could get. They are not too large. This time I did 'run' Xorg from gdb at approximately 00:58.
kmsg -- only the last few lines were written on starting Xorg.

Not sure how much is useful.

Stopping for now ...

[Mike Agnew (magnew-euronet)]

Copied this data from ssh when I did the 'run' of Xorg inside gdb.

[Mike Agnew (magnew-euronet)]

ken.log

[Mike Agnew (magnew-euronet)]

syslog

[Mike Agnew (magnew-euronet)]

Xorg.o.log

[Tormod Volden (tormodvolden)]

I can not see any X process in your sysrq traces. You do the sysrq-t after X has gone wild, right?

[Mike Agnew (magnew-euronet)]

mike@magnew-ubuntu:~$ sudo /etc/init.d/gdm start
 * Starting GNOME Display Manager... [ OK ]
mike@magnew-ubuntu:~$ echo 1 | sudo tee /proc/sysrq-trigger
1
mike@magnew-ubuntu:~$ echo t | sudo tee /proc/sysrq-trigger
t
mike@magnew-ubuntu:~$

I did the sysrq-t immediately after srarting gdm with 'dri' enabled. Nothing more apears on this terminal.
tail -f of syslog is attached.

[Tormod Volden (tormodvolden)]

You should do the sysrq-trigger in the ssh session, after X is hung. The sysrq trace gives a snapshot of the current processes exactly when you trigger it. And give us the whole syslog, not the tail, because sysrq-t spits out a lot and we need to see the Xorg part in there.

[Bugzi09-fdo-tormod (bugzi09-fdo-tormod)]

Adeline, since you're using Ubuntu, you might find some prebuilt packages on https://wiki.ubuntu.com/XorgOnTheEdge which you can try, before you try compiling everything yourself.

[Tormod Volden (tormodvolden)]

Mike, I think we should file an upstream bug about this on bugs.freedesktop.org. But they will just ask if you have tested the latest version :) Are you wiling to try xorg-server 1.3 and ati driver 6.6.192? Have a look at https://wiki.ubuntu.com/XorgOnTheEdge for packages.

[Mike Agnew (magnew-euronet)]

Tormod,

Attached is the syslog from the last run .. it starts with me restrating the system, then stopping gdm, then starting gdm with "dri" enabled. Then doing the sysrq-1 and sysrq-t. I don't think there is much.

Yes I'll give xorg-server 1.3 a go and the ati driver 6.6.192.
But how do I get the old X server and driver back?

[Tormod Volden (tormodvolden)]

So at the time you did the sysrq-trigger command over ssh, Xorg was running with high CPU usage? Strangely enough it doesn't appear in the the trace output, which otherwise seems to be complete this time.

For returning to the old versions, I described it on the wiki page.

There is one upstream bug on 9200/9250 PCI cards, https://bugs.freedesktop.org/show_bug.cgi?id=10874, but there it crashes only after some time, not immediately at start-up like in your case...

[Mike Agnew (magnew-euronet)]

Yes Xorg was running with high CPU usage just before I did the sysrq-trigger.

Will try the xorg-server 1.3 and ati driver 6.6.192 probably tonight my time.
I'll provide the syslog trace after doing the sysrq-trigger if it does not work well :-)

[Mike Agnew (magnew-euronet)]

Upgraded to xorg-server 1.3 and ati driver 6.6.192.
Here are syslog after doing the sysrq-trigger and the Xorg.0.log file.

(The screen actually flashes a few times then sort of dies black -- possibly flashes more than xorg-server 1.2.)

[Mike Agnew (magnew-euronet)]

Well its been a few weeks and yes I managed to get dri to work!! All thanks to Tormods reference to Bugzilla Bug 10874.
I took Adelaines xorg.conf and tried some of her extra options ... it is attached what I actually used.

glxgears gave 624 to 685 FPS which seems quite reasonable.

Will try some more experiments to see what were the significant changes.

[Mike Agnew (magnew-euronet)]

Spoke to soon ... it just worked the one time after I did a /etc/init.d/gdm restart. Was exciting though!

Rebooted and it started with black screen again. :-(

A couple of attempts have failed since.

[Githlar (githlar-deactivatedaccount)]

I also have an ATI Radeon 9250. The root of my problem though is that I'm not able to boot up Ubuntu with my BIOS set to use PCI as the video adapter (instead of the onboard). In Recovery Mode, I see the crash happens right after "Loading hardware drivers." In the standard boot mode, the loading freezes after three sections of the loading bar are filled.

[w4ett (w4ett)]

Gilthar: Please post your xorg.conf and lspci...it will help with troubleshooting.

Note: he is using the the xorg-driver ati

[Tormod Volden (tormodvolden)]

Githlar, if your machine crashes without X starting (like in Recovery mode) it is a different problem, and you should file a new bug report.

[w4ett (w4ett)]

Tormod...here is the original thread from UF for your review:

http://ubuntuforums.org/showthread.php?t=507165

[Tormod Volden (tormodvolden)]

Mike, what does this look like in Gutsy Beta + ati 6.7.194 ?

[Mike Agnew (magnew-euronet)]

Tormod, loaded Gutsy Beta (guess it was ati 6.7.194?).

When I booted the Live CD, it stopped after the UBUNTU moving bar with cursor trapped in top left hand corner.
I then tried 'Boot in safe graphics mode'. That did much more, getting beyond the UBUNTU moving bar to the progress bar and it then worked OK (but then that's VESA).

[Tormod Volden (tormodvolden)]

I am not sure I understand this moving bar vs progress bar. Can you remove "usplash" and "quiet" in the boot menu (F6) and tell what the last lines are?

[Mike Agnew (magnew-euronet)]

Tormod, thank goodness for digital cameras!

Anyway, I edited the boot menu line as suggested. Here are the last few lines:

* CPU frequency scaling not supported

* Starting ConsoleKit daemon console-kit-daemon
* Starting Avahl mDNS/DNS-SD daemon avahl-daemon
* Starting DHCP D-bus daemon dhcdbd
* Starting Bluetooth services
* Starting GNOME Display Manager...
* Starting deferred execution scheduler atd
* Starting periodic command scheduler crond

[Tormod Volden (tormodvolden)]

"Starting GNOME Display Manager..." means that X is being started. When you use "Boot in safe graphics mode" the vesa driver will be used instead of the "ati" driver.

[Mike Agnew (magnew-euronet)]

Yes I did boot it in unsafe graphics mode here. Immediately after the last line above, the screen goes black.

(I did try it with "Boot in safe graphics mode" on another occasion. This did not give the black sreen.)

[agd5f (agd5f)]

*** Bug 11247 has been marked as a duplicate of this bug. ***

[agd5f (agd5f)]

Does this problem persist with a more recent version of the radeon driver (ati 6.7.19x or git master) or radeon drm (git master)?

[Tormod Volden (tormodvolden)]

Could you please try the ati 6.7.196 from https://wiki.ubuntu.com/XorgOnTheEdge ? If possible, also the latest radeon drm module, as they ask in the upstream bug report.

[Mike Agnew (magnew-euronet)]

Tried the ati 6.7.196 and it's ceratinly different from before. I never get the completely hanging black screen anymore. Of my 4 or 5 attempts to boot, 1 time it worked.

The 4 or so failure times I got a partial screen usually with the revolving circular cursor spinning then stopping and then console freeze.

The 1 time it worked glxgears gave around 500 FPS.

Will try the latest radeon drm module next.

[Bugzi09-fdo-tormod (bugzi09-fdo-tormod)]

From the report on https://bugs.launchpad.net/bugs/114520, 6.7.196 is different and somewhat better.

[Mike Agnew (magnew-euronet)]

Tried a few things tonight.

It seems that ati 6.7.196 does work quite well if I power off the PC rather than restart it. I got the PC to start 2 or 3 times tonight having powered off without error and still showing glxgears around 500 FPS.

I then installed the latest radeon drm modules using the Tormod easy installer. This was not so good as hardware acceleration seemed to fail altogether and glxgears dropped down to 95 FPS! I read the instructions but don't know how to restore back to standard Gutsy release of drm. I realise I have to download some files and then delete the drm-20071125 folder ... and re-run the install but don't know where to get the drm files? Any help would be appreciated. Thanks.

[Mike Agnew (magnew-euronet)]

Read the readme in 'easy installer' and got everything back where it was prior to installing latest drm modules. Good script as it renamed the drm.ko to drm.ko.orig and savage.ko to savage.ko.orig.

Put the .orig ones back! All OK.

And yes the ati 6.7.196 does continue to work quite well as I powered off the PC after renaming the .orig files back. Then powered on again and all OK. glxgears back up at 500 or so.

[Tormod Volden (tormodvolden)]

> hardware acceleration seemed to fail altogether
Do you have the log from this run?

> it renamed the drm.ko to drm.ko.orig and savage.ko to savage.ko.orig
I hope it did the same for radeon.ko which you would be using. The version attached to XorgOnTheEdge should compile all modules, not only savage.

I just discovered that the script does not check that you have linux-headers installed. I will fix that soon :)

[Tormod Volden (tormodvolden)]

Updated the script. Please get easy-drm-modules-installer.v3 from https://wiki.ubuntu.com/XorgOnTheEdge

[Bugzi09-fdo-tormod (bugzi09-fdo-tormod)]

Mike from the above Ubuntu bug reports that 6.7.196 works fine after a cold start, but not after a reboot.

[Mike Agnew (magnew-euronet)]

Same problem - hardware acceleration failed. The script I downloaded seemed to only build drm.ko, i810.ko and i915.ko.
Had a look in the log and it seemed to be a version problem - perhaps not surprising?

Will also attach the Xorg.0.log.old which I had from the prior run (and acceleration worked OK.

[Mike Agnew (magnew-euronet)]

(Meant to also say in previous post that radeon.ko did not appear to be built)

Xorg.0.log.old from the prior run using the original .ko files and acceleration worked OK.
Seems still to be OK with ati 6.7.196 if I power off the PC rather than restart it.

[Tormod Volden (tormodvolden)]

> The script I downloaded seemed to only build drm.ko, i810.ko and i915.ko. Had a look in the log and it seemed to be a version problem - perhaps not surprising?

I tested the v3 script on Gutsy, and it should build all modules. You'll need radeon.ko and drm.ko. If you're sure you've got the right script, please send me the build log.

[Probablement (probablement)]

Hi there,
I have the exact same problem as Adeline under Debian etch with Xorg 7.1.1 (ati 6.6.3 as far as I can tell, using driver radeon). I will try to disable DRI.

(II) RADEON(0): [dri] Found DRI library version 1.2.0 and kernel module version 1.25.0

[Mike Agnew (magnew-euronet)]

Sorted it out ... the script built all the modules. But when close to end i.e. doing mv to .orig and stat, the script was unable to stat mach64.ko and stopped with 'Press enter to exit the script'. I manually renamed original radeon.ko to radeon.ko.orig and copied over the new radeon.ko built in /tmp/...

There does seem to be an improvement in that glxgears is now reporting circa 570 FPS up from approximately 500 FPS from before.

Will try to restart computer as that's the only thing now not working :-)
(I have been consistently powering off and on.)

[Mike Agnew (magnew-euronet)]

Did a restart of the computer and all worked!

Will try a few more times and let you know if this new combination of drm.ko, radeon.ko and ati 6.7.196 continues to work well.

Thanks for all help to date.

[Mike Agnew (magnew-euronet)]

Tried a few more times tonight. All OK.

[Bugzi09-fdo-tormod (bugzi09-fdo-tormod)]

Mike reported that with the newest drm modules, it now works fine all the time.

[Tormod Volden (tormodvolden)]

Thanks for all your testing. You hit a bug in the drm-easy-installer where it would crap out if new modules were compiled and installed which were not already shipped with Ubuntu. It's now fixed in easy-drm-modules-installer.v4

[Tormod Volden (tormodvolden)]

xserver-xorg-video-ati 1:6.7.197-1 is now in Hardy and should include the -ati driver fix for this bug. Please update if you are running Hardy. This version will also be included in Hardy Alpha 3, which is scheduled for release next week. If you want to test this version (or newer) in Gutsy, try the test packages from https://wiki.ubuntu.com/XorgOnTheEdge

If you find that this bug is not fixed with the new version in Hardy, please reopen the bug report.

[Benjamin-close (benjamin-close)]

Bugzilla Upgrade Mass Bug Change

NEEDSINFO state was removed in Bugzilla 3.x, reopening any bugs previously listed as NEEDSINFO.

  - benjsc
    fd.o Wrangler

[Bugzi09-fdo-tormod (bugzi09-fdo-tormod)]

Unless Adeline disagrees, I guess this bug can be closed now? It seems to be fixed in both the radeon driver and drm.

[agd5f (agd5f)]

closing, please re-open if there are still issues.