9fans archive / 1997 / 07 / 53 /    prev next

From: Lucio de Re lucio@pro...
Subject: [9fans] SCSI update and NE2000 question
Date: Tue, 15 Jul 1997 17:56:39 +0200

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@pro...)
Disclaimer: I'm working at getting my opinions to agree with me.