AMD 8.40.4 Driver -- One Bug A Day Keeps AIGLX Away

[Kano]

Option "ChipID" "0x71C6"

That must be ignored because the only valid way to specify ChipID is:

ChipID 0x71C6

Without "Option" and quotes.

[Alistair]

That must be ignored because the only valid way to specify ChipID is:

ChipID 0x71C6

Without "Option" and quotes.

/me tippitoes across the livingroom, down the hall and flushes head

thanks.... I needed that -- some weeks I have no brains at all ...some weeks I do.

[Alistair]

Yet more on the X1650Pro AGP saga

Okay -- so chipid seems to still work as an option given the syntax i didn't use.

I found several chipids for the primary device of an X1650 (rv535 chip) card.

some were ugly (unsupported in driver) and others did nothing for me (locking up at agp initialization afaict)

found testgart.c on utah glx

gcc -m23 -o testagp testgart.c

and I get the following from that program :

Using AGPIOC_ACQUIRE
Using AGPIOC_INFO
version: 0.102
bridge id: 0xe110de
agp_mode: 0x1f00421b
aper_base: 0xa0000000
aper_size: 512
pg_total: 491264
pg_system: 491264
pg_used: 0
Using AGPIOC_SETUP
Using AGPIOC_ALLOCATE
Using AGPIOC_BIND
entry.key : 0
Using AGPIOC_ALLOCATE
Using AGPIOC_BIND
entry.key : 1
Using AGPIOC_INFO
version: 0.102
bridge id: 0xe110de
agp_mode: 0x1f00421b
aper_base: 0xa0000000
aper_size: 512
pg_total: 491264
pg_system: 491264
pg_used: 2048
Allocated 8 megs of GART memory
MemoryBenchmark: 30 mb/s
MemoryBenchmark: 31 mb/s
MemoryBenchmark: 31 mb/s
Average speed: 30 mb/s
Testing data integrity (1st pass): passed on first pass.
Using AGPIOC_UNBIND
Using AGPIOC_UNBIND
Using AGPIOC_BIND
Using AGPIOC_BIND
Testing data integrity (2nd pass): passed on second pass.
Using AGPIOC_DEALLOCATE
Using AGPIOC_DEALLOCATE
Using AGPIOC_RELEASE

that plus whats in dmesg

Aug 24 22:33:18 ajftl1 agpgart: Found an AGP 3.0 compliant device at
0000:00:00.0.
Aug 24 22:33:18 ajftl1 agpgart: testagp tried to set rate=x12. Setting to AGP3
x8 mode.
Aug 24 22:33:18 ajftl1 agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x
mode
Aug 24 22:33:18 ajftl1 agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x
mode
Aug 24 22:34:00 ajftl1 agpgart: Found an AGP 3.0 compliant device at
0000:00:00.0.
Aug 24 22:34:00 ajftl1 agpgart: testagp tried to set rate=x12. Setting to AGP3
x8 mode.
Aug 24 22:34:00 ajftl1 agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x
mode
Aug 24 22:34:00 ajftl1 agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x
mode

pretty much convinces me this is a driver bug.....

Anyone else with differing opinions/ideas/suggestions/swings of baseball bat?

[Kano]

Maybe you should thankfull that your card at least can show a picture without vesa driver unlike the new X2000 series cards. I use ATI cards to test my driver script, but when you really want/need speed use a different one. The older cards work with beryl (execept water effect) with free driver so these could be a choice for OSS driver friends. avivo is an interesting project for your card, but needs time. Everything with ATI needs time just to test how long you can live with Linux drawbacks till you sell the card. At least you can find lots of Win users who will be happy with it. ATI does not really much for their Linux users, no developers active in Linux boards, useless bugzilla system and monthly updated drivers who nobody needs as they add more problems than they fix (when you lock back a little bit), just like the "funny" google earth bug because of a bad opengl lib. Even when they work on a new driver, then they should not waste the time of others to test "stable" marked drivers monthly. They could use public beta drivers (not only for a few ppl with NDA) to find those bugs. I really don't get why they can not copy the basically working model of NVIDIA. The developers even directly support endusers in a public board and you can "feel" at least that someone knows about your problems. Here you wait and wait and wait till something happens (usually nothing happens). It seems they think that pushing out 12 alpha drivers a year without real fixes is something that makes Linux users love ATI...

[d2kx]

I guess AMDs fglrx developers would not release a new driver every month, so they have more time to work on the new one that comes later this year as Michael mentioned. They don't new developers, they need new managers.

Btw. Kano, nice to see you here

[Michael]

Maybe you should thankfull that your card at least can show a picture without vesa driver unlike the new X2000 series cards. I use ATI cards to test my driver script, but when you really want/need speed use a different one. The older cards work with beryl (execept water effect) with free driver so these could be a choice for OSS driver friends. avivo is an interesting project for your card, but needs time. Everything with ATI needs time just to test how long you can live with Linux drawbacks till you sell the card. At least you can find lots of Win users who will be happy with it. ATI does not really much for their Linux users, no developers active in Linux boards, useless bugzilla system and monthly updated drivers who nobody needs as they add more problems than they fix (when you lock back a little bit), just like the "funny" google earth bug because of a bad opengl lib. Even when they work on a new driver, then they should not waste the time of others to test "stable" marked drivers monthly. They could use public beta drivers (not only for a few ppl with NDA) to find those bugs. I really don't get why they can not copy the basically working model of NVIDIA. The developers even directly support endusers in a public board and you can "feel" at least that someone knows about your problems. Here you wait and wait and wait till something happens (usually nothing happens). It seems they think that pushing out 12 alpha drivers a year without real fixes is something that makes Linux users love ATI...

Kano, everything will become very clear shortly. Trust me

[Alistair]

I see a lot of folks seriously ticked off with ATI linux drivers - and what they see as ATI/AMD's development model.

Here is where I come from.


a) Canadian - okay I was born in that political entity south of our border, but I've lived in canada essentailly all my life, and took out Canadian Citizenship with pride.
ATI was one of the few Computer Systems companies to evolve in canada, survive and thrive. I will continue to support them as a functional part of AMD just 'cause I'm all for the 'little' guy and Intel needs the competition.

b) back in the bad old days when ATI first put out the rage series of chips I knew a couple folks working there - and helped write the OS/2 initial overlays to get the cards working. (and oddly - both video and modem) -- I still have fond memories of the successes and failures as we accomplished that.

c) I work for an organization which suffers (and believe me it IS SUFFERS) from the same evolutionary development model.

Someone somewhere has convinced management entities that evoluationary process is appropriate for software development. Being in systems support (at the os level thank god, not the app level) I have to note that it makes my life easier since 'evolutionary' software development ****cannot fix low level conceptual errors**** that is - if there is a conceptual error in the logical design, evolutionary software development cannot cope with the size/complexity of change required to correct the issue, and struggles along with minor workarounds, tweaks and more hardware/processing power/memory until it fails to scale out effectively. At which point we have an evolutionary event. (i.e the software gets nuked and rewritten without the flaw, but introducing new ones). As far as I can see it at the moment, ATI has approached an Evolutionary Software Event -- so we have to have a complete rewrite at this stage to fix the collection of issues at hand.

Point to be taken here - if you have evolutionary software processes and are approaching and evolutionary event, you need BODIES and lots of them ... so your regular code development curve gets gutted of staff for the rewrite and you have minor issues that start to stack up and cause huge complaints.

I've seen this protocol and event sequence in 4 different organizations - over 20+ years. It SUCKS -- and it has horrid fallout -- however it is what has worked for software development all along, and it has definable pluses, that is the work to solve an issue is quantifiable, the time to solve an issue is quantifiable and the beancounters get nice staggering numbers on just how expensive those damn developers are ... which makes them look good and cheap.

[Michael]

As you will see by the end of the year, AMD is not taking an evolutionary step but a revolutionary step in embracing the GNU/Linux and alternative OS communities.

[Alistair]

As you will see by the end of the year, AMD is not taking an evolutionary step but a revolutionary step in embracing the GNU/Linux and alternative OS communities.

I'm a bit of a pragmatist Michael -- but (if/when) something interesting happens, I'll celebrate the win with you.....
Scotch on me even ...

Besides -- for all the complaining folks do on this board, there's just as much whinging and complaining on the nvidia side --
And I'm not even gonna start on the stuff that gets said on intel support fora.....

[DrLecter]

As you will see by the end of the year, AMD is not taking an evolutionary step but a revolutionary step in embracing the GNU/Linux and alternative OS communities.

evolutionary = good driver
revolutionary = open specs