In article <9me2l7$p42$1@inn.qnx.com>, cococr@cs.rpi.edu says…
Right. I don’t have the software to do this, he definitely shouldn’t be
able to. It’s weird, this problem has only popped up with 2 of our
customers. It consistently reproduces itself with those people, each unit
we send ends up the same way. Both have claimed they have a “standard
network setup” (literally, both said the exact same thing).
The card is an SMC1211TX (RTL chipset). I even called SMC to ask them how
just plugging it in to a network could cause the problem and they have no
idea. Definitely a limited fluke no doubt.
I was just looking to see if I can, at least temporarily per boot, set the
ID’s to what they should be so the rest of the software can work without
rewriting parts of it. Using the CA_PCI functions, should I be able to do
this?
I don’t know about the CA_PCI function (I don’t think it can do
anything for you)
If the chipset is the RTL 8029AS, we can maybe write you something to
change the id back… (Since we already have our configuration program
that reads and writes the EEPROM on our card - which is based on an RTL
8029AS )
It wouldn’t be temporary, though. It would change the ID back to what it
should be. (Until they put it into their “standard network setups”
again! You would also have to power off, power on to use the new ID.
“Stephen Munnings” <> steve@cormantech.com> > wrote in message
news:> MPG.15f455ebe5dfb72a9896ab@inn.qnx.com> …
In article <9mdtf1$m97$> 1@inn.qnx.com> >, > cococr@cs.rpi.edu > says…
Hello,
I’ve had this problem with a network card I’m using. A customer
successfully changed the Device ID on all of the network cards we use in
his
network, just by plugging it into his network. I don’t even have the
first
clue as to how this happens, but it does (aren’t they supposed to be
unchangeable?). Anyway, for a while, I put a temporary hack into our
system
Not that unchangeable…
But still - you(he) should not have software to do that, and I would go
to some effort to track down and squash anything that changed the PCI
ids.
It could be some hacker program, or a virus of some sort, or a very badly
written program.
Depending on the card type, we might even be able to change the PCI id’s
back to what they should be… (don’t hold your breath, though! > 
I would also be worried that other important configuration information
was “whacked” by this whacko program (whatever it is)…
Usually a network card has a small EEPROM on it, that contains
configuration information. Depending on the card’s chipset, the PCI
Device and Vendor Id’s are also saved on this chip (or can be overridden
from it). Some chip sets do not allow this kind of disaster to happen
because they do NOT get the Vendor and Device ID from the EEPROM.
to avoid the problem of the network driver not being able to find the
card
in this situation. I hex edited the driver and changed one of the ID
sets
that it scans for to the new combination that gets created. This worked
beautifully.
Now, I have a problem. The network driver supported 2 combinations. It
turns out we’re switching our network card over to the OTHER combination
that I had hex edited out. The amount of code I’d have to change to
pass
the device and vendor ID’s into the driver isn’t too bad, but I was
thinking
of another way. Can I write a device and vendor ID to a PCI device when
I
start up, and will QNX work OK with that? This way I can force the
malformed ID’s to be correct, and the driver will detect it OK and not
complain. I’m thinking of the CA_PCI_Write* functions to set the IDs,
but
I have never done a Write before. Any help is appreciated > 
TIA
Ron
\
Stephen Munnings
Software Developer
Corman Technologies Inc.
\
–
Stephen Munnings
Software Developer
Corman Technologies Inc.