[net.bugs.4bsd] retraction on uda.c bug

sid@linus.UUCP (Sid Stuart) (04/17/84)

Please ignore the bug anouncement I sent out about the uda.c code.
The original problem arose because of a mistake I made. It is a long
and sordid tale, but here it goes.

	In configuing our 4.2 system, I took the configuration guide's advice
and picked up one of the sample configurations to modify to fit our layout.
I picked the ANSEL configuration file because it had uda's configured.
It turns out that the csr ANSEL has defined for the uda is 160340,
a standard csr for dmf controllers. Since the system came up correctly,
I thought that the csr for the uda was specified correctly in the
conf file. I did not know
that the uda driver had a list of standard uda csr's that it would try in the
case that the specified csr was incorrect. I also did not notice that
the csr in the conf file differed from the csr that was found.

	When we stuck our Emulex dmf board in the unibus, configured
with the standard dmf csr of 160340, autoconfig saw the dmf and said,
ahah! here is the uda that supposed to be out here, stored the dmf's
csr as the uda's csr and then
printed it on the console. I did not see that the uda's
csr was changed when the dmf board was in. I feel stupid for not catching
that. So the uda driver thought that the uda was at 160340 and sent the
message to initialize the uda to that csr. Then the driver waited for
the status register to change, forever.

	It would be nice to have the probe routine in uda.c check
to see if it really is a uda that has been found. It would
be nice to have autoconf mention to you that it has found
a different csr from that specified. It would also
be nice if udinit timed out of its wait for the register change
and sent a message to the console about it. That would have saved
me two days of inserting printfs. But that would make the kernal
larger and the 4.2 kernal is large enough. Anyway, the initial error
in not double checking the csr for the uda was mine. I want
to apologize to the net for boring you with my troubles, and
worrying you with my erroneous bug reports.


			sid at linus