From owner-freebsd-current@FreeBSD.ORG Sat Sep 2 18:51:28 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A098816A4E1; Sat, 2 Sep 2006 18:51:28 +0000 (UTC) (envelope-from simon@zaphod.nitro.dk) Received: from mx.nitro.dk (zarniwoop.nitro.dk [83.92.207.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id C71BE43D49; Sat, 2 Sep 2006 18:51:26 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: from zaphod.nitro.dk (unknown [192.168.3.39]) by mx.nitro.dk (Postfix) with ESMTP id C762532E5A5; Sat, 2 Sep 2006 18:51:25 +0000 (UTC) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id 8C67F1141D; Sat, 2 Sep 2006 20:51:25 +0200 (CEST) Date: Sat, 2 Sep 2006 20:51:25 +0200 From: "Simon L. Nielsen" To: David Christensen Message-ID: <20060902185124.GB59963@zaphod.nitro.dk> References: <44F5C5A9.30605@delphij.net> <09BFF2FA5EAB4A45B6655E151BBDD90301E2F1CF@NT-IRVA-0750.brcm.ad.broadcom.com> <20060902181850.GA90659@lath.rinet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060902181850.GA90659@lath.rinet.ru> User-Agent: Mutt/1.5.11 Cc: LI Xin , freebsd-current@freebsd.org, Oleg Bulyzhin Subject: Re: bge(4) on BCM 5752 A02 panic due to media autoselect X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Sep 2006 18:51:28 -0000 On 2006.09.02 22:18:50 +0400, Oleg Bulyzhin wrote: > On Wed, Aug 30, 2006 at 11:59:08AM -0700, David Christensen wrote: > > > Recently one of my colleagues found that BCM 5752 A02 on Dell Latitude > > > D820 would get "panic: invalid ife->ifm_data (0xa) in > > > mii_phy_setmedia". > > > After some investigation I have found that removing BCMR_ANEG from > > > mii_capabilities in ukphy.c would work around the problem, > > > and it turns > > > out that without explicitly specifying media type, the code > > > will finally > > > get to pass the "intentionally invalid index" to mii_phy_setmedia and > > > trigger an assertion fail. > > > > > > I have not tested the situation in -STABLE yet, but it was > > > said to work > > > there, though. Is there anyone can shed some light to me about how to > > > debug the issue? Thanks in advance! > > > > > > PS. During the debugging I have found that the attached patch can make > > > "bge0: firmware handshake timeout" issue disappear from the said chip. > > > Because I do not have Broadcom specification at hand I would > > > like to see > > > if there is someone to give appropriate review for it. > > > > Try the attached patch instead and let me know if it works. When > > FastBoot > > is enabled on supported Broadcom controllers it allows the controller to > > skip rereading firmware after a reset, allowing the driver to complete > > its initialization more quickly. The Linux driver specifically disables > > FastBoot because it performs some read/write tests to controller memory, > > potentially corrupting the firmware, so FastBoot is disabled to insure > > an > > error free firmware reload. We don't do the same test so the same > > change > > isn't necessary. The patch happens to work because the bge driver > > doesn't > > perform firmware synchronization correctly, and the firmware initializes > > too fast for the driver. > > > > Dave > > Content-Description: fastboot_patch.txt > > Index: if_bge.c > > =================================================================== > > RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v > > retrieving revision 1.140 > > diff -p -u -r1.140 if_bge.c > > --- if_bge.c 24 Aug 2006 14:41:16 -0000 1.140 > > +++ if_bge.c 30 Aug 2006 18:50:19 -0000 > > @@ -2326,6 +2326,12 @@ bge_reset(struct bge_softc *sc) > > } > > } > > > > + /* > > + * Write the magic number to the firmware mailbox at 0xb50 > > + * so that the driver can synchronize with the firmware. > > + */ > > + bge_writemem_ind(sc, BGE_SOFTWARE_GENCOMM, BGE_MAGIC_NUMBER); > > + > > /* Issue global reset */ > > bge_writereg_ind(sc, BGE_MISC_CFG, reset); > > > > @@ -2362,11 +2368,6 @@ bge_reset(struct bge_softc *sc) > > CSR_WRITE_4(sc, BGE_MARB_MODE, BGE_MARBMODE_ENABLE); > > > > /* > > - * Prevent PXE restart: write a magic number to the > > - * general communications memory at 0xB50. > > - */ > > - bge_writemem_ind(sc, BGE_SOFTWARE_GENCOMM, BGE_MAGIC_NUMBER); > > - /* > > * Poll the value location we just wrote until > > * we see the 1's complement of the magic number. > > * This indicates that the firmware initialization > > Index: if_bgereg.h > > =================================================================== > > RCS file: /home/ncvs/src/sys/dev/bge/if_bgereg.h,v > > retrieving revision 1.52 > > diff -p -u -r1.52 if_bgereg.h > > --- if_bgereg.h 23 Aug 2006 11:32:54 -0000 1.52 > > +++ if_bgereg.h 30 Aug 2006 18:50:20 -0000 > > @@ -1768,10 +1768,11 @@ > > } while(0) > > > > /* > > - * This magic number is used to prevent PXE restart when we > > - * issue a software reset. We write this magic number to the > > - * firmware mailbox at 0xB50 in order to prevent the PXE boot > > - * code from running. > > + * This magic number is written to the firmware mailbox at 0xb50 > > + * before a software reset is issued. After the internal firmware > > + * has completed its initialization it will write the opposite of > > + * this value, ~BGE_MAGIC_NUMBER, to the same location, allowing the > > + * driver to synchronize with the firmware. > > */ > > #define BGE_MAGIC_NUMBER 0x4B657654 > > > > Hello. > > Today Simon L. Nielsen (simon@freebsd.org) reported breakage of bcm5703: > > bge0: mem 0xfe000000-0xfe00ffff irq 27 a > t device 3.0 on pci2 > miibus0: on bge0 > brgphy0: on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX > -FDX, auto > bge0: Ethernet address: 00:50:45:00:aa:a2 > bge1: mem 0xfe010000-0xfe01ffff irq 27 a > t device 4.0 on pci2 > miibus1: on bge1 > brgphy1: on miibus1 > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX > -FDX, auto > bge1: Ethernet address: 00:50:45:00:aa:a3 > > bge0@pci2:3:0: class=0x020000 card=0x000c14e4 chip=0x16a614e4 rev=0x02 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'BCM5702X NetXtreme Gigabit Ethernet' > class = network > subclass = ethernet > bge1@pci2:4:0: class=0x020000 card=0x000c14e4 chip=0x16a614e4 rev=0x02 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'BCM5702X NetXtreme Gigabit Ethernet' > class = network > subclass = ethernet > > Driver fails to start with diagnostic: > bge0: RX CPU self-diagnostics failed! As a followup, I tried backing out only the latest bge(4) changes and now the system (sledge.freebsd.org) works again. Basically the system responded to ICMP ping, but it seemed all other network trafic didn't work, at least NFS mounts, NTP etc. failed at boot and ssh to the system didn't work. It now works with: $FreeBSD: src/sys/dev/bge/if_bge.c,v 1.140 2006/08/24 14:41:16 oleg Exp $ $FreeBSD: src/sys/dev/bge/if_bgereg.h,v 1.52 2006/08/23 11:32:54 glebius Exp $ I can test patches if needed. -- Simon L. Nielsen