Another 2.6.18 regression? (SunBlade1000)

Another 2.6.18 regression? (SunBlade1000)

[Jurij Smakov]

This is a report by Roland Stigge (CC'd), who is trying to run 2.6.18 
on his SunBlade1000:

  I also noticed a regression with 2.6.18-1-sparc64, but it looks
  different from #392078. See screenshot at 
  http://people.debian.org/~stigge/sun4u.jpg : To prevent this "Cheetah
  error trap" ... "Irrecoverable deferred error trap", I'm using my old
  2.6.14-2-sparc64 kernel (didn't try sth. inbetween - considered useful?).

Roland later reported that the last working kernel for his box is 
2.6.16, and that the latest SunBlade 100/150 patch did not help with 
his problem in any way.

Best regards,
-- 
Jurij Smakov                                           jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                      KeyID: C99E03CC

Re: Another 2.6.18 regression? (SunBlade1000)

[David Miller]

From: Jurij Smakov <jurij@wooyd.org>
Date: Mon, 23 Oct 2006 20:16:43 -0700

> This is a report by Roland Stigge (CC'd), who is trying to run 2.6.18 
> on his SunBlade1000:
> 
>   I also noticed a regression with 2.6.18-1-sparc64, but it looks
>   different from #392078. See screenshot at 
>   http://people.debian.org/~stigge/sun4u.jpg : To prevent this "Cheetah
>   error trap" ... "Irrecoverable deferred error trap", I'm using my old
>   2.6.14-2-sparc64 kernel (didn't try sth. inbetween - considered useful?).
> 
> Roland later reported that the last working kernel for his box is 
> 2.6.16, and that the latest SunBlade 100/150 patch did not help with 
> his problem in any way.

See if disabling the floppy driver fixes the problem.

Re: Another 2.6.18 regression? (SunBlade1000)

[Roland Stigge]

David Miller wrote:
>> Roland later reported that the last working kernel for his box is 
>> 2.6.16, and that the latest SunBlade 100/150 patch did not help with 
>> his problem in any way.
> 
> See if disabling the floppy driver fixes the problem.

After removing the floppy driver, the result looks a bit different: The
bootup proceeds a bit further, but the error message is similar.

See http://people.debian.org/~stigge/sun4u-nofd.jpg

Roland

Re: Another 2.6.18 regression? (SunBlade1000)

[David Miller]

From: Roland Stigge <stigge@antcom.de>
Date: Fri, 27 Oct 2006 22:20:34 +0200

> David Miller wrote:
> >> Roland later reported that the last working kernel for his box is 
> >> 2.6.16, and that the latest SunBlade 100/150 patch did not help with 
> >> his problem in any way.
> > 
> > See if disabling the floppy driver fixes the problem.
> 
> After removing the floppy driver, the result looks a bit different: The
> bootup proceeds a bit further, but the error message is similar.
> 
> See http://people.debian.org/~stigge/sun4u-nofd.jpg

What does 0x4268e8 match up to in your System.map?

Re: Another 2.6.18 regression? (SunBlade1000)

[Roland Stigge]

David Miller wrote:
>> After removing the floppy driver, the result looks a bit different: The
>> bootup proceeds a bit further, but the error message is similar.
>>
>> See http://people.debian.org/~stigge/sun4u-nofd.jpg
> 
> What does 0x4268e8 match up to in your System.map?

Looks like tomatillo_wsync_handler:

0000000000426818 T of_get_parent
0000000000426830 T of_get_next_child
0000000000426844 T of_find_node_by_phandle
0000000000426874 t sabre_wsync_handler
00000000004268c8 t tomatillo_wsync_handler
0000000000426948 T of_find_property
000000000042698c T of_getintprop_default
00000000004269c4 T of_get_property
00000000004269ec t pci_sun4v_irq_trans_init
0000000000426a3c t schizo_irq_trans_init
0000000000426ad8 t sabre_irq_trans_init
0000000000426b48 t psycho_irq_trans_init

Re: Another 2.6.18 regression? (SunBlade1000)

[David Miller]

From: Roland Stigge <stigge@antcom.de>
Date: Sat, 28 Oct 2006 23:23:41 +0200

> David Miller wrote:
> >> After removing the floppy driver, the result looks a bit different: The
> >> bootup proceeds a bit further, but the error message is similar.
> >>
> >> See http://people.debian.org/~stigge/sun4u-nofd.jpg
> > 
> > What does 0x4268e8 match up to in your System.map?
> 
> Looks like tomatillo_wsync_handler:

That explains the bug clearly.

Please try this patch, thanks a lot!

diff --git a/arch/sparc64/kernel/prom.c b/arch/sparc64/kernel/prom.c
index c60efb3..0917c24 100644
--- a/arch/sparc64/kernel/prom.c
+++ b/arch/sparc64/kernel/prom.c
@@ -793,7 +793,7 @@ static unsigned int schizo_irq_build(str
 	return virt_irq;
 }
 
-static void schizo_irq_trans_init(struct device_node *dp)
+static void __schizo_irq_trans_init(struct device_node *dp, int is_tomatillo)
 {
 	struct linux_prom64_registers *regs;
 	struct schizo_irq_data *irq_data;
@@ -807,11 +807,24 @@ static void schizo_irq_trans_init(struct
 	dp->irq_trans->data = irq_data;
 
 	irq_data->pbm_regs = regs[0].phys_addr;
-	irq_data->sync_reg = regs[3].phys_addr + 0x1a18UL;
+	if (is_tomatillo)
+		irq_data->sync_reg = regs[3].phys_addr + 0x1a18UL;
+	else
+		irq_data->sync_reg = 0UL;
 	irq_data->portid = of_getintprop_default(dp, "portid", 0);
 	irq_data->chip_version = of_getintprop_default(dp, "version#", 0);
 }
 
+static void schizo_irq_trans_init(struct device_node *dp)
+{
+	__schizo_irq_trans_init(dp, 0);
+}
+
+static void tomatillo_irq_trans_init(struct device_node *dp)
+{
+	__schizo_irq_trans_init(dp, 1);
+}
+
 static unsigned int pci_sun4v_irq_build(struct device_node *dp,
 					unsigned int devino,
 					void *_data)
@@ -1050,8 +1063,8 @@ static struct irq_trans pci_irq_trans_ta
 	{ "pci108e,8001", schizo_irq_trans_init },
 	{ "SUNW,schizo+", schizo_irq_trans_init },
 	{ "pci108e,8002", schizo_irq_trans_init },
-	{ "SUNW,tomatillo", schizo_irq_trans_init },
-	{ "pci108e,a801", schizo_irq_trans_init },
+	{ "SUNW,tomatillo", tomatillo_irq_trans_init },
+	{ "pci108e,a801", tomatillo_irq_trans_init },
 	{ "SUNW,sun4v-pci", pci_sun4v_irq_trans_init },
 };
 #endif

Re: Another 2.6.18 regression? (SunBlade1000)

[Roland Stigge]

David Miller wrote:
>>>> After removing the floppy driver, the result looks a bit different: The
>>>> bootup proceeds a bit further, but the error message is similar.
>>>>
>>>> See http://people.debian.org/~stigge/sun4u-nofd.jpg
>>> What does 0x4268e8 match up to in your System.map?
>> Looks like tomatillo_wsync_handler:
> 
> That explains the bug clearly.
> 
> Please try this patch, thanks a lot!
> [...]

Yes, that works! Thanks very much! :-)

Roland