On Fri, 19 Jan 2001, Nyef wrote:

> After running the EtherPort driver through a disassembler, I noticed that
> while it didn't ever call SIntInstall, it _did_ call VInstall. The obvious
> conclusion was that the card didn't generate slot interrupts (which the
> NetBSD ae driver appears to rely on). Looking at the ae driver code, there
> is a procedure that is only compiled in if DEBUG is defined that calls the
> interrupt handler manually if a timeout occurs. This got the MacCon card
> to "work" (extremely slowly, and one has to keep sending packets out in
> order to recieve any), and the EtherPort card to lock up the system when I
> try to send packets out over it.

More findings: The IM:XREF listing for trap a075 is wrong. (The driver
does call SIntInstall after all).

The EtherPort IIN memory is laid out as word locations with long
alignment, which means writing new read_hdr(), ring_copy(), write_mbuf(),
and test_mem() functions for it.

The MacOS EtherPort driver contains separate IIN and SE/30 interrupt
routines and memory tests, and uses something akin to strcmp() on the card
name to tell the difference.

I've hacked up the ae driver to send packets properly over my EtherPort
card. I'll clean it up and try to get packet reception working later...

For some reason, NetBSD is ignoring interrups requested by either card,
and I haven't been able to figure out why. Does anyone have any ideas?

> So now I have a few new questions:
> 
> Does the EtherPort SE/30 card work if you don't define DEBUG in
> arch/mac68k/nubus/if_ae_nubus.c?

I still don't know this one.

> What is the best way of handling an ethernet card that has to be polled,
> rather than interrupt-driven? (other than throwing it out, that is)

Stupid question, based on a false assumption.

> Are my problems with the MacCon card indicitive of a hardware
> problem? (given that MacCon cards are listed as working in the ethernet
> status document)

No, they aren't a hardware problem, the card works fine in MacOS. I'd
still like to know why I'm not seeing any interrupts from it, though.

---------------------------
All programming can be viewed as an exercise.
---------------------------
Alastair Bridgewater
e-mail: nyef@softhome.net