Re: [PATCH, RESEND] Add MWI workaround for Tulip DC21143
* Francois Romieu [EMAIL PROTECTED] [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/ - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RESEND] Add MWI workaround for Tulip DC21143
Martin Michlmayr wrote: * Francois Romieu [EMAIL PROTECTED] [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. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RESEND] Add MWI workaround for Tulip DC21143
On Wed, 8 Mar 2006, Francois Romieu wrote:
Geert Uytterhoeven [EMAIL PROTECTED] :
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-mtabletp-mtable-has_mii))
iowrite32(0x0004, 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(0x0001, 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 -- [EMAIL PROTECTED]
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
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RESEND] Add MWI workaround for Tulip DC21143
Geert Uytterhoeven [EMAIL PROTECTED] : [...] 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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RESEND] Add MWI workaround for Tulip DC21143
Geert Uytterhoeven [EMAIL PROTECTED] :
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-mtabletp-mtable-has_mii))
iowrite32(0x0004, 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(0x0001, 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);
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RESEND] Add MWI workaround for Tulip DC21143
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 -- [EMAIL PROTECTED]
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
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RESEND] Add MWI workaround for Tulip DC21143
* Peter Horton [EMAIL PROTECTED] [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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RESEND] Add MWI workaround for Tulip DC21143
Martin Michlmayr [EMAIL PROTECTED] : [...] 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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RESEND] Add MWI workaround for Tulip DC21143
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH, RESEND] Add MWI workaround for Tulip DC21143
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.
P.
Signed-off-by: P. Horton [EMAIL PROTECTED]
Index: linux.git/drivers/net/tulip/tulip_core.c
===
--- linux.git.orig/drivers/net/tulip/tulip_core.c 2006-01-29
21:43:40.0 +
+++ linux.git/drivers/net/tulip/tulip_core.c2006-01-29 21:56:50.0
+
@@ -294,6 +294,8 @@
if (tp-mii_cnt || (tp-mtabletp-mtable-has_mii))
iowrite32(0x0004, 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(0x0001, ioaddr + CSR0);
udelay(100);
@@ -1155,8 +1157,10 @@
/* if we have any cache line size at all, we can do MRM */
csr0 |= MRM;
+#ifndef CONFIG_TULIP_MWI_DC21143
/* ...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 @@
*/
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);
Index: linux.git/drivers/net/tulip/tulip.h
===
--- linux.git.orig/drivers/net/tulip/tulip.h2006-01-29 21:43:40.0
+
+++ linux.git/drivers/net/tulip/tulip.h 2006-01-29 21:52:01.0 +
@@ -262,7 +262,15 @@
#define RX_RING_SIZE 128
#define MEDIA_MASK 31
-#define PKT_BUF_SZ 1536/* Size of each temporary Rx buffer. */
+/* MWI can fail on 21143 rev 65 if the receive buffer ends
+ on a cache line boundary. Ensure it doesn't ...
+*/
+
+#ifdef CONFIG_TULIP_MWI_DC21143
+#define PKT_BUF_SZ (1536 + 4) /* Size of each temporary Rx
buffer. */
+#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 */
Index: linux.git/drivers/net/tulip/Kconfig
===
--- linux.git.orig/drivers/net/tulip/Kconfig2006-01-29 21:48:09.0
+
+++ linux.git/drivers/net/tulip/Kconfig 2006-01-29 21:50:28.0 +
@@ -57,6 +57,16 @@
If unsure, say N.
+config TULIP_MWI_DC21143
+ bool Enable MWI workaround on dc21143 controllers
+ depends on TULIP_MWI
+ help
+ This enables a workaround for MWI (New bus configuration) on DC21143
+ controllers. Normally MWI is disabled on these chips because of
+ hardware errata.
+
+ If unsure, say N.
+
config TULIP_MMIO
bool Use PCI shared mem for NIC registers
depends on TULIP
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
