Subject: 7500-class boot SOLUTION (nap mode BAD, doze mode GOOD!)
To: Tsubai Masanari <tsubai@iri.co.jp>
From: Monroe Williams <monroe@pobox.com>
List: port-macppc
Date: 10/27/2000 02:28:20
on 10/27/00 1:46 AM, Tsubai Masanari at tsubai@iri.co.jp wrote:

>> The change which kills my machine happened between 20000208-UTC and
>> 20000209-UTC.  The full list of files that changed between these two dates
> ...
> 
> It seems that meaningful change is power-saving related.
> Does this patch work?
[snip]

Before I received this patch from you, I tried changing the power-saving
code in my 20000209 tree to put the 750 into "doze" mode instead of "nap"
mode.  (In the same place, cpuattach() in arch/macppc/macppc/cpu.c.)

This seems to fix the problem.

I can see why this would be the case.  According to section 10.2.1.4 of the
MPC750 User's Manual:

"[...] To maintain data coherency, bus snooping is disabled for nap and
sleep modes through a hardware handshake sequence using the quiesce request
(QREQ) and quiesce acknowledge (QACK) signals. [...] If the system
determines that a bus snoop cycle is required, QACK is deasserted to the
MPC750 for at least eight bus clock cycles, and the MPC750 will then be able
respond to a snoop cycle. [...]"

I'd be willing to bet money that the DMA controller in the 7500 doesn't
deassert QACK before it writes to RAM (hell, that pin probably isn't even
connected to anything), and the cpu blissfully naps right through the whole
thing.  It then wakes up and uses stale data from its cache as SCSI command
responses or whatever else it was supposed to get back.

I'll try applying this change to a more recent version of -current and see
if the resulting kernel will boot.  If this really is what's causing the
problem, it sure would be nice to get some sort of fix into the next
release...

-- monroe
------------------------------------------------------------------------
Monroe Williams                                         monroe@pobox.com