New AGPGart

[cybland]

Hi Slice,

 

Welcome back.

 

I don't see if GA.plugin is reading gart-width. But I can say nothing about nVidia drivers.

 

 

Than I'm confused. While ago I've compared ioreg outputs from Leo with and without AGPGart and the only difference I found was the value of gart-width. That's why I thought that GA.plugin in Leo demands gart-width=0x40. Have you checked Tiger's or Leo's GA.plugin since the two are not the same?

[Never Mind]

Hi Zorglups,

 

Better late than never reply...

 

Just wanted to say thank you for your post below!

 

I tried those kexts but I still can't get QE...

 

I think I'll give up now.

 

Either way, I will keep an eye on the forum

 

Cheers,

 

N.M.

 

 

 

 

I don't get it at all.I just tryed a few things (again):

 

1) just ATIRadeon9700* from 10.4.11 -> CI/QE OKNote that the BUS is PCI, and the VRAM (Total) 128 (NOT 64 as it should be)!

 

2) Modifyed ATIRadeon9700GA.plugin (usefull to keep CallistoFB with AGPGart):<key>CFPlugInTypes</key><dict>

<key>ACCF0000-0000-0000-0000-000a2789904e</key>

<array><string>10024e50-0000-0000-0000-000a27898d3e</string> <----- this is what i changed->

NO more CI/QE.

a diff of both ioreg reveales a few chages, notably in ATIRadeaon9700:

InUsebyPids goes from 0x58 to blank

Performance statistics gives diffrent vram, gart sizes

and mostely an entire section called ATIR3002DContext (and Surface/GLContext) disapears.

 

3) ATIRadeon9700* from 10.4.11 and IONDRV1442 (from Slice) -> CI/QE OK

the IONDRV report VGA size...a diff of both ioreg reveales no critical changes (Power and HID...)

 

4) ATIRadeon9700* from 10.4.11 and Callisto003 -> No more CI/QE

I had CI/QE on previous test!!! Actually, I kept ioregs from past tests, and all Callistos have ATIR3002DContext!

a diff of the dmesgs shows different kernel virtual address

a diff of the kextstats shows exact same kexts but loaded in a diffrent order...

The VRAM switched allways to 64.

But I guess taht is all off topic for you...

 

5) ATIRadeon9700* from 10.4.11 and AGPGart266 - various AGP_Base

Nothing worked at all: black screen on all Bases/fastwrite enabled/disabled (<key>AGP_Mode</key><integer>0xffffffff</integer> / <integer>0x7fffffff</integer> ).

 

6) Earlier ATIRadeon9700* from 10.4.11 , Callisto003 and AGPGart266 -> No more CI/QE

That is where I started actually; And where I too needed clarification:

AGP_Base is reported by Windows (and IONDRV1442?) as a8000000 but that simply failes (no GUI)

f8000000 f0000000 (no GUI)

fa000000 7d000000 d4000000 (GUI but no chages)

I guess any value above RAM is OK, any value below (i.e. in RAM range) failes; VRAM does not matter; Except for my VRAM beying sometime displayed as 64 or 128: and that is when I messed up, and resolved to remove all Extensions and tar back an earlier stage (than removed AGPGart, and Callisto and ended at stage 1).

 

I can't do a thing before I resolve how I went through stage 4;I don't get It either why ATIRadeon9700* from 10.4.11 and AGPGart266 don't work anymore (stage 5).

Not much I can do anymore.

 

I forgot, for Never Mind:I suppose it is OK to upload plain 10.4.11 kext (from the combo update).I don't know if moderators will like that.Here are thoses kext you requested.

[toadspit]

I see your have aperture=0x02000000=32Mb. With this aperture you can't have QE! See my previous post with my answer to JaS. So no changes with flushtime.

 

Ok sorry but I can't boot in GUI with 64 or 128 mb aperture.

I tried 64Mb with different values for AGP_Base:

0: KP the first time, other times a strange white and black composition like a chessboard.

d8000000, e0000000, e8000000: KP.

[Slice]

Ok sorry but I can't boot in GUI with 64 or 128 mb aperture.

I tried 64Mb with different values for AGP_Base:

0: KP the first time, other times a strange white and black composition like a chessboard.

d8000000, e0000000, e8000000: KP.

KP is possible if AGP_Base overlaps other device.

Your VRAM address=e0000000 so AGP_BASE may be e4000000 or equal to HostAddress=f8000000

I have no other idea.

[JaS]

Just wanted to post that everything is still smooth with agpgart 2.6.7. Tell me what else I can test for you Slice.

[toadspit]

KP is possible if AGP_Base overlaps other device.

Your VRAM address=e0000000 so AGP_BASE may be e4000000 or equal to HostAddress=f8000000

I have no other idea.

 

e4000000 -> KP

f8000000 -> KP

 

[Slice]

Just wanted to post that everything is still smooth with agpgart 2.6.7. Tell me what else I can test for you Slice.

You means "slow"? Show me cinebench test in Mac and Windows.

 

e4000000 -> KP

f8000000 -> KP

 

Impossible! There must be some address without KP. Or you forget to erase kext cache.

For me ATI chipset works.

For CommonSense nVidia works.

I see no my mistakes.

 

2 Wippley

One of previous user (Mazazi) have the same chipset and had no freezes as you have.

[JaS]

You means "slow"? Show me cinebench test in Mac and Windows.

Impossible! There must be some address without KP. Or you forget to erase kext cache.

For me ATI chipset works.

For CommonSense nVidia works.

I see no my mistakes.

 

2 Wippley

One of previous user (Mazazi) have the same chipset and had no freezes as you have.

 

No I don't mean slow the speed is good. I am saying it is running perfect. Everything is up to speed and running well.

[zorglups]

Hi Slice,

 

Something works?

Radeon9700GA disabled, yes:

AGP: VRAM=[a8000000, 08000000]

AGPINTEL: aperture [ac000000, 04000000]

AGPINTEL trace PCI space

(00)=33408086 (04)=20900006 (08)=06000021 (0c)=00000000

(10)=ac000008 (14)=00000000 (18)=00000000 (1c)=00000000

(20)=00000000 (24)=00000000 (28)=00000000 (2c)=005a1025

AGP: Device is in legacy mode, setting 04 data rate

AGP memory 008b8000 length 00001000 offset 00000000 cnt 00000000

AGP memory 008b8000 length 00001000 offset 00001000 cnt 00000001

AGP memory 008b8000 length 00001000 offset 00002000 cnt 00000002

RadeonPCI::start

Range[0] a8000000:08000000

Range[1] 0000c100:00000100

Range[2] e0010000:00010000

Range@0x10 a8000000:08000000

Range@0x10 (a8000000) mapped to kernel virtual address 26903000

ATI ROM start at 000c0000 mapped to kernel virtual address 26903000

ROM signature is read as: 0000aa55

Config register@0x4 = 02b00007

Note:RadeonPCI gives the exact same values with no AGPGart and Radeon9700GA enabled...

 

That is old news...

 

Without GA.plugin all is good with any values. But without acceleration.

Radeon9700GA enabled, No:

the screen keeps the dmesg-style text, mouse is shown and working, about 2 minutes (long) activity, and a system crash (mouse stucked).

 

The IORadeonSupport101 is not working yet!

Yes, I know; I get a sytem crash when I try to load the kext at boot (at least I thing It did; don't remerber). I've gotten your source codes to have a look: I am not a system/hardware programmer, so I don't follow much of the process.

 

What I would like to know is the difference between:

<key>IOProviderClass</key>

<string>IOFramebuffer</string>

and

<string>IONDRVFramebuffer</string>

Note: I am trying AGPGart, Radeon9700GA enabled, with either IONDRVFramebuffer or IOFramebuffer but the ioregs look practically the same.

Actually, the same also as AGPGart, Radeon9700GA disabled!

Needless to say the acceleration part (Boot_display, Alppe_display, ATIR3002DContext... are all missing, but NO GUI.

too late to check further now.

[Slice]

No I don't mean slow the speed is good. I am saying it is running perfect. Everything is up to speed and running well.

You simply want to assuage me... Meanwhile thanks for good news.

I have no more to test but I need more theoretical information about my problems. If you found something interesting - publish, please!

 

2 zorglups.

Note:RadeonPCI gives the exact same values with no AGPGart and Radeon9700GA enabled...

Yes, of cause. neither AGPGart nor GA.plugin influence on Radeon registers except

170 - AGP_BASE

14c - MC_AGP_LOCATION

174 - AGP_CNTL - dunno what is it.

other values changed without my interference.

Radeon9700GA enabled, No:

the screen keeps the dmesg-style text, mouse is shown and working, about 2 minutes (long) activity, and a system crash (mouse stucked).

It is common problem of all users. I have exactly same behaviour or even KP if I set AGP_Base to any value except my unique value 0x3c000000. How I found the value? By numerous tryings!

But more.

I have only "checkboard" or "fuzzy screen" or "strange white and black composion" with F8 value larger then 0x00300000. I inject it by ATILead. Dunno what to do with nVidia.

What is the value?

It is Video Memory Size reported by BIOS directly to Radeon chip. MacOSX knows other value from PCI bus. ATI driver must correct the value but I see it does very late.

What is the influence? Why? How to correct?

My AGP bus works (sure!!!), my Radeon doesn't give me hardware OpenGL output. I see black window instead of rotating cube.

 

So my work is follow

AGP driver -> ATI framebuffer -> QE with GA

[jlvaio]

You simply want to assuage me... Meanwhile thanks for good news.

I have no more to test but I need more theoretical information about my problems. If you found something interesting - publish, please!

 

2 zorglups.

 

Yes, of cause. neither AGPGart nor GA.plugin influence on Radeon registers except

170 - AGP_BASE

14c - MC_AGP_LOCATION

174 - AGP_CNTL - dunno what is it.

other values changed without my interference.

 

It is common problem of all users. I have exactly same behaviour or even KP if I set AGP_Base to any value except my unique value 0x3c000000. How I found the value? By numerous tryings!

But more.

I have only "checkboard" or "fuzzy screen" or "strange white and black composion" with F8 value larger then 0x00300000. I inject it by ATILead. Dunno what to do with nVidia.

What is the value?

It is Video Memory Size reported by BIOS directly to Radeon chip. MacOSX knows other value from PCI bus. ATI driver must correct the value but I see it does very late.

What is the influence? Why? How to correct?

My AGP bus works (sure!!!), my Radeon doesn't give me hardware OpenGL output. I see black window instead of rotating cube.

 

So my work is follow

AGP driver -> ATI framebuffer -> QE with GA

hello i m trying to have internal screen in a vaio vgn-ar61zu with8600m gt 512 the monitor is 1900x1200 wxga

there s dvi vga s video and tv out i don t know if the problem is about nvcap i ve tried nvinject go and that works but only with external screen i can t flash my rom

 

when i use no driver the plist from geforce.kext change:

 

before:

<string>NVKernel</string>

<key>IOMatchCategory</key>

<string>IOAccelerator</string>

<key>IOPCIMatch</key>

<string>0x000010de&0x0000ffff</string>

after

<string>NVKernel</string>

<key>IOMatchCategory</key>

<string>IOAccelerator</string>

<key>IOPCIClassMatch</key>

<string>0x03000000&0xffff0000</string>

<key>IOPCIMatch</key>

<string>0x000010de&0x0000ffff</string>

 

 

but when i use driver it seems the line disapear like my internal screen:

 

0x03000000&0xffff0000

 

is that an adress for my internal screen?

do you think the way for having internal screen in vaio is having nvcap with svideo tvout

i tried to have my internal screen with qi/ce enabled since 3 month now

thanx if anyone can help

[Slice]

I didn't understand about what you say. May be you look here?

http://forum.insanelymac.com/index.php?showtopic=103549

 

 

It seems to be too late but I have new idea:

Till now I am supposing that AGP_Base must be the same address as Host controller IODeviceMemory.

If not I can write AGPGart with two different addresses

AGP_Base for Video card

HOST_Base for Host controller

But I have no idea how to calculate both of them. By fingering?

[cybland]

It seems to be too late but I have new idea:

Till now I am supposing that AGP_Base must be the same address as Host controller IODeviceMemory.

If not I can write AGPGart with two different addresses

AGP_Base for Video card

HOST_Base for Host controller

But I have no idea how to calculate both of them. By fingering?

 

Hi Slice,

 

 

 

Could those two bases be read from PCI dumps in Windows? I have used two utilities, or better said two representations of the same utility, to get the reports in Windows. They are "Craig Hart's PCI+AGP bus sniffer" and "System Information Viewer". I've already attached the reports from those two utilities in post 608. Could you take a look if you can read needed values?

[aitikin]

Hey Slice, I've been following this as long as I could and I'm excited to say that I now have my AGP recognized as such, however when I put the Geforce kexts back in the system doesn't start. Here's the relevant output of my system log:

 

Jun 11 13:41:39 Adams-Desktop kernel[0]: NVDA::start(VGAG) <1> failed
Jun 11 13:41:39 Adams-Desktop kernel[0]: AGP: Coherence support: no
Jun 11 13:41:39 Adams-Desktop kernel[0]: AGP: GART is 32 bit capable
Jun 11 13:41:39 Adams-Desktop kernel[0]: AGP: Found an AGP 3.0 compliant device.
Jun 11 13:41:39 Adams-Desktop kernel[0]: AGPAMD: 1 hammers found
Jun 11 13:41:39 Adams-Desktop kernel[0]: AGPAMD apbase=f0000000
Jun 11 13:41:39 Adams-Desktop kernel[0]: AGPAMD: aperture [f0000000, 02000000]
Jun 11 13:41:39 Adams-Desktop kernel[0]: AGPAMD trace hammer PCI space
Jun 11 13:41:39 Adams-Desktop kernel[0]: (00)=11031022   (04)=00000000   (08)=06000000   (0c)=00800000   
Jun 11 13:41:39 Adams-Desktop kernel[0]: (10)=00000000   (14)=00000000   (18)=00000000   (1c)=00000000   
Jun 11 13:41:39 Adams-Desktop kernel[0]: (20)=00000000   (24)=00000000   (28)=00000000   (2c)=00000000   
Jun 11 13:41:39 Adams-Desktop kernel[0]: (30)=00000000   (34)=00000000   (38)=00000000   (3c)=00000000   
Jun 11 13:41:39 Adams-Desktop kernel[0]: (40)=00003bff   (44)=08000040   (48)=00000000   (4c)=00000000   
Jun 11 13:41:39 Adams-Desktop kernel[0]: (50)=00000000   (54)=00000000   (58)=00000000   (5c)=99b75240   
Jun 11 13:41:39 Adams-Desktop kernel[0]: (60)=00000025   (64)=00000000   (68)=00000000   (6c)=00000000   
Jun 11 13:41:39 Adams-Desktop kernel[0]: (70)=51020111   (74)=50008011   (78)=08003800   (7c)=0000221a   
Jun 11 13:41:39 Adams-Desktop kernel[0]: (80)=23070000   (84)=21132113   (88)=00000000   (8c)=00000000   
Jun 11 13:41:39 Adams-Desktop kernel[0]: (90)=00000001   (94)=00000078   (98)=0003f5a0   (9c)=00000000   
Jun 11 13:41:39 Adams-Desktop kernel[0]: (a0)=00000000   (a4)=00000000   (a8)=00000000   (ac)=00000000   
Jun 11 13:41:39 Adams-Desktop kernel[0]: (b0)=00000000   (b4)=00000000   (b8)=4000002f   (bc)=00000000   
Jun 11 13:41:39 Adams-Desktop kernel[0]: (c0)=00000000   (c4)=00000000   (c8)=00000000   (cc)=00000000   
Jun 11 13:41:39 Adams-Desktop kernel[0]: (d0)=00000000   (d4)=000da701   (d8)=00000000   (dc)=00000000   
Jun 11 13:41:39 Adams-Desktop kernel[0]: (e0)=00000000   (e4)=0e680b20   (e8)=00001119   (ec)=00000000   
Jun 11 13:41:39 Adams-Desktop kernel[0]: (f0)=00000000   (f4)=00000000   (f8)=00000000   (fc)=00000000   
Jun 11 13:41:39 Adams-Desktop kernel[0]: AGPAMD trace host PCI space
Jun 11 13:41:39 Adams-Desktop kernel[0]: (00)=00e110de   (04)=00b00006   (08)=060000a1   (0c)=00000000   
Jun 11 13:41:39 Adams-Desktop kernel[0]: (10)=f0000008   (14)=00000000   (18)=00000000   (1c)=00000000   
Jun 11 13:41:39 Adams-Desktop kernel[0]: (20)=00000000   (24)=00000000   (28)=00000000   (2c)=00000000   
Jun 11 13:41:39 Adams-Desktop kernel[0]: AGP: Setting 08 data rate
Jun 11 13:41:39 Adams-Desktop kernel[0]: AGP: command written target=00000312 master=0000e313
Jun 11 13:41:39 Adams-Desktop kernel[0]: AGP memory 129cd000 length 00001000 offset 00000000 cnt 00000000
Jun 11 13:41:39 Adams-Desktop kernel[0]: AGP memory 129cd000 length 00001000 offset 00001000 cnt 00000001
Jun 11 13:41:39 Adams-Desktop kernel[0]: AGP memory 129cd000 length 00001000 offset 00002000 cnt 00000002
Jun 11 13:41:39 Adams-Desktop kernel[0]: NVDA::probe(VGAG)

 

If I remove the GeForce stuff, it boots like normal and this is what's seen in my System Profiler:

 

I'm going to try loading the kexts manually.

[Slice]

Could those two bases be read from PCI dumps in Windows? I have used two utilities, or better said two representations of the same utility, to get the reports in Windows. They are "Craig Hart's PCI+AGP bus sniffer" and "System Information Viewer". I've already attached the reports from those two utilities in post 608. Could you take a look if you can read needed values?

You really can get HOST_Base from windows

Bus 0 (PCI), Device Number 0, Device Function 0

Vendor 10DEh Nvidia Corp

Device 00E1h nforce3 CPU to PCI Bridge

Command 0006h (Memory Access, BusMaster)

Status 00B0h (Has Capabilities List, Supports 66MHz, Supports Back-To-Back Trans., Fast Timing)

Revision A1h, Header Type 00h, Bus Latency Timer 00h

Self test 00h (Self test not supported)

PCI Class Bridge, type PCI to HOST

Subsystem ID 02501462h Unknown

Subsystem Vendor 1462h Micro-Star International Co Ltd (MSI)

Address 0 is a Memory Address (anywhere in 0-4Gb, Prefetchable) : F0000000h

But AGP_Base is a value for QuartzExtreme output. Only for Macintosh!

In theory it is the same as HOST_Base. And all previous drivers assume they are the same. Practically I have black screen if I use 0xc4000000 as supposed by Windows. I think GA.plugin shifts address for output by own matter.

For Leo there is new problem of allocating 32-bit AGP addresses to 64-bit OS space. I make it in v267 according AMD documents but... You see no difference?

 

2 aitikin

Your report looks like good. You have Leo? Same problem as Cybland?

Jun 11 13:41:39 Adams-Desktop kernel[0]: (10)=f0000008 (14)=00000000 (18)=00000000 (1c)=00000000

Last digit 8 has no influence. It if Prefetchable flag. Same address. Might works!

[hotcorez]

Hello Jas,

 

Glad you got agpgart 2.67 working

 

Can you get this to work with geforce 7 cards on nvidia amd on leo?

 

If you can, please explain how. I know that Ati was working well.

 

Cheers

[aitikin]

2 aitikin

Your report looks like good. You have Leo? Same problem as Cybland?

 

Yeah, looks to be exactly the same problem as Cybland. What was your solution (if you had one) Cybland?

[cybland]

You really can get HOST_Base from windows

 

But AGP_Base is a value for QuartzExtreme output. Only for Macintosh!

In theory it is the same as HOST_Base. And all previous drivers assume they are the same. Practically I have black screen if I use 0xc4000000 as supposed by Windows. I think GA.plugin shifts address for output by own matter.

For Leo there is new problem of allocating 32-bit AGP addresses to 64-bit OS space. I make it in v267 according AMD documents but... You see no difference?

 

2 aitikin

Your report looks like good. You have Leo? Same problem as Cybland?

 

Last digit 8 has no influence. It if Prefetchable flag. Same address. Might works!

 

 

Yeah, looks to be exactly the same problem as Cybland. What was your solution (if you had one) Cybland?

 

@aitikin

 

There is no solution (so far) for AGPGart in Leo. I don’t think that anyone managed to get it working in Leo. On all combinations of MB (Via, Intel, AMD) and VGA (ATI, nVidia) as far as I have seen it always gives black screen with mouse cursor. It seems that Slice is right that GA.plugin in LEO does shift memory address for QE output, so whenever we have QE active it results in black screen. Strange thing is that this is not issue with Tiger, but as we already know GA.plugin from Tiger is different from the one in Leo and cannot be used.

 

 

Hi Slice,

 

I’ve compared ioreg outputs in LEO with (black screen) and without (full CI/QE) AGPGart and Tiger with AGPGart. You can find analysis in attached excel file. Anyhow, I’ve found a lot of differences between ioregs. For easier browsing I’ve marked in yellow all parameters that are unique to the single output, and in red all parameters where two outputs are different. One weird difference is that Leo with AGPGart doesn’t have NV30GLContext line, where both Leo without AGPGart and Tiger with AGPGart have it. I hope that you can find some useful info in this excel file.

IOReg_Analysis.xls.zip

[Slice]

I’ve compared ioreg outputs in LEO with (black screen) and without (full CI/QE) AGPGart and Tiger with AGPGart. You can find analysis in attached excel file. Anyhow, I’ve found a lot of differences between ioregs. For easier browsing I’ve marked in yellow all parameters that are unique to the single output, and in red all parameters where two outputs are different. One weird difference is that Leo with AGPGart doesn’t have NV30GLContext line, where both Leo without AGPGart and Tiger with AGPGart have it. I hope that you can find some useful info in this excel file.

Interesting alalysis! Deja vue! With Common Sense we did it.

No GLContext means GA.plugin is not switched on. Hm-m-m... I have no any info about GA principles.

Other differencies:

"AAPL,address" =

"AAPL,iokit-ndrv" =

"driver-ist" =

"AAPL,RegEntryID" =

and other ...ID are random numbers different from boot to boot. No matter!

Leo w/wo AGP

"noNVRAM" =

"VRAM,memsize" =

Tiger+AGP,

"VRAM,memsize" =

I think it means

Whole aperture 256Mb=PCI aperture 128Mb + AGP aperture 128Mb (in Tiger)

in Leo we have only left part - PCI aperture.

What is mean "noNVRAM" in Leo? IOGraphics has no such property but use NVRAM for displayParameters

	if (entry)
{
	gIODisplayFastBootPlatform->writeNVRAMProperty(entry, gIODisplayFastBootEDIDKey, 
							property);
}

But in PCI mode it works. Don't know.

I think we need to know how GA.plugin works.

 

P.S. are you sure that all kexts in Leo are Intel or Universal? If PowerPC - not works.

[cybland]

P.S. are you sure that all kexts in Leo are Intel or Universal? If PowerPC - not works.

 

Hello Slice,

 

Here is a list of my Leo graphical kexts with version numbers:

GeForce.kext - GeForce 1.5.24.9 (16.7.2f7)

GeForce7xxxGLDriver.bundle - GeForce7xxxGLDriver 1.5.24.9 (16.7.2f7)

GeForceGA.plugin - GeForceGA 1.5.24.9 (16.7.2f7)

GeForceVADriver.bundle - GeForceVADriver 1.5.24.9 (16.7.2f7)

IOGraphicsFamily.kext – IOGraphicsFamily 1.4.3, Apple Computer, Inc.

NVDANV40Hal.kext - NVDANV40Hal 1.5.24.9 (16.7.2f7)

NVDAResman.kext - NVDAResman 1.5.24.9 (16.7.2f7)

 

I’m quite sure that all are Intel code since they give hardware CI and QE (without AGPGart of course).

 

Definitely the key is to examine code of Leo’s GA.plugin. Seems that AGPGart in Leo will be a dead-end without knowledge of GA.plugin workings.

[Slice]

Hello Slice,

 

Here is a list of my Leo graphical kexts with version numbers:

GeForce.kext - GeForce 1.5.24.9 (16.7.2f7)

GeForce7xxxGLDriver.bundle - GeForce7xxxGLDriver 1.5.24.9 (16.7.2f7)

GeForceGA.plugin - GeForceGA 1.5.24.9 (16.7.2f7)

GeForceVADriver.bundle - GeForceVADriver 1.5.24.9 (16.7.2f7)

IOGraphicsFamily.kext – IOGraphicsFamily 1.4.3, Apple Computer, Inc.

NVDANV40Hal.kext - NVDANV40Hal 1.5.24.9 (16.7.2f7)

NVDAResman.kext - NVDAResman 1.5.24.9 (16.7.2f7)

 

I’m quite sure that all are Intel code since they give hardware CI and QE (without AGPGart of course).

 

Definitely the key is to examine code of Leo’s GA.plugin. Seems that AGPGart in Leo will be a dead-end without knowledge of GA.plugin workings.

RadeonGA.plugin works in Leo!

Check all kext as in my picture.

 

One other question. Why you have "gpu-sensor" in Leo but not in Tiger. What is the dependency? Can it influence on AGP?

[toadspit]

I continue testing, without better luck.

 

My VRAM = 0xe0000000

My Host_Address = 0xfc000000

 

I tried:

 

1. Keeping 64Mb aperture,

AGP_Base = VRAM+64Mb = 0xe4000000

AGP_Base = Host_Address+64Mb = 0x100000000

AGP_Base = 0xf0000000, 0xe8000000, 0xe4000000, 0xe2000000 (just guessing!)

Results: always KP

 

2. With 32Mb aperture, with every value I can boot into GUI!

 

And: yes, I deleted Extensions.mkext and Extensions.kextcache every time I change a value in AGPGart/Contents/Info.plist or change Aperture Size!

 

 

[cybland]

Hi Slice,

 

RadeonGA.plugin works in Leo!

Check all kext as in my picture.

 

I’ve checked all files with “Get Info” from right-click menu and all are universal.

 

One other question. Why you have "gpu-sensor" in Leo but not in Tiger. What is the dependency? Can it influence on AGP?

 

Well it seems that Leo detects a hardware sensor on my VGA (thermal sensor in GPU) and Tiger doesn’t detect it. An AppleHWSensor.kext must be installed to be able to utilize data from hardware sensors. I haven’t had it in Leo and that’s why gpu-sensor area show only detected data. After I’ve installed the AppleHWSensor.kext (from Tiger) I have now additional info in ioreg (attached ioreg) but also now there is 1.5 min. black screen (not the one I get with AGPGart but the black screen that normally lasts for just a second) before booting to GUI. Black screen with mouse cursor remains when I install AGPGart even with AppleHWSensor.kext, only difference is that now it takes longer to get to it (1.5 to 2 minutes).

 

Do you think that using IOMMU boot flag might help? It is a UNIX flag and it seems that 00Diabolic in this topic thinks that it may work in OS X. Here is a quote from his post:

 

IOMMU is Input/output memory management unit Flags

 

Currently four x86-64 PCI-DMA mapping implementations exist:

 

iommu=[1,2,3,4][<size>][,noagp][,off][,force][,noforce][,leak[=<nr_of_leak_pages>]

[,memaper[=<order>]][,merge][,forcesac][,fullflush][,nomerge]

[,noaperture][,calgary]

 

1-4 consist of the following combined options:

 

1. <arch/x86_64/kernel/pci-nommu.c>: use no hardware/software IOMMU at all (e.g. because you have < 3 GB memory).

Kernel boot message: "PCI-DMA: Disabling IOMMU"

 

2. <arch/x86_64/kernel/pci-gart.c>: AMD GART based hardware IOMMU.

Kernel boot message: "PCI-DMA: using GART IOMMU"

3. <arch/x86_64/kernel/pci-swiotlb.c> : Software IOMMU implementation. Used e.g. if there is no hardware IOMMU in the system and it is need because you have >3GB memory or told the kernel to us it (iommu=soft))

Kernel boot message: "PCI-DMA: Using software bounce buffering for IO (SWIOTLB)"

 

4. <arch/x86_64/pci-calgary.c> : IBM Calgary hardware IOMMU. Used in IBM pSeries and xSeries servers. This hardware IOMMU supports DMA address mapping with memory protection, etc.

Kernel boot message: "PCI-DMA: Using Calgary IOMMU"

 

General iommu options:

 

off = Don't initialize and use any kind of IOMMU.

 

noforce = Don't force hardware IOMMU usage when it is not needed. (default).

 

force = Force the use of the hardware IOMMU even when it is not actually needed (e.g. because < 3 GB memory).

 

soft = Use software bounce buffering (SWIOTLB) (default for Intel machines). This can be used to prevent the usage

of an available hardware IOMMU.

 

iommu options only relevant to the AMD GART hardware IOMMU:

 

<size> Set the size of the remapping area in bytes.

 

allowed Overwrite iommu off workarounds for specific chipsets.

 

fullflush Flush IOMMU on each allocation (default).

 

nofullflush Don't use IOMMU fullflush.

 

leak Turn on simple iommu leak tracing (only when CONFIG_IOMMU_LEAK is on). Default number of leak pages is 20.

 

memaper[=<order>] Allocate an own aperture over RAM with size 32MB<<order.

(default: order=1, i.e. 64MB)

 

merge Do scatter-gather (SG) merging. Implies "force" (experimental).

 

nomerge Don't do scatter-gather (SG) merging.

 

noaperture Ask the IOMMU not to touch the aperture for AGP.

 

forcesac Force single-address cycle (SAC) mode for masks <40bits (experimental).

 

noagp Don't initialize the AGP driver and use full aperture.

 

allowdac Allow double-address cycle (DAC) mode, i.e. DMA >4GB. DAC is used with 32-bit PCI to push a 64-bit address in

two cycles. When off all DMA over >4GB is forced through an IOMMU or software bounce buffering.

 

nodac Forbid DAC mode, i.e. DMA >4GB.

 

panic Always panic when IOMMU overflows.

 

calgary Use the Calgary IOMMU if it is available

 

Hi toadspit,

 

I continue testing, without better luck.

 

My VRAM = 0xe0000000

My Host_Address = 0xfc000000

 

I tried:

 

1. Keeping 64Mb aperture,

AGP_Base = VRAM+64Mb = 0xe4000000

AGP_Base = Host_Address+64Mb = 0x100000000

AGP_Base = 0xf0000000, 0xe8000000, 0xe4000000, 0xe2000000 (just guessing!)

Results: always KP

 

2. With 32Mb aperture, with every value I can boot into GUI!

 

And: yes, I deleted Extensions.mkext and Extensions.kextcache every time I change a value in AGPGart/Contents/Info.plist or change Aperture Size!

 

If I remember correctly Aperture size of 32Mb turns off AGPGart (same thing with aperture of 256Mb or more). That is why you can boot into GUI. Only aperture values of 64Mb or 128Mb make AGPGart active.

New_Leo_ioreg.txt

[Slice]

2 toadspit

I really don't know what to do else. The problem seem to be in nVidia driver.

I am thinking what I can propose related to the problem.

 

2 cybland

Very interesting observation!

About gpu-sensor: you need frontend to observe the card temperature. (?)

About IOMMU - I don't know. If AGPDriver works under Tiger so we need to find differences between settings if exists.

One interesting thing I see - allowdac. Something about 64-bit addressing.

[cybland]

Hi Slice,

 

2 cybland

Very interesting observation!

About gpu-sensor: you need frontend to observe the card temperature. (?)

 

Yes you are right. To be able to observe a GPU temperature I would need some front-end software. AppleHWSensor.kext is needed for the front-end to interpret the data received from sensors. But that’s not important for AGPGart anyhow.

 

About IOMMU - I don't know. If AGPDriver works under Tiger so we need to find differences between settings if exists.

One interesting thing I see - allowdac. Something about 64-bit addressing.

 

Unfortunately, it seems that OS X does not support IOMMU flag after all. I’ve tried it but there was no kernel boot message as 00Diabolic stated in his post and there was no change in the system behavior.

 

One other thing. If I remember correctly you said that you have used part of Joblo’s code for AMD64. Interestingly I get the same result in Leo if I use Joblo’s AGPGart (same black screen with mouse pointer and the same error in the system log: NVChannel(GL): Graphics channel exception! status = 0xffff info32 = 0x6 = Fifo: Parse Error 0000000b). Also WindowServer.log list all sorts of GL and CoreGraphics errors.

 

I have also noticed a difference in dmesg in Leo and Tiger. In Leo I always have (with or without AGPGart):

 

NVDA,Display-A: vram [00000000:10000000]
NVDA,Display-B: vram [00000000:08000000]

 

While in Tiger it is always:

 

NVDA,Display-A: vram [ef8c0000:10000000]
NVDA,Display-B: vram [00000000:01000000]

 

Also I’ve tried to overcome the 64bit addressing problem with –legacy flag which should, as far as I know, force the system to load in 32bit mode, but when I use that flag Leo freezes during the boot. I’m running out of ideas. What do you think I should try next?