In message <000001be992a$32a51b70$53cb08d4@martins.teuto.de>,
"Martin Husemann" writes:

>> Back when the mcd0 probe used to match *anything* it could blow away
>> the nonvolatile config of some Ethernet cards so badly that even the
>> vendor firmware couldnt find them. It doesnt do that anymore, and it
>> does port accounting. I dont think there's any real reason (besides
>> superstition) not to enable the mcd driver.
>
>Been there, happened to me twice. Charles Hannum fixed my card (I was about
>to buy a new one) - I owe hime at least a beer or a pizza!

Do you know if it's the mcd probe routine or something else in the driver?
Was this before we had port accounting, or after?

The problem with the mcd probe was that mcdfind() would accept *any*
response that didn't cause `mcdsend()' to fail. That meant the mcd
driver would attach itself (not merely probe), then the ed driver
(this was before the frontend split, iirc) would attach itself, and
then the wangtek probe would clobber the we station address.

If I re-enabled mcd0, I'd reorder the device declarations in
sys/dev/isa so that mcd came after the Ethernet drivers--
even though I'm not proposing enabling the wt driver.

>can examine this further. I have a mitsumi CD-Rom and multiple we0 cards -
>as well as  the tools to fix them if it busts them ;-)

Please do.


>The problem was not that simple: the mcd0 probe enabled writes to the SMC
>cards EEPROM and the wt0 probe managed to change its ethernet ID and card
>type field and store it back - wich resulted in a checksum mismatch, so
>neither our driver nor the SMC "ezconfig" DOS tools recognized the card any
>more.

Yep. Thats the one.

>What's needed to check if this is safe? Compile a test kernel with mcd0, wt0
>and we0, check if the probe order is still the same, if not rearange that
>and see if it still happens? 

If we rearrange the probes it cant happen, because all the relevant
drivers now do port accounting.

>Or better do code inspection? I would put this
>on my TODO list after "get my ep0 card to work" (the EISA one, you probably
>remember).

Yes, I remember :)

That would be great. Here's a patch to do all that; the mcd probe is
moved after the MI ISA probes, and the wt probe (which you say is what
acutally clobbers the SMC EEPROM) is moved before the mcd probe
(which say does the write-enable) -- even though I'm not re-enabling wt0.

This moves both mcd (and wt) later in probe order than the we driver.
Since all the drivers now do port accounting, there's no way that the
mcd0 probe in the GENERIC kernel can write to a we device at 0x300:
the we1 device allocates the io-ports first. To trigger the bug, you'd
have to comment out the we at 0x300 and comment in the wt driver.
Which is not significantly different from what you'd have to do now.



--- /sys/dev/isa/files.isa	Tue Mar 23 04:15:19 1999
+++ /sys/dev/isa/files.isa.MCD	Sat May  8 06:14:40 1999
@@ -114,14 +114,9 @@
 
 #
 # Other ISA disk controllers
+# (still more below ISA Ethernet controllers)
 #
 
-# Mitsumi CD-ROM controllers
-device	mcd: disk
-attach	mcd at isa
-file	dev/isa/mcd.c			mcd needs-flag
-defopt	MCD_PROMISC			# enable "promiscuous" match
-
 # Sony CDU-3[13]A CD-ROM drives
 device	scd: disk
 attach	scd at isa
@@ -130,11 +125,6 @@
 attach	wdc at isa with wdc_isa: isadma
 file    dev/isa/wdc_isa.c           	wdc_isa
 
-# Wangtek- and Archive-compatible tape controller boards
-device	wt: tape, isadma
-attach	wt at isa
-file	dev/isa/wt.c			wt needs-flag
-
 #
 # ISA networking drivers
 #
@@ -249,6 +239,22 @@
 attach	tr at isa with tr_isa: tr_isa, elink
 file	dev/isa/if_tribm_isa.c		tr_isa
 file	dev/isa/if_trtcm_isa.c		tr_isa
+
+#
+# ISA disk/CD/tape controllers with invasive probes
+# (can clobber we firmware state if run before we)
+#
+
+# Mitsumi CD-ROM controllers
+device	mcd: disk
+attach	mcd at isa
+file	dev/isa/mcd.c			mcd needs-flag
+defopt	MCD_PROMISC			# enable "promiscuous" match
+
+# Wangtek- and Archive-compatible tape controller boards
+device	wt: tape, isadma
+attach	wt at isa
+file	dev/isa/wt.c			wt needs-flag
 
 #
 # ISA Sound hardware
--- /sys/arch/i386/conf/GENERIC	Thu Apr 29 04:11:24 1999
+++ /sys/arch/i386/conf/GENERIC.MCD	Sat May  8 06:14:51 1999
@@ -411,7 +411,7 @@
 #fd0	at fdc0 drive 0
 
 # ISA CD-ROM devices
-#mcd0	at isa? port 0x300 irq 10	# Mitsumi CD-ROM drives
+mcd0	at isa? port 0x300 irq 10	# Mitsumi CD-ROM drives
 
 # ISA tape devices
 # note: the wt driver conflicts unpleasantly with SMC boards at the