[Etherboot-developers] Re: FYI, I've had a Y2K bug with etherboot

[Ken Y. <ke...@nl...>]

|I just can't tell wether this is in etherboot or my BIOS.
|
|I think I've found the offending statement in lance.c from 4.7.17
|(actually I'm using 4.6.12, 4.7.17+ does not recognize my kernels):
|
|>361:        time = currticks() + TICKS_PER_SEC;             /* wait one seco
>nd */
|>>>362:        while (currticks() < time && (lp->tx_ring.u.base & 0x80000000)
> != 0);
|				
|This seems to cause an overflow and results in my network getting
|flooded with the same ethernet frame all over. 
|It helped to set the bios clock of the machine way back. Quite possibly
|this might be a bug in the machine,
|because the machine is an old 2nd hand compaq deskpro 2000 5120 with
|onboard amd lance/pcnet 32 10 Mbit NIC.

It won't be a Y2K bug, Etherboot has no notion of year. currticks()
returns an unsigned long which are the ticks (units of 1/18.22 seconds)
since midnight of today, providing your BIOS implemented it correctly,
not since some date in the past. However once initialised currticks()
continues to increment correctly past midnight, and wraps around at
about 2700 days.

And anyway I don't see immediately how this statement would cause a
resend of the packet, all it does it provide a timeout for the transmit
completion.

It would help if you inserted some printf statements to display the
value returned by currticks to verify or disprove your bug.

Also in future, please send bug reports to the users or developers list,
not to me directly. The idea is for me not to become a single point of
failure for the project if I decide to drop out to some South Pacific
island where there is no Ethernet. :-)