Intel 8255x, DHCP, MII

QNX Newsgroups (Archives) qdn.public.qnxrtp.newuser
1

So I’ve got an Intel 8255x NIC plugged into a Motorola cable modem
through Road Runner. I get told that there’s no response from the MII
transceiver. Eh? Even after a nice crisp cold reboot, no go. The card is
detected 100% by nettrap. No problem there. As far as I know, everything
is detected just spiffy. I slay io-net and run it again, making sure of all
the parameters I am sure of, and I still get the same error.
Oh yeah, and BTW, in Windows98, how do I find my hostname? I find
.xxxx.rr.com, where is the name designated for my
machine on my home LAN. However, my email address is, for instance,
@xxxx.rr.com.
… On another note, when I slay dhcp.client and try restarting it with
the same parameters as which ‘ps’ said it had, it no longer appears in ‘ps’
anymore. Unrelated to the ‘MII’ issue.
Thanks.

–Charles

2

So I’ve got an Intel 8255x NIC plugged into a Motorola cable modem
through Road Runner. I get told that there’s no response from the MII
transceiver. Eh? Even after a nice crisp cold reboot, no go. The card is
detected 100% by nettrap. No problem there. As far as I know, everything
is detected just spiffy. I slay io-net and run it again, making sure of all
the parameters I am sure of, and I still get the same error.

Try not rebooting so crisply. Sometimes a slushier reboot is preferred.

Oh yeah, and BTW, in Windows98, how do I find my hostname? I find
mycomputer>.xxxx.rr.com, where is the name designated for my
machine on my home LAN. However, my email address is, for instance,
mycomputer4>@xxxx.rr.com.

Your hostname is just the part. Your email address has very
little to do with your hostname.

… On another note, when I slay dhcp.client and try restarting it with
the same parameters as which ‘ps’ said it had, it no longer appears in ‘ps’
anymore. Unrelated to the ‘MII’ issue.

It could be that (as far as it’s concerned) the dhcp.client does
it’s job instantly and goes away before you can run `ps’.

I’m configured static now, but I seem to remember when I was
using it, it would come up, do it’s job, and then go away. If things
weren’t tiggety-boo with the NIC, it would hang around for a while and
keep trying.

3

<pete@qnx.com> wrote in message news:9bg6ap$fse$1@inn.qnx.com…

So I’ve got an Intel 8255x NIC plugged into a Motorola cable modem
through Road Runner. I get told that there’s no response from the MII
transceiver. Eh? Even after a nice crisp cold reboot, no go. The card
is
detected 100% by nettrap. No problem there. As far as I know,
everything
is detected just spiffy. I slay io-net and run it again, making sure of
all
the parameters I am sure of, and I still get the same error.

Try not rebooting so crisply. Sometimes a slushier reboot is preferred.
Well, the first time I tried, while the 25M version of QNX was

downloading for Windows I was looking around in the Knowledge Center (I
think it’s called?) looking up all the info I could on setting up a cable
modem through a standard NIC (RR originally installed it through USB…
Hah!). Copied down all the info I could find (love winipcfg for that), and
entered it as I could when I rebooted into QNX. Like I said, nettrap finds
it fine, io-net starts, but it tells me that it can’t find the MII
transceiver. Is this a driver issue, perhaps? So, a reboot out of Win98
into QNX or a cold boot straight into QNX (BIOS setting PnP OS set to NO,
like so many posts say to do), and it won’t go. It’s like the system
finds the card, but it won’t talk to it.

Your hostname is just the part. Your email address has very
little to do with your hostname.
Huh, okay, that’s cool. If I recall, it’s something we entered just for

our LAN; I don’t recall RR giving us a hostname. But the only thing I can
find is that.

It could be that (as far as it’s concerned) the dhcp.client does
it’s job instantly and goes away before you can run `ps’.
So, how come when I first boot in, dhcp.client is there, but when I slay

and attempt to restart it, it’s gone?

I’m configured static now, but I seem to remember when I was
using it, it would come up, do it’s job, and then go away. If things
weren’t tiggety-boo with the NIC, it would hang around for a while and
‘tiggety-boo’? Care to elaborate?

So, technically, if dhcp.client works right, it shouldn’t pop up in
‘ps’. So if upon bootup I’m seeing it, something’s wrong?

keep trying.
Erf. I’m not used to being so… helpless. In Windows, I at least know

where to go and what to change to TRY and make things work. In QNX, I’m
lost. Could this possibly be a symptom of IRQ conflict? (I’m not a
hardware guy; I’m a software guy. My father’s the hardware guy.) How can I
tell what devices are taking what IO ranges and IRQs in QNX?
Thanks!

–Charles

4

Chalz <nospam@chalz-of-internetusa.net> wrote:

It could be that (as far as it’s concerned) the dhcp.client does
it’s job instantly and goes away before you can run `ps’.
So, how come when I first boot in, dhcp.client is there, but when I slay
and attempt to restart it, it’s gone?

If it’s gone, it probably thinks it succeeded. If you read the docs
for it, it says it will retry every minute, so on boot, if the DHCP
request fails the first time, it will wait for a minute before trying
again.

I’m configured static now, but I seem to remember when I was
using it, it would come up, do it’s job, and then go away. If things
weren’t tiggety-boo with the NIC, it would hang around for a while and
‘tiggety-boo’? Care to elaborate?

tiggety-boo == spiffy

So, technically, if dhcp.client works right, it shouldn’t pop up in
‘ps’. So if upon bootup I’m seeing it, something’s wrong?

Yes… I don’t think it’s received the config info.

keep trying.
Erf. I’m not used to being so… helpless. In Windows, I at least know
where to go and what to change to TRY and make things work. In QNX, I’m
lost. Could this possibly be a symptom of IRQ conflict? (I’m not a
hardware guy; I’m a software guy. My father’s the hardware guy.) How can I
tell what devices are taking what IO ranges and IRQs in QNX?
Thanks!

`nicinfo’ will tell you what IRQ and IO range your NIC is using. It will
also tell you if you’re getting and sending packets.

Your NIC may only think it’s sending packets, but if it shows that you
received packets, your NIC is probably working, and you should look elsewhere
to figure out what’s wrong.

5

Hi Chalz,

(Warning: non-QSSL response)

Your “can’t find MII transceiver” is almost certainly a driver/hardware
issue.

The basic NIC chipset (8255x) is “augmented” by an MII transceiver chip.
This chip (MII) can be from a number of different manufacturers and while
they are all supposed to implement a common core of functions mandated by a
spec, they all seem to have their own unique modifications/enhancements,
etc.,
It is almost like having another PnP card within the NIC! The driver
finds/talks to the MII by a serial bus type technique (similar but not
identical to IIC) and the driver usually has to pound a particular register
on the NIC chipset, toggling bits, reading a bit at a time, etc.,
Because each MII can potentially differ from others, the driver also has to
identify which MII chip is in use.
So the problem is likely one of two things…
a. The “bit-pounding” done to talk to the MII is not returning valid info -
i.e. cannot “talk” to MII at all.
b. The MII is active and responding, but the driver is not up to date for
the particular MII chip and does not recognize it.

Hope this helps

Regards

Chalz <nospam@chalz-of-internetusa.net> wrote in message
news:9bgfie$kji$1@inn.qnx.com…

pete@qnx.com> > wrote in message news:9bg6ap$fse$> 1@inn.qnx.com> …
So I’ve got an Intel 8255x NIC plugged into a Motorola cable modem
through Road Runner. I get told that there’s no response from the MII
transceiver. Eh? Even after a nice crisp cold reboot, no go. The
card
is
detected 100% by nettrap. No problem there. As far as I know,
everything
is detected just spiffy. I slay io-net and run it again, making sure
of
all
the parameters I am sure of, and I still get the same error.

Try not rebooting so crisply. Sometimes a slushier reboot is preferred.
Well, the first time I tried, while the 25M version of QNX was
downloading for Windows I was looking around in the Knowledge Center (I
think it’s called?) looking up all the info I could on setting up a cable
modem through a standard NIC (RR originally installed it through USB…
Hah!). Copied down all the info I could find (love winipcfg for that),
and
entered it as I could when I rebooted into QNX. Like I said, nettrap
finds
it fine, io-net starts, but it tells me that it can’t find the MII
transceiver. Is this a driver issue, perhaps? So, a reboot out of Win98
into QNX or a cold boot straight into QNX (BIOS setting PnP OS set to NO,
like so many posts say to do), and it won’t go. It’s like the system
finds the card, but it won’t talk to it.

Your hostname is just the part. Your email address has very
little to do with your hostname.
Huh, okay, that’s cool. If I recall, it’s something we entered just
for
our LAN; I don’t recall RR giving us a hostname. But the only thing I can
find is that.

It could be that (as far as it’s concerned) the dhcp.client does
it’s job instantly and goes away before you can run `ps’.
So, how come when I first boot in, dhcp.client is there, but when I
slay
and attempt to restart it, it’s gone?

I’m configured static now, but I seem to remember when I was
using it, it would come up, do it’s job, and then go away. If things
weren’t tiggety-boo with the NIC, it would hang around for a while and
‘tiggety-boo’? Care to elaborate?
So, technically, if dhcp.client works right, it shouldn’t pop up in
‘ps’. So if upon bootup I’m seeing it, something’s wrong?

keep trying.
Erf. I’m not used to being so… helpless. In Windows, I at least
know
where to go and what to change to TRY and make things work. In QNX, I’m
lost. Could this possibly be a symptom of IRQ conflict? (I’m not a
hardware guy; I’m a software guy. My father’s the hardware guy.) How can
I
tell what devices are taking what IO ranges and IRQs in QNX?
Thanks!

–Charles

6

(Warning: non-QSSL response)
I have no problem with that at all.



Your “can’t find MII transceiver” is almost certainly a driver/hardware
issue.
Yeah, that’s what we (my father and I) figured. It’s his machine. He’s

always been intrigued by QNX; we live like 2hrs from Ottawa.

The basic NIC chipset (8255x) is “augmented” by an MII transceiver chip.
This chip (MII) can be from a number of different manufacturers and while
they are all supposed to implement a common core of functions mandated by
a
spec, they all seem to have their own unique modifications/enhancements,
etc.,
This seems to be a - er - standard problem…



Because each MII can potentially differ from others, the driver also has
to
identify which MII chip is in use.
… And it looks like the driver isn’t doing that. Shy of popping the

machine open and reading chip labels, how can I find the info I need here?
And what do I do with it then?
Hmm… Likely the info would be in the docs, but not sure if he’s got that
on hand.

So the problem is likely one of two things…
a. The “bit-pounding” done to talk to the MII is not returning valid
info -
i.e. cannot “talk” to MII at all.
b. The MII is active and responding, but the driver is not up to date for
the particular MII chip and does not recognize it.
Any recommendations as to what I should do to deal with this? ie, I find

I have a different MII in there than nettrap notices. Then what?
Watch this turn out to be something fixed in Patch B, like the TNT issue.
I need to get a network connection working to get Patch B… erf.

Hope this helps
Me too > :wink: > And thanks.

–Charles

7

If it’s gone, it probably thinks it succeeded. If you read the docs
winces RTFM. Where can I find, specifically, said docs?



for it, it says it will retry every minute, so on boot, if the DHCP
request fails the first time, it will wait for a minute before trying
again.
Step 1 is to find all of the suspects involved, understand how they talk

to each other, and figure out where communications are breaking down. Once
I get all of this, I can tinker with it. So io-net and dhcp.client … next?

weren’t tiggety-boo with the NIC, it would hang around for a while and
‘tiggety-boo’? Care to elaborate?

tiggety-boo == spiffy
Gotcha. Office phraseology? > :wink:



So, technically, if dhcp.client works right, it shouldn’t pop up in
‘ps’. So if upon bootup I’m seeing it, something’s wrong?

Yes… I don’t think it’s received the config info.
And how can I get it to receive said info?



`nicinfo’ will tell you what IRQ and IO range your NIC is using. It will
also tell you if you’re getting and sending packets.
Gotcha. I know what values it /should/ be using… However, it’s also a

matter of what values the other hardware is using.

Your NIC may only think it’s sending packets, but if it shows that you
received packets, your NIC is probably working, and you should look
elsewhere
to figure out what’s wrong.
And if it’s not doing a thing?.. gurgle

8

Hi Chalz,

Chalz <nospam@chalz-of-internetusa.net> wrote in message
news:9bhu4t$i8l$1@inn.qnx.com…

Because each MII can potentially differ from others, the driver also has
to
identify which MII chip is in use.
… And it looks like the driver isn’t doing that. Shy of popping the
machine open and reading chip labels, how can I find the info I need here?
And what do I do with it then?

Well, I know how to write/modify the driver to report the configuration
information coming back from the MII, but for a “normal user”, I think your
only option is to pop the NIC and look at the chips on it. The MII is
usually quite a small 64 pin LQFP (or similar) chip. Some NICs do not have
MII chips, instead they have a simpler chip called a “SYM PHY”. If this is
your case, it is unknown whether your driver could handle this situation or
not. Some drivers would handle it o.k.

After that, you could ask QSSL if they support 8255x NICs with that
particular MII chip…

I am afraid that this does not help you much at all, but might at least help
you understand what is going on.

There is a possibility (unless this card works just fine for another OS)
that the card is “broken”. In which case you have a pretty good idea where
the problem most likely lies! :sunglasses:

Hmm… Likely the info would be in the docs, but not sure if he’s got
that
on hand.

Not likely - most manufacturers do NOT directly document what MII chip they
are using - 99% of users would neither care, nor understand what it meant
anyway.

So the problem is likely one of two things…
a. The “bit-pounding” done to talk to the MII is not returning valid
info -
i.e. cannot “talk” to MII at all.
b. The MII is active and responding, but the driver is not up to date
for
the particular MII chip and does not recognize it.
Any recommendations as to what I should do to deal with this? ie, I
find
I have a different MII in there than nettrap notices. Then what?

Actually (AFAIK) nettrap does not know or care what MII chip is in there -
he only looks for the main NIC chipset.
It is up to the driver (once the correct driver is started) to recognize (or
not) the MII chip and try to use it.
Some drivers (most? all?) have code to handle unrecognized MII chips as
“generic”, but that can still fail if the chip “extends” the spec in the
wrong way…

Watch this turn out to be something fixed in Patch B, like the TNT
issue.
I need to get a network connection working to get Patch B… erf.

Yeah, but I believe that the “older” $10.00 (or less) 10BaseT NICs are
probably supported quite nicely.
Something based on a Realtek 80x9 chipset or other NE2000 compatible chipset
They are not the most efficient performers possible, but they do tend to
work!
You might be able to pick up one of these just to get you connected for
updates.

Hope this helps
Me too > :wink: > And thanks.

You are welcome