At 8:12 AM -0500 9/28/04, Donald Lee wrote:
>Thanks to Tim Kelly, I believe we have eliminated the possibility that
>the L2/L3 cache is not being set up right in OF.
>
>Many thanks to Tim, who helped me run some tests with his new ofwboot.xcf
>code, and reminded me that we can telnet to OF (Cool!) for debugging.

Don is being generous about my efforts. I suggested this possibility
because the condition occurs only with the upgraded CPU card installed, and
I offered that perhaps there was a misconfiguration in the cache sizes
between actual and expected. In the event of an overflow, the CPU would
read values other than what should be in the cache. I actually used this
approach to dynamically calculate L2 cache sizes in the bootloader I was
experimenting with. By writing more (memory location specific) data than
the cache could handle while in test mode, I looked for the first data
value on cache size boundaries that did not match the expected value. That
location indicated the boundary of the cache was the one previously read.
Since Don had said that the ftp transactions will yield the correct file
size but have gibberish in the files, I thought that perhaps this was
because data in memory was outside the cache unbeknownst to the CPU. Again,
this was only relevant because it was a CPU upgrade that may or may not
have enough Open Firmware code included to properly configure itself.

Due to the presence of additional L2 cache information in the /cpus node
that matches the expected L3 specs, and the fact that in MacOS 9 and X no
additional software was necessary in order to have everything work, it does
not appear that the cache is the problem. However, I'd like to button down
a few details.

If someone could please tell me, which version and branch of cpu.c was
1.6.2 built with?

>From Don's original post:

Sep 26 14:53:31 temp /netbsd: cpu0: HID0
8450c0bc<EMCP,TBEN,NAP,DPM,ICE,DCE,SGE,
BTIC,LRSTK,FOLD,BHT>

It would appear that power save mode is enabled. Could this be a possible
problem that would explain why a while(1) loop in the background makes all
the problems go away (i.e., it never naps)?

Is anyone else running high end upgrade CPUs on their AGP G4s?

>On this "upgraded" machine, the "while(1)" program running in the
>background makes the machine quite stable.  If I kill it, then
>the machine freezes up the next time I try to do any interesting
>network activity.  This seems to be the same with the 3Com and the gem
>(built-in) ethernet.
>
>Any other thoughts from anyone?

thanks in advance,
tim