Subject: Re: Problem with Sonic and rarp/bootp
To: Ken Nakata <kenn@eden.rutgers.edu>
From: Andrey E. Lerman <lae@uniyar.ac.ru>
List: port-mac68k
Date: 03/06/1998 20:55:56
On Thu, 5 Mar 1998, Ken Nakata wrote:

> Yes, the address difference is caused by the sn driver; it's written
> in a way so that it bit-reverses the hardware address only when it's
> in 8:0:7 range (the bit-reversal of 8:0:7, 10:0:e0, isn't a legal
> address range for Apple hardware, so bit-reversal is necessary).  But
> it's hard to say it is a bug.
> 
> After all, it uses a unique address officially assigned to Apple,
> either with or without bit-reversal if the address is in 0:5:2 or
> 0:a0:40 range.  IOW, it doesn't break any protocol or law whether we
> use a 0:5:2 address or a 0:a0:40 address.  And it's not always
> possible for sn driver to use the same one MacOS driver is using,
> since that depends on which MacOS driver (pre- or post-OT 1.1.1) you
> are using.
I'm using OpenTransport v1.1.1 (on System 7.5.1).

> 
> Is it possible for you to configure the Bootp server such that it
> looks like your Mac has two network interfaces on one network? (one
> with the address in 0:a0:40 range, and another in 0:5:2 range)  That
> should work around this problem.
Tried this... Now bootp server accepts both hw addresses and returns
the same IP for both. But this doesn't change anything, still errors with
NetBSD while it perfectly working with MacOS.

> 
> Ok, we've still got a problem - the "Tx - timeout" problem is entirely
> different matter.  I had the exact same problem when I tried to run
> NetBSD on a IIci with Apple Ethernet NB TP.  I can't say for sure, but
> I think what was happening there was the following:
> 
> Sn driver allocates a small chunk of *system memory* for communication
> with SONIC chip, regardless of the presence or absence of on-board
> RAM.  Now, the SONIC chip is supposed to read from and write to this
> buffer, but the chip on the NB TP card can't seem to do that.  IOW,
> the SONIC chip on board can't read outgoing packets from the buffer,
> can't write incoming packets into the buffer, or can't even update the
> status of any packet.  Hence timeouts.  I think the NB TP card is not
> designed to be a bus master.
In my case the card is able to send packets. I can see messages that
bootpd successufully answered to request. Problem with receiving...

> 
> I modified sn driver so that it uses on-board RAM if the card is NB
> TP, and got somewhat better results (never had a chance to finish the
> debugging; the system was Rutgers Physics Department's for whom I no
> longer work).  I think the same or something similar is happening on
> your system.
Can you build kernel with these modifications for my card? I can test and
report results. Or maybe I can build kernel myself if you send me patches
(this requires installation of cross-compiler somewhere, but this is
really not a big problem for me)

> 
> What kind of Ethernet card you got?  We might need the output of Slots
> program for the declaration ROM details.
Card made by Apple and has serial number 820-0607-A. Chip "SONIC(tm)-T"
has S9524BV and DP83934AVQB written on it.
That is the Slots program. I can send the output if you tell me where can
I get it.