ethernet/b44: Bug in b44.c:v0.93 (Mar, 2004) ethernet driver in 2.6.6

ethernet/b44: Bug in b44.c:v0.93 (Mar, 2004) ethernet driver in 2.6.6

[Miroslav Zubcic]

Hi.

After reading Changelog for 2.6.6, I have seen b44 driver was updated,
and it should support new HP/compaq laptops now. I tried 2.6.6 kernel,
but I have a problem: b44 module does not work(TM).

System info:

Laptop compaq nx5000
kernel 2.6.6
gcc 3.2.3
binutils-2.14.90.0.4
module-init-tools 2.4.26


lspci:

--------------
00:00.0 Host bridge: Intel Corp. 82852/855GM Host Bridge (rev 02)
00:00.1 System peripheral: Intel Corp.: Unknown device 3584 (rev 02)
00:00.3 System peripheral: Intel Corp.: Unknown device 3585 (rev 02)
00:02.0 VGA compatible controller: Intel Corp. 82852/855GM Integrated Graphics Device (rev 02)
00:02.1 Display controller: Intel Corp. 82852/855GM Integrated Graphics Device (rev 02)
00:1d.0 USB Controller: Intel Corp. 82801DB USB (Hub #1) (rev 01)
00:1d.1 USB Controller: Intel Corp. 82801DB USB (Hub #2) (rev 01)
00:1d.2 USB Controller: Intel Corp. 82801DB USB (Hub #3) (rev 01)
00:1d.7 USB Controller: Intel Corp. 82801DB USB2 (rev 01)
00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 81)
00:1f.0 ISA bridge: Intel Corp. 82801DBM LPC Interface Controller (rev 01)
00:1f.1 IDE interface: Intel Corp. 82801DBM Ultra ATA Storage Controller (rev 01)
00:1f.5 Multimedia audio controller: Intel Corp. 82801DB AC'97 Audio Controller (rev 01)
00:1f.6 Modem: Intel Corp. 82801DB AC'97 Modem Controller (rev 01)
01:04.0 Network controller: Intel Corp. PRO/Wireless LAN 2100 3B Mini PCI Adapter (rev 04)
01:06.0 CardBus bridge: Texas Instruments: Unknown device ac8e
01:06.1 CardBus bridge: Texas Instruments: Unknown device ac8e
01:06.3 Unknown mass storage controller: Texas Instruments: Unknown device ac8f
01:0d.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link)
01:0e.0 Ethernet controller: Broadcom Corporation: Unknown device 170c (rev 02)
--------------
Verbose lspci of the last entry:

01:0e.0 Ethernet controller: Broadcom Corporation: Unknown device 170c (rev 02)
        Subsystem: Hewlett-Packard Company: Unknown device 08bc
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 64
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at 90080000 (32-bit, non-prefetchable) [size=8K]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=2 PME-
--------------

modprobe b44 and `ip link set dev eth0 up' gives this in dmesg:

--------------
b44.c:v0.93 (Mar, 2004)
PCI: Guessed IRQ 11 for device 0000:01:0e.0
divert: allocating divert_blk for eth0
eth0: Broadcom 4400 10/100BaseT Ethernet 00:08:02:e2:2d:ba
b44: eth0: BUG!  Timeout waiting for bit 80000000 of register 428 to clear.
b44: eth0: BUG!  Timeout waiting for bit 80000000 of register 428 to clear.
b44: eth0: BUG!  Timeout waiting for bit 80000000 of register 428 to clear.
b44: eth0: Link is down.
b44: eth0: BUG!  Timeout waiting for bit 80000000 of register 428 to clear.
b44: eth0: BUG!  Timeout waiting for bit 80000000 of register 428 to clear.
--------------

Host pinging on network timeouts with icmp destination host
unreachable, pinging of my own address (on the nx5000 laptop) works,
lsmod always shows b44 is zero used, even when link is up and local
ping works. It is not possible to ping any other address on the link.
If I remove b44 from kernel eth0 dissapears, even if it has IP address
on it.

loaded modules: rtc and b44 (single user mode). Kernel is vanilla
2.6.6 from kernel.org.

Output from "/sbin/ip addr list" looks perfectly normal BTW. :-\

It works OK with 2.4.21 kernel and bcm4401 driver from broadcom
www site. It does not work with 2.6.5 in any way.


-- 
		Miroslav

Re: ethernet/b44: Bug in b44.c:v0.93 (Mar, 2004) ethernet driver in 2.6.6

[Pekka Pietikainen]

On Fri, May 14, 2004 at 01:17:46AM +0200, Miroslav Zubcic wrote:
> After reading Changelog for 2.6.6, I have seen b44 driver was updated,
> and it should support new HP/compaq laptops now. I tried 2.6.6 kernel,
> but I have a problem: b44 module does not work(TM).
> 
> modprobe b44 and `ip link set dev eth0 up' gives this in dmesg:
> 
> --------------
> b44.c:v0.93 (Mar, 2004)
> PCI: Guessed IRQ 11 for device 0000:01:0e.0
> divert: allocating divert_blk for eth0
> eth0: Broadcom 4400 10/100BaseT Ethernet 00:08:02:e2:2d:ba
> b44: eth0: BUG!  Timeout waiting for bit 80000000 of register 428 to clear.
> b44: eth0: BUG!  Timeout waiting for bit 80000000 of register 428 to clear.
> b44: eth0: BUG!  Timeout waiting for bit 80000000 of register 428 to clear.
> Host pinging on network timeouts with icmp destination host
> Output from "/sbin/ip addr list" looks perfectly normal BTW. :-\
> 
> It works OK with 2.4.21 kernel and bcm4401 driver from broadcom
> www site. It does not work with 2.6.5 in any way.
Hi

This bug has appeared in the past too 
(eg. http://bugzilla.kernel.org/show_bug.cgi?id=2030 ), for me it triggers
only when using a broadcom driver and then trying b44 without a cold reset 
or using the workaround in the bug report that runs a part of bcm4400 
initialization process.

Another known bug has been seen when using 4G/4G split and having 
> 1G of memory (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=118165
, bugzilla is broken currently tho), but if you have more than a gig
mem=900M or whatnot is worth a try in any case.

Since it works perfectly (tm) on my hardware assuming I never load bcm4400 I
haven't put that much effort in tracking the reason what magic
"break b44 bit" bit broadcom drivers  set. I suppose I could give it a few 
hours this weekend tho... On some machines (I think dells) the timeout
waiting for 428 appears to happen even without bcm4400 getting loaded
so finally tracking this down would be really nice...

[PATCH] Re: ethernet/b44: Bug in b44.c:v0.93 (Mar, 2004) ethernet driver in 2.6.6

[Pekka Pietikainen]

On Fri, May 14, 2004 at 04:02:06PM +0300, Pekka Pietikainen wrote:
> haven't put that much effort in tracking the reason what magic
> "break b44 bit" bit broadcom drivers  set. I suppose I could give it a few 
> hours this weekend tho... On some machines (I think dells) the timeout
Could you try this patch? It makes the b44 after bcm4400 scenario work for
me. What was happening is that the broadcom driver sets a "power off MAC"
bit, and we didn't remove that when initializing the chip.
Also added some (a bit ugly, I know :-) ) logic to clear up the address
filter stuff, which is what recent broadcom drivers do...

--- linux-2.6.5-1.358/drivers/net/b44.c.orig	2004-05-15 13:59:57.000000000 +0300
+++ linux-2.6.5-1.358/drivers/net/b44.c	2004-05-15 14:59:39.794720368 +0300
@@ -27,8 +27,8 @@
 
 #define DRV_MODULE_NAME		"b44"
 #define PFX DRV_MODULE_NAME	": "
-#define DRV_MODULE_VERSION	"0.94"
-#define DRV_MODULE_RELDATE	"May 4, 2004"
+#define DRV_MODULE_VERSION	"0.95"
+#define DRV_MODULE_RELDATE	"May 15, 2004"
 
 #define B44_DEF_MSG_ENABLE	  \
 	(NETIF_MSG_DRV		| \
@@ -1187,8 +1187,9 @@
 	b44_chip_reset(bp);
 	b44_phy_reset(bp);
 	b44_setup_phy(bp);
-	val = br32(B44_MAC_CTRL);
-	bw32(B44_MAC_CTRL, val | MAC_CTRL_CRC32_ENAB);
+
+	/* Enable CRC32, set proper LED modes and power on MAC */
+	bw32(B44_MAC_CTRL, MAC_CTRL_CRC32_ENAB | MAC_CTRL_PHY_LEDCTRL);
 	bw32(B44_RCV_LAZY, (1 << RCV_LAZY_FC_SHIFT));
 
 	/* This sets the MAC address too.  */
@@ -1337,7 +1338,7 @@
 	return nstat;
 }
 
-static void __b44_load_mcast(struct b44 *bp, struct net_device *dev)
+static int __b44_load_mcast(struct b44 *bp, struct net_device *dev)
 {
 	struct dev_mc_list *mclist;
 	int i, num_ents;
@@ -1347,12 +1348,15 @@
 	for (i = 0; mclist && i < num_ents; i++, mclist = mclist->next) {
 		__b44_cam_write(bp, mclist->dmi_addr, i + 1);
 	}
+	return i+1;
 }
 
 static void __b44_set_rx_mode(struct net_device *dev)
 {
 	struct b44 *bp = dev->priv;
 	u32 val;
+	int i=0;
+	unsigned char zero[6] = {0,0,0,0,0,0};
 
 	val = br32(B44_RXCONFIG);
 	val &= ~(RXCONFIG_PROMISC | RXCONFIG_ALLMULTI);
@@ -1365,8 +1369,11 @@
 		if (dev->flags & IFF_ALLMULTI)
 			val |= RXCONFIG_ALLMULTI;
 		else
-			__b44_load_mcast(bp, dev);
-
+			i=__b44_load_mcast(bp, dev);
+		
+		for(;i<64;i++) {
+			__b44_cam_write(bp, zero, i);			
+		}
 		bw32(B44_RXCONFIG, val);
         	val = br32(B44_CAM_CTRL);
 	        bw32(B44_CAM_CTRL, val | CAM_CTRL_ENABLE);

Re: [PATCH] Re: ethernet/b44: Bug in b44.c:v0.93 (Mar, 2004) ethernet driver in 2.6.6

[Pekka Pietikainen]

On Sat, May 15, 2004 at 03:05:19PM +0300, Pekka Pietikainen wrote:
> +	/* Enable CRC32, set proper LED modes and power on MAC */
> +	bw32(B44_MAC_CTRL, MAC_CTRL_CRC32_ENAB | MAC_CTRL_PHY_LEDCTRL);
Erk, that comment should of course be "power on PHY". I hate acronyms...

--- linux-2.6.5-1.358/drivers/net/b44.c.orig	2004-05-15 13:59:57.000000000 +0300
+++ linux-2.6.5-1.358/drivers/net/b44.c	2004-05-15 14:59:39.794720368 +0300
@@ -27,8 +27,8 @@
 
 #define DRV_MODULE_NAME		"b44"
 #define PFX DRV_MODULE_NAME	": "
-#define DRV_MODULE_VERSION	"0.94"
-#define DRV_MODULE_RELDATE	"May 4, 2004"
+#define DRV_MODULE_VERSION	"0.95"
+#define DRV_MODULE_RELDATE	"May 15, 2004"
 
 #define B44_DEF_MSG_ENABLE	  \
 	(NETIF_MSG_DRV		| \
@@ -1187,8 +1187,9 @@
 	b44_chip_reset(bp);
 	b44_phy_reset(bp);
 	b44_setup_phy(bp);
-	val = br32(B44_MAC_CTRL);
-	bw32(B44_MAC_CTRL, val | MAC_CTRL_CRC32_ENAB);
+
+	/* Enable CRC32, set proper LED modes and power on PHY */
+	bw32(B44_MAC_CTRL, MAC_CTRL_CRC32_ENAB | MAC_CTRL_PHY_LEDCTRL);
 	bw32(B44_RCV_LAZY, (1 << RCV_LAZY_FC_SHIFT));
 
 	/* This sets the MAC address too.  */
@@ -1337,7 +1338,7 @@
 	return nstat;
 }
 
-static void __b44_load_mcast(struct b44 *bp, struct net_device *dev)
+static int __b44_load_mcast(struct b44 *bp, struct net_device *dev)
 {
 	struct dev_mc_list *mclist;
 	int i, num_ents;
@@ -1347,12 +1348,15 @@
 	for (i = 0; mclist && i < num_ents; i++, mclist = mclist->next) {
 		__b44_cam_write(bp, mclist->dmi_addr, i + 1);
 	}
+	return i+1;
 }
 
 static void __b44_set_rx_mode(struct net_device *dev)
 {
 	struct b44 *bp = dev->priv;
 	u32 val;
+	int i=0;
+	unsigned char zero[6] = {0,0,0,0,0,0};
 
 	val = br32(B44_RXCONFIG);
 	val &= ~(RXCONFIG_PROMISC | RXCONFIG_ALLMULTI);
@@ -1365,8 +1369,11 @@
 		if (dev->flags & IFF_ALLMULTI)
 			val |= RXCONFIG_ALLMULTI;
 		else
-			__b44_load_mcast(bp, dev);
-
+			i=__b44_load_mcast(bp, dev);
+		
+		for(;i<64;i++) {
+			__b44_cam_write(bp, zero, i);			
+		}
 		bw32(B44_RXCONFIG, val);
         	val = br32(B44_CAM_CTRL);
 	        bw32(B44_CAM_CTRL, val | CAM_CTRL_ENABLE);

Re: [PATCH] Re: ethernet/b44: Bug in b44.c:v0.93 (Mar, 2004) ethernet driver in 2.6.6

[Miroslav Zubcic]

Pekka Pietikainen <pp@ee.oulu.fi> writes:

> On Sat, May 15, 2004 at 03:05:19PM +0300, Pekka Pietikainen wrote:
>> +	/* Enable CRC32, set proper LED modes and power on MAC */
>> +	bw32(B44_MAC_CTRL, MAC_CTRL_CRC32_ENAB | MAC_CTRL_PHY_LEDCTRL);
> Erk, that comment should of course be "power on PHY". I hate acronyms...
>
> --- linux-2.6.5-1.358/drivers/net/b44.c.orig	2004-05-15 13:59:57.000000000 +0300
> +++ linux-2.6.5-1.358/drivers/net/b44.c	2004-05-15 14:59:39.794720368 +0300
> @@ -27,8 +27,8 @@

Pekka, thank you very much for your patch. It looks like things are
working now:

dmesg part:
b44.c:v0.95 (May 15, 2004)
...
eth0: Broadcom 4400 10/100BaseT Ethernet 00:08:02:e2:2d:ba
ip_tables: (C) 2000-2002 Netfilter core team
b44: eth0: Link is down.
b44: eth0: Link is up at 100 Mbps, full duplex.
b44: eth0: Flow control is off for TX and off for RX.

I have tried moving large packets, NFS, ping etc ... no problem
anymore, it works.

Thanks again!


-- 
		The Network is the Filesystem.

Re: [PATCH] Re: ethernet/b44: Bug in b44.c:v0.93 (Mar, 2004) ethernet driver in 2.6.6

[Jeff Garzik]

hrm...  I agree with the patch, but it doesn't apply to 2.6.6-bk... can 
you rediff please?

Re: [PATCH] Re: ethernet/b44: Bug in b44.c:v0.93 (Mar, 2004) ethernet driver in 2.6.6

[Jeff Garzik]

Ignore my last email...  I used BK to clone a 2.6.5 tree, then merge to 
latest.

Patch applied.

	Jeff