Bug 182180
| Summary: | Invalid memory access at %SSR0: .... | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Andrew Cagney <cagney> |
| Component: | kernel | Assignee: | Dave Jones <davej> |
| Status: | CLOSED RAWHIDE | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5 | CC: | clumens, dhu, dwmw2, kapointer, nobody+pnasrat, pfrields, wtogami |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | powerpc | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-03-05 18:36:23 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Andrew Cagney
2006-02-20 21:42:09 UTC
Can you type .registers after this. Also what is load-base set at? printenv load-base You might want to try setting the OF defaults and restarting: set-defaults reset-all 0 > .registers state not valid ok 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) The machine can boot an FC-5 Test 1 CD. 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
.properties
(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.
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? 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 .properties and let me know what linux,stdout-package and linux,stdout-path are. 0 > dev /chosen Invlid memory access ..... 0 > .properties Invalid memory .... Hmm ok, that could be something different to the bug I'm seeing, can you try tomorrows rawhide tree and see how that goes. I tried the 2006-02-22 rescue cd; same barf :-( can a ppc boot from one of these images copied to usb memory stick? 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,10.0.0.1" io 3) on another box telnet 10.0.0.1 you should get an OF prompt 4) boot cd:,\\:tbxi - use the boot.iso from the tree http://download.fedora.redhat.com/pub/fedora/linux/core/development/ppc/images/ 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. This was with the rescue CD; I'll have to download the boot cd. $ telnet tooma Trying ...... Connected to tooma. Escape character is '^]'. ok 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: ok 0 > 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) *** Bug 182518 has been marked as a duplicate of this bug. *** Yeah the OF chrp script sets the screen output. Can you try a normal boot, and try: .registers when it drops back to OF. No luck, while:
0 > dev /chosen
0 > .properties
...
now works
0 > .registers
state not valid
ok
0 >
doesn't.
I'll utter those fateful words: what version of firmware appears to work?
I'm using the same firmware on my mac 3.5.1.8f7 BootROM built on 10/26/04 at 16:30:32 on a PowerMac7,3 (dual G5). Did you try set-defaults yet? set-defaults? yes, but not with the latest boot cd, will try same firmware
after set-defaults reset-all the boot shows the original:
Invalid memory access at ...
I'm wondering if this is possibly the root cause: http://ozlabs.org/pipermail/linuxppc-dev/2006-March/021353.html Dave can you look at the kernel patch in the gcc bugzilla and consider for FC 5 final. Reassigning to gcc, I'm pretty sure this is the root cause. 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). 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: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c05b47704570b015134522c36142cd17bd48640a Linus' fix was merged in kernel-2.6.15-1.2016_FC5 |