Radeon driver and ATI ES1000 problem

I upgraded a HP Proliant server to openSUSE 11.4 (X86-64) with KDE, and I’m encountering various graphical problems. This machine’s been running SUSE versions since 11.0 on similar hardware with few major issues, and I did the ‘upgrade’ by a new install keeping only /home partition intact.
This Server has 10GB memory

It has a PCI ATI ES1000 with 64MB and uses the radeon driver.
It boots up fine under the monitor’s correct resolution of 1600*1000, but

  1. It flickers one time each 4 of 5 seconds :frowning:
  2. during works more and more memory is used : starting at 9% and going up to 51% after 20 minutes and I receive then allocation error in /var/log/messages >:(
Apr  8 11:05:55 hpprol kernel:  2423.872667] [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (4096, 2, 4096, -12)
Apr  8 11:05:55 hpprol kernel:  2423.872720] [TTM] Unable to allocate page.
Apr  8 11:05:55 hpprol kernel:  2423.872724] radeon 0000:01:03.0: object_init failed for (4096, 0x00000002)

These allocation errors occur many times / second !

Here the lspci -v output for the video card

01:03.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02) (prog-if 00 [VGA controller])
        Subsystem: Hewlett-Packard Company Device 31fb
        Flags: bus master, stepping, medium devsel, latency 64, IRQ 23
        Memory at f0000000 (32-bit, prefetchable) [size=128]
        I/O ports at 3000 [size=256]
        Memory at f9ff0000 (32-bit, non-prefetchable) [size=64]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [50] Power Management version 2
        Kernel driver in use: radeon

the only error found in Xorg.0.log are
17.177] (EE) AIGLX error: Calling driver entry point failed
17.177] (EE) AIGLX: reverting to software rendering

These problems doesn’t occurs on Opensuse 11.2 and 11.3

Any idea?
Many thanks in advance
Philippe[/size][/size][/size]

I upgraded a HP Proliant server to openSUSE 11.4 (X86-64) with KDE, and I’m encountering various graphical problems. This machine’s been running SUSE versions since 11.0 on similar hardware with few major issues, and I did the ‘upgrade’ by a new install keeping only /home partition intact.

I was thinking this query sounds familiar, and then I realised you’ve adapted the text from my own post a few days ago!

Well, I don’t have any real answers to either your or my own problems, and I would advise you to wait for better advice from somebody here before doing anything, but you might want to consider installing the 2.6.38 kernel because I’ve noted a lot less log file output, and the radeon driver is possibly a bit more stable overall running under that, though seemingly still not perfect.

I had to grab it from the kernel:HEAD repo for 11.4 because it appears that kernel:stable won’t be set up until 2.6.39 has been released. You should be able to revert back to 2.6.37 easily enough if things don’t work out. Then again, I know nothing about running servers so perhaps this procedure is more risky.

Yes,

I’m not very fluent in English and I updated your description of the install.

Now I have installed the kernel 2.6.38-31 and rebooted the system/
At firs look there is no change
Flickering remains and the memory used is still growing

I found one error in /var/log/messages
Apr 8 13:55:06 hpprol kernel: 19.900307] [drm:r100_bandwidth_update] ERROR You may not have enough display bandwidth for current mode
Apr 8 13:55:06 hpprol kernel: 19.900310] If you have flickering problem, try to lower resolution, refresh rate, or color depth

I find this strange because this error is not present in Opensuse 11.3.
I’ll try to adapt the refresh rate

also drm is involved in the allocation error
All is pointing to the radeon driver used in 11.4

Regards
Philippe

For gumb, I provided some suggested edits to the 50-device.conf and you decided to ignore that. Fair enough, but are you 100% certain your choice is correct without trying the suggestion?

For phil524 if this is to be a server, is there any reason why you even need to run X ?

And if you do want to run X, and if screen flicker is an issue, did you try the vesa or fbdev graphic drivers?

I typed “man radeon” and noted your PC’s graphics is supported. Did you turn OFF special desktop effects when using the ‘radeon’ driver ?

No I didn’t choose to ignore it. I tried it out but like everything else it still made no difference and I couldn’t get X started with nomodeset. I’ve not followed up on it any further because time’s run out for me now, and I’ve just got to make best of what there is, and identify the actions that cause the corruption so as to advise the PC’s users which things not to touch.

I think phil524’s issue is probably very different but it seems that the newer kernel spews a lot less graphics errors into the logs and might just be better at handling radeon devices in general. The radeon support in the kernel is still relatively new so the first iterations are probably going to be more buggy.

I’m sorry to read that it did not work.

I ask you do me a favour next time. If a suggestion does not work, please advise. Else I’m sitting hanging wondering if my suggestions are good or not. Your previous reply to me in that thread stated you were not going to try it. To quote:

‘could try’ in my limited knowledge of English suggests it has NOT yet been tried.

Hi Oldcpu

Thanks for your remarks

My answers:

  • Desktop effects are disabled.
  • I use this system as a home server (DHCP, DNS, Apache and Xen) and as a desktop for which I need X. The card is integrated on the motherboard and cannot be changed :frowning:

I changed the modeline (60HZ in place of 76Hz) using gtf therefor and adding the line in the /etc/x11/xorg.conf.d/50-monitor.conf but no luck

  • The bandwidth error in /var/log/messages is gone
  • Flickering remains (maybe less frequent)
  • The memory used growths from 9% to more than 50% ==> at some moment (when above the 50% of memory used) the allocation errors are inserted in /var/log/messages so rapidly that I cannot read it via tail-f messages >:(

Therein a lot of allocation error but also a trace

Apr  9 12:13:23 hpprol kernel:  1891.793005] [TTM] Unable to allocate page.
Apr  9 12:13:23 hpprol kernel:  1891.793026] radeon 0000:01:03.0: object_init failed for (163840, 0x00000002)
Apr  9 12:13:23 hpprol kernel:  1891.793029] [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (163840, 2, 4096, -12)
Apr  9 12:13:23 hpprol kernel:  1891.794804] Xorg: page allocation failure. order:0, mode:0x200d4, alloc_flags:0x40 pflags:0x402100
Apr  9 12:13:23 hpprol kernel:  1891.794808] Pid: 1599, comm: Xorg Not tainted 2.6.38-31-xen #1
Apr  9 12:13:23 hpprol kernel:  1891.794810] Call Trace:
Apr  9 12:13:23 hpprol kernel:  1891.794826]  <ffffffff800093ea>] dump_trace+0x7a/0x1b0
Apr  9 12:13:23 hpprol kernel:  1891.794832]  <ffffffff80489bce>] dump_stack+0x67/0x6d
Apr  9 12:13:23 hpprol kernel:  1891.794838]  <ffffffff800d8027>] __alloc_pages_nodemask+0x567/0x790
Apr  9 12:13:23 hpprol kernel:  1891.794866]  <ffffffffa00aca76>] ttm_get_pages+0x1b6/0x270 [ttm]
Apr  9 12:13:23 hpprol kernel:  1891.794888]  <ffffffffa00a3ff8>] __ttm_tt_get_page+0x98/0xc0 [ttm]
Apr  9 12:13:23 hpprol kernel:  1891.794896]  <ffffffffa00a4698>] ttm_tt_populate+0x48/0x90 [ttm]
Apr  9 12:13:23 hpprol kernel:  1891.794904]  <ffffffffa00a4726>] ttm_tt_bind+0x46/0x80 [ttm]
Apr  9 12:13:23 hpprol kernel:  1891.794912]  <ffffffffa00a6a57>] ttm_bo_handle_move_mem+0x1f7/0x460 [ttm]
Apr  9 12:13:23 hpprol kernel:  1891.794924]  <ffffffffa00a7c7e>] ttm_bo_move_buffer+0x18e/0x1a0 [ttm]
Apr  9 12:13:23 hpprol kernel:  1891.794935]  <ffffffffa00a7d1d>] ttm_bo_validate+0x8d/0x130 [ttm]
Apr  9 12:13:23 hpprol kernel:  1891.794947]  <ffffffffa00a7f8d>] ttm_bo_init+0x1cd/0x270 [ttm]
Apr  9 12:13:23 hpprol kernel:  1891.794975]  <ffffffffa025c8ff>] radeon_bo_create+0x13f/0x290 [radeon]
Apr  9 12:13:23 hpprol kernel:  1891.795022]  <ffffffffa02739b1>] radeon_gem_object_create+0x91/0x130 [radeon]
Apr  9 12:13:23 hpprol kernel:  1891.795082]  <ffffffffa0273e24>] radeon_gem_create_ioctl+0x54/0xe0 [radeon]
Apr  9 12:13:23 hpprol kernel:  1891.795140]  <ffffffffa01c02dc>] drm_ioctl+0x39c/0x460 [drm]
Apr  9 12:13:23 hpprol kernel:  1891.795148]  <ffffffff8012fd65>] do_vfs_ioctl+0x85/0x330
Apr  9 12:13:23 hpprol kernel:  1891.795152]  <ffffffff801300a8>] sys_ioctl+0x98/0xa0
Apr  9 12:13:23 hpprol kernel:  1891.795157]  <ffffffff80007388>] system_call_fastpath+0x16/0x1b
Apr  9 12:13:23 hpprol kernel:  1891.795165]  <00007f8fbc411ce7>] 0x7f8fbc411ce7

I had opened a bug about this but no answer till now
Bug 679861 - kernel memory allocation errors with opensuse11.4 and radeon driver

Regards
Philippe

I think gtf is more for older monitors, and cvt is for newer monitors. Take a read of post#56 here: openSUSE Graphic Card Practical Theory Guide for Users and #55 might also be of interest. ie

The VESA Standards Body has, as of early 2003, replaced the GTF (General Timing Formula) video timings standard with the CVT (Coordinated Video Timings) standard.

The error messages you quote don’t mean much to me. Is there anything helpful in /var/log/Xorg.0.log ?

Nothing in Xorg.o.log that can I can identify as error (596 lines)
here this file 16.975] X.Org X Server 1.9.3 Release Date: 2010-12-13 16.978] X Pr - Pastebin.com](http://pastebin.com/KQKnAWTa)

kdm.log has a lot of errors

Failed to allocate :
   size      : 3328 bytes
   alignment : 0 bytes
   domains   : 2

Regards
Philippe

I don’t know about the kdm.log, but these entries don’t look healthy in the Xorg.0.log file:


#    17.489] (EE) AIGLX error: Calling driver entry point failed
#    17.489] (EE) AIGLX: reverting to software rendering
.......
#    17.430] (WW) RADEON(0): Option "EnableDepthMoves" is not used
#    17.430] (WW) RADEON(0): Option "PreferredMode" is not used

It looks to me that you have an /etc/X11/xorg.conf file you are using (trying to force a preferred mode) and trying to force enable depth modes, or you have a file edited in /etc/X11/xorg.conf.d/some-file. CLEARLY thats not working. Why leave it in ?

Why try it in the 1st place ?

What happens if you remove any /etc/X11/xorg.conf file, and if you comment out any custom edits in the /etc/x11/xorg.conf.d/somefiles and let X try to configure automatically.

I don’t have /etc/X11/xorg.conf but I have updated the 50-monitor.conf: so I renamed it as 50-monitor.bad and rebooted the system
X started but at a resolution of 1024*768 : This is the maximum resolution available :frowning:
The AIGLX error is still present and the memory problem remains.

I tried adding only the monitor definition but no luck X start at maximum 1024*768

Section "Monitor"
  Identifier "Default Monitor"
  ## If your monitor doesn't support DDC you may override the
  ## defaults here
  DisplaySize  531 299
  HorizSync 28-85
  VertRefresh 50-76
  ModelName    "BENQ G2411HD (DIGITAL)"
  VendorName   "BENQ"
 Endsection

if I add therein use “mode[0]” and define a section “mode” with the modeline definitions for 1600900, 14001050 etc
then X11 can start at resolution 1600*900

Seems that the system can’t find the correct settings for the monitor and go to the default VGA.
Remark that this screen is a wide 16:9 and VGA is 4:3.

Thanks for your advice
Philippe

There was a time when any file in the /etc/modprobe.d/ directory would be treated as a functional file, EVEN if it had .bad or .bak or any other non-nominal naming convention. I do not know if that is the case any more, nor do I know if it is the case for /etc/X11/xorg.conf.d/ directory, but if it were me, I would not take the chance in something that I known next to nothing about wrt the code. But I assume you have checked the code and confirmed that only files with the .conf extension are loaded ?

How about the remainder of the 50-something files in that directory? Are there any other entries that could be clouding this issue? Has EVERYTHING been restored to installation default ?

I don’t know enough about the syntax of these files to give specific help. It could be possible to implement, but someone who understands this would need to chime in.

If one types “man xorg” and “man x” one can read many of the options that are possible and I in essence do not know any of these options. Its well above my experience.

For example, reading your post over and over and I’m still puzzled where the following came from in your Xorg.0.log :


#    17.430] (WW) RADEON(0): Option "EnableDepthMoves" is not used 
#    17.430] (WW) RADEON(0): Option "PreferredMode" is not used 

because you made no mention of those specific entries, why they were considered necessary (if implemented manually and I guess now they were not), so I have to assume my previous guess was wrong. Its difficult for someone with limited knowledge like myself to offer suggestions without knowing the assumptions of others.

I’m hoping someone more knowledgeable chimes in.

Thanks for your helps oldcpu

I found the following warnings are not more present:

#    17.430] (WW) RADEON(0): Option "EnableDepthMoves" is not used 
#    17.430] (WW) RADEON(0): Option "PreferredMode" is not used

I removed these two options from 50-monitor.conf file: seems that these are not more used or cannot be set in this file

in 50-screen.conf I found the following remark but I don’t see what is the magic???

Doesn’t help for radeon/radeonhd drivers; use magic in

50-device.conf instead

for the flickering I observed that this occurs also in the alternate console (Alt-Ctrl F1–> Alt-Ctrl-F6)
this is very strange because X is not active I think in this case

I have a dual boot Opensuse 11-3 /11-4 and I verified that in Opensuse 11.3 this doesn’t occurs, so the hardware is not concerned.
I think that there is some problems with this card and the radeon driver

Regards
Philippe

That is strange. Any chance this is a loose cable ?

That is strange. Any chance this is a loose cable ?

I don’t think because it doesn’t occur in opensuse11.3