|
From: Marty C. <md...@th...> - 2001-03-06 21:17:04
|
On 3/6/2001 9:48 AM Jim McQuillan ja...@Mc... wrote: >It appears that the workstation is doing an arp request >to get the mac address of the server. Sounds like the card is going deaf. I guess if I were going to debug this, I'd first ask questions like: - Does it happen with just this card, or with all 3C905Cxxxxx cards? - Does it happen when you switch CAT 5 cables? - Does it happen when you switch hubs? - Have you power-cycled the hub/switch in between tests? - Is loopback properly configured in the kernel? I'm sure you've probably checked those things already. What I find interesting here is that the kernel loads properly, which suggests that Etherboot managed to get the information it needed. It sounds like the kernel is having trouble either initializing the card or talking to it afterwards. This somewhat begs the question of whether the kernel code is fresh and wholesome. I know for example that the vmlinuz.all kernel on ltsp.org fails to boot my rtl8139 card, but the vmlinuz.rtl8139 works. So I guess I'd try another version of the kernel to see if that helps. Now turning to the possibility that Etherboot is leaving the card in a state that makes the kernel unable to hear, I'd also ponder the consequences of this code (or lack thereof) in 3c90x.c in the Etherboot code: /*** a3c90x_disable: exported routine to disable the card. What's this for? *** the eepro100.c driver didn't have one, so I just left this one empty too. *** Ideas anyone? ***/ static void a3c90x_disable(struct nic *nic) { } Note that since that comment was written, eepro100.c has been changed: static void eepro100_disable(struct nic *nic) { /* See if this PartialReset solves the problem with interfering with kernel operation after Etherboot hands over. - Ken 20001102 */ outl(2, ioaddr + SCBPort); } and tulip.c does: static void tulip_disable(struct nic *nic) { whereami("tulip_disable\n"); /* disable interrupts */ outl(0x00000000, ioaddr + CSR7); /* Stop the chip's Tx and Rx processes. */ outl(inl(ioaddr + CSR6) & ~0x00002002, ioaddr + CSR6); /* Clear the missed-packet counter. */ (volatile unsigned long)inl(ioaddr + CSR8); } Which suggests that in 3c90x.c something like: static void a3c90x_disable(struct nic *nic) { /** Send the reset command to the card **/ a3c90x_internal_IssueCommand(INF_3C90X.IOAddr, cmdGlobalReset, 0); /** wait for reset command to complete **/ while (inw(INF_3C90X.IOAddr + regCommandIntStatus_w) & INT_CMDINPROGRESS); } might just help things along. It's probably overkill, since other drivers seem to just disable RX and TX and clear interrupt masks, but worth a shot. Let us know if this does anything interesting. Marty P.S. We might want to check all drivers for this, since it has now been added to tulip and eepro100, and I am wondering if the leaving the receiver on after Etherboot is gone could lead to a card randomly writing in memory that doesn't belong to it, possibly corrupting a loaded OS or loader. The rtl8139 driver for example still does: static void rtl_disable(struct nic *nic) { } I suspect as a rule we should really reset cards before handing control over to another program. Seems only fair :-) --- Try: http://rom-o-matic.net/ to make Etherboot images instantly. Name: Martin D. Connor US Mail: Entity Cyber, Inc.; P.O. Box 391827; Cambridge, MA 02139; USA Voice: (617) 491-6935, Fax: (617) 491-7046 Email: md...@th... Web: http://www.thinguin.org/ |
