In message <200603071058.FAA06705@Sparkle.Rodents.Montreal.QC.CA>, der Mouse wr
ites:
>> Line 1: mfspr   %r3,SPR_DBCR0
>> 	Load DBCR0 into r3
>> Line 2: oris    %r3,%r13,DBCR0_RST_SYSTEM@h
>> 	Or the top half of DBCR0_RST_SYSTEM with the leftmost bits of r13 into
>> 	r3.
>> Line 3: mtspr   SPR_DBCR0,%r3
>> 	Load r3 into DBCR0

>> The first operation has no effect, because we immediately smash it
>> with whatever random garbage happened to be in r13.

>It looks effectless, yes, but a lot of machines have registers with
>magic effects when they're read, independent of what you may do with
>the data you get by reading them.

True.  But I don't think this is one.

>I don't know whether SPR_DBCR0 is such a register in this case, but
>your "because..." makes it look as though you're not considering the
>possibility.  (Of course, this could be because you did think about it
>and determined that it's not such a register, in which case just ignore
>me.)

I can't prove anything.  I have found code on several platforms for
resetting 4xx CPUs.  Some of them read the existing values, some just set
the reset bits.  It doesn't seem to matter.

So, at this point, the mystery is this:

* The above code resets the machine if called from the debugger
* It does not if called from elsewhere in the kernel

So, for instance, if I enter "reboot" at the boot device prompt, that code
hangs.  If I enter "halt", it drops to the debugger... And then "reboot"
works fine.

So cpu_reboot, if asked to reboot, can do so if and only if it's being
called from the debugger.  This makes no sense, because there's nothing in the
CPU documentation to suggest this.  All I can think of is that there's some
kind of address mapping which is disabled while in the debugger, which
causes the read from 0x3f2 to be routed to generic memory... But even that
can't be right, because it DOES have an effect, it just hangs instead
of resetting.

-s