2.6.25 works fine on my Ultra5, but 2.6.26-rc1 hangs
early in boot. I don't have a serial cable to capture
early kernel messages, but extrapolating from 2.6.25 I get:

PROMLIB: Sun IEEE Boot Prom 'OBP 3.25.3 2000/06/29 14:12'
PROMLIB: Root node compatible: 
Linux version 2.6.25 (mikpe@sparge) (gcc version 4.2.3) #1 Thu Apr 17 19:53:16 CEST 2008
console [earlyprom0] enabled
ARCH: SUN4U
Ethernet address: 08:00:20:fd:ec:1f
Kernel: Using 1 locked TLB entries for main kernel image.
Remapping the kernel... done.
[0000000200000000-fffff80000400000] page_structs=262144 node=0 entry=0/0
[0000000200000000-fffff80000800000] page_structs=262144 node=0 entry=1/0
[0000000200000000-fffff80000c00000] page_structs=262144 node=0 entry=2/0
[0000000200000000-fffff80001000000] page_structs=262144 node=0 entry=3/0
OF stdout device is: /pci@1f,0/pci@1,1/SUNW,m64B@2
PROM: Built device tree with 46848 bytes of memory.
On node 0 totalpages: 32298
  Normal zone: 335 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 31963 pages, LIFO batch:7
  Movable zone: 0 pages used for memmap
Booting Linux...
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 31963
Kernel command line: ro root=/dev/sda5
PID hash table entries: 1024 (order: 10, 8192 bytes)
clocksource: mult[28000] shift[16]
clockevent: mult[66666666] shift[32]
Console: colour dummy device 80x25
console handover: boot [earlyprom0] -> real [tty0]

*** 2.6.26-rc1 gets as far as the line above, then hangs

Dentry cache hash table entries: 32768 (order: 5, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 4, 131072 bytes)
Memory: 237256k available (1928k kernel code, 744k data, 144k init) [fffff80000000000,0000000017f46000]
SLUB: Genslabs=13, HWalign=32, Order=0-2, MinObjects=8, CPUs=1, Nodes=1
Calibrating delay using timer specific routine.. 800.81 BogoMIPS (lpj=4004065)
...

Full config is available in <http://user.it.uu.se/~mikpe/linux/sparge/>.

If anyone has patches to try I can try them t...
[ message continues ]

From: Mikael Pettersson <mikpe@it.uu.se>

It's possible your machine does boot up all the way.
The video driver simply isn't registerring for whatever
reason.

Can you ping the box if you wait a minute or two after the
messages stop?

The only patch to the aty driver since 2.6.25 is the
following, below, which you can try reverting.

Another thing you can do is edit arch/sparc64/kernel/setup.c
and in the prom_early_console struct initializer, remove the
"CON_BOOT" bit from the .flags setting.  That will keep the
PROM console enabled even when another console wants to
register.  We'll get more messages that way.

commit 21b4d1db84a70175251d86078123cc27e46ff69d
Author: Roel Kluin <12o3l@tiscali.nl>
Date:   Mon Apr 28 02:15:04 2008 -0700

    video/aty/atyfb_base.c: free when fb can't be registered
    
    Free buffer when the framebuffer can't be registered
    
    Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
    Cc: "Antonino A. Daplas" <adaplas@pol.net>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

diff --git a/drivers/video/aty/atyfb_base.c b/drivers/video/aty/atyfb_base.c
index 62f9c6e..e4bcf53 100644
--- a/drivers/video/aty/atyfb_base.c
+++ b/drivers/video/aty/atyfb_base.c
@@ -2621,10 +2621,13 @@ static int __devinit aty_init(struct fb_info *info)
 #endif /* CONFIG_FB_ATY_CT */
 	info->var = var;
 
-	fb_alloc_cmap(&info->cmap, 256, 0);
+	if (fb_alloc_cmap(&info->cmap, 256, 0) < 0)
+		goto aty_init_exit;
 
-	if (register_framebuffer(info) < 0)
+	if (register_framebuffer(info) < 0) {
+		fb_dealloc_cmap(&info->cmap);
 		goto aty_init_exit;
+	}
 
 	fb_list = info;
 
--

David Miller writes:
 > From: Mikael Pettersson <mikpe@it.uu.se>
 > Date: Tue, 6 May 2008 09:54:05 +0200
 > 
 > > OF stdout device is: /pci@1f,0/pci@1,1/SUNW,m64B@2
 > > PROM: Built device tree with 46848 bytes of memory.
 > > On node 0 totalpages: 32298
 > >   Normal zone: 335 pages used for memmap
 > >   Normal zone: 0 pages reserved
 > >   Normal zone: 31963 pages, LIFO batch:7
 > >   Movable zone: 0 pages used for memmap
 > > Booting Linux...
 > > Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 31963
 > > Kernel command line: ro root=/dev/sda5
 > > PID hash table entries: 1024 (order: 10, 8192 bytes)
 > > clocksource: mult[28000] shift[16]
 > > clockevent: mult[66666666] shift[32]
 > > Console: colour dummy device 80x25
 > > console handover: boot [earlyprom0] -> real [tty0]
 > > 
 > > *** 2.6.26-rc1 gets as far as the line above, then hangs
 > 
 > It's possible your machine does boot up all the way.
 > The video driver simply isn't registerring for whatever
 > reason.
 > 
 > Can you ping the box if you wait a minute or two after the
 > messages stop?

No joy, it's dead.

 > The only patch to the aty driver since 2.6.25 is the
 > following, below, which you can try reverting.
 > 
 > Another thing you can do is edit arch/sparc64/kernel/setup.c
 > and in the prom_early_console struct initializer, remove the
 > "CON_BOOT" bit from the .flags setting.  That will keep the
 > PROM console enabled even when another console wants to
 > register.  We'll get more messages that way.

I removed "| CON_BOOT" and got what looks like the same oops
Raúl Porcel reported earlier today (which he for some reason
sent only to the lists, not to you or me); his oops was:

[    0.760209] NET: Registered protocol family 1
[    0.808403] Unpacking initramfs...<1>Unable to handle kernel paging 
reques...
[ message continues ]

From: Mikael Pettersson <mikpe@it.uu.se>

I can reproduce this problem here in my t1000.

It looks like some kind of initrd regression.

Looking at the crashes, the kernel seems to be trying
to dereference a physical address when peeking at the
initrd instead of using a virtual one.  That's a big
clue.

This patch should fix it:

commit d45100f7b69e3d9cd0cd5e956b6ac2c78d460d07
Author: David S. Miller <davem@davemloft.net>
Date:   Tue May 6 15:19:54 2008 -0700

    sparc64: Fix initrd regression.
    
    We die because we forget to convert initrd_start and
    initrd_end to virtual addresses.
    
    Reported by Mikael Pettersson
    
    Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/arch/sparc64/mm/init.c b/arch/sparc64/mm/init.c
index db8e7fb..ec3e2c7 100644
--- a/arch/sparc64/mm/init.c
+++ b/arch/sparc64/mm/init.c
@@ -771,6 +771,9 @@ static void __init find_ramdisk(unsigned long phys_base)
 		initrd_end = ramdisk_image + sparc_ramdisk_size;
 
 		lmb_reserve(initrd_start, initrd_end);
+
+		initrd_start += PAGE_OFFSET;
+		initrd_end += PAGE_OFFSET;
 	}
 #endif
 }

--

That fixed it for me as well, thanks!
--

David Miller writes:
 > From: Mikael Pettersson <mikpe@it.uu.se>
 > Date: Tue, 6 May 2008 21:38:24 +0200
 > 
 > > I removed "| CON_BOOT" and got what looks like the same oops
 > > Raúl Porcel reported earlier today (which he for some reason
 > > sent only to the lists, not to you or me); his oops was:
 > 
 > I can reproduce this problem here in my t1000.
 > 
 > It looks like some kind of initrd regression.
 > 
 > Looking at the crashes, the kernel seems to be trying
 > to dereference a physical address when peeking at the
 > initrd instead of using a virtual one.  That's a big
 > clue.
 > 
 > This patch should fix it:
 > 
 > commit d45100f7b69e3d9cd0cd5e956b6ac2c78d460d07
 > Author: David S. Miller <davem@davemloft.net>
 > Date:   Tue May 6 15:19:54 2008 -0700
 > 
 >     sparc64: Fix initrd regression.
 >     
 >     We die because we forget to convert initrd_start and
 >     initrd_end to virtual addresses.
 >     
 >     Reported by Mikael Pettersson
 >     
 >     Signed-off-by: David S. Miller <davem@davemloft.net>
 > 
 > diff --git a/arch/sparc64/mm/init.c b/arch/sparc64/mm/init.c
 > index db8e7fb..ec3e2c7 100644
 > --- a/arch/sparc64/mm/init.c
 > +++ b/arch/sparc64/mm/init.c
 > @@ -771,6 +771,9 @@ static void __init find_ramdisk(unsigned long phys_base)
 >  		initrd_end = ramdisk_image + sparc_ramdisk_size;
 >  
 >  		lmb_reserve(initrd_start, initrd_end);
 > +
 > +		initrd_start += PAGE_OFFSET;
 > +		initrd_end += PAGE_OFFSET;
 >  	}
 >  #endif
 >  }

This solved my boot problem. Thanks.

Tested-by: Mikael Pettersson <mikpe@it.uu.se>
--

I've got the same issue on a Sun Blade 1000, doing the CON_BOOT thing 
this is what i get, obviously it just hangs and i can't return to OBP.

Allocated 8 Megs of memory at 0x40000000 for kernel
Loaded kernel version 2.6.26
Loading initial ramdisk (755279 bytes at 0x3F800000 phys, 0x40C00000 
virt)...
|
[    0.000000] PROMLIB: Sun IEEE Boot Prom 'OBP 4.16.4 2004/12/18 05:18'
[    0.000000] PROMLIB: Root node compatible:
[    0.000000] Linux version 2.6.26-rc1-git3 (root@monchisun) (gcc 
version 4.1.2 (Gentoo 4.1.2 p1.08
[    0.000000] console [earlyprom0] enabled
[    0.000000] ARCH: SUN4U
[    0.000000] Kernel: Using 2 locked TLB entries for main kernel image.
[    0.000000] Remapping the kernel... done.
[    0.000000] OF stdout device is: /pci@8,700000/ebus@5/serial@1,400000:a
[    0.000000] PROM: Built device tree with 64227 bytes of memory.
[    0.000000] Top of RAM: 0x3ff0e000, Total RAM: 0x3fee0000
[    0.000000] Memory hole size: 0MB
[    0.000000] [0000000200000000-fffff80000400000] page_structs=131072 
node=0 entry=0/0
[    0.000000] [0000000200000000-fffff80000800000] page_structs=131072 
node=0 entry=1/0
[    0.000000] Zone PFN ranges:
[    0.000000]   Normal          0 ->   130951
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[5] active PFN ranges
[    0.000000]     0:        0 ->   129023
[    0.000000]     0:   129024 ->   130914
[    0.000000]     0:   130916 ->   130928
[    0.000000]     0:   130944 ->   130946
[    0.000000]     0:   130950 ->   130951
[    0.000000] Booting Linux...
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on. 
Total pages: 130033
[    0.000000] Kernel command line: root=/dev/sda4 doscsi 
rdinit=/linuxrc real_root=/dev/sda4
[    0.000000] PID hash table entries: 4096 (order: 12, 32768 bytes)
[    0.004000] clocksource: mult[c80000] shift[16]
[    0.004000] clockevent: mult[147ae14] shift[32]
[    0.004000] ------------[ cut here ]------------
[    0.004000] ...
[ message continues ]