Patchwork sparc64: Netra AX1105 loses console output while booting

login
register
mail settings
Submitter Adrien Mazarguil
Date Nov. 7, 2010, 1:20 p.m.
Message ID <20101107132051.GE19881@here>
Download mbox | patch
Permalink /patch/70346/
State RFC
Delegated to: David Miller
Headers show

Comments

Adrien Mazarguil - Nov. 7, 2010, 1:20 p.m.
Hi list,

While trying recent kernels on a Sun Netra AX1105 board, I noticed that the
boot process stopped before init had a chance to run. Using git bisect, I
narrowed this regression down to that commit:

25edd6946a1d74e5e77813c2324a0908c68bcf9e is the first bad commit
commit 25edd6946a1d74e5e77813c2324a0908c68bcf9e
Author: David S. Miller <davem@davemloft.net>
Date:   Mon Aug 23 23:10:57 2010 -0700

    sparc64: Get rid of indirect p1275 PROM call buffer.

I already sent this information to David but since did additional testing.

On this board, the new prom_nbputchar() fails at some point in the boot
process and no subsequent output is shown. Using either the older function
in place of this one or a static buffer solve that issue. This seems related
to this paragraph in the above commit log:

    The reasoning behind the temporary buffer is entirely historical.  It
    used to be the case that we had problems referencing dynamic kernel
    memory (including the stack) early in the boot process before we
    explicitly told the firwmare to switch us over to the kernel trap
    table.

Looks like it is still required by older boards, or maybe something else
needs to be fixed? This is strange because everything works fine until the
first call to schedule() just before the last assembly part of switch_to()
macro.
David Miller - Nov. 16, 2010, 8:01 p.m.
From: Adrien Mazarguil <maz@p0d.org>
Date: Sun, 7 Nov 2010 14:20:51 +0100

> While trying recent kernels on a Sun Netra AX1105 board, I noticed that the
> boot process stopped before init had a chance to run. Using git bisect, I
> narrowed this regression down to that commit:
 ...
> On this board, the new prom_nbputchar() fails at some point in the boot
> process and no subsequent output is shown. Using either the older function
> in place of this one or a static buffer solve that issue. This seems related
> to this paragraph in the above commit log:
...
> Looks like it is still required by older boards, or maybe something else
> needs to be fixed? This is strange because everything works fine until the
> first call to schedule() just before the last assembly part of switch_to()
> macro.

Thanks for tracking down this problem.

The real issue is that on older boards, passing larger than 32-bit
addresses to prom calls (generally) doesn't work correctly.

That's why using a static variable instead of a kernel stack variable
fixes the problem.

This is a larger can of worms than just these two console I/O
routines, let me do the audit and I'll give you a patch to test.

Thanks!
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Miller - Dec. 3, 2010, 6:18 p.m.
From: David Miller <davem@davemloft.net>
Date: Tue, 16 Nov 2010 12:01:01 -0800 (PST)

> This is a larger can of worms than just these two console I/O
> routines, let me do the audit and I'll give you a patch to test.

Sorry for taking so long.

I have a set of patches which fix this problem, I'll post
them with you CC:'d so you can test them out.

Thanks!
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Adrien Mazarguil - Dec. 4, 2010, 9:34 a.m.
On Fri, Dec 03, 2010 at 10:18:08AM -0800, David Miller wrote:
> > This is a larger can of worms than just these two console I/O
> > routines, let me do the audit and I'll give you a patch to test.
> 
> Sorry for taking so long.
> 
> I have a set of patches which fix this problem, I'll post
> them with you CC:'d so you can test them out.

Thanks! I applied them to the current kernel head, compiled for sparc64 and
tested on my board (Netra AX1105). Works perfectly.
David Miller - Dec. 4, 2010, 7:53 p.m.
From: Adrien Mazarguil <maz@p0d.org>
Date: Sat, 4 Dec 2010 10:34:54 +0100

> On Fri, Dec 03, 2010 at 10:18:08AM -0800, David Miller wrote:
>> > This is a larger can of worms than just these two console I/O
>> > routines, let me do the audit and I'll give you a patch to test.
>> 
>> Sorry for taking so long.
>> 
>> I have a set of patches which fix this problem, I'll post
>> them with you CC:'d so you can test them out.
> 
> Thanks! I applied them to the current kernel head, compiled for sparc64 and
> tested on my board (Netra AX1105). Works perfectly.

Thanks for your report, patience, and testing.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/arch/sparc/prom/console_64.c b/arch/sparc/prom/console_64.c
index 10322dc..fe2a7c0 100644
--- a/arch/sparc/prom/console_64.c
+++ b/arch/sparc/prom/console_64.c
@@ -22,7 +22,7 @@  inline int
 prom_nbgetchar(void)
 {
	unsigned long args[7];
-	char inc;
+	static char inc;
 
	args[0] = (unsigned long) "read";
 	args[1] = 3;
@@ -46,8 +46,8 @@  inline int
 prom_nbputchar(char c)
 {
	unsigned long args[7];
-	char outc;
-	
+	static char outc;
+
	outc = c;
 
	args[0] = (unsigned long) "write";
@@ -62,8 +62,7 @@  prom_nbputchar(char c)
 
	if (args[6] == 1)
 	   return 0;
-	   else
-		return -1;
+		return -1;
 }
 
 /* Blocking version of get character routine above. */