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/
|