Bug 62447 - drmRadeon... functions abort with -16
drmRadeon... functions abort with -16
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
7.3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks: 67218
  Show dependency treegraph
 
Reported: 2002-03-31 22:46 EST by Michal Jaegermann
Modified: 2007-04-18 12:41 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-07-28 04:27:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
XFree86 log from Acer laptop with Radeon Mobility (5.50 KB, application/x-gzip)
2002-03-31 22:48 EST, Michal Jaegermann
no flags Details

  None (edit)
Description Michal Jaegermann 2002-03-31 22:46:56 EST
Description of Problem:

This is not exactly an "official" configuration but still...

On a laptop with ATI Radeon Mobility built-in video with Red Hat 7.2
distribution (sorry, but installing full "Skipjack" on this machine is
out of question due to cirmcumstances beyond my control) I added
kernel-2.4.18-0.4, which is really needed regardless for a proper
operation, and XFree86-4.2.0-6.47 with all required support (freetype,
glut, Glide).  Things seems to work ok, and I got an accelerated
display, but various programs from Mesa-demos-3.4.2-10 work for a
while and terminate with error codes; especially if on a screen is a
lot of fast movement.  For example:

$ gloss
652 frames in 5.002 seconds = 130.348 FPS
649 frames in 5.007 seconds = 129.619 FPS
drmRadeonSwapBuffers: return = -16
$ tunnel
Tunnel V1.5
Written by David Bucciarelli (tech.hmw@plus.it)
drmRadeonClear: return = -16

The later after displaying for a while with frame rates around 118 per
second.

Usually 'drmRadeonSwapBuffers' shows there and 'drmRadeonClear'
is sort of anomaly

I attach XFree86.0.log file from these experiments.
Comment 1 Michal Jaegermann 2002-03-31 22:48:31 EST
Created attachment 51586 [details]
XFree86 log from Acer laptop with Radeon Mobility
Comment 2 Mike A. Harris 2002-04-01 00:12:00 EST
michael, can you attach your /var/log/messages file also from a crash

Also, just a note - please dont compress file attachments.
Comment 3 Michal Jaegermann 2002-04-01 13:13:32 EST
There was no "crash" with things like reported and there are no traces
of these incidents in /var/log/messages.  Just programs exiting unexpectedly
with non-zero codes.

OTOH I did crash later.  An owner of this laptop asked for Maple V to be
installed (yes, this requires libc5 and its loader to run - at least for copies
sold by the local University a while ago).  Trying Maple graphics with
XFree86-4.2.0-6.47 caused an immediate crash with a screen covered by pinkish
stripes and no access to the box - either local or over a network.
Unfortunately nothing was logged either; things died instantly.

After reverting to 4.1.0-15 a display is not accelerated but Maple does not
have any problems with its graphics and nothing crashes.
Comment 4 Michal Jaegermann 2002-04-01 19:02:35 EST
I managed to repeat some crash with 4.1.0-15.  I turns out that in depth
16 I can get an accelerated display.  Still 'gears' from Mesa-demos
turn few times very slowly and exit with 'drmRadeonSwapBuffers: return = -16'.
An attempt to run 'teapot' initially looked normally but after a while
it wedged taking an X server with it.  A machine was still accessible
over a network.  This time I found various things in my log files.
Here they are:

kernel: Linux agpgart interface v0.99 (c) Jeff Hartmann
kernel: agpgart: Maximum main memory to use for agp memory: 203M
kernel: agpgart: Detected Intel i830M chipset
kernel: agpgart: AGP aperture is 256M @ 0xe0000000
kernel: [drm] AGP 0.99 on Unknown @ 0xe0000000 256MB
kernel: [drm] Initialized radeon 1.1.1 20010405 on minor 0
......
kernel: [drm:radeon_cp_vertex] *ERROR* ring space check failed!
last message repeated 5 times
kernel: [drm:radeon_cp_swap] *ERROR* ring space check failed!
kernel: [drm:radeon_cp_indirect] *ERROR* ring space check failed!
last message repeated 2 times
kernel: [drm:radeon_cp_swap] *ERROR* ring space check failed!
kernel: [drm:radeon_cp_indirect] *ERROR* ring space check failed!
last message repeated 3 times
kernel: [drm:radeon_cp_vertex] *ERROR* ring space check failed!
last message repeated 16 times
last message repeated 13 times
kernel: [drm:radeon_freelist_get] *ERROR* returning NULL!
last message repeated 1784 times
last message repeated 3599 times
last message repeated 653 times
kernel: [drm:radeon_freelist_get] *ERROR* returning NULL!
kernel: [drm:radeon_freelist_get] *ERROR* returning NULL!
kernel: [drm:radeon_freelist_get] *ERROR* returning NULL!
last message repeated 1819 times
last message repeated 3597 times
last message repeated 3611 times
last message repeated 3610 times
last message repeated 3607 times 
last message repeated 3607 times
last message repeated 3612 times
last message repeated 3608 times

After a while a frozen image of teapot turned black and a machine
dropped from the net completely.

Graphics from Maple on an accelerated display from 4.1.0-15 still
works.
Comment 5 Mike A. Harris 2002-04-01 23:25:51 EST
Please attach output of uname -a
Comment 6 Michal Jaegermann 2002-04-02 12:01:59 EST
This is "Skipjack" kernel.
Linux dyna0 2.4.18-0.4 #1 Wed Mar 13 10:36:06 EST 2002 i686 unknown
Comment 7 Michal Jaegermann 2002-04-12 17:45:26 EDT
I did retry with kernel 2.4.18-0.21 and XFree86-4.2.0-6.62.  There are
differences but no cigar.

drmRadeonSwapBuffers: return = -16
drmRadeonClear: return = -16

error message, mostly the first one, are still there sooner or later for
every of Mesa-demos if there is some more vigorous motion on a screen.
Something new showed up - like this:

Proxying 64x64 level 0 RGBA8 texture (level 0)
proxy allocation succeeded

Proxying 2048x2048 level 0 RGBA16 texture (big so unlikely to be supported)
proxy allocation failed

In /var/log/messages I collected a bunch of:

[drm:radeon_cp_vertex] *ERROR* ring space check failed!
[drm:radeon_cp_swap] *ERROR* ring space check failed!
[drm:radeon_cp_indirect] *ERROR* ring space check failed!
[drm:radeon_cp_clear] *ERROR* ring space check failed!
[drm:radeon_cp_indirect] *ERROR* ring space check failed!
[drm:radeon_cp_vertex] *ERROR* ring space check failed!
[drm:radeon_cp_indirect] *ERROR* ring space check failed!
[drm:radeon_cp_vertex] *ERROR* ring space check failed!
[drm:radeon_cp_swap] *ERROR* ring space check failed!
[drm:radeon_cp_indirect] *ERROR* ring space check failed!
[drm:radeon_cp_vertex] *ERROR* ring space check failed!
[drm:radeon_cp_swap] *ERROR* ring space check failed!
[drm:radeon_cp_indirect] *ERROR* ring space check failed!
[drm:radeon_cp_vertex] *ERROR* ring space check failed!
[drm:radeon_cp_swap] *ERROR* ring space check failed!
[drm:radeon_cp_indirect] *ERROR* ring space check failed!
[drm:radeon_cp_clear] *ERROR* ring space check failed!
[drm:radeon_cp_indirect] *ERROR* ring space check failed!
[drm:radeon_cp_vertex] *ERROR* ring space check failed!
[drm:radeon_cp_swap] *ERROR* ring space check failed!
[drm:radeon_cp_indirect] *ERROR* ring space check failed!
[drm:radeon_cp_vertex] *ERROR* ring space check failed!
[drm:radeon_cp_swap] *ERROR* ring space check failed!
[drm:radeon_cp_indirect] *ERROR* ring space check failed!
[drm:radeon_cp_indirect] *ERROR* ring space check failed!
[drm:radeon_cp_swap] *ERROR* ring space check failed!
[drm:radeon_cp_indirect] *ERROR* ring space check failed!
[drm:radeon_cp_swap] *ERROR* ring space check failed!
[drm:radeon_cp_indirect] *ERROR* ring space check failed!
[drm:radeon_cp_vertex] *ERROR* ring space check failed!

Last, but not least, trying graphics from Maple made this time X server only
to wedge instead of crashing immediately the whole machine.  A cursor turned
into "busy" indicator and although alive it was ineffective.  Keybord was
not reacting at all.  A machine was still reachable over a network.  In 
/var/log/messages lines with

[drm:radeon_freelist_get] *ERROR* returning NULL!

started to appear and /var/log/XFree86.0.log was collecting quite fast lines
like that:

(EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1002
(EE) RADEON(0): GetBuffer timed out, resetting engine...
(EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1002
(EE) RADEON(0): GetBuffer timed out, resetting engine...
(EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1002
(EE) RADEON(0): GetBuffer timed out, resetting engine...

'gdm' was unkillable.  Eventually, after few tries, I managed to 'kill -9'
X server.  This still did not change anything in an appearance of a screen
nor in a mouse/keyboard response.  An attempt to restart, from a network
login, once again 'gdm' this time turned a screen blank and the whole machine
"power switch" dead.

OTOH the same version of X on Alpha with ATI Radeon 7500 QW (AGP) is doing
quite nicely. :-)  Thanks!
Comment 8 Mike A. Harris 2002-06-21 23:29:12 EDT
This is filed for RHL 7.3 right now, however above you've indicated that
you were using an older release with the newer X.  Are you now running
a full Red Hat Linux 7.3 installation on this laptop, and experiencing
the same problem?  If not, could you please do a full installation, and
report back the results.  Be sure to be using the latest erratum kernel
as well.

Also, please attach new log file and config file, and please do not
compress them as it makes it difficult to view them inline in the web
browser without downloading and viewing manually.
Comment 9 Michal Jaegermann 2002-06-21 23:53:14 EDT
I am afraid that with as various hardware which is passing through my hands
I may never see it again.  The laptop in question is actually right now on the
other continent. :-)  It _may_ reappear again - some day.
Comment 10 Mike A. Harris 2002-08-06 01:52:08 EDT
I'm closing this bug for now, as I don't have a Radeon Mobility to
investigate this to see if it works or not, and you've indicated that
you do not have the hardware any longer either.

Please reopen the bug with updated info, if you find the problem
occurs in the Red Hat Limbo beta, or a future release.

Note You need to log in before you can comment on or make changes to this bug.