Jump to content

New AGPGart

Slice

By Slice,
in AGPGart

 Share
941 posts in this topic

Recommended Posts

cyclonefr
cyclonefr
Posted
Posted

hum a via chipset but u didnt answer all my questions : what system? 10.4.X? QE/CI? what about Leo?

So the only problem was linked to AGPGART which wasnt functionnaL? cause afaik it was working from strach with AGPGART from joblo and VIA chipset on TIGER

Link to comment
Share on other sites
Common Sense
Common Sense
Posted
Posted
I could not get remote desktop to work, at all, even when i got to the desktop, but i was able to access my shared folders.
Interesting, I think it could be useful for Slice if you managed to remote login through SSH and get a dmesg and an ioreg dump from within Tiger. Since your computer is working to some degree I think you should be able to login with SSH if you enable it.
hum a via chipset but u didnt answer all my questions : what system? 10.4.X? QE/CI? what about Leo?So the only problem was linked to AGPGART which wasnt functionnaL?
Sorry I missed some questions im tired.Im running 10.4.10 I have:QE/Q2D/CI workingLeo isn't working at all and never has, I get a black screen and a coursor.I haven't tried earlier version of Slices AGP in Tiger but many of them might have been working.But yes it all seems to depend just on AGPGart for it to work, atleast in Tiger. No need for modified IOPCIFamily on my computer.Did I miss something? :)Im getting some sleep soon.Good luck!
Link to comment
Share on other sites
Common Sense
Common Sense
Posted
Posted

The Tiger issues with Intel should be solvable, if it works on VIA chipset then its just a matter of getting the Intel drivers to work correctly imho.

 

EDIT: adding GioFX OpenMark test in Tiger with AGP

EDIT2: adding GioFX OpenMark test in Tiger without AGP

EDIT3: adding GioFX OpenMark test in Leopard without AGP

post-78274-1203124777_thumb.png

post-78274-1203125617_thumb.png

post-78274-1203126151_thumb.png

Link to comment
Share on other sites
Common Sense
Common Sense
Posted
Posted
| | | +-o NVDA,Display-B@1 <class IONDRVDevice, registered, matched, active, busy 0, retain count 10>

| | | | | {

| | | | | "AAPL,maps" = ("_IOMemoryMap is not serializable","_IOMemoryMap is not serializable","_IOMemoryMap is not serializable","_IOMemoryMap is not serializable")

| | | | | "AAPL,ndrv-interrupt-set" = "IONDRVInterruptSet is not serializable"

| | | | | "IODeviceMemory" = (({"address"=0xfffffffffd000000,"length"=0x1000000}),({"address"=0xffffffffd0000000,"length"=0x10000000}),({"address"=0xfffffffffc000000,"length"=0x1000000}),({"address"=0xfffffffffe8e0000,"length"=0x20000}))

| | | | | "com-dcpp" = <9ba58c47>

| | | | | "display-cfg" = <ffffffff>

| | | | | "IOFBDependentID" = 0x4226c00

| | | | | "connector-type" = <00000000>

| | | | | "width" = <00000000>

| | | | | "height" = <00000000>

| | | | | "name" = <"NVDA,Display-B">

| | | | | "AAPL,RegEntryID" = <806601047f99fefb656d69537a6c7552>

| | | | | "AAPL,ndrv-dev" = Yes

| | | | | "AAPL,gray-value" = <c38c6400>

| | | | | "device_type" = <"display">

| | | | | "depth" = <00000000>

| | | | | "driver-ist" = <802785040100000080278504020000008027850403000000>

| | | | | "com-dspp" = <36ab8c47>

| | | | | "VRAM,memsize" = <0000000800000010>

| | | | | "com-varp" = <00a00324>

| | | | | "IOFBDependentIndex" = 0x0

| | | | | "nativeNDRV" = <"advn">

| | | | | "AAPL,address" = <0050c9470050c9480050c9580050c959>

| | | | | "refresh" = <00000000>

| | | | | "display-connect-flags" = <00000000>

| | | | | "compatible" = <"NVDA,NVMac">

| | | | | "AAPL,iokit-ndrv" = <20fc7247>

| | | | | "noNVRAM" = <01000000>

| | | | | "AAPL,gray-page" = <01000000>

| | | | | }

 

"connector-type" = <00000000>

"width" = <00000000>

"height" = <00000000>

"depth" = <00000000>

"refresh" = <00000000>

"display-connect-flags" = <00000000>

"VRAM,memsize" = <0000000800000010>

 

you have some funny looking values in your ioreg, im going to sleep now and because im tired I have only looked briefly, but it looks wrong. The VRAM, memsize doesn't look right from what I can see and the other values are _absolutely_ wrong. I mean the width of a screen can't be 0 pixels ;) and so on...

 

display-connect-flags seems to indicate that no display is connected which explains the other values.

 

Great information, lets see what the guru thinks :)

 

EDIT:

IMPORTANT.... :)

 

Bimmer I need to know if this is from Tiger or Leopard, the reason im asking is because you get the exact same error message as I get in Leopard.

 

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

0000000b

 

If tihs is in Leopard then please try to use AGPGart in Tiger and report your result.

 

If this is in Tiger then im confused.

 

but now: ZzzzZZZzzzZZZZzzzzzzzz

Link to comment
Share on other sites
Common Sense
Common Sense
Posted
Posted
That was from Tiger, 10.4.11. I'm only testing Tiger right now, I want to get it working there first. I know AGPGart 2.1 worked with 10.4.8 and my ATI x700 Pro.

 

That's very interesting that Tiger 10.4.11 seems to introduce the same problem as Leopard does, it means that I should be able to upgrade my OS X to 10.4.11 and if i'm lucky get the problem you have then I revert files from 10.4.11 to 10.4.10 one by one until I get it working to see which file does cause this.

Link to comment
Share on other sites
Common Sense
Common Sense
Posted
Posted

@ bimmer

 

It doesn't seem we can make it work for Intel atm but there is hope I think, the problem is absolutely in AGPGart and not in IOPCIFamily, at least in the case of Tiger.

 

It's strange that I get it to work in Tiger (running 10.4.11 now) but in leopard I get an error message from the nvidia driver. The funny thing is that you get the same error in Tiger as I get in Leopard but somehow Tiger works for me.

 

My guess is that we reach the same problem through different actions, your AGPGart is not working well so it screws up memory addressing or something, and for me Leopard screws up memory addressing and therefore we get the same problem but the cause of the problem is different.

Link to comment
Share on other sites
Bimmer
Bimmer
Posted
Posted

@ common sense

 

I tried AGP 2.1 with PCI 2.2 again, i now make it to the blue screen before the login window, i was able remote in, and get the dmesg. Here they are. What are you using to get your Nvidia card working? (ie.. NVInject, Natit, Titan?????)

 

Edit:

 

Here are my files from single user mode.

Remote_Login_AGP21_PCI22.zip

Test_Single_Users_Mode_AGP21_PCI22.zip

Link to comment
Share on other sites
Common Sense
Common Sense
Posted
Posted
@ common sense

 

I tried AGP 2.1 with PCI 2.2 again, i now make it to the blue screen before the login window, i was able remote in, and get the dmesg. Here they are. What are you using to get your Nvidia card working? (ie.. NVInject, Natit, Titan?????)

 

Edit:

 

Here are my files from single user mode.

 

Im using the same version of NVInject as you do. Please try my modified version of AGPGart 2.62. Use IOPCIFamily 2.2 for the test.

 

Thanks!

AGPGart.kext_2.62_cs_modified.zip

Link to comment
Share on other sites
Slice
Slice
Posted
  • Author
Posted
It doesn't seem we can make it work for Intel atm but there is hope I think, the problem is absolutely in AGPGart and not in IOPCIFamily, at least in the case of Tiger.

 

It's strange that I get it to work in Tiger (running 10.4.11 now) but in leopard I get an error message from the nvidia driver. The funny thing is that you get the same error in Tiger as I get in Leopard but somehow Tiger works for me.

 

My guess is that we reach the same problem through different actions, your AGPGart is not working well so it screws up memory addressing or something, and for me Leopard screws up memory addressing and therefore we get the same problem but the cause of the problem is different.

What I found.

With old IOPCIFamily

AGPINTEL trace PCI space
(00)=25708086   (04)=20900006   (08)=06000002   (0c)=00000000   
(10)=f0000008   (14)=00000000   (18)=00000000   (1c)=00000000

(10) - AGP_APER_BASE

With new one

AGPINTEL trace PCI space
(00)=25788086   (04)=20900006   (08)=06000002   (0c)=00000000   
(10)=00000008   (14)=00000000   (18)=00000000   (1c)=00000000

See the difference!

 

I don't know is it a difference Tiger 2.2Leo 2.4 or it is my correction 2.42.4.x because 2.4 don't work for me.

I want you make such traces of host controller (dev=0 func=0) and hammer (dev=24 func=3) and compare two cases:

1. Working situation in Tiger

2. Black screen in Leo

 

I also check that

  //Slice
err = getDTNubAddressing( nub );  //V22
//	err = getNubAddressing( nub );  //V16

result in non-working PCCard, so I return back to getNub as in IOPCIFamily 2.4.2 (v16)

 

NEXT

Link to comment
Share on other sites
Common Sense
Common Sense
Posted
Posted
What I found.

With old IOPCIFamily

AGPINTEL trace PCI space
(00)=25708086   (04)=20900006   (08)=06000002   (0c)=00000000   
(10)=f0000008   (14)=00000000   (18)=00000000   (1c)=00000000

(10) - AGP_APER_BASE

With new one

AGPINTEL trace PCI space
(00)=25788086   (04)=20900006   (08)=06000002   (0c)=00000000   
(10)=00000008   (14)=00000000   (18)=00000000   (1c)=00000000

See the difference!

 

I don't know is it a difference Tiger 2.2<->Leo 2.4 or it is my correction 2.4<->2.4.x because 2.4 don't work for me.

I want you make such traces of host controller (dev=0 func=0) and hammer (dev=24 func=3) and compare two cases:

1. Working situation in Tiger

2. Black screen in Leo

 

I also check that

  //Slice
	err = getDTNubAddressing( nub );  //V22
//	err = getNubAddressing( nub );  //V16

Give me non-working PCCard, so I return back to getNub as in IOPCIFamily 2.4.2 (v16)

 

You do remember that you have changed the deviceNum to 1 in amd64.cpp? Anyway for the debugging im reading from dev=0 and func=0 as you wanted just checking if that is correct or if you forgot that you changed deviceNum to 1.

 

Im attaching the zip file as usual, let us know what you find!

 

EDIT: I just compared the Tiger 2.4.3 and Tiger 2.2 and noticed a difference so I decided to do a second try with Tiger and 2.2 just to verify that the result would again be the same as before.

 

The result differed!! so even when using Tiger and IOPCIFamily 2.2 the results are going to differ from reboots! But yet AGP always works so its going to be hard to draw any conclusions from these values since if they change across reboots with the same setup how could we draw conclusions when we compare these results?

 

EDIT2: The results differ for both hammer and host controll (across reboots with the same version of IOPCIFamily as stated above)

cs_dmesg_ioreg.zip

Link to comment
Share on other sites
Common Sense
Common Sense
Posted
Posted
@Slice

 

Is this for Common Sense or me? If it is me, I'm not sure what you want me to do. I see the difference. Just give me a little me instruction on what you want.

 

It must be for me since he talks about hammer and that applies only to AMD systems. He quotes some Intel results in another later post are those from your machine?

Link to comment
Share on other sites
Slice
Slice
Posted
  • Author
Posted

First of all thank you for detailed testing!

You do remember that you have changed the deviceNum to 1 in amd64.cpp? Anyway for the debugging im reading from dev=0 and func=0 as you wanted just checking if that is correct or if you forgot that you changed deviceNum to 1.

You didn't understand me

via.s.deviceNum = 1; -- this is previous codes. It is wrong because real device

| | +-o VIAN@0

Real VIA host controller Dev=0 -- right value

Im attaching the zip file as usual, let us know what you find!

 

EDIT: I just compared the Tiger 2.4.3 and Tiger 2.2 and noticed a difference so I decided to do a second try with Tiger and 2.2 just to verify that the result would again be the same as before.

 

The result differed!! so even when using Tiger and IOPCIFamily 2.2 the results are going to differ from reboots! But yet AGP always works so its going to be hard to draw any conclusions from these values since if they change across reboots with the same setup how could we draw conclusions when we compare these results?

 

EDIT2: The results differ for both hammer and host controll (across reboots with the same version of IOPCIFamily as stated above)

It is real problem to find why PCI bus different from reboots. Some unintialized values in IOPCIFamily?

I, for example, have a different OpenGL memory size from reboots.

But my previous question about (10) you resolve. For you it is always 0.

 

This value (98)=00058d40 is always different because it is IOMalloc result. Random address.

 

The real difference in hammer

243 for tiger

 (50)=0fc29778   (5c)=fd9be7c0	 (e4)=08670020

243 for leo

 (50)=00000000  (5c)=fd9befc0	 (e4)=08630020

I have no description of these places ;)

Probably for Leo AMD works in other mode?

 

2 Bimmer

I have no yet any comment s for you.

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...