* Re: [PATCH, RESEND] Add MWI workaround for Tulip DC21143 [not found] ` <20060218220851.GA1601@colonel-panic.org> @ 2006-03-06 22:51 ` Martin Michlmayr 2006-03-06 23:15 ` Francois Romieu 0 siblings, 1 reply; 9+ messages in thread From: Martin Michlmayr @ 2006-03-06 22:51 UTC (permalink / raw) To: netdev, linux-mips * 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH, RESEND] Add MWI workaround for Tulip DC21143 2006-03-06 22:51 ` [PATCH, RESEND] Add MWI workaround for Tulip DC21143 Martin Michlmayr @ 2006-03-06 23:15 ` Francois Romieu 2006-03-07 3:58 ` Ralf Baechle 0 siblings, 1 reply; 9+ messages in thread From: Francois Romieu @ 2006-03-06 23:15 UTC (permalink / raw) To: Martin Michlmayr; +Cc: netdev, linux-mips 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH, RESEND] Add MWI workaround for Tulip DC21143 2006-03-06 23:15 ` Francois Romieu @ 2006-03-07 3:58 ` Ralf Baechle 2006-03-07 9:32 ` Geert Uytterhoeven 0 siblings, 1 reply; 9+ messages in thread From: Ralf Baechle @ 2006-03-07 3:58 UTC (permalink / raw) To: Francois Romieu; +Cc: Martin Michlmayr, netdev, linux-mips 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH, RESEND] Add MWI workaround for Tulip DC21143 2006-03-07 3:58 ` Ralf Baechle @ 2006-03-07 9:32 ` Geert Uytterhoeven 2006-03-08 22:41 ` Francois Romieu 0 siblings, 1 reply; 9+ messages in thread From: Geert Uytterhoeven @ 2006-03-07 9:32 UTC (permalink / raw) To: Ralf Baechle Cc: Francois Romieu, Martin Michlmayr, netdev, Linux/MIPS Development 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH, RESEND] Add MWI workaround for Tulip DC21143 2006-03-07 9:32 ` Geert Uytterhoeven @ 2006-03-08 22:41 ` Francois Romieu 2006-03-09 9:37 ` Geert Uytterhoeven 0 siblings, 1 reply; 9+ messages in thread From: Francois Romieu @ 2006-03-08 22:41 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Ralf Baechle, Martin Michlmayr, netdev, Linux/MIPS Development, P. Horton 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); ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH, RESEND] Add MWI workaround for Tulip DC21143 2006-03-08 22:41 ` Francois Romieu @ 2006-03-09 9:37 ` Geert Uytterhoeven 2006-03-09 22:44 ` Francois Romieu 0 siblings, 1 reply; 9+ messages in thread From: Geert Uytterhoeven @ 2006-03-09 9:37 UTC (permalink / raw) To: Francois Romieu Cc: Ralf Baechle, Martin Michlmayr, netdev, Linux/MIPS Development, P. Horton 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH, RESEND] Add MWI workaround for Tulip DC21143 2006-03-09 9:37 ` Geert Uytterhoeven @ 2006-03-09 22:44 ` Francois Romieu 2006-03-27 7:01 ` Martin Michlmayr 0 siblings, 1 reply; 9+ messages in thread From: Francois Romieu @ 2006-03-09 22:44 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Ralf Baechle, Martin Michlmayr, netdev, Linux/MIPS Development, P. Horton 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH, RESEND] Add MWI workaround for Tulip DC21143 2006-03-09 22:44 ` Francois Romieu @ 2006-03-27 7:01 ` Martin Michlmayr 2006-03-27 12:39 ` Peter Horton 0 siblings, 1 reply; 9+ messages in thread From: Martin Michlmayr @ 2006-03-27 7:01 UTC (permalink / raw) To: P. Horton Cc: Geert Uytterhoeven, netdev, Linux/MIPS Development, Francois Romieu * 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/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH, RESEND] Add MWI workaround for Tulip DC21143 2006-03-27 7:01 ` Martin Michlmayr @ 2006-03-27 12:39 ` Peter Horton 0 siblings, 0 replies; 9+ messages in thread From: Peter Horton @ 2006-03-27 12:39 UTC (permalink / raw) To: Martin Michlmayr Cc: P. Horton, Geert Uytterhoeven, netdev, Linux/MIPS Development, Francois Romieu 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2006-03-27 12:39 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20060129230816.GD4094@colonel-panic.org>
[not found] ` <20060218220851.GA1601@colonel-panic.org>
2006-03-06 22:51 ` [PATCH, RESEND] Add MWI workaround for Tulip DC21143 Martin Michlmayr
2006-03-06 23:15 ` Francois Romieu
2006-03-07 3:58 ` Ralf Baechle
2006-03-07 9:32 ` Geert Uytterhoeven
2006-03-08 22:41 ` Francois Romieu
2006-03-09 9:37 ` Geert Uytterhoeven
2006-03-09 22:44 ` Francois Romieu
2006-03-27 7:01 ` Martin Michlmayr
2006-03-27 12:39 ` Peter Horton
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).