AMD 8.36.5 Driver -- The Still no fglrx AIGLX Support Edition

[time2IPL]

Hi, Michael -

Have you tried reverting to a very simple xorg.conf? A configuration as basic as you can have, just to see if it starts up properly?

Set xorg.conf to the plain version I posted yesterday on three different machines, still no luck / no difference. I did, however, remember / notice that the numbers fglrx reported in /var/log/messages / dmesg didn't seem to correspond to anything:

[fglrx] Maximum main memory to use for locked dma buffers: 1899 MBytes.
[fglrx] total      GART = 532676608
[fglrx] free       GART = 516685824
[fglrx] max single GART = 516685824
[fglrx] total      LFB  = 267911168
[fglrx] free       LFB  = 250081280
[fglrx] max single LFB  = 250081280
[fglrx] total      Inv  = 268435456
[fglrx] free       Inv  = 268435456
[fglrx] max single Inv  = 268435456
[fglrx] total      TIM  = 0

I don't know what these numbers mean; but, in looking over posts from others, I don't recall seeing others posted with "0" for any of these totals, except in instances where someone is/was having the same problem I am; there are quite a few of us...

Was also wondering about the BIOS setting for aperature size && PCI-e cards; does how that's used vary from motherboard to motherboard or ??? If it does (or should) matter, what does the driver expect it to be set to? I have a choice of "disabled", 16Mb, 32Mb, 64Mb & 128Mb; none of the values match the amt of memory on my card (512Mb). Again, the card is PCI-e but the motherboard has on-board AGP graphics - which should be disabled, right?

Setting makes no difference as far as I can tell w 8.32.5 driver, and if there is a magic one for later drivers, I haven't found it yet.

Do the numbers above seem correct for a 512Mb PCI-e X1600 (RV530) card in a system w/2Gb RAM, with aperature currently set to 128Mb?

Thanks,
- Larry

[Michael]

Hi, Michael -



Set xorg.conf to the plain version I posted yesterday on three different machines, still no luck / no difference. I did, however, remember / notice that the numbers fglrx reported in /var/log/messages / dmesg didn't seem to correspond to anything:

[fglrx] Maximum main memory to use for locked dma buffers: 1899 MBytes.
[fglrx] total      GART = 532676608
[fglrx] free       GART = 516685824
[fglrx] max single GART = 516685824
[fglrx] total      LFB  = 267911168
[fglrx] free       LFB  = 250081280
[fglrx] max single LFB  = 250081280
[fglrx] total      Inv  = 268435456
[fglrx] free       Inv  = 268435456
[fglrx] max single Inv  = 268435456
[fglrx] total      TIM  = 0

I don't know what these numbers mean; but, in looking over posts from others, I don't recall seeing others posted with "0" for any of these totals, except in instances where someone is/was having the same problem I am; there are quite a few of us...

Was also wondering about the BIOS setting for aperature size && PCI-e cards; does how that's used vary from motherboard to motherboard or ??? If it does (or should) matter, what does the driver expect it to be set to? I have a choice of "disabled", 16Mb, 32Mb, 64Mb & 128Mb; none of the values match the amt of memory on my card (512Mb). Again, the card is PCI-e but the motherboard has on-board AGP graphics - which should be disabled, right?

Setting makes no difference as far as I can tell w 8.32.5 driver, and if there is a magic one for later drivers, I haven't found it yet.

Do the numbers above seem correct for a 512Mb PCI-e X1600 (RV530) card in a system w/2Gb RAM, with aperature currently set to 128Mb?

Thanks,
- Larry

Larry,

The aperture size shouldn't cause the DRI issues you are experiencing.

I left a message this morning with AMD, and am waiting on hearing back from them since it seems a number of people with PCI-E GPU -> AGP interface cards are running into problems.

Though 8.32 is working for you, have you tried upgrading your kernel or updating any other packages?

I would also suggest upgrading to 8.37 once available to see if the issue can be reproduced there.

[Alistair]

Hi, Michael -



Set xorg.conf to the plain version I posted yesterday on three different machines, still no luck / no difference. I did, however, remember / notice that the numbers fglrx reported in /var/log/messages / dmesg didn't seem to correspond to anything:

[fglrx] Maximum main memory to use for locked dma buffers: 1899 MBytes.
[fglrx] total      GART = 532676608
[fglrx] free       GART = 516685824
[fglrx] max single GART = 516685824
[fglrx] total      LFB  = 267911168
[fglrx] free       LFB  = 250081280
[fglrx] max single LFB  = 250081280
[fglrx] total      Inv  = 268435456
[fglrx] free       Inv  = 268435456
[fglrx] max single Inv  = 268435456
[fglrx] total      TIM  = 0

I don't know what these numbers mean; but, in looking over posts from others, I don't recall seeing others posted with "0" for any of these totals, except in instances where someone is/was having the same problem I am; there are quite a few of us...

Larry
Just checked on my running (working) agp card -
ATI Technologies Inc RV350 AS [Radeon 9550]
(the box said 9600 of course but sapphire clearly lies *grin*)

I have the following in dmesg (and World of Warcraft currently running in wine, on opengl)

agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode
[fglrx] AGP enabled,  AgpCommand = 0x1f004312 (selected caps)
[fglrx] total      GART = 134217728
[fglrx] free       GART = 118222848
[fglrx] max single GART = 118222848
[fglrx] total      LFB  = 134217728
[fglrx] free       LFB  = 116002816
[fglrx] max single LFB  = 116002816
[fglrx] total      Inv  = 134217728
[fglrx] free       Inv  = 134217728
[fglrx] max single Inv  = 134217728
[fglrx] total      TIM  = 0

so lets see --

I'm running an nforce2 chipset and an amd64 (64bit) installation, the bios on this motherboard ***does not have*** a GART apeture modification setting.
This is a 939 pin socket AMD 64 (single core).

Assume a default 128Mb apeture, and that GART total makes sense (bits not bytes),

and we have this as well:

(II) Module fglrxdrm: vendor="FireGL - ATI Technologies Inc."
        compiled for 7.1.0, module version = 8.35.5
        ABI class: X.Org Server Extension, version 0.3
(--) fglrx(0): VideoRAM: 131072 kByte, Type: DDR SGRAM / SDRAM
(II) fglrx(0): AGP card detected
(II) fglrx(0): board/chipset is supported by this driver (original ATI board)

Which isn't quite right either, since my card clearly has 256Mb on board, but it appears to be split 50/50 for the two heads.

(again the numeric differences are likely due to bits/bytes/kb/Kb)

one interesting table I've found along my travels with ATI products is in

/proc/dri/0/mem

                 total counts                    |    outstanding
type      alloc freed fail      bytes      freed | allocs      bytes
system        0     0    0 1577525248 18446604435732824064 |      0 -4294967296
locked      202   189    0  111013888   96141312 |     13   14872576
sareas       14    12    0   29417472   25214976 |      2    4202496
driver       15    12    0       1710        156 |      3       1554
magic        25    25    0        600        600 |      0          0
maplist      28    24    0       2240       1920 |      4        320
vmalist     546   516    0      13104      12384 |     30        720
buflist   192076 190211    0   23102248   22825320 |   1865     276928
files       174   168    0      56376      54432 |      6       1944
contexts     19    18    0        688        624 |      1         64
hwcontext   149   143    0    1220608    1171456 |      6      49152

which tells me the driver can darned well map my entire system memory if it wants (or at the very least knows what I have to map)

and /proc/dri/0/vm (excellent point of reference for what its actually doing right now)

offset     size       type flag handle     mtrr map_count

0xffffc200012af000 0x00002000  SHM 0x20 0xffffc200012af000 none 3
0xd0000000 0x08000000   FB 0x00 0x00000000    3 2
0xf9000000 0x00010000  REG 0x00 0xffffc200012e0000 none 2
0xffff81003a734000 0x00001000 PCIB 0x00 0xffff81003a734000 none 3
0xf0001000 0x00100000 AGPB 0x00 0xffffc20001300000 none 3
0xf0101000 0x00640000 AGPB 0x00 0x00000000 none 3
0xffffc20001401000 0x00400000  SHM 0x00 0xffffc20001401000 none 0
0xd0000000 0x00715000 LFBB 0x00 0x00000000 none 1
0xd0715000 0x00514000 LFBB 0x00 0x00000000 none 2
0xd7aca000 0x00536000 LFBB 0x00 0x00000000 none 2
0x19b14000 0x00001000  CTX 0x01 0xffff810019b14000 none 0
0xd0c29000 0x00004000 LFBB 0x00 0x00000000 none 1
0xd0c2d000 0x00001000 LFBB 0x00 0x00000000 none 1
0xd0c2e000 0x00001000 LFBB 0x00 0x00000000 none 1
0x1b422000 0x00001000  CTX 0x01 0xffff81001b422000 none 0
0xf0741000 0x00170000 AGPB 0x00 0x00000000 none 1
0x253aa000 0x00001000  CTX 0x01 0xffff8100253aa000 none 0
0xf08b1000 0x00170000 AGPB

I very much suspect that if I were to play with the allocations in vm I could get the addition to match the LFB in the dmesg entry

And I can map the contents of /proc/dri/0/vm against /proc/mtrr and it all adds up too.

[time2IPL]

Larry,

The aperture size shouldn't cause the DRI issues you are experiencing.

I'm still uncertain as to why that setting is even there; I thought it was specific to AGP cards && resulted in the setting aside of a "memory window" in "regular" RAM for memory-mapped I/O involving the video card; I didn't realize PCI-e used a similar scheme - actually, I'm still not sure if / that it does.

The lines I was thinking along - and this may be completely wrong; I have nothing other than a vague suspicion to support it - is that the presence of the memory window (aperature), combined with this motherboard's on-board graphics (GeForce 6100; chipset == nForce 430), might be confusing newer versions of the driver that are trying to contend with hybrid PCI-e + AGP cards. Call it a sneaking suspicion; I couldn't figure out what had changed that would have affected me between driver versions, and then that occurred to me as a possibility. Like I said, I can't confirm or even offer much in support; it would make some sense, though.

From Alistair's post:

I'm running an nforce2 chipset and an amd64 (64bit) installation, the bios on this motherboard ***does not have*** a GART apeture modification setting.
This is a 939 pin socket AMD 64 (single core).

So, Alistair, you have a "real" 8X AGP board that doesn't have an AGP aperature setting; interesting... Besides that and PCI-e, the other main differences between our setups is nForce 430 (mine) vs nForce2 && am2; also, my machine is dual-core. All of which shouldn't add up to a hill of beans. It's not SMP that's the problem; even with a kernel without SMP support, I get the exact same thing when I type "startx".

I'm also seeing the same thing you are with respect to the amount of memory fglrx reports for my card:

(--) fglrx(0): VideoRAM: 262144 kByte, Type: DDR2

for a 512Mb card.

I left a message this morning with AMD, and am waiting on hearing back from them since it seems a number of people with PCI-E GPU -> AGP interface cards are running into problems.

Thanks. I think part of the problem to date has been that they haven't believed there were any problems other than "failure to read the (non-existant) FM". Hopefully, your intervention will help.

Though 8.32 is working for you, have you tried upgrading your kernel or updating any other packages?

No problems there to speak of; my "daily driver" is running kernel 2.6.20-1.2948.ljm (the suffix == my initials), all of the official RedHat / Fedora RPMs on the system are current (give or take a day or two, anyway). I've built & installed mplayer && mplayerplug-in, VLC, OGLE, etc.; no issues building or running any of them. Google Earth and Celestia run terrifically. Have full browser integration going w/ Acrobat Reader, FP9 - even RP10 support (though I generally use mplayerplug-in in lieu of it). No issues running VMWare, WINE, vncviewer... No problems with the ATI driver until the kernel went to 2.6.20, at which point, it wouldn't compile; so, I patched the driver, and once I was back up and running, discovered that you had already done the same (eg., it finally occurred to me to check the ATI site for an updated driver). Oops.

When I first built this system I was actually amazed that everything went together as smoothly as it did; everthing on the motherboard worked, including the board's integraged graphics. No problems with any of the device drivers I've written, either (including one for a wireless NIC). I actually remember being amazed at how simply & smoothly the initial setup of the X1600 went, having fought with other, older versions of the ATI driver; the current driver when I bought the card was 8.31.5, one version prior to what I'm using now.

I would also suggest upgrading to 8.37 once available to see if the issue can be reproduced there.

I'll definitely do that; if the problem is even along the lines of what I'm thinking that it might be, then the problem might very well go away...

At this point, I'm guessing I've hit the point where we're "in the dark", huh? I was afraid of that; hopefully, ATI will open source the driver and that'll be that; until then, I'll keep trying whatever they put out and hope that it fixes things, if I keep this card; I'll wait until the 8.37 driver is out, and I really hope that fixes things; if it doesn't, I'm going to have to go with a diferent card (sigh; yet even more money out the window...)

Thanks for your help; if I ever do resolve this I'll be sure to let y'all know what the problem and fix were.

- Larry


it will end up both documented and

[Michael]

At this point, I'm guessing I've hit the point where we're "in the dark", huh? I was afraid of that; hopefully, ATI will open source the driver and that'll be that; until then, I'll keep trying whatever they put out and hope that it fixes things, if I keep this card; I'll wait until the 8.37 driver is out, and I really hope that fixes things; if it doesn't, I'm going to have to go with a diferent card (sigh; yet even more money out the window...

At least you won't need to wait long for 8.37. The end of the month is near

[time2IPL]

As you may have already guessed, I can't seem to stop thinking about this (which is about par for the course)...

Larry
Just checked on my running (working) agp card -

...

agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode
[fglrx] AGP enabled,  AgpCommand = 0x1f004312 (selected caps)
[fglrx] total      GART = 134217728
[fglrx] free       GART = 118222848
[fglrx] max single GART = 118222848
[fglrx] total      LFB  = 134217728
[fglrx] free       LFB  = 116002816
[fglrx] max single LFB  = 116002816
[fglrx] total      Inv  = 134217728
[fglrx] free       Inv  = 134217728
[fglrx] max single Inv  = 134217728
[fglrx] total      TIM  = 0

You're right, 128Mb is a reasonable default, and would seem to make sense in your case; if you look at the figures fglrx left in my dmesg, though (BTW, what I meant by "I have no idea what they mean" is "they're so far off what I would expect that I can't make sense of them"):

[fglrx] Maximum main memory to use for locked dma buffers: 1899 MBytes.
[fglrx] total      GART = 532676608
[fglrx] free       GART = 516685824
[fglrx] max single GART = 516685824
[fglrx] total      LFB  = 267911168
[fglrx] free       LFB  = 250081280
[fglrx] max single LFB  = 250081280
[fglrx] total      Inv  = 268435456
[fglrx] free       Inv  = 268435456
[fglrx] max single Inv  = 268435456
[fglrx] total      TIM  = 0

then, following that same logic would suggest (at least) two things:

0. That the driver is treating a PCI-e card's entire RAM as its GART;
to me, that suggests that the driver is assuming that every bit of
that memory is permanently mapped in and addressable; no "sliding
aperature", etc.; and,

1. the driver isn't using the aperature size setting at all when it's
dealing with a PCI-e card; that setting is, apparently,
effectively meaningless to the driver.

Sound realistic? See anything I'm missing?

The next part is interesting to me for two reasons; when X dies, that's the last thing that makes it into Xorg.0.log:

(II) Loading sub module "fglrxdrm"
(II) LoadModule: "fglrxdrm"
(II) Loading /usr/lib64/xorg/modules/linux/libfglrxdrm.so
(II) Module fglrxdrm: vendor="FireGL - ATI Technologies Inc."
        compiled for 7.1.0, module version = 8.36.5
        ABI class: X.Org Server Extension, version 0.3

it doesn't matter if I'm running x86_64 or i386 32-bit; the log file ends at exactly the same place. Which pretty much screams "architectural issue" (eg., driver isn't liking something on my motherboard) to me...

Also, it's usually followed by

(--) fglrx(0): VideoRAM: 262144 kByte, Type: DDR2
(II) fglrx(0): PCIE card detected
(II) fglrx(0): board/chipset is supported by this driver (original ATI board)

It'd be interesting to know if fglrxdrm died while attempting to figure out how much memory was on the card; that would suggest a sparse vs. flat / NUMA vs "normal" / etc. issue - or, at least, some sort of memory access issue; from the way utilization shoots up it looks more like a contention issue of some sort, maybe even deadlock.

(II) Module fglrxdrm: vendor="FireGL - ATI Technologies Inc."
        compiled for 7.1.0, module version = 8.35.5
        ABI class: X.Org Server Extension, version 0.3
(--) fglrx(0): VideoRAM: 131072 kByte, Type: DDR SGRAM / SDRAM
(II) fglrx(0): AGP card detected
(II) fglrx(0): board/chipset is supported by this driver (original ATI board)

Which isn't quite right either, since my card clearly has 256Mb on board, but it appears to be split 50/50 for the two heads.

I'm ony getting half my RAM reported too, and I'm definitely not running in dual-head mode; I don't know what's going on there. Maybe it's nothing more than a bug in libfglrxdrm.

... one interesting table I've found along my travels with ATI products is in

/proc/dri/0/mem

...

I see what you're saying; that does make sense. From the looks of it, the driver is doing it's own memory management on top of what the kernel provides; I vaguely remember hearing something to the effect of the driver was capable of that, but for whatever reason, that never stuck.

Since it is, it seems even more possible that if the driver was being run on an architecture with, say, NUMA support, or encountered an unusual memory layout, or both, that that part of it might run into some "issues". Which, the more I think about it, is what it appears is going on here...

Unfortunately, though, at this point in history, I can't test any of this and it'll have to remain pure speculation for the time being; perhaps someday...

If nothing else, as Michael noted, the end of the month is rapidly approaching, and as we're all far too well aware, there's a whole lot that can change in a couple of hours, let alone ten days.

- Larry

[Michael]

Well, it looks like this month's driver may be a late bloomer...

[yoshi314]

huh? what's that supposed to mean?

[sundown]

I guess it means it could be May 30th when it comes out or it could be any other day before that.
But hey, look on the bight side... Should it be postponed for next month, we might get two releases in June. This should be cool.

[yoshi314]

not really. but it would give developers more time to improve the driver.

i hate 8.36 driver for being released in half-finished state (well, at least i have that impression) just because there has to be 1 release per month.

i'd rather have ati release new driver with each development `milestone`, so to speak - that means after something new is introduced AND completely implemented.

or when new kernel/x.org comes out to sort out the compatibility issues.