Re: [PATCH, RESEND] Add MWI workaround for Tulip DC21143

Re: [PATCH, RESEND] Add MWI workaround for Tulip DC21143

[Martin Michlmayr]

* Peter Horton <pdh@colonel-panic.org> [2006-02-18 22:08]:
> This patch works around the MWI bug on the DC21143 rev 65 Tulip by
> ensuring that the receive buffers don't end on a cache line boundary (as
> documented in the errata).
> 
> This patch is required for the MIPs based Cobalt Qube/RaQ as supporting
> the extra PCI commands seems to reduce the chance of a hard lockup
> between the Tulip and the PCI bridge.

Does anyone have comments regarding this patch?  I received
confirmation from a number of Debian users that this patch
significantly improves the lockup situation on Cobalt, so
it would be nice if it could go in.
-- 
Martin Michlmayr
tbm@cyrius.com

Re: [PATCH, RESEND] Add MWI workaround for Tulip DC21143

[Francois Romieu]

Martin Michlmayr <tbm@cyrius.com> :
[...]
> Does anyone have comments regarding this patch?  I received
> confirmation from a number of Debian users that this patch
> significantly improves the lockup situation on Cobalt, so
> it would be nice if it could go in.

I'll queue it with the pending de2104x fix(es ?) during my next
upkeep.

-- 
Ueimor

Re: [PATCH, RESEND] Add MWI workaround for Tulip DC21143

[Ralf Baechle]

On Tue, Mar 07, 2006 at 12:15:30AM +0100, Francois Romieu wrote:

> [...]
> > Does anyone have comments regarding this patch?  I received
> > confirmation from a number of Debian users that this patch
> > significantly improves the lockup situation on Cobalt, so
> > it would be nice if it could go in.
> 
> I'll queue it with the pending de2104x fix(es ?) during my next
> upkeep.

I'm just not convinced of having such a workaround as a build option.
The average person building a a kernel will probably not know if the
option needs to be enabled or not.

  Ralf

Re: [PATCH, RESEND] Add MWI workaround for Tulip DC21143

[Geert Uytterhoeven]

On Tue, 7 Mar 2006, Ralf Baechle wrote:
> On Tue, Mar 07, 2006 at 12:15:30AM +0100, Francois Romieu wrote:
> 
> > [...]
> > > Does anyone have comments regarding this patch?  I received
> > > confirmation from a number of Debian users that this patch
> > > significantly improves the lockup situation on Cobalt, so
> > > it would be nice if it could go in.
> > 
> > I'll queue it with the pending de2104x fix(es ?) during my next
> > upkeep.
> 
> I'm just not convinced of having such a workaround as a build option.
> The average person building a a kernel will probably not know if the
> option needs to be enabled or not.

Indeed, if it's mentioned in the errata of the chip, the driver should take
care of it.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [PATCH, RESEND] Add MWI workaround for Tulip DC21143

[Francois Romieu]

Geert Uytterhoeven <geert@linux-m68k.org> :
> On Tue, 7 Mar 2006, Ralf Baechle wrote:
[...]
> > I'm just not convinced of having such a workaround as a build option.
> > The average person building a a kernel will probably not know if the
> > option needs to be enabled or not.
> 
> Indeed, if it's mentioned in the errata of the chip, the driver should take
> care of it.

Something like the patch below (+Mr Horton Signed-off-by: and description):

diff --git a/drivers/net/tulip/tulip.h b/drivers/net/tulip/tulip.h
index 05d2d96..d109540 100644
--- a/drivers/net/tulip/tulip.h
+++ b/drivers/net/tulip/tulip.h
@@ -262,7 +262,14 @@ enum t21143_csr6_bits {
 #define RX_RING_SIZE	128 
 #define MEDIA_MASK     31
 
+/* MWI can fail on 21143 rev 65 if the receive buffer ends
+   on a cache line boundary. Ensure it doesn't ... */
+
+#ifdef CONFIG_MIPS_COBALT
+#define PKT_BUF_SZ		(1536 + 4)
+#else
 #define PKT_BUF_SZ		1536	/* Size of each temporary Rx buffer. */
+#endif
 
 #define TULIP_MIN_CACHE_LINE	8	/* in units of 32-bit words */
 
diff --git a/drivers/net/tulip/tulip_core.c b/drivers/net/tulip/tulip_core.c
index c67c912..ca6eeda 100644
--- a/drivers/net/tulip/tulip_core.c
+++ b/drivers/net/tulip/tulip_core.c
@@ -294,6 +294,8 @@ static void tulip_up(struct net_device *
 	if (tp->mii_cnt  ||  (tp->mtable  &&  tp->mtable->has_mii))
 		iowrite32(0x00040000, ioaddr + CSR6);
 
+	printk(KERN_DEBUG "%s: CSR0 %08x\n", dev->name, tp->csr0);
+
 	/* Reset the chip, holding bit 0 set at least 50 PCI cycles. */
 	iowrite32(0x00000001, ioaddr + CSR0);
 	udelay(100);
@@ -1155,8 +1157,10 @@ static void __devinit tulip_mwi_config (
 	/* if we have any cache line size at all, we can do MRM */
 	csr0 |= MRM;
 
+#ifndef CONFIG_MIPS_COBALT
 	/* ...and barring hardware bugs, MWI */
 	if (!(tp->chip_id == DC21143 && tp->revision == 65))
+#endif
 		csr0 |= MWI;
 
 	/* set or disable MWI in the standard PCI command bit.
@@ -1182,7 +1186,7 @@ static void __devinit tulip_mwi_config (
 	 */
 	switch (cache) {
 	case 8:
-		csr0 |= MRL | (1 << CALShift) | (16 << BurstLenShift);
+		csr0 |= MRL | (1 << CALShift) | (8 << BurstLenShift);
 		break;
 	case 16:
 		csr0 |= MRL | (2 << CALShift) | (16 << BurstLenShift);

Re: [PATCH, RESEND] Add MWI workaround for Tulip DC21143

[Geert Uytterhoeven]

On Wed, 8 Mar 2006, Francois Romieu wrote:
> Geert Uytterhoeven <geert@linux-m68k.org> :
> > On Tue, 7 Mar 2006, Ralf Baechle wrote:
> [...]
> > > I'm just not convinced of having such a workaround as a build option.
> > > The average person building a a kernel will probably not know if the
> > > option needs to be enabled or not.
> > 
> > Indeed, if it's mentioned in the errata of the chip, the driver should take
> > care of it.
> 
> Something like the patch below (+Mr Horton Signed-off-by: and description):
> 
> diff --git a/drivers/net/tulip/tulip.h b/drivers/net/tulip/tulip.h
> index 05d2d96..d109540 100644
> --- a/drivers/net/tulip/tulip.h
> +++ b/drivers/net/tulip/tulip.h
> @@ -262,7 +262,14 @@ enum t21143_csr6_bits {
>  #define RX_RING_SIZE	128 
>  #define MEDIA_MASK     31
>  
> +/* MWI can fail on 21143 rev 65 if the receive buffer ends
> +   on a cache line boundary. Ensure it doesn't ... */
> +
> +#ifdef CONFIG_MIPS_COBALT
> +#define PKT_BUF_SZ		(1536 + 4)
> +#else
>  #define PKT_BUF_SZ		1536	/* Size of each temporary Rx buffer. */
> +#endif
>  
>  #define TULIP_MIN_CACHE_LINE	8	/* in units of 32-bit words */
>  
> diff --git a/drivers/net/tulip/tulip_core.c b/drivers/net/tulip/tulip_core.c
> index c67c912..ca6eeda 100644
> --- a/drivers/net/tulip/tulip_core.c
> +++ b/drivers/net/tulip/tulip_core.c
> @@ -294,6 +294,8 @@ static void tulip_up(struct net_device *
>  	if (tp->mii_cnt  ||  (tp->mtable  &&  tp->mtable->has_mii))
>  		iowrite32(0x00040000, ioaddr + CSR6);
>  
> +	printk(KERN_DEBUG "%s: CSR0 %08x\n", dev->name, tp->csr0);
> +
>  	/* Reset the chip, holding bit 0 set at least 50 PCI cycles. */
>  	iowrite32(0x00000001, ioaddr + CSR0);
>  	udelay(100);
> @@ -1155,8 +1157,10 @@ static void __devinit tulip_mwi_config (
>  	/* if we have any cache line size at all, we can do MRM */
>  	csr0 |= MRM;
>  
> +#ifndef CONFIG_MIPS_COBALT
>  	/* ...and barring hardware bugs, MWI */
>  	if (!(tp->chip_id == DC21143 && tp->revision == 65))
> +#endif
>  		csr0 |= MWI;

So when compiling for Cobalt, we work around the hardware bug, while for other
platforms, we just disable MWI?

Wouldn't it be possible to always (I mean, when a rev 65 chip is detected) work
around the bug?

>  	/* set or disable MWI in the standard PCI command bit.
> @@ -1182,7 +1186,7 @@ static void __devinit tulip_mwi_config (
>  	 */
>  	switch (cache) {
>  	case 8:
> -		csr0 |= MRL | (1 << CALShift) | (16 << BurstLenShift);
> +		csr0 |= MRL | (1 << CALShift) | (8 << BurstLenShift);
>  		break;
>  	case 16:
>  		csr0 |= MRL | (2 << CALShift) | (16 << BurstLenShift);

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [PATCH, RESEND] Add MWI workaround for Tulip DC21143

[Francois Romieu]

Geert Uytterhoeven <geert@linux-m68k.org> :
[...]
> So when compiling for Cobalt, we work around the hardware bug, while for other
> platforms, we just disable MWI?
> 
> Wouldn't it be possible to always (I mean, when a rev 65 chip is detected)
> work around the bug?

Of course it is possible but it is not the same semantic as the initial
patch (not that I know if it is right or not).

So:
- does the issue exist beyond Cobalt hosts ?
- is the fix Cobalt-only ?

-- 
Ueimor

Re: [PATCH, RESEND] Add MWI workaround for Tulip DC21143

[Martin Michlmayr]

* Francois Romieu <romieu@fr.zoreil.com> [2006-03-09 23:44]:
> > So when compiling for Cobalt, we work around the hardware bug, while for other
> > platforms, we just disable MWI?
> > 
> > Wouldn't it be possible to always (I mean, when a rev 65 chip is detected)
> > work around the bug?
> 
> Of course it is possible but it is not the same semantic as the initial
> patch (not that I know if it is right or not).
> 
> So:
> - does the issue exist beyond Cobalt hosts ?
> - is the fix Cobalt-only ?

I don't think anyone has replied to this message yet.  My
understanding is that it's not Cobalt only but a problem in a specific
revision of the chip, which the Cobalt happens to use.  However, I'd
be glad if somone else could comment.  Peter, you read the errata
right?
-- 
Martin Michlmayr
http://www.cyrius.com/

Re: [PATCH, RESEND] Add MWI workaround for Tulip DC21143

[Peter Horton]

Martin Michlmayr wrote:
> * Francois Romieu <romieu@fr.zoreil.com> [2006-03-09 23:44]:
>   
>>> So when compiling for Cobalt, we work around the hardware bug, while for other
>>> platforms, we just disable MWI?
>>>
>>> Wouldn't it be possible to always (I mean, when a rev 65 chip is detected)
>>> work around the bug?
>>>       
>> Of course it is possible but it is not the same semantic as the initial
>> patch (not that I know if it is right or not).
>>
>> So:
>> - does the issue exist beyond Cobalt hosts ?
>> - is the fix Cobalt-only ?
>>     
>
> I don't think anyone has replied to this message yet.  My
> understanding is that it's not Cobalt only but a problem in a specific
> revision of the chip, which the Cobalt happens to use.  However, I'd
> be glad if somone else could comment.  Peter, you read the errata
> right?
>   

According to the errata it applies to all DEC 21143-PD and 21143-TD 
which are the chips with the revision code 0x41 (65). The errata states 
the receive buffers should not end on a cache aligned boundary when 
using MWI otherwise the receiver will not close the last descriptor.

P.