Re: 3c905B stops responding during ifconfig alias
Of all the gin joints in all the towns in all the world, tc...@staff.circle.net had to walk into mine and say: [...] During an ifconfig xl0 alias, the xl0 interface drops packets. It does NOT generate errors (netstat -in). In fact, on several occasions I've seen it go completely unresponsive (not responding to arp requests) until kicked back to life by outbound packets. [...] 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. = To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: 3c905B stops responding during ifconfig alias
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
3c905B stops responding during ifconfig alias
This happens in -current and -stable. Machine: CPU: Pentium II (quarter-micron) (350.80-MHz 686-class CPU) Origin = GenuineIntel Id = 0x652 Stepping=2 Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA, CM OV,PAT,PSE36,MMX,b24 real memory = 402653184 (393216K bytes) config quit avail memory = 388808704 (379696K bytes ... xl0: 3Com 3c905B Fast Etherlink XL 10/100BaseTX rev 0x30 int a irq 9 on pci0.18.0 ... During an ifconfig xl0 alias, the xl0 interface drops packets. It does NOT generate errors (netstat -in). In fact, on several occasions I've seen it go completely unresponsive (not responding to arp requests) until kicked back to life by outbound packets. This does NOT happen on the: xl0: 3Com 3c905 Fast Etherlink XL 10/100BaseTX rev 0x00 int a irq 10 on pci0.1 8.0 Here's a quick test program that I use: #!/usr/bin/perl # call this as just_alias.pl class_c num_ips $ip_base=$ARGV[0] || 209.95.67.; $num=$ARGV[1] || 250; for (1..$num) { print aliasing for $ip_base.$_.\n; system (ifconfig xl0 alias $ip_base.$_. netmask 255.255.255.255); # the sleep command allows us to see the problem more # clearly, though it does happen w/o the sleep here... sleep 1; } -Troy Cobb Circle Net, Inc. http://www.circle.net To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message