[9fans] SCSI update and NE2000 question

[9fans] SCSI update and NE2000 question

[forsyth]

i think one of York's students might have been responsible for jmk adding
the nodummyrr option, since the student had such a card, which
gave the effects you describe.  the `dummy read' documented in the
data sheet looks like a fix for a chip bug that a clone manufacturer
didn't clone.  if you enable that option, you
should be able to get your card working.  even so, the 8390 cards are best avoided.
for 10m/bit operation, of those supported by plan 9, the 3com 3c509 cards
are a better choice, and now very reasonably priced.

[9fans] SCSI update and NE2000 question

[jmk]

there are some ne2000 clones which don't work as advertised and
should not do the dummy remote read, apparently you have such.
with dummyrr set the code is as described in the 8390 datsheet.

if you looked in ether2000.c you would see how to turn it off as
an option in plan9.ini

	ctlr->dummyrr = 1;
	for(i = 0; i < ether->nopt; i++){
		if(strcmp(ether->opt[i], "nodummyrr"))
			continue;
		ctlr->dummyrr = 0;
		break;
	}

[9fans] SCSI update and NE2000 question

[Lucio]

The SCSI problem I had, failing to operate with the newer Adaptec
eventually was resolved by using the most recent bootstrap code (B.COM
from the PC distribution) and patching the PCFS code to include the
read-only mailbox fixes, as pointed out to be by Jim McKie (and
assisted by "forsyth" mailing me an updated kernel driver).

If anyone wants diffs for the FS driver, I'll happily mail them, they
merely repeat what has been done for B.COM and the non-FS kernels.  It
made me wonder whether the conciseness of the FS kernel makes up for
the tedium of maintenance.  I don't have an answer :-)

Still on the SCSI side, I have a Sony Magneto-Optical drive and lots of
small capacity (280MB x 2) platters and, not having thought much about
it, I wonder how best to configure it; I'm hoping to attach it,
intelligently, to the File Server.  If anyone else has in fact used, or
is still using magneto-optical technology, I'll appreciate any
suggestions on how best to deal with removable media.

I've had a problem with Ethernet adaptors for a while and eventually had to sit down and look into it.  This is what I discovered:

In the "write" function of the NE2000 driver there is some code that depends on the value of the "dummyrr" field of the adaptor data structure.  This causes the DMA destination address to be adjusted, downwards, by one plus the contents of the "card.bit16" value in the same data structure, while the transfer length is adjusted upwards accordingly.

This seems to me to be designed to cater for some extraordinary condition, seeing as there is no obvious way to turn "dummyrr" off (I may well be missing something, I'll get back to that shortly) and the nett effect with the adaptor I'm using is that the function loops endlessly waiting for some value to come up to expectations, which it never does.

Note that a quick browse of equivalent NetBSD driver code doesn't disclose anything along these lines while NetBSD is perfectly comfortable with the adaptors Plan 9 gets jammed on.

I'd like somebody to throw some light on how this peculiar fudge came into being.  I'm also curious as to whether it is at all possible to indicate with some options (the NE2000 driver code checks for the string "nodummyrr", but I can't find any other instance of the tested variable) that the dummyrr condition does not apply.

I have created a kernel with "dummyrr" forced to zero, and it looks more promising, what prompted this message is the necessity now to modify B.COM and the fear that in producing a new B.COM I may lose some functionality which, I seem to recall, is in the version released with the current PC Distribution, but for which sources are not available.

If anyone knows of a mechanism to pass the value "nodummyrr" to the appropriate portion of B.COM, I'd love to hear it.

Many thanks.
--
Lucio de Re (lucio@proxima.alt.za)
Disclaimer: I'm working at getting my opinions to agree with me.