kern/94307: [bge] kernel panics when passing trafffic through
bge1
Internet Partners, Inc. Tech Support
support at ipinc.net
Wed May 3 01:10:19 UTC 2006
The following reply was made to PR kern/94307; it has been noted by GNATS.
From: "Internet Partners, Inc. Tech Support" <support at ipinc.net>
To: <bug-followup at FreeBSD.org>, <grehan at FreeBSD.org>
Cc:
Subject: Re: kern/94307: [bge] kernel panics when passing trafffic through bge1
Date: Tue, 2 May 2006 18:06:23 -0700
I made the following change in the FreeBSD driver:
$ diff -c if_bge.c.dist if_bge.c
*** if_bge.c.dist Tue May 2 10:58:41 2006
--- if_bge.c Tue May 2 11:55:39 2006
***************
*** 2099,2109 ****
sc->bge_chiprev = BGE_CHIPREV(sc->bge_chipid);
/*
! * Treat the 5714 and the 5752 like the 5750 until we have more info
* on this chip.
*/
! if (sc->bge_asicrev == BGE_ASICREV_BCM5714 ||
! sc->bge_asicrev == BGE_ASICREV_BCM5752)
sc->bge_asicrev = BGE_ASICREV_BCM5750;
/*
--- 2099,2108 ----
sc->bge_chiprev = BGE_CHIPREV(sc->bge_chipid);
/*
! * Treat the 5752 like the 5750 until we have more info
* on this chip.
*/
! if (sc->bge_asicrev == BGE_ASICREV_BCM5752)
sc->bge_asicrev = BGE_ASICREV_BCM5750;
/*
$
And the HP DL320 G4 _still_ panics when more than a few K of data is
passed over the ethernet interface. Additionally, I have corrected the
ASIC revs in the driver and added some more, see PR/94863
In looking at the latest Linux driver from Broadcom, it appears they
are special-casing the BCM5714 in a number of places in the Linux
driver. I have tested the Linux driver on OpenSUSE and it works fine,
no panics on OpenSUSE. In particular in the Linux driver look at this
section:
/* Prevent chip from dropping frames when flow control
* is enabled.
*/
tw32_f(MAC_LOW_WMARK_MAX_RX_FRAME, 2);
if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5704 &&
(tp->tg3_flags2 & TG3_FLG2_PHY_SERDES)) {
/* Use hardware link auto-negotiation */
tp->tg3_flags2 |= TG3_FLG2_HW_AUTONEG;
}
if ((tp->tg3_flags2 & TG3_FLG2_MII_SERDES) &&
(GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5714)) {
u32 tmp;
tmp = tr32(SERDES_RX_CTRL);
tw32(SERDES_RX_CTRL, tmp | SERDES_RX_SIG_DETECT);
tp->grc_local_ctrl &= ~GRC_LCLCTRL_USE_EXT_SIG_DETECT;
tp->grc_local_ctrl |= GRC_LCLCTRL_USE_SIG_DETECT;
tw32(GRC_LOCAL_CTRL, tp->grc_local_ctrl);
}
And look at this section:
/* Set bit 23 to enable PCIX hw bug fix */
tp->dma_rwctrl |= 0x009f0000;
} else if (GET_ASIC_REV(tp->pci_chip_rev_id) ==
ASIC_REV_5780) {
/* 5780 always in PCIX mode */
tp->dma_rwctrl |= 0x00144000;
} else if (GET_ASIC_REV(tp->pci_chip_rev_id) ==
ASIC_REV_5714) {
/* 5714 always in PCIX mode */
tp->dma_rwctrl |= 0x00148000;
} else {
tp->dma_rwctrl |= 0x001b000f;
}
Note also that in PR/94863 regarding the IBM e326m Opteron server, that the
originator of the PR concluded that his server had a BCM5780 chip in it.
I don't know where in the FreeBSD driver the cooresponding "PCI-X" bugfix
would be located. There's a lot similar between the Linux driver and the
FreeBSD driver but a lot also that's different.
Ted
More information about the freebsd-bugs
mailing list