I've updated my home debian insallation to new testing, which includes KDE 4.2.2. But seems that it lacks 3d acceleration in plasma. The CPU load is up to 100% when adding just 1 widget. Also I have a weird colors on toolbar and in menus.

Pegasos/Radeon?

You could take a look at the thread about radeon-rewrite elsewhere on this board and see if you can get that built, it may substantially improve performance too.

_________________
Matt Sealey

Pegasos II / Radeon 9200

I'll take a look. Is there a problem with 3d and kde on peg?

There shouldn't be but nobody is going to update the standard original Radeon driver anymore. Finding a problem in radeon-rewrite is more likely to get fixed.

_________________
Matt Sealey

Didnt help. I've rebuild mesa from trunk (with radeon-rewrite already in trunk). AIGLX is now not working. Composites are not working yet.

Ok. Now another one problem appeared. I've fixed the problem wirh wrong PCI node but now VBlank interrupt refuses to set up properly:
(II) RADEON(0): [drm] failure adding irq handler, there is a device already using that irq
[drm] falling back to irq-free operation

How to fix that I just don't know. My searches on the net gave nothing.
Can anyone help?

Ok. That problem is also fixed via "dirty hack".
The hack needs apt-get source libdrm and editing xf86drm.c:
In function drmGetInterruptFromBusID you need to replace the line to In function drmGetBusid you need to add BEFORE After that you should
and then

can you provide a patch? And maybe submit it to mesa3d-dev?

_________________
acrux _at_ linuxmail _dot_ org

I'll late do this. Submitting is useless. This is a very "dirty" patch only suitable to those, who does have their videocards on PCI:0001:xx:xx.x.

That's right, i only saw pegasos 1/2 and some old pseries with a videocards on PCI:0001

Well, i did a patch against libdrm-2.4.19 with your suggestions and DRI now works on this peg2. Thanks.

_________________
acrux _at_ linuxmail _dot_ org

It should happen on any system where the PCI controller is split into several domains and the graphics card is not in the 0 domain. On Pegasos, the first PCI bus - domain 0 - is the PCI bus. The second PCI bus - domain 1 - is the "AGP" bus.

This is both a weird concept that was done on the Mai northbridge for Pegasos I and an intentional design decision for the Marvell northbridge (since it could be either on the Marvell..) as it makes using PC southbridges a little less crazy when they assume they are on the only PCI bus.

On the PC the PCI buses are usually split into discrete controllers, and domains are only common in extreme server environments where a system may have 16 or 32 PCI slots or something all with discrete configuration spaces in order to make it fit within the PCI standard (more commonly it'd be something like 4 to 8 on a desktop PC or low end server and there is usually very little problem fitting 8 PCI cards in the 2GB address space).
What I am disappointed with here is that even with the new libpciaccess library for X.org and all the other technology in the kernel that changed how this works for the better, something somewhere STILL assumes that graphics adapters always live in Domain 0.

After all the fuss about it on Pegasos, the fact it went through every distro bugtracker (Ubuntu, SuSE, reported directly to X.org, Ian Romanick knew about it.. especially since he works at IBM and was responsible for pSeries!) it is surprising that it is still broken.

_________________
Matt Sealey