[vortex] Tyan Thunder K7 S2462 Dual 3c59x

[Donald Becker]

On Tue, 15 Jan 2002, Bogdan Costescu wrote:

> Kirk, please read at least the final part of the message...
> On Tue, 15 Jan 2002, Donald Becker wrote:
> 
> > It's not clear that the EEPROM is broken. 
> 
> Sure, as long as there is no specific documentation about these chips. 
> However, if we assume that the documentation for 905C still stands, the 
> content is simply not valid.

I now think that I was wrong: this specific EEPROM is broken or corrupted.

> I'm not debating this. My concern was about cards with invalid EPROM 
> content; in this case, it happened that the invalid EPROM matched this 
> "catch-all" pattern; but what if it didn't ? Your driver would then behave 
> like the LK driver does now.

That's what the EEPROM checksum would be useful for, although 3Com
didn't keep the checksum location the same, or consistently update the
value when programs change the contents.

> I actually wonder what would happen if I would put a DEC-based card PCI ID 
> in this EPROM. Would the tulip driver detect it and try to drive it ?

Yup.  And that would be the proper action.

[[ BTW, I think that EEPROM-set primary PCI IDs are a bad idea.  Only
the subsystem IDs should be updatable.  But vendors want a way to make
their product appear to be unique, even the chip is unchanged. ]]

> To come back to EPROM problems, I modified a bit vortex-diag to be able to 
> save and load an EPROM image file. It's available along with a short 
> description at:
> 
> http://www.iwr.uni-heidelberg.de/groups/biocomp/bogdan/tornado/

Ohhh, watch out for this.  Most *-diag programs implement but disable
the -E option to do an emergency reload.  When I enable it, people use
it without understanding the implications, and usually break their NICs. 

Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
Annapolis MD 21403			410-990-9993