Jump to content
941 posts in this topic

Recommended Posts

I harried to claim that all is OK. I found mistakes in IOPCIFamily all versions including Chun-Nan. I wait for corrections.

 

2 common-sense

I see no differencies! Same aperture and bridge memory spaces!

I really don't know what is the diff 2.1 and 2.4.9! 2.6.0 is quite other.

I've got an nForce 3 system with AGP X1600Pro, running Tiger 10.4.7 and I'm now trying Leopard on this machine. I only found AGPGart 2.49 yet, where can I get V2.6 or newer? Are there any Leopard hints without searching the whole thread?

@ naquaada

 

Have a look at post 138 in this thread (number is in the right upper corner of the post) I think it should be on page 7 or 8 in this thread, there you will find all the instructions you will need to setuo AGPGart 2.60 and a download link.

 

For now it doesnt work at all but we are getting really close now so stay tuned for a new version of IOPCIFamily that probably are going to make the AGPGart kext work. Please read the first post in this thread for more instructions but keep in mind it doesnt work yet.

  • 2 weeks later...

I must be doing something wrong...

 

I replace IOPCIFamily.kext and IOPCCardFamily.kext, reboot...all is good. I add AGPGart.kext, clear the cache, repair permissions, reboot, and when my box gets to the Mighty Apple boot screen, I get a message saying that I need to reboot the system. So I reboot the system. And I get the same message again. And again. And again...

 

Any ideas?

 

Here is the IOREG from the system I have been working on the most...Ill try to remember to get one from my other TP tomorrow (I left it at work)

 

IBM ThinkPad T42p, ATI Mobility Radeon 9600, JaS Tiger 10.4.8

 

If you can figure this one out, I assure you that you will be crowned Coolest Person of the Day at my house.

  • 2 weeks later...

At last!Lets continue testing! :P

Now I have AGPGart 2.6.2 compatible with new IOPCIFamily 2.4.2 but problem with IOPCCardFamily.kext.

Ready to use IOPCIFamily for Tiger herehttp://forum.insanelymac.com/index.php?sho...81048&st=83

Sources for any system herehttp://forum.insanelymac.com/index.php?sho...0&start=333

New AGPGart attached. It is compiled for Tiger as well as all previous versions so I think it system independent. If anyone want I upload sources to compile it for Leo.

Test please! Successful or no report here.

Sorry, forum is buggy

hi slice,

system goes over the gray screen with apple and whirling circle, changes to blue screen and then KP.

I'm using Titan, IOPCIFamily 2.4.2 and your new AGPGart.

The graphic card is a Geforce 6200 (AGP of course!)

 

dmesg and ioreg in attachment

 

 

EDIT: uhm I see that in your debug info AGPGart shows Firewire memory map.

I don't have a Firewire, but an integrated Ethernet that OSX sees as a Firewire...

I've tried removing all IOFirewire* kext, KP anyway.

ioreg.txt

dmesg.txt

hi slice,

system goes over the gray screen with apple and whirling circle, changes to blue screen and then KP.

I'm using Titan, IOPCIFamily 2.4.2 and your new AGPGart.

The graphic card is a Geforce 6200 (AGP of course!)

 

dmesg and ioreg in attachment

EDIT: uhm I see that in your debug info AGPGart shows Firewire memory map.

I don't have a Firewire, but an integrated Ethernet that OSX sees as a Firewire...

I've tried removing all IOFirewire* kext, KP anyway.

Sorry, this is debug messages for me

AGPATI trace PCI space FireWire dev=4 func=1
(00)=ffffffff   (04)=ffffffff   (08)=ffffffff   (0c)=ffffffff

this ffff means no Firewire.

I need more detailed ioreg

ioreg -l -x -w 2048 >ioregToadspit.txt

Zip it before upload!

You have the same bus as me but another video so your experience would be very interesting.

Blue screen usually means that driver is switch on but framebuffer (NVDAResman in your case) - no.

Hi!

 

I get the black screen and the mouse cursor, I'm sending my dmesg and ioreg!

 

To me all looks fine except the line:

 

"AGP_Master" = <> in "display@0 <class IOAGPDevice, registered, matched, active, busy 0, retain 15>"

 

Is it really supposed to be empty?

 

Hope you find some useful information in there ;)

 

I'm running AGPGart 2.62 and IOPCIFamily 2.4.2 for Leopard.

 

EDIT:

 

I have A VIA K8T800 Pro shouldnt it be AGPVIA instead of AGPAMD?

 

AGP: Coherence support: no

AGP: GART is 32 bit capable

AGP: Found an AGP 3.0 compliant device.

AGPAMD: 1 hammers found

AGPAMD apbase=d0000000

AGP: Setting 08 data rate

AGP: command written target=00000b12 master=1f00e312

dmesg_and_ioreg.zip

2 toadspit

It is trace version of AGPGart for you.

boot with -v -s

/sbin/fsck -fy

/sbin/mount -uw /

sh /etc/rc

wait and type ctrl-c

dmesg >dmesgToadspit-2.txt.

 

for other chipsets there is no change

 

2 Common Sense

I saw no bad messages in your report.

AGP_Master really is empty. It is needed only as presence.

Can you boot into desktop if you exclude *GA.plugin?

Did you exclude IOPCCardFamily or it works fine for you?

@ Slice!

 

I get a picture now and can boot as usual into the desktop, System profiler says that I have QuarzGL and that Quartz Extreme is not supported, Core image is run in software and that AGP is working! OpenGL doesn't work it gets an error message (same as before):

 

NVChannel(GL): Graphics channel exception! status = 0xffff info32 = 0x6 = Fifo: Parse Error

0000000b

 

When I launch an OpenGL application it just crashes. Im bundling my dmesg and ioreg so you can check if there is any difference.

 

It will be interesting to hear your thoughts on this!

 

EDIT: My computer doesn't have any PCCard comptaible interface, its not a laptop.

dmesg_and_ioreg.zip

post-78274-1202832178_thumb.png

@ Slice!

 

I get a picture now and can boot as usual into the desktop, System profiler says that I have QuarzGL and that Quartz Extreme is not supported, Core image is run in software and that AGP is working! OpenGL doesn't work it gets an error message (same as before):

 

NVChannel(GL): Graphics channel exception! status = 0xffff info32 = 0x6 = Fifo: Parse Error

0000000b

 

When I launch an OpenGL application it just crashes. Im bundling my dmesg and ioreg so you can check if there is any difference.

 

It will be interesting to hear your thoughts on this!

 

EDIT: My computer doesn't have any PCCard comptaible interface, its not a laptop.

So you booted without GA?

It is may be a problem of physical address of Gart table. Can you help me?

Compare sources of 2.1 that is asserted as working with my sources 2.6.2 step by step for your AMD64 branch.

May be you find what I miss.

Especially all places with gartPhys.

May be you find more recent sources?

 

 

here you are!

I see some problem for you

AGPATI: MEM_CONF=00000000
AGPATI: aperture [00000000, 04000000]

Give me a time to think.

@ Slice

 

Yes I booted without GA.

 

About joblos version it gets the same error as yours in Leopard it only worked on Tiger, I don't think that it would help much to check his version against yours since they both suffer from the same problem, but if you like I will go trough it. A thing that strikes me is that you use 64-bits numbers in amd64.cpp and 64-bit function getPhysicalSegment64.

 

Leopard can't run in 64-bit mode on AMD cpus since there is no hacked kernel that currently enables it. so AMD machines only run in 32-bit mode (even though they can run 64-bit and Leopard is a 64-bit os).

 

so what will the result then be of:

 

pte = (phys & 0x000000ff00000000ULL) >> 28;

te |=(phys & 0x00000000fffff000ULL);

 

which uses 64-bits numbers to calculate, well whatever its calculating ;)

 

and this function:getPhysicalSegment64(...) seems to be 64-bits.

 

but atleast the calculations above can't go well in 32-bit mode they must produce a bad result.

 

Could you try to rewrite to 32-bit?

 

I will check much more in detail as soon as im able to I must do some school work now before going to bed.

 

 

EDIT:

 

Comparing Windows against OS X I found something interesting:

 

OS X:

AGPgart: BridgeMemoryRange [f9f00000, fbffffff]

AGPgart: BridgePrefetchableMemoryRange [f0000000, f8ffffff]

AGPgart: BridgeIORange [0000f000, 00000fff]

 

Windows:

Memory range: F9F00000 - FBFFFFFF

Memory range: F0000000 - F8FFFFFF

Memory range: 000A0000 - 000BFFFF

Memory range: E8000000 - EFFFFFFF

 

I/O interval: 03B0 - 03BB

I/O interval: 03C0 - 03DF

 

The BridgeIORange seems to be wrong since it never shows up anywhere in Windows. The other two seems to be correct as it corresponds to two of the memory ranges in Windows.

 

What do you think are we simply pointing to the wrong memory addresses?

Yes I booted without GA.

Without Ga you don't use gartTable so it is wrong.

Without gart OpenGL would crash as you see.

About joblos version it gets the same error as yours in Leopard it only worked on Tiger, I don't think that it would help much to check his version against yours since they both suffer from the same problem, but if you like I will go trough it. A thing that strikes me is that you use 64-bits numbers in amd64.cpp and 64-bit function getPhysicalSegment64.

I use this function always and didn't see any difference in 32-bit space. This function also used by Apple in his AGP driver AppleMacRiscPCI but PowerPC is 64-bit. :hysterical:

Leopard can't run in 64-bit mode on AMD cpus since there is no hacked kernel that currently enables it. so AMD machines only run in 32-bit mode (even though they can run 64-bit and Leopard is a 64-bit os).

 

so what will the result then be of:

 

pte = (phys & 0x000000ff00000000ULL) >> 28;

te |=(phys & 0x00000000fffff000ULL);

 

which uses 64-bits numbers to calculate, well whatever its calculating :hysterical:

 

and this function:getPhysicalSegment64(...) seems to be 64-bits.

 

but atleast the calculations above can't go well in 32-bit mode they must produce a bad result.

 

Could you try to rewrite to 32-bit?

My recent codes use only low 32-bit of the address

	OSWriteLittleInt32(gartArray, gartOffset, (phys64 & ~PAGE_MASK) | bridgeDev->addrMask);

Or you think we must to recalculate physical 64-bit address to Leo virtual 32-bit space? Any documentation how to?

Intel said that gart table use Physical-to-Physical translation.

And I have no AMD documentation about gartTable in cpu AMD64.

Comparing Windows against OS X I found something interesting:

 

OS X:

AGPgart: BridgeMemoryRange [f9f00000, fbffffff]

AGPgart: BridgePrefetchableMemoryRange [f0000000, f8ffffff]

AGPgart: BridgeIORange [0000f000, 00000fff]

 

Windows:

Memory range: F9F00000 - FBFFFFFF

Memory range: F0000000 - F8FFFFFF

Memory range: 000A0000 - 000BFFFF

Memory range: E8000000 - EFFFFFFF

 

I/O interval: 03B0 - 03BB

I/O interval: 03C0 - 03DF

 

The BridgeIORange seems to be wrong since it never shows up anywhere in Windows. The other two seems to be correct as it corresponds to two of the memory ranges in Windows.

 

What do you think are we simply pointing to the wrong memory addresses?

Yes, it is a problem! 0000f000 > 00000fff

Dejavu. I shall find it in IOPCIFamily or elsewhere.

 

Another joblo sources 2.1z

 

Slice,

 

I have 4c66 (Dell 600m), and just tested IOPCIFamily 2.4.2, AGPGart 2.6.2, and ATISlice 1.0.5, but I replied to the other thread:

 

http://forum.insanelymac.com/index.php?s=&...st&p=621173

Yes, you are right. Your problem is for those thread.

2 Common Sense and other VIA users

I found a real mistake for VIA chipset

			via.s.deviceNum = 1;  //Slice - ???

But with Common Sense I see

	| |   +-o VIAN@0  <class IOPCIDevice, registered, matched, active, busy 0, retain 6>
| |   |   {
| |   |	 "IOPCIResourced" = Yes
| |   |	 "IOName" = "pci1106,282"
| |   |	 "IODeviceMemory" = (({"address"=0xffffffffe8000000,"length"=0x8000000}))
| |   |	 "class-code" = <00000600>
| |   |	 "IOAGPFlags" = 0x1
| |   |	 "AGP_Target" = <>
| |   |   }

This means that via.s.deviceNum=0; :)

 

2 Toadspit

This version contain more traces for you. I want your dmesg.

EDITED

I found what is wrong for you

For target there must be

| | "IODeviceMemory" = (({"address"=0xfffffffff8000000,"length"=0x4000000}),({"address"=0xfffffffff7f00000,"length"=0x1000}))

but I see

AGPATI: map mmio f7f00000 to @259ac000

AGPATI: aperture [00000000, 04000000]

 

EDITED

The same problem

| | | | "Bridge Memory Ranges" = (0xffffffffd2b00000,0xffffffffdfffffff,0xfffffffff0000000,0xfffffffff2afffff,0xf

fffffff2c00000,0xfffffffff3ffffff,0xfffffffff6000000,0xfffffffff6dfffff)

but

AGPgart: BridgeMemoryRange [f2c00000, f6dfffff]

AGPgart: BridgePrefetchableMemoryRange [d2b00000, f2afffff]

?????

@ Slice

 

I'm trying to enter IO Bridge range manually assuming my IO addresses from Windows is going to be there, so far without success. I have two ranges in windows:

 

03B0 - 03BB

03C0 - 03DF

 

and only one in AGPGart.kext. Should I use the range: 0x03B00000 - 0x03DF0000 or should I call the allocating function twice with 0x03B00000 - 03BB0000 first followed by a second call with 0x03C0000 - 0x03DF0000?

@ Slice

 

I'm trying to enter IO Bridge range manually assuming my IO addresses from Windows is going to be there, so far without success. I have two ranges in windows:

 

03B0 - 03BB

03C0 - 03DF

 

and only one in AGPGart.kext. Should I use the range: 0x03B00000 - 0x03DF0000 or should I call the allocating function twice with 0x03B00000 - 03BB0000 first followed by a second call with 0x03C0000 - 0x03DF0000?

No-no.

There are port addresses. We don't need explicitly use its. Bridge IO Range might be at 80000 - 100000, it is PCI addresses.

Check spaces at

| | +-o AppleACPIPCI

But I think you must first of all try via.s.deviceNum=0 and may be exclude Bridge IO Range because it is not used by your NVidia.

EDITED

I found your old ioreg without my drivers. All memories are the same!

	| |   |   |   "CFBundleIdentifier" = "com.apple.iokit.IOPCIFamily"
| |   |   |   "Bridge Memory Ranges" = (0xfffffffff8000000,0xfffffffff8ffffff,0xfffffffff9f00000,0xfffffffff9fdffff)
| |   |   |   "IOMatchCategory" = "IODefaultMatchCategory"
| |   |   |   "Bridge IO Ranges" = (0xf000,0xfff)
| |   |   |   "IONameMatched" = "pci-bridge"

 

2 toadspit

the magic value in your report is

(ec)=ffffffc0

In past I saw other interesting values in the place It might be a key. But I have no documentation about ATI RS300 AGP bus as I have for Intel.

Our first problem is aperture address=0 ;) as I have too.

×
×
  • Create New...