I have recently made the PCNet driver supplied with the DDK and built a
devn-pcnet.so. When I am using the supplied driver file with RtP (dated Oct
13), all three cards are picked up and work. When I try to use the DDK
driver to load into io-net, it fails to pick up any of the three PCNet-based
cards in my PC. Further investigation reveals that the pci_device_find
function fails to find ANY devices of vid 1022, did 2000. Despite “pci”
revealing this to be the did and vid of the three cards.
Mounting the driver using -o"vid=0x1022,did=0x2000" options results in
the index 0 card being set up (as expected) but
trying -o"vid=0x1022,did=0x2000,pci=1" to get the index 1 card results in an
error on device attach. Further to this,
trying -o"vid=0x1022,did=0x2000,pci=1" as the first mount into io-net
actually mounts the index 0 card, which would explain why multiple mounts on
different pci numbers falls over.
However, when using the RtP supplied driver, multiple mounts work and
the correct indexed card is set up. Is there something fundamentally wrong
with the code or am I just missing something obvious?
Part of the problem has been solved. There appears to be a bug in the
source code to the PCNet driver. In the common Nic functions file Nic.c, the
option handling function nic_drvr_options handles a “pci=x” option by
Orequalling(|=) it to the nic->cfg.Device_ID.SerialNum. Unfortunately,
nic->cfg.Device_ID.SerialNum just happens to be 0xFFFFFFFF prior to this
(for me anyway!!) and the result remains unchanged regardless of the value
of the desired PCI index.
I have changed the code to a simple assignment and it works to allow
multiple mounts. Two questions remain:
Is a simple assignment here valid or does the SerialNum have more to
it than the pci index?
This still doesn’t explain why pci_device_find doesn’t work?
I have recently made the PCNet driver supplied with the DDK and built a
devn-pcnet.so. When I am using the supplied driver file with RtP (dated
Oct
13), all three cards are picked up and work. When I try to use the DDK
driver to load into io-net, it fails to pick up any of the three
PCNet-based
cards in my PC. Further investigation reveals that the pci_device_find
function fails to find ANY devices of vid 1022, did 2000. Despite “pci”
revealing this to be the did and vid of the three cards.
Mounting the driver using -o"vid=0x1022,did=0x2000" options results
in
the index 0 card being set up (as expected) but
trying -o"vid=0x1022,did=0x2000,pci=1" to get the index 1 card results in
an
error on device attach. Further to this,
trying -o"vid=0x1022,did=0x2000,pci=1" as the first mount into io-net
actually mounts the index 0 card, which would explain why multiple mounts
on
different pci numbers falls over.
However, when using the RtP supplied driver, multiple mounts work and
the correct indexed card is set up. Is there something fundamentally wrong
with the code or am I just missing something obvious?
I have tried in vain today to load the QNX 6.1.0 Upgrade (to get the DDK
updates) from the repository on my 6.0.0 machine. Are the problems with this
upgrade that are on the other Newsgroups mean it has been temporarily
withdrawn or am I looking in the wrong haystack (WWW repositories)?
The other part of the problem is now solved. In the pcnet_init (init.c)
function where the code checks for a specific pci index being sent as an
option where no did or vid is sent, the value is checked for >=0. The result
of NIC_PCI_INDEX(…) appears to be unsigned so >=0 is always true. Casting
this to an int makes the code work, forcing index to 0 in the else code for
negative indices.
Am I the only one to see this? In which case, do these uninitialised
variables become 0 (rather than ffff…) on everyone elses built driver
except mine?
The other part of the problem is now solved. In the pcnet_init (init.c)
function where the code checks for a specific pci index being sent as an
option where no did or vid is sent, the value is checked for >=0. The result
of NIC_PCI_INDEX(…) appears to be unsigned so >=0 is always true. Casting
this to an int makes the code work, forcing index to 0 in the else code for
negative indices.
Am I the only one to see this? In which case, do these uninitialised
variables become 0 (rather than ffff…) on everyone elses built driver
except mine?
Nope - that is the bug actually. Perhaps I miss-read what your problem
was before but this is the main issue. I forgot to set the index to -1
and I didn’t catch it until after the first beta of the DDK was made.
This shouldn’t be the case in the DDK on the 6.1.0 CDROM.
chris
\
cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
It should be fixed in the DDK’s that