2.6.12-rc5-git8 regression on PPC64

-git7 seems to boot fine, but -git8 is broken. See here:

http://ftp.kernel.org/pub/linux/kernel/people/mbligh/abat/4547/debug/console.log

for full boot log, but basically it does this:

DEFAULT CATCH!, handler-entered=fff00300
Open Firmware exception handler entered from non-OF code

Client's Fix Pt Regs:
00 0000000000000003 000000000291f800 00000000040acb88 0000000000000010 04 0000000024004042 0000000000000000 0000000000000000 0000000000000000 08 0000000000000000 000000077f800000 0000000000100000 0000000000000001 0c 2000000000000000 0000000000000000 0000000000000000 0000000000000000 10 0000000000000000 0000000000000000 0000000000000000 0000000000000000 14 0000000000230000 0000000780000000 0000000003a10000 0000000003ef2300 18 000000000291fa24 bffffffffc5f0000 000000077f800000 0000000003ef2478 1c bffffffffc5f0000 000000000291fa30 000000000291fab0 000000000291faf4
Special Regs:

    %IV: 00000300     %CR: 84004044    %XER: 00000000  %DSISR: 0a000000 
  %SRR0: 0000000003ec6644   %SRR1: 8000000000003000 
    %LR: 0000000003ec661c    %CTR: 0000000000000000 

%DAR: 000000077f800000
PID = 0

ofdbg

Which doesn't give me anything useful, but perhaps it does for you ;-)

M.

I'm seeing something possibly related as well -- with an up-to-date git tree (HEAD == d8d088d25822b0199fdfb392085e1cf8a5914a97), I get a hang early in the boot on an OpenPower 710 (2 x POWER5). It seems to get just a little further:

Please wait, loading kernel...
Elf64 kernel loaded...
Loading ramdisk...
ramdisk loaded at 02300000, size: 949 Kbytes
OF stdout device is: /vdevice/vty@30000000
command line: ro console=hvsi0 root=/dev/sdd5
memory layout at init:
memory_limit : 0000000000000000 (16 MB aligned) alloc_bottom : 00000000023ee000
alloc_top : 0000000040000000
alloc_top_hi : 00000001e8000000
rmo_top : 0000000040000000
ram_top : 00000001e8000000
Looking for displays
found display : /pci@800000020000003/pci@2,2/pci@1/display@0, opening ... done
instantiating rtas at 0x00000000077ca000 ... done
0000000000000000 : boot cpu 0000000000000000
0000000000000002 : starting cpu hw idx 0000000000000002... done copying OF device tree ...
Building dt strings...
Building dt structure...
Device tree strings 0x00000000027ef000 -> 0x00000000027f02f8 Device tree struct 0x00000000027f1000 -> 0x0000000002809000

and that's the last thing I see.

- R.

Backing this one out fixes it here on a Power5 570.

http://marc.theaimsgroup.com/?l=bk-commits-head&m=111772917211270&q=raw

Ben, any ideas?

Nathan

Nathan> Backing this one out fixes it here on a Power5 570.

Nathan> http://marc.theaimsgroup.com/?l=bk-commits-head&m=111772917211270&q=raw

This fixes the boot on an OpenPower 710 for me as well.

Thanks,
Roland

Typo in prom_find_machine_type from Ben's recent patch "ppc64: Fix result code handling in prom_init" prevents pSeries LPAR systems from booting.

Tested on a pSeries 570 and OpenPower 720 (both Power5 LPAR).

 arch/ppc64/kernel/prom_init.c |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.12-rc5-git8/arch/ppc64/kernel/prom_init.c
===================================================================
@@ -1370,7 +1370,7 @@ static int __init prom_find_machine_type
 	}
 	/* Default to pSeries. We need to know if we are running LPAR */
 	rtas = call_prom("finddevice", 1, 1, ADDR("/rtas"));
-	if (!PHANDLE_VALID(rtas)) {
+	if (PHANDLE_VALID(rtas)) {
 		int x = prom_getproplen(rtas, "ibm,hypertas-functions");
 		if (x != PROM_ERROR) {
 			prom_printf("Hypertas detected, assuming LPAR !\n");

Damn ! I'm certain I tested it on P5 ! I must have forgotten to "quilt ref" before sending the patch (as I did notice this typo and fixed it just before sending).

Sorry!

Ben.

Hello,
Same typo has creped in again from 2.6.17 kernel onwards and causing open firmware exception in pSeries systems.
=====================================================================================

Welcome to yaboot version 10.1.21-r910.SuSE
booted from '/vdevice/v-scsi@30000003/disk@8100000000000000' Enter "help" to get some basic usage information
boot: 2.6.23.1
Please wait, loading kernel...
Allocated 03500000 bytes for kernel @ 01c00000
Elf64 kernel loaded...
Loading ramdisk...
ramdisk loaded 0020d000 @ 06b00000
DEFAULT CATCH!, exception-handler=fff00300 at %SRR0: c00000000202705c %SRR1: 8000000000003002 Open Firmware exception handler entered from non-OF code

Client's Fix Pt Regs:
00 0223100003080000 00000000018bfac0 0000000004bbeaf8 00000000018bfb48 04 00000000018bfc90 0000000000c39a48 0000000000000000 5c3a03080000a0fa 08 0000000000000001 0000000000000000 05910000194c0223 000000005cae0000 0c 0000000003f1eaf8 0000000000000000 0000000000000000 0000000000000000 10 0000000000000000 0000000000c39a48 0000000000000000 00000000018bfc90 14 0000000000c00000 000000000020d000 0000000000000000 0000000008b00000 18 0000000000280004 00000000018bff04 0000000000000001 0000000000000000 1c 0000000008b00000 0000000000c39a48 c000000004d1e530 0000000008b00000 Special Regs:
%IV: 00000300 %CR: 44000028 %XER: 00000000 %DSISR: 08000000
%SRR0: c00000000202705c %SRR1: 8000000000003002
%LR: c000000002027428 %CTR: c0000000020273f0
%DAR: 05910000194c02eb
Virtual PID = 0 PFW: Unable to send error log!
ofdbg
0 >

===========================================================================================
The patch that is provided solves the problem.

Regards,
Poornima.

Hi-

Looking at the current code, I don't see how this analysis could be correct.

Which patch? Did you forget to include it?

It would be best if you sent your problem report and any patches to [email protected]. linuxppc64-dev is dead.

Thanks.

You are right. Sorry for the confusion. I had overlooked the changes
in the code (prom_init.c) Will check if
the problem still persists on the latest version. Thanks!

Can you forward the patch ?

Weird, works fine on our POWER5 here. What is the output ? Especially, what if you enable DEBUG_PROM in there ?

Ben.