Re: patch to get latest XFree 4.0 snapshot (xf3918) to work on pp cwith r128

On Tue, 6 Jun 2000, Kevin B. Hendricks wrote:

quoted

quoted

3. 601 processors may barf(?) on some of these instructions.

No, it does not. It's just that the cache is unified which makes most
coherency functions irrelevant.

So 601's have no problems with sync and isync, just eieio?  AFAIK, there is
some code snippet in the kernel that somehow works around a 601 problem
with one of the synchronization instructions but I don't remember which one
right off hand.

There's a bug on certain cards in x100-land that makes them crash on
sync() and eieio().  isync() is irrelevant on a 601, since there's not a
separate instruction cache.

I can only assume that this is what the original poster meant.


Later,
David


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Thu, 9 Mar 2000, David A. Gatwood wrote:

quoted

So 601's have no problems with sync and isync, just eieio?  AFAIK, there is
some code snippet in the kernel that somehow works around a 601 problem
with one of the synchronization instructions but I don't remember which one
right off hand.

There's a bug on certain cards in x100-land that makes them crash on
sync() and eieio().  isync() is irrelevant on a 601, since there's not a
separate instruction cache.

What do you mean with x100 ? Is it a series of PMAC models ? sync and
eieio perform an address-only bus broadcast that should be terminated by
the host bridge but never to the PCI bus so they can't crash HW. Is the
host bridge/memory controller really that buggy ?

And isync is not irrelevant on any processor since a) it flushes the
instruction queue and b) it ensures that the effect of all previous
instructions on machine state is taken into account before the next
instruction executes (that's important if you change context by changing
segment registers or modify some MSR bits).

	Gabriel


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Fri, Mar 10, 2000, Gabriel Paubert [off-list ref] wrote:

What do you mean with x100 ? Is it a series of PMAC models ? sync and
eieio perform an address-only bus broadcast that should be terminated by
the host bridge but never to the PCI bus so they can't crash HW. Is the
host bridge/memory controller really that buggy ?

Those machines are also known as the NuBus PowerMacs. The adress only
cycle is broadcast on their bus and makes some of Apple's AV cards crash.

And isync is not irrelevant on any processor since a) it flushes the
instruction queue and b) it ensures that the effect of all previous
instructions on machine state is taken into account before the next
instruction executes (that's important if you change context by changing
segment registers or modify some MSR bits).

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Fri, 10 Mar 2000, Gabriel Paubert wrote:

On Thu, 9 Mar 2000, David A. Gatwood wrote:

quoted

quoted

So 601's have no problems with sync and isync, just eieio?  AFAIK, there is
some code snippet in the kernel that somehow works around a 601 problem
with one of the synchronization instructions but I don't remember which one
right off hand.

There's a bug on certain cards in x100-land that makes them crash on
sync() and eieio().  isync() is irrelevant on a 601, since there's not a
separate instruction cache.

What do you mean with x100 ? Is it a series of PMAC models ? sync and
eieio perform an address-only bus broadcast that should be terminated by
the host bridge but never to the PCI bus so they can't crash HW. Is the
host bridge/memory controller really that buggy ?

NuBus, not PCI.  There's no bridge involved.  If the value in whichever
register, when shifted appropriately, results in a value within the NuBus
range, the address-only transaction causes problems, specifically the
system just locks up solid.  Only happens with certain cards.

And isync is not irrelevant on any processor since a) it flushes the
instruction queue and b) it ensures that the effect of all previous
instructions on machine state is taken into account before the next
instruction executes (that's important if you change context by changing
segment registers or modify some MSR bits).

My reference manual is in another city, so I can't look this up, but I'm
pretty sure isync is either a no-op or is mapped onto another instruction
for the 601.


David


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Fri, 10 Mar 2000, David A. Gatwood wrote:

quoted

What do you mean with x100 ? Is it a series of PMAC models ? sync and
eieio perform an address-only bus broadcast that should be terminated by
the host bridge but never to the PCI bus so they can't crash HW. Is the
host bridge/memory controller really that buggy ?

NuBus, not PCI.  There's no bridge involved.  If the value in whichever
register, when shifted appropriately, results in a value within the NuBus
range, the address-only transaction causes problems, specifically the
system just locks up solid.  Only happens with certain cards.

Ok, bad HW design, some of the so called address-only transactions do not
even use the address bits. They just use the address phase of the bus
protocol.

quoted

And isync is not irrelevant on any processor since a) it flushes the
instruction queue and b) it ensures that the effect of all previous
instructions on machine state is taken into account before the next
instruction executes (that's important if you change context by changing
segment registers or modify some MSR bits).

My reference manual is in another city, so I can't look this up, but I'm
pretty sure isync is either a no-op or is mapped onto another instruction
for the 601.

Wrong, and I had a 601 manual in front of me when I wrote this. You might
have confused it with icbi which is a no-op on 601, but isync definitely
is not.

	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/