network takes 1 minute to start in 6.3

I have a sbc that i have installed qnx 6.3 on. The card has an integrated 82559ER network adapter(which uses the devn-speedo driver). I have set it up with a static IP. After boot, it takes slightly over 1 minute before the network is available.

the problem really seems to be with the io-net command. If I just use netmanager and ifconfig to bring up and down the network and make changes manually, the network comes up and down immediately. Once I slay the io-net process and restart it manually, I have to wait the full minute again for the network to be available.

Are there any arguments I need ot pass to the speedo driver? Are there any timeouts that I need to disable using the io-net command? Here is the command that I have been using so far to start things manually:

io-net -dspeedo vid=0x8086,did=0x1209 -ptcpip

Thanx in advance for any help.

I have narrowed the problem down to either the SBC or the devn-speedo driver. I installed QNX 6.3.0 on 3 other machines laying around the office that use different network chipsets and they all start the network up quickly… so it must not be an issue with QNX.

Next, As I have a handfull of these SBC’s(TME-P3 pc-104), I was able to try all of them and they all have the same problem with the 1 minute delay to start the network. this leads me to believe that it is either the devn-speedo driver, or perhaps some PCI issue inherent with the design of the sbc.

There are a few service packs available for QNX 6.3.0… does anybody know where I can download them? I am beginning to wonder if there might be an upgraded devn-speedo.so driver that I need to install.

Flyznest,

The service pack I’d recommend is SP3 because it’s the latest one obviously.

Also because it’s the only one that can be downloaded as either a SP update to an existing install or a complete O/S install on it’s own (SP1 and SP2 have to be applied to an already existing 6.3 install).

Assuming you’ve purchased the IDE and aren’t using a trial version you can go to QNX’s web site, register your serial number and get access to any of the patches or the full 6.3 SP3 install.

Tim

P.S. Why are you supplying the vid=0x8086,did=0x1209 arguments? Normally I don’t have to supply those when using that driver so it makes me wonder if those arguments cause the slowdown.

Tim,
Unfortunately, I didn’t purchase the IDE. I work for a university on very limited grant money so I qualify to use the non commercial version… is there a way to register as a NC user?

I have tried using the command both with, and without the “vid” and “did” strings and it made no noticeable difference in how networking operates… that idea went through my head as well… It occurred to me today to maybe set the speed and duplex as arguments as well but I have not had a chance to do so.

Thanx for your info

CJ

CJ,

I am running 6.3 SP3 and I use that exact speedo driver on a PC 104 board we have (different manufacturer though).

I just look a look at my devn-speedo.so and the date is something like April 2004. So it hasn’t been updated in a long time. I suspect this is the same one you are running.

Even io-net was last updated in August 2005.

I assume you’ve turned off PlugNPlay O/S in the BIOS of your PC 104 boards.

Tim

as you suspected, my speedo driver is april 30, 2004, but my io-net is may 5, 2005… so it looks like the difference is the io-net… I have a hard time justifying that this is a problem though… I have built various other systems in the past with the same N/C version and had no problems… I can’t recall if I ever used an intel card before… possibly because I have never had any real problems with qnx until now.

I checked in BIOS and indeed, both plug and play O/S and plug and play support are disabled.

I’m beginning to wonder if maybe this is not a network problem, and is possibly a PCI controller problem? maybe there is some sort of bus contention/timeout when io-net first queries for the device? is there some way to test this theory?

This afternoon I will look to see if there is a verbose switch in io-net, and see if it generates anything useful… Maybe I should also pop the CF card off of there, pop on a cdrom, and see if I can get ubuntu to boot and run the network without the same delay.

Thanx again for all of your help.
CJ

CJ,

There is detailed logging for io-net and for the devn-speedo driver. See the doc’s for how to enable logging for both of those.

Then you can view the log info via the sloginfo command.

Tim

Tim,
Sorry for the delay… work had a few emergencies. So loggong is now enabled for both io-net and devn-speedo in its most verbose form… I really like that btw… very powerful little tool for embedded apps… thanx for pointing that out to me.

My result had a bunch of stuff… First a bunch of address and irq stuff for the network card… I’m assuming that these are part of the pci discovery. Their timestamps were all the same. Next, about 1 second later, TCP/IP started… that same second the random number generator came up… About 3 seconds later the card came up in 100M FD mode. 4 seconds later it reported “link down”. 1 minute later it came up in 10 megabit mode… that is the last entry. there is the delay… it takes one minute before the thing reverts to 10M. So its obvious to me that the thing is having problems establishing 100M comm. I looked at the switch and it is definitely a 100M switch.

I forced the card to 10M using the “speed=10,duplex=0” arguments and the thing boots WAY faster… no more delays… 10M will work for the short term but I eventually need the 100M so I tried different switches, different cables, combinations of both… all the while changing settings between 100M and 10M. The result is that on some older switches it will not connect at all… but otherwise it gives the same results on everything. I tried all of the PC/104 cards that I have(all the same model) and they all have the same issue…

so I’m still stuck… Boot time is better and I have something usable for the short term… but now I have a speed issue.

any more ideas?

6.3 is VERY old and many bugs were fixed since then.

ok… the software vs hardware debate just got a little hotter. As you can see from this post, this problem has been plaguing me for quite a while, all the while I have been getting SERIOUS GRIEF. well… it turns out that this was a hardware problem… This particular SBC does not have a female rj45 onboard… it has a tiny little bulkhead connector. The SBC came with a 6" long rj45 pigtail. The EE on my team decided to clip the bulkhead off and butt splice it to a longer cable… He did a nice clean job too so I would have never known had I not looked at the manual and seen that it came with a 6" pigtail, and what I had in my hand was 18". We have 5 of these SBC’s and he modified 4 of the pigtails so they all looked the same so the idea never occurred to me. This afternoon, after a while of pestering him, I finally got the EE to give me the only remaining original pigtail… and guess what… I have 100M link and boot time is FAST… Bastard owes me… he has been hovering over me like I am holding up the project for a MONTH… all the while telling me qnx was a bad choice…

Flyznest,

I hope for your sake that the EE didn’t throw out all those original pigtails. And make sure he buys you a couple of beer!

Tim