fglrx, 64bit linux and sb600 dma issue

[Kizo]

I don't get the connection. AFAIK there is nothing in the GPU or the GPU driver which uses a SB DMA controller. All the "DMA transfers" to/from the GPU are what used to be called "bus mastering", where the peripheral (in this case the GPU) supplies the address directly.

Why do you think that 64-bit issues with fglrx are related to sb600 dma, other than both being 64-bit issues ?

@Kano: Yes it is.

Well, the first thing that makes me think that way, is that "64bit linux + fglrx + 2GB ram" works Ok, but when > 3GB ram is installed, X doesn't start. The thing is SB600 reports 64bit DMA support, when in reality it is not so. It was the same problem that was corrected in the kernel ahci driver, so they forced 32bit DMA operation for SB600.
-In case of 32bit DMA the memory-mapped IO is placed in the upper part of the memory adresses, hence when 4GB is installed you get 3.2GB, the rest being reserved for IO adresses.
-In case of 64bit DMA the MMIO is placed somewhere higher (possibly in upper part of 64bit adresses, 32GB or 64GB), which makes adressing full 4GB and more possible, because there is much higher number of adresses.

I'm not specialist in the internal operation of fglrx, but i beleive it is possible that in 64bit linux it asumes that it deals with IO which addresses are placed higher and 64bit DMA that handles that (since almost every other SB on Intel or AMD 64bit platform except SB600 supports 64bit DMA, it is very unusual in a 64bit system to have 32bit DMA), but beyond the reach of the 32bit limitation of SB600.

If you do not beleive this is the problem, I'm sure it is possible for the makers of fglrx to test with SB600 any 64bit linux with fglrx, and try once with 2GB and once with 4GB or more installed (if it works with 4GB or more ram installed, I would be much surprised), in order to get to the bottom of the problem.

As a side-note: I have a friend (has SB600) who recently bought 6GB of ram and tried 64bit Windows Vista, and AHCI driver for Windows Vista made by AMD itself doesn't solve the problem (thankfully the guys making the anci linux kernel driver saw the problem and solved it), so he cannot get the OS to work with anything more then 3GB ram.

[Kizo]

I think i have found the same problem explained in this thread, which might give further indication to where the problem is.

[bridgman]

I thought Dennis had 3GB; that shouldn't be enough to trip the problem you're talking about, should it ?

My recollection was that on mobo's which were problematic with 64-bit and large RAM we could use the mem= boot parameter to make them run with a bit over 3GB; peripherals eat up a fair amount of address space but usually less than 1 GB (unless you have multiple graphics adapters).

My understanding from the dev team is that we see BIOS problems running 64-bit and large memory on a variety of configurations - not just SBxxx parts. I guess what I'm trying to say is that the fact an SBxxx part is involved with a 64-bit graphics driver problem doesn't necessarily mean that the southbridge is the issue, particularly since the southbridge is not involved in graphics driver operation AFAIK.

From what I remember, peripherals stay below 4GB and memory "displaced" by the peripherals gets remapped above 4GB, along with any RAM over 4GB. Modern GPUs support pretty large physical addresses (including your HD2600) so should not have trouble addressing a buffer anywhere including above 4GB. Older chips only support 32-bit physical addresses but they are all AGP parts so normally just access physical memory via the AGP mapped aperture anyways.

[energyman]

and which kernels do you have tried so far?

[Kano]

@Kizo

Now we know that fglrx is tested on Intel boards

[bridgman]

energyman; most testing is done on the kernels which are delivered in release versions of the "supported distros"; RHEL, SuSE and Ubuntu. We do advance testing on pre-release versions of those distros but do not block driver release for a failure on a pre-release distro.

Kano; yes, the secret is out

[Kizo]

Ok I would only like to ask this, and thank you for answering in advance:
-Can you identify the problem in your lab? (I have tried on 2 similar systems and the result is the same - black screen, second system was AMD770+SB600, 6GB ram and HD4650; I have also tried on Intel P45+ICH10R, 8GB ram and HD4850, and no problem there)
-Will there by any chance be a solution for this issue in future releases of fglrx?

@energyman: I have tried only with 2.6.27 and 2.6.28 kernels.

@Kano: LOL

P.S. I'm just trying to help solve the problem and if its somewhere else, fine, but I would like to use fglrx on 64bit linux on my system without "sacrificing" 2GB of ram to the gods.

[bridgman]

My understanding is that the problems vary from mobo to mobo, but invariably they go away with an SBIOS update. In cases where we can't get a BIOS upgrade from the mobo vendor we may have to start working around the remaining problems in the driver on a case-by-case basis, but that is one of those "bottomless pit" kind of tasks.

In cases where the mobo is all AMD we may have an easier time influencing the mobo vendor to fix the BIOS.

[Kizo]

Ok tnx for the answer.
Until then i will have to rely on radeon or radeonhd then.
I read radeon will have acceleration for r6xx/r7xx soon, so I guess there may be a workaround after all.

Thanks everyone.

[energyman]

well, there is a reason why I made sure that my mobo does not have a sb600 when I was looking around for a new one