|
From: Marty C. <md...@th...> - 2001-05-30 17:26:10
|
[ we may be getting into Etherboot-Developers territory, but I think some
people might be interested in the subtle kinds of interactions that
happen when you get close to the hardware. figuring out "whose bug it
is" is not always easy, because often at this level, it a question of
semantics - that is that both sides are doing something that is legal,
but because of timing or protocol they are not able to communicate. The
tulip driver is an especially complicated because DEC wrote the spec and
people made clone cards that sort of followed the spec, but there was
room for variance and interpretation, and so there are times where things
don't work as we think they should. Anyway, onward we go. ]
On 5/27/01 2:51 AM Michael Stein ma...@uc... wrote:
>PS: Why is the number of loops 1000? The loop might only
> be a few clocks long and at 2 ns/clock (466 Mhz, almost 500 Mhz)
> that's only a few ms. Perhaps it just takes longer.
The inl(...) instruction takes a bus cycle, which would be 33/66/100 MHZ,
so the loop is slowed down by that.
> Or the problem is something else and is completely unrelated to this.
Looking at the code again and comparing to the Linux driver, I have
another thought. Etherboot drivers don't use interrupts, and so where in
the kernel, you can do things like set "next_tick" and then run_at, we
have to do things other ways.
What it looks like to me (and boy would it be nice if I had a Cisco
hub/switch to test this with) is that there is a time delay (and recheck)
needed after media selection.
Here is the place I think we might be coming to (need to verify this with
a printf):
else {
/* Start with 10mbps to do autonegotiation. */
outl(0x32, ioaddr + CSR12);
tp->csr6 = 0x00420000;
outl(0x0001B078, ioaddr + 0xB8);
outl(0x0201B078, ioaddr + 0xB8);
next_tick = 1*HZ;
}
That "next_tick" statement is later followed (in the Linux driver) by:
/* Set the timer to switch to check for link beat and perhaps
switch
to an alternate media type. */
init_timer(&tp->timer);
tp->timer.expires = RUN_AT(next_tick);
tp->timer.data = (unsigned long)dev;
tp->timer.function = tulip_tbl[tp->chip_id].media_timer;
add_timer(&tp->timer);
In Etherboot we don't have this interrupt functionality. But since we're
single-threaded serial processing, we could just wait, and run the
"pnic_timer" code inline for this card.
I think the reason it works for me and not for you at 100BASE-T is
because I'm using a Netgear 10/100 hub, and autonegotiation with the
Netgear FA310TX is very fast on my end. Some Cisco switches/hubs have
autonegotiation issues, especially with duplex. Certain Macintosh
internal ethernet interfaces for example can't reliably synch up with
them.
So, I think I have a good handle on what might be causing the problem,
and it fits well with past reports that I could not replicate. I bet if
I tried this with a Cisco 4000 hub I'd see the problem too.
The way to fix this I think is to first isolate the code path (stuff that
only happens with LC82C168) and then compare with the Linux and Etherboot
code paths. We've been cheating a little, by not inserting a N second
wait, followed by a recheck of the speed/duplex parameters, which the
linux driver does asynchronously.
I won't be able to work more on this problem for a few days, but if
you're willing to help debug, I'm sure we can figure it out. My first
thought is add a tulip_wait() call after the autonegotiation code,
followed by the code in pnic_timer() which will check and reset the
speed/duplex, which may have settled down by then. I suspect if we
looked closely we'd find that the card duplex was not matching the
switch/hub duplex so the card is happily transmitting at the wrong speed
or duplex, and the hub is not hearing any of it because it is listening
differently. The brute-force test for this is to insert a cheap 10
BASE-T hub in between you and the Cisco, and see if it magically works.
Anyway, thanks for your patience and help, and if you're willing to help
debug this, I'm sure we can figure it out. (and anybody else who wants
to help, just let me know.)
Marty
---
Try: http://rom-o-matic.net/ to make Etherboot images instantly.
Name: Marty 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/
|
