problem with dhcpcd-1.3.18-pl3 daemon, 3c59x driver and 3com 905c card

[Donald Becker]

On Wed, 22 Mar 2000, Dusan Vujosevic wrote:

>  I have a problem with dhcpcd-1.3.18-pl3 daemon (by Sergei Viznyuk), 3c59x
> driver (by Donald Becker, obtained in March from
> http://cesdis.gsfc.nasa.gov/pub/linux/drivers/3c59x.c) and 3com 905c
> card. When the dhcpcd asks for an IP from a Windows 2000 server (retail
> version) it reports the MAC address (hardware address, station address
> ... whatever you want to call it) of eth0 as 00:00:00:00:00:00. The
> servers gives it an IP.

Hmmm, exactly what is reporting this address?

My first guess is that dhcpcd is the problem.  I've never met a DHCP client
that worked reliably on Linux.  We *really* want one for cluster work, so
we have looked.  In part the problem that the kernel has changed the
interface several times -- see the 'bootp' references on
  http://cesdis.gsfc.nasa.gov/linux/index.html
But there must be something about writing DHCP clients that causes otherwise
sane programmers to write programs that want to control every aspect of the
machine, for all time, and to use 100% of the CPU doing it.

I've been burnt (almost literally, my laptop gets hot when 'pump' runs amok)
so many time in the past year by this...

> The  driver provided by 3com (patch for kernel 2.2.5) behaves in the exact
> same way.

That's completely different code, from scratch, so that really points to a
non-driver bug.

> Donald Becker's driver also gives a checksum error on load but loads
> OK (shown in dmesg below).

This is harmless, as long as it happens on the new 3c905C cards.  It exists
because 3Com continues to stuff more info into the EEPROM.  Rather than
computing a checksum over the whole EEPROM, or having a backwards-compatible
subset and retaining the old checksum location, they keep moving the
checksum word a few bytes at a time.

The "solution" in the updated drivers is to just omit the warning with new
cards.  I've never seen a report of EEPROM that became spontaneously
corrupted.

> VFS: Disk change detected on device ide1(22,0)
> protocol 0400 is buggy, dev eth0
> protocol 0400 is buggy, dev eth0

Hmmm, very curious.  I don't know what is generating this message, but it's
not from the driver.

A final note: it's the protocol software layer that stuffs the Ethernet
station address into the packet, not the hardware.  The hardware only cares
for filtering Rx packets.

Donald Becker
Scyld Computing Corporation, becker@scyld.com

-------------------------------------------------------------------
To unsubscribe send a message body containing "unsubscribe"
to linux-vortex-bug-request@beowulf.org