Bill,
Your patch worked perfectly. THANK YOU!
By the way, I'd be happy to fedex a 3c905B to
you for your use in testing these sorts of things
if that would be helpful. We have a fairly large
commitment to this card now (40+) and I'd do this
happily to facilitate continuing performance
enhancements or other improvements to it.
Sincerely,
-Troy Cobb
Circle Net, Inc.
http://www.circle.net
> -Original Message-
> From: wp...@ctr.columbia.edu [mailto:wp...@ctr.columbia.edu]
> My apologies for not replying to you on this sooner; it
> took me a while
> to locate a machine with which I could do some testing (all
> the 3c905B
> hardware I have is in the form of embedded chipsets in Dell desktop
> machines, and they've been moving around on me a lot).
>
> > This does NOT happen on the:
> > xl0: <3Com 3c905 Fast Etherlink XL 10/100BaseTX> rev 0x00
> int a irq 10 on
>
> I think I found the problem. Currently, xl_stop() and xl_init() both
> issue RX and TX resets. Seems logical doesn't it? I mean,
> the purpose
> of xl_init() is to put the NIC into a known good state, and
> the purpose
> of xl_stop() is to slap it in the face and make it shut up ASAP. The
> difference between the 3c905 and the 3c905B (well, the important
> difference in this case) is that the 3c905B's chipset has a
> built-in PHY,
> while the 3c905 requires an external one (3Com uses a
> DP83840A for the
> 3c905 boards, judging by the one sample 3c905 card I have).
> Apparently,
> issuing the RX and TX reset commands on the 3c905B causes it to also
> reset the PHY, which causes the PHY to restart its
> autonegotiation session
> with its link partner. It takes a few seconds for the
> autoneg session to
> finish, and during this time the 3c905B stops receiving packets.
>
> This doesn't happen on the 3c905 because issuing the RX and TX reset
> commands does not have any affect on the external PHY: the only way
> to reset the PHY is by writing to the PHY's basic mode
> control register
> via the MII management interface.
>
> I'm including a patch which should fix this problem. It
> just disables
> the code that does the reset in both xl_stop() and xl_init(). Please
> try this and let me know if it helps.
>
> To apply the patch, do the following:
>
> - Make sure you have the kernel source code installed under
> /usr/src.
> - Save this message to a file, i.e. /tmp/xl.patch
> - Become root.
> - Run the following commands:
> # cd /sys/pci
> # patch < /tmp/xl.patch
> - Compile a new kernel and boot it.
>
> This patch was generated using a version of if_xl.c from
> FreeBSD-current,
> but it should work on any version of the driver with only a
> couple of
> mild warnings.
>
> -Bill
>
> --
>
> =
> -Bill Paul(212) 854-6020 | System Manager,
> Master of Unix-Fu
> Work: wp...@ctr.columbia.edu | Center for
> Telecommunications Research
> Home: wp...@skynet.ctr.columbia.edu | Columbia University,
> New York City
>
> =
> "Mulder, toads just fell from the sky!" "I guess their
> parachutes didn't open."
>
> =
>
> *** ../CVSWORK/sys_pci/if_xl.c Mon Feb 1 16:25:52 1999
> --- if_xl.c Thu Feb 11 18:34:39 1999
> ***
> *** 2363,2373
> --- 2363,2375
> for (i = 0; i < 3; i++)
> CSR_WRITE_2(sc, XL_W2_STATION_MASK_LO + (i * 2), 0);
>
> + #ifdef notdef
> /* Reset TX and RX. */
> CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_RX_RESET);
> xl_wait(sc);
> CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_TX_RESET);
> xl_wait(sc);
> + #endif
>
> /* Init circular RX list. */
> if (xl_list_rx_init(sc) == ENOBUFS) {
> ***
> *** 2715,2724
> --- 2717,2728
> CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_TX_DISABLE);
> CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_COAX_STOP);
> DELAY(800);
> + #ifdef notdef
> CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_RX_RESET);
> xl_wait(sc);
> CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_TX_RESET);
> xl_wait(sc);
> + #endif
> CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_INTR_ACK|XL_STAT_INTLATCH);
>
> /* Stop the stats updater. */
>
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message