Installing QNX 6.2.1NC on a Shuttle PC, QNX does not
bring up the Ethernet controller.
The Ethernet controller never appears in /dev/io-net.
“pci” reports the Ethernet controller on the motherboard
correctly, as Vendor ID 10ec (Realtek), Device ID
8139 (RT8139 Fast Ethernet Controller). That vendor/device
combo is recognized by QNX, which then loads “devn-rtl”,
as it should. But “devn-rtl” produces the log message
“devn-rtl: Unable to mmap_device_memory.”
Slaying “io-net” and starting it manually produces the same
results. Starting “io-net” and specifying the rti driver
doesn’t help. Doing that with “verbose=4” causes the driver
to print the correct values for the vendor and device ID, but
the MAC prints as all zeroes.
I’ve previously run QNX on Shuttle/AMD boxes, with good
results. This box is supposedly identical to the other one
I have. But it won’t run QNX.
John Nagle
Team Overbot
Correction: it runs QNX just fine, except that the
Ethernet controller won’t come up. JN
John Nagle wrote:
Installing QNX 6.2.1NC on a Shuttle PC, QNX does not
bring up the Ethernet controller.
The Ethernet controller never appears in /dev/io-net.
“pci” reports the Ethernet controller on the motherboard
correctly, as Vendor ID 10ec (Realtek), Device ID
8139 (RT8139 Fast Ethernet Controller). That vendor/device
combo is recognized by QNX, which then loads “devn-rtl”,
as it should. But “devn-rtl” produces the log message
“devn-rtl: Unable to mmap_device_memory.”
Slaying “io-net” and starting it manually produces the same
results. Starting “io-net” and specifying the rti driver
doesn’t help. Doing that with “verbose=4” causes the driver
to print the correct values for the vendor and device ID, but
the MAC prints as all zeroes.
I’ve previously run QNX on Shuttle/AMD boxes, with good
results. This box is supposedly identical to the other one
I have. But it won’t run QNX.
John Nagle
Team Overbot
Looking at the differences between the (supposedly identical)
machine that works and the one that doesn’t, I notice that the one that
works has a “devn-rtl.so” dated 1/18/2003, while the
one that doesn’t work has one dated in 2002. Something’s
wrong there.
The one that works was previously running QNX 6.2.0NC,
and was recently upgraded to 6.2.1NC by performing the
upgrade process with the new 6.2.1 NC CD-ROM.
The one that doesn’t work had QNX 6.2.1 NC
installed from the same 6.2.1 NC CD-ROM, but as a
single install onto a blank hard drive.
It looks like the drivers on the QNX 6.2.1 NC
disk’s boot image may be out of sync with those in
the upgrade repository on the same disk.
Please advise.
John Nagle
John Nagle wrote:
Installing QNX 6.2.1NC on a Shuttle PC, QNX does not
bring up the Ethernet controller.
The Ethernet controller never appears in /dev/io-net.
“pci” reports the Ethernet controller on the motherboard
correctly, as Vendor ID 10ec (Realtek), Device ID
8139 (RT8139 Fast Ethernet Controller). That vendor/device
combo is recognized by QNX, which then loads “devn-rtl”,
as it should. But “devn-rtl” produces the log message
“devn-rtl: Unable to mmap_device_memory.”
Slaying “io-net” and starting it manually produces the same
results. Starting “io-net” and specifying the rti driver
doesn’t help. Doing that with “verbose=4” causes the driver
to print the correct values for the vendor and device ID, but
the MAC prints as all zeroes.
I’ve previously run QNX on Shuttle/AMD boxes, with good
results. This box is supposedly identical to the other one
I have. But it won’t run QNX.
John Nagle
Team Overbot
John Nagle <nagle@downside.com> wrote:
Looking at the differences between the (supposedly identical)
machine that works and the one that doesn’t, I notice that the one that
works has a “devn-rtl.so” dated 1/18/2003, while the
one that doesn’t work has one dated in 2002. Something’s
wrong there.
[SNIP]
Hey! You cross posted. Answered elsewhere.
chris
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
Sorry. I posted from two different machines, and the
machines are seeing different sets of QNX newsgroups.
John Nagle
Chris McKillop wrote:
[SNIP]
Hey! You cross posted. Answered elsewhere.
chris
“Chris McKillop” <cdm@qnx.com> wrote in message
news:bbs54f$k8$2@nntp.qnx.com…
John Nagle <> nagle@downside.com> > wrote:
[SNIP]
Hey! You cross posted. Answered elsewhere.
I do understand why you would not want to answer all of the crossposts.
However, could you please tell us in which group you replied?
Thanks,
Steve
Steve Cobb <steve_cobb0@yahoo.com> wrote:
“Chris McKillop” <> cdm@qnx.com> > wrote in message
news:bbs54f$k8$> 2@nntp.qnx.com> …
John Nagle <> nagle@downside.com> > wrote:
[SNIP]
Hey! You cross posted. Answered elsewhere.
I do understand why you would not want to answer all of the crossposts.
However, could you please tell us in which group you replied?
Errrr…I don’t remember? 
chris
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
This discussion continues in
news://inn.qnx.com:119/qdn.public.qnxrtp.installation
This newsgroup is
news://inn.qnx.com:119/qdn.public.installation
I’m not sure what the distinction between the two is.
John Nagle
Animats
Chris McKillop wrote:
Steve Cobb <> steve_cobb0@yahoo.com> > wrote:
“Chris McKillop” <> cdm@qnx.com> > wrote in message
news:bbs54f$k8$> 2@nntp.qnx.com> …
John Nagle <> nagle@downside.com> > wrote:
[SNIP]
Hey! You cross posted. Answered elsewhere.
I do understand why you would not want to answer all of the crossposts.
However, could you please tell us in which group you replied?
Errrr…I don’t remember? >
chris
John Nagle <nagle@downside.com> wrote:
This discussion continues in
news://inn.qnx.com:119/qdn.public.qnxrtp.installation
This newsgroup is
news://inn.qnx.com:119/qdn.public.installation
I’m not sure what the distinction between the two is.
Well, “qnxrtp” stood for ‘QNX Real Time Platform’, and we’re
not marketing anything under that name anymore. (Much of
what was RTP is now QNX Momentics Non Commercial Edition.)
qdn.public.installation was created to replace the .qnxrtp.
version, and .qnxrtp. version was disabled (closed). In fact
all the “deprecated” .qnxrtp. newsgroups were deprecated and
closed – but they were being used, so that closure was reversed,
and now we have some overlapping groups.
Though, the .qnxrtp.installation would tend to be primarily
self-hosted install issues, while the other could also cover
Windows and Solaris hosted install issues.
More than you need to know…
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.