OSS Radeon Drivers in Debian Testing are a letdown

[Kano]

@agd5f

That's absolutely stupid! If a user does not see X on startup he needs help. So he has to see something. With Kanotix (lenny based) only xv is accellerated anyway with r600+, so this does not hurt at all. You should write a driver that does not need any override which a normal user do not know at all! It seems that you like to tell every single user to use an override setting instead of makeing a save default.

@legume

Do you want to test a live image with that patch? KMS will not be used anyway...

[legume]

@legume

Do you want to test a live image with that patch? KMS will not be used anyway...

I'll test if you want - it would be interesting to see if the issues I listed are still there or not. It was some time ago I last tried.

If it's like any other Live CD I've ever used testing xv will be a pain as the players never seem to work with normal mpeg2 streams for some reason.

[legume]

I use a RV670 AGP and on my nforce2 mobo had to set AGP Aperture to 256 in bios to get things working.

I just retested this using drm-next and the problem is still there, but only for UMS, KMS so far is working OK.

[Kano]

The patch is not against drm but against the ddx, as i can only compile the 6-12 branch i only tested this.

[legume]

The patch is not against drm but against the ddx, as i can only compile the 6-12 branch i only tested this.

Yea - I was just retesting the aperture thing as I hadn't done so recently - the test was with my setup using AGP - no patch.

The results do make me wonder if your user would have got a working system without possible PCIE problems if kantonix used kms or if he/she changed the aperture size.

[agd5f]

@agd5f

That's absolutely stupid! If a user does not see X on startup he needs help. So he has to see something. With Kanotix (lenny based) only xv is accellerated anyway with r600+, so this does not hurt at all. You should write a driver that does not need any override which a normal user do not know at all! It seems that you like to tell every single user to use an override setting instead of makeing a save default.

Kano, feel free to tweak the drivers as you see fit for your distro. It doesn't make sense to disable AGP for all users because one user is having a problem. Should I disable acceleration for all users since there might be a user that has a problem with acceleration?

[Kano]

Why don't add an extra option to mark cards which needs that workaround?

[legume]

Why don't add an extra option to mark cards which needs that workaround?

Card + mobo rather than just card.

You could detect agpgart loaded before X starts and use BusType PCIE if you wanted and possibly add workarounds for the problems it causes at the same time.

At least AGP users could then choose to try using their hardware as it should be.

I tried your ISO and as expected got corruption and poor xv Cpu usage.

http://www.andyqos.ukfsn.org/kanotix-dfs.png

Both of which could be sorted using xorg.conf.

I notice that you don't use the power saving options anyway, but for me they still cause hard locks with BusType PCIE.

[Kano]

Well the system i tested had VIA chipset, maybe NV is different. Did a BusType "AGP" setting fix your problems?

[bridgman]

Card + mobo rather than just card.

It's even worse than that, depending on card/GPU + mobo/NB + SBIOS version + chipset drivers at the very least.

AGP at higher speeds / lower voltages is also quite sensitive to electrical noise in the system, which tends to get worse over time as parts age.

Doing something like SmartGART (**) would be a pretty big project, but I'm wondering if it might be possible to put in some simple logic that detects when the last Xorg startup was unsuccessful and turns off acceleration next time to improve the chances of a successful startup.

** SmartGART was an AGP diagnostic that ran at startup in our Windows drivers and automatically set options like AGP bus speed and FastWrite