Bug 182180 - Invalid memory access at %SSR0: ....
Invalid memory access at %SSR0: ....
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
powerpc Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
: 182518 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2006-02-20 16:42 EST by Andrew Cagney
Modified: 2015-01-04 17:25 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-05 13:36:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Andrew Cagney 2006-02-20 16:42:09 EST
Description of problem:

Attempting to boot fc5test3 ppc boot cd 2-cpu G5 machine.  Get this very soon
after the <<boot:>> prompt:

Invalid memory access at   %SRR0: 00000000.01409018  %SRR1: 10000000.00003030

Apple PowerMac7,3 5.1.8f7 BootROM built on 10/26/04 at 16:30:32
Copyright 1994-2004 Apple Computer, Inc.
All RIghts Reserved.

Welcome to Open Firmware, the system time and date is:
Invalid memory access at %SRR0: 00000000.86874196  %SRR1: 68435456.33599536
0 >
Comment 1 Paul Nasrat 2006-02-20 18:21:07 EST
Can you type


after this.  Also what is load-base set at?

printenv load-base

You might want to  try setting the OF defaults and restarting:


Comment 2 Andrew Cagney 2006-02-21 09:25:12 EST
0 > .registers
state not valid
0 > printenv load-base
---- blah blah ---
load-base           0x800000      0x800000
[I checked, it's 5, not 7, zeros]

(the machine is booting an fc4ish system)
Comment 3 Andrew Cagney 2006-02-21 09:39:28 EST
The machine can boot an FC-5 Test 1 CD.
Comment 4 Paul Nasrat 2006-02-21 14:37:56 EST
OK this is potentially weirdness between our OF/yaboot/kernel display
initialisation in prom_init.  I've seen on a quad G5 here too.  Our initial
analysis shows the following - please check:

* The G5 has an started to load the kernel
dev /chosen
(look for linux,stdout-package and linux,stdout-path - can you note the values.)
* The stdout-package is invalid FFFFFF so we don't get prom_printf (and thus
building with DEBUG_PROM is useless without hardcoding the phandle - which we'll
do when the quad is next in).
* yaboot with DEBUG=1 built works
* Removing the setup_display call in yaboot makes it work
* Removing the prom_printf('\xc') in setup_display() works.

I can produce a boot image for you to test the various setups to ensure it's the
same error.
Comment 5 Andrew Cagney 2006-02-21 15:51:35 EST
Test a boot image?  Sure;  It is probably the above: the kernel is loaded; the
screen goes blank; the barf appears.

Would a firmware update talso fix this?
Comment 6 Paul Nasrat 2006-02-21 17:24:23 EST
I think I see what is going on here, I've dropped a patch from yaboot which I
hope will fix this.  Can you just confirm in OF after failure

dev /chosen

and let me know what linux,stdout-package and linux,stdout-path are.
Comment 7 Andrew Cagney 2006-02-21 18:05:51 EST
0 > dev /chosen
Invlid memory access .....
0 > .properties
Invalid memory ....
Comment 8 Paul Nasrat 2006-02-21 18:27:54 EST
Hmm ok, that could be something different to the bug I'm seeing, can you try
tomorrows rawhide tree and see how that goes.
Comment 9 Andrew Cagney 2006-02-22 11:20:02 EST
I tried the 2006-02-22 rescue cd; same barf :-(
Comment 10 Andrew Cagney 2006-02-22 11:23:06 EST
can a ppc boot from one of these images copied to usb memory stick?
Comment 11 Paul Nasrat 2006-02-22 13:23:05 EST
OK I think you are experiencing a different problem to the one I'm seeing on the
quad, the complete corruption (invalid memory access) of OF concerns me - have
you tried to zap the PROM.

It might be worth seeing if there is an OF upgrade.  Can you also do the
following. Replace 10.0.01 with a valid ip address for the G5:

1) boot into OF
2) " enet:telnet," io
3) on another box telnet you should get an OF prompt
4) boot cd:,\\:tbxi - use the boot.iso from the tree
5) hit return at yaboot.

This will give a session you can record (maybe run script prior to the telnet).

Yes ppc can boot from USB memory stick, but let's try and figure what's up here.
Comment 12 Andrew Cagney 2006-02-22 13:40:15 EST
This was with the rescue CD; I'll have to download the boot cd.

$ telnet tooma
Trying ......
Connected to tooma.
Escape character is '^]'.
0 > eject cd  ok
0 > boot cd:,\\:tbxi load-size=802 adler32=7c65e56d

parsing <CHRP-BOOT>

evaluating <BOOT-SCRIPT>

telnet> c


The screen displayed the boot: prompt, went blank and then displayed:

0 >
Comment 13 Andrew Cagney 2006-02-25 11:58:01 EST
Same with the 2006-02-24 boot disk.

Btw, is there something missing; after the panic, my input from the telnet
session appears on the monitor screen :-/

And if I don't use the telnet trick, dev /chosen .properties works (i.e., at
least it is no longer smashing something)
Comment 14 Paul Nasrat 2006-02-28 15:15:30 EST
*** Bug 182518 has been marked as a duplicate of this bug. ***
Comment 15 Paul Nasrat 2006-02-28 15:18:36 EST
Yeah the OF chrp script sets the screen output.  Can you try a normal boot, and try:


when it drops back to OF.
Comment 16 Andrew Cagney 2006-03-01 13:11:05 EST
No luck, while:
   0 > dev /chosen
   0 > .properties
now works
   0 > .registers
   state not valid
   0 >

I'll utter those fateful words: what version of firmware appears to work?
Comment 17 Paul Nasrat 2006-03-01 15:04:12 EST
I'm using the same firmware on my mac BootROM built on 10/26/04 at
16:30:32 on a PowerMac7,3 (dual G5).

Did you try set-defaults yet?
Comment 18 Andrew Cagney 2006-03-01 15:17:40 EST
set-defaults? yes, but not with the latest boot cd, will try
Comment 19 Andrew Cagney 2006-03-02 13:42:30 EST
same firmware

after set-defaults reset-all the boot shows the original:
    Invalid memory access at ...
Comment 20 Paul Nasrat 2006-03-03 10:28:05 EST
I'm wondering if this is possibly the root cause:

Comment 22 Paul Nasrat 2006-03-03 11:41:50 EST
Dave can you look at the kernel patch in the gcc bugzilla and consider for FC 5

Reassigning to gcc, I'm pretty sure this is the root cause.
Comment 23 Jakub Jelinek 2006-03-05 09:11:16 EST
If you read the PR, you'll find this is not a GCC bug.  If you call the function
with %r1 not 16 byte aligned, that's a kernel's (or OF's) fault.  And if it is
16 byte aligned, then there is not a problem - rlwinm 3,3,0,0,27
sets %r3 = (%r3 & 0xfffffff0) and as GCC assumes that &a; is 16 byte aligned
(%r1 is and if GCC places it on an offset which multiple of 16 from %r1),
(unsigned) &a is equal to ((long) &a & 0xfffffff0).
Comment 24 David Woodhouse 2006-03-05 10:42:25 EST
We currently think it's yaboot's fault. Linus has made the kernel work around it
by ensuring the stack pointer is aligned at start-up:
Comment 25 Dave Jones 2006-03-05 13:36:23 EST
Linus' fix was merged in kernel-2.6.15-1.2016_FC5

Note You need to log in before you can comment on or make changes to this bug.