Network Problems.

bridged with qdn.public.qnx4
Len Meakin

Re: Network Problems.

Post by Len Meakin » Fri Oct 31, 2003 10:51 am

Hugh Brown wrote:
As I said before, this is a problem with the NE2000 chip and not the driver.
The driver has no way of knowing whether there is a link or not with this
chipset. The newer 10/100 chipsets have a PHY that you can probe to tell
whether there is a link or not. There is no way with the NE2000 chipset that
you can probe the link status before transmitting a packet.
OK, I now understand the problem is with the chip (finally got that one
into my head). My solution of slaying the Net.ether1000 driver on a
connection failure and restarting it seems to do the trick, with the
exception of only being able to do this a certain number of times. I
have now found out the reason for the limited number of restarts. Every
time I slay / restart the Net.ether1000 driver the Net process is
creating a timer. These timers are building up, until the system limit
is reached and then bingo no more restarts are possible and all system
timers are used.

Now I would slay the entire network and restart it, but this takes way
too much time to perform (3 network drivers, detecting which one is
being used for the main network connection...). The simple slaying and
restarting of the Net.ether1000 driver is much quicker and more
desirable. So is there a way to cleanly unregister a driver from the Net
process. I have taken out the code that attempts a connection to the
un-powered device, and these times are still created so I guess the
drivers are not being unregistered from the Net process.

If it is not possible to cleanly unregister with the Net process then
would it be possible for me to write an app that resets the card upon a
connection failure. And would doing this while the Net.ether1000 driver
is running upset the driver in any way?

Thank you.
Len.

Hugh Brown

Re: Network Problems.

Post by Hugh Brown » Fri Oct 31, 2003 2:44 pm

I have been running the following script for over an hour, without any
problems.
slay -f Net.ether905.424N Net.ether1000 Tcpip

sleep 1

Net.ether1000 -p320 -i7 &

Net.ether905 -l2 &

sleep 1

Tcpip hsb

ifconfig en1 10.30

while true; do

slay -f Net.ether1000

sleep 1

Net.ether1000 -p320 -i7 &

sleep 3

ping -c3 10.90

done

Net and its drivers do not create timers, they connect directly to the timer
interrupt, so I don't understand you saying that you are running out of
timers!

"Len Meakin" <len.m@incubus.co.uk_REMOVE> wrote in message
news:bntdut$kc4$1@inn.qnx.com...
Hugh Brown wrote:
As I said before, this is a problem with the NE2000 chip and not the
driver.
The driver has no way of knowing whether there is a link or not with
this
chipset. The newer 10/100 chipsets have a PHY that you can probe to tell
whether there is a link or not. There is no way with the NE2000 chipset
that
you can probe the link status before transmitting a packet.


OK, I now understand the problem is with the chip (finally got that one
into my head). My solution of slaying the Net.ether1000 driver on a
connection failure and restarting it seems to do the trick, with the
exception of only being able to do this a certain number of times. I
have now found out the reason for the limited number of restarts. Every
time I slay / restart the Net.ether1000 driver the Net process is
creating a timer. These timers are building up, until the system limit
is reached and then bingo no more restarts are possible and all system
timers are used.

Now I would slay the entire network and restart it, but this takes way
too much time to perform (3 network drivers, detecting which one is
being used for the main network connection...). The simple slaying and
restarting of the Net.ether1000 driver is much quicker and more
desirable. So is there a way to cleanly unregister a driver from the Net
process. I have taken out the code that attempts a connection to the
un-powered device, and these times are still created so I guess the
drivers are not being unregistered from the Net process.

If it is not possible to cleanly unregister with the Net process then
would it be possible for me to write an app that resets the card upon a
connection failure. And would doing this while the Net.ether1000 driver
is running upset the driver in any way?

Thank you.
Len.







Hugh Brown

Re: Network Problems.

Post by Hugh Brown » Fri Oct 31, 2003 2:57 pm

To follow up.

OK, I've just had the "No free timers" in traceinfo. I guess this must be
something to do with Tcpip.

"Hugh Brown" <hsbrown@qnx.com> wrote in message
news:bntqv2$ssd$1@inn.qnx.com...
I have been running the following script for over an hour, without any
problems.
slay -f Net.ether905.424N Net.ether1000 Tcpip

sleep 1

Net.ether1000 -p320 -i7 &

Net.ether905 -l2 &

sleep 1

Tcpip hsb

ifconfig en1 10.30

while true; do

slay -f Net.ether1000

sleep 1

Net.ether1000 -p320 -i7 &

sleep 3

ping -c3 10.90

done

Net and its drivers do not create timers, they connect directly to the
timer
interrupt, so I don't understand you saying that you are running out of
timers!

"Len Meakin" <len.m@incubus.co.uk_REMOVE> wrote in message
news:bntdut$kc4$1@inn.qnx.com...
Hugh Brown wrote:
As I said before, this is a problem with the NE2000 chip and not the
driver.
The driver has no way of knowing whether there is a link or not with
this
chipset. The newer 10/100 chipsets have a PHY that you can probe to
tell
whether there is a link or not. There is no way with the NE2000
chipset
that
you can probe the link status before transmitting a packet.


OK, I now understand the problem is with the chip (finally got that one
into my head). My solution of slaying the Net.ether1000 driver on a
connection failure and restarting it seems to do the trick, with the
exception of only being able to do this a certain number of times. I
have now found out the reason for the limited number of restarts. Every
time I slay / restart the Net.ether1000 driver the Net process is
creating a timer. These timers are building up, until the system limit
is reached and then bingo no more restarts are possible and all system
timers are used.

Now I would slay the entire network and restart it, but this takes way
too much time to perform (3 network drivers, detecting which one is
being used for the main network connection...). The simple slaying and
restarting of the Net.ether1000 driver is much quicker and more
desirable. So is there a way to cleanly unregister a driver from the Net
process. I have taken out the code that attempts a connection to the
un-powered device, and these times are still created so I guess the
drivers are not being unregistered from the Net process.

If it is not possible to cleanly unregister with the Net process then
would it be possible for me to write an app that resets the card upon a
connection failure. And would doing this while the Net.ether1000 driver
is running upset the driver in any way?

Thank you.
Len.









Bill Caroselli

Re: Network Problems.

Post by Bill Caroselli » Fri Oct 31, 2003 4:54 pm

Hugh Brown <hsbrown@qnx.com> wrote:
HB > I have been running the following script for over an hour, without any
HB > problems.
HB > slay -f Net.ether905.424N Net.ether1000 Tcpip

Not that this is related to your problem, but you should slay Tcpip
and any other clients of the Net drivers *before* the network drivers.

Len Meakin

Re: Network Problems.

Post by Len Meakin » Fri Oct 31, 2003 8:27 pm

It was definatley Net using all system timers, as the output from "sin rt"
showed loads of timers for the Net process. The "osinfo" app showed
the system timers going up everytime the Net.ether1000 driver was being
slayed and restarted.

As I'm not currently at work I can not post the output from "sin rt" but
will do so first thing Monday morning if required.

Thank you,
Len.

On Fri, 31 Oct 2003 09:57:37 -0500, Hugh Brown
wrote:
To follow up.

OK, I've just had the "No free timers" in traceinfo. I guess this must be
something to do with Tcpip.

"Hugh Brown" <hsbrown@qnx.com> wrote in message
news:bntqv2$ssd$1@inn.qnx.com...
I have been running the following script for over an hour, without any
problems.
slay -f Net.ether905.424N Net.ether1000 Tcpip

sleep 1

Net.ether1000 -p320 -i7 &

Net.ether905 -l2 &

sleep 1

Tcpip hsb

ifconfig en1 10.30

while true; do

slay -f Net.ether1000

sleep 1

Net.ether1000 -p320 -i7 &

sleep 3

ping -c3 10.90

done

Net and its drivers do not create timers, they connect directly to the
timer
interrupt, so I don't understand you saying that you are running out of
timers!

"Len Meakin" <len.m@incubus.co.uk_REMOVE> wrote in message
news:bntdut$kc4$1@inn.qnx.com...
Hugh Brown wrote:
As I said before, this is a problem with the NE2000 chip and not the
driver.
The driver has no way of knowing whether there is a link or not with
this
chipset. The newer 10/100 chipsets have a PHY that you can probe to
tell
whether there is a link or not. There is no way with the NE2000
chipset
that
you can probe the link status before transmitting a packet.


OK, I now understand the problem is with the chip (finally got that one
into my head). My solution of slaying the Net.ether1000 driver on a
connection failure and restarting it seems to do the trick, with the
exception of only being able to do this a certain number of times. I
have now found out the reason for the limited number of restarts. Every
time I slay / restart the Net.ether1000 driver the Net process is
creating a timer. These timers are building up, until the system limit
is reached and then bingo no more restarts are possible and all system
timers are used.

Now I would slay the entire network and restart it, but this takes way
too much time to perform (3 network drivers, detecting which one is
being used for the main network connection...). The simple slaying and
restarting of the Net.ether1000 driver is much quicker and more
desirable. So is there a way to cleanly unregister a driver from the Net
process. I have taken out the code that attempts a connection to the
un-powered device, and these times are still created so I guess the
drivers are not being unregistered from the Net process.

If it is not possible to cleanly unregister with the Net process then
would it be possible for me to write an app that resets the card upon a
connection failure. And would doing this while the Net.ether1000 driver
is running upset the driver in any way?

Thank you.
Len.









Hugh Brown

Re: Network Problems.

Post by Hugh Brown » Mon Nov 03, 2003 1:33 pm

This is NOT Net.ether1000 that is causing the problem. As I said before,
neither the network drivers nor Net create any timers. All Net services,
divers and Tcpip are all aliased to Net, so it appears as though Net.is
creating the timers, when in fact it is Tcpip that is creating the timers.
You will have to slay Net to remove all the timers.

"Len Meakin" <len.m@incubus.co.uk_REMOVE> wrote in message
news:pan.2003.10.31.20.26.46.181561@incubus.co.uk_REMOVE...
It was definatley Net using all system timers, as the output from "sin rt"
showed loads of timers for the Net process. The "osinfo" app showed
the system timers going up everytime the Net.ether1000 driver was being
slayed and restarted.

As I'm not currently at work I can not post the output from "sin rt" but
will do so first thing Monday morning if required.

Thank you,
Len.

On Fri, 31 Oct 2003 09:57:37 -0500, Hugh Brown
wrote:

To follow up.

OK, I've just had the "No free timers" in traceinfo. I guess this must
be
something to do with Tcpip.

"Hugh Brown" <hsbrown@qnx.com> wrote in message
news:bntqv2$ssd$1@inn.qnx.com...
I have been running the following script for over an hour, without any
problems.
slay -f Net.ether905.424N Net.ether1000 Tcpip

sleep 1

Net.ether1000 -p320 -i7 &

Net.ether905 -l2 &

sleep 1

Tcpip hsb

ifconfig en1 10.30

while true; do

slay -f Net.ether1000

sleep 1

Net.ether1000 -p320 -i7 &

sleep 3

ping -c3 10.90

done

Net and its drivers do not create timers, they connect directly to the
timer
interrupt, so I don't understand you saying that you are running out of
timers!

"Len Meakin" <len.m@incubus.co.uk_REMOVE> wrote in message
news:bntdut$kc4$1@inn.qnx.com...
Hugh Brown wrote:
As I said before, this is a problem with the NE2000 chip and not
the
driver.
The driver has no way of knowing whether there is a link or not
with
this
chipset. The newer 10/100 chipsets have a PHY that you can probe to
tell
whether there is a link or not. There is no way with the NE2000
chipset
that
you can probe the link status before transmitting a packet.


OK, I now understand the problem is with the chip (finally got that
one
into my head). My solution of slaying the Net.ether1000 driver on a
connection failure and restarting it seems to do the trick, with the
exception of only being able to do this a certain number of times. I
have now found out the reason for the limited number of restarts.
Every
time I slay / restart the Net.ether1000 driver the Net process is
creating a timer. These timers are building up, until the system
limit
is reached and then bingo no more restarts are possible and all
system
timers are used.

Now I would slay the entire network and restart it, but this takes
way
too much time to perform (3 network drivers, detecting which one is
being used for the main network connection...). The simple slaying
and
restarting of the Net.ether1000 driver is much quicker and more
desirable. So is there a way to cleanly unregister a driver from the
Net
process. I have taken out the code that attempts a connection to the
un-powered device, and these times are still created so I guess the
drivers are not being unregistered from the Net process.

If it is not possible to cleanly unregister with the Net process then
would it be possible for me to write an app that resets the card upon
a
connection failure. And would doing this while the Net.ether1000
driver
is running upset the driver in any way?

Thank you.
Len.










Len Meakin

Re: Network Problems.

Post by Len Meakin » Tue Nov 04, 2003 1:51 pm

Hugh Brown wrote:
This is NOT Net.ether1000 that is causing the problem. As I said before,
neither the network drivers nor Net create any timers. All Net services,
divers and Tcpip are all aliased to Net, so it appears as though Net.is
creating the timers, when in fact it is Tcpip that is creating the timers.
You will have to slay Net to remove all the timers.
Just for your information, I have been running the following script,
note just starting Net then starting and stopping the Net.ether1000
driver. Timers are still growing for the Net process and Socklet is NOT
running neither are any network services as far as I can see.

#-----------------------------------------------------------------------------
echo "Stopping Currently Running Network Drivers..."
slay Net Air350 Socklet pccard SMBfsys inetd 1>/dev/null 2>&1
sleep 2

echo "Starting pccard Server..."
pccard
sleep 5

echo "Starting Net Server..."
Net -T -d3 &

echo "Starting Ether1000 Driver..."
Net.ether1000 -p280 -i0 -l1 &

#-----------------------------------------------------------------------------

nettry=20
while [ nettry -gt 0 ]; do
if [ "$(sin | grep -sc Net\.*RECV)" -ge "2" ]; then
break;
fi
let nettry=nettry-1
sleep 1
done

loop=1
while true ; do
echo "*** Loop $loop ***"
let loop=loop+1

slay Net.ether1000
sleep 1
Net.ether1000 -p280 -i0 -l1 &
sleep 2
echo "Number of Net Timers: $(sin rt | grep -sc Net)"
done

#-----------------------------------------------------------------------------


Output from sin:
SID PID PROGRAM PRI STATE BLK CODE DATA
-- -- Microkernel --- ----- --- 10537 0
0 1 sys/Proc32 30f READY --- 118k 864k
0 2 sys/Slib32 10r RECV 0 53k 4096
0 4 /bin/Fsys 29r RECV 0 77k 13758k
0 5 /bin/Fsys.eide 22r RECV 0 61k 114k
0 8 idle 0r READY --- 0 1351k
0 16 //1/bin/Dev32 24f RECV 0 32k 86k
0 19 //1/bin/Dev32.ansi 20r RECV 0 40k 126k
0 34 //1/bin/Dev32.pty 20r RECV 0 12k 32k
0 36 //1/bin/Pipe 10r RECV 0 16k 40k
0 39 //1/bin/tinit 10o WAIT -1 4096 28k
1 49 //1/bin/ksh 10o REPLY 16 47k 118k
0 255 //1/usr/bin/int10 24r RECV 0 65k 65k
0 256 //1/bin/Dev32.ser 20r RECV 0 16k 32k
0 262 //1/bin/tinit 10o WAIT -1 4096 28k
0 264 //1/bin/tinit 10o WAIT -1 4096 28k
2 474 //1/bin/login 10o REPLY 16 4915 24k
3 475 //1/bin/login 10o REPLY 16 4915 24k
4 476 //1/bin/login 10o REPLY 16 4915 24k
5 477 //1/bin/login 10o REPLY 16 4915 24k
6 478 //1/bin/login 10o REPLY 16 4915 24k
0 5323 //1/bin/tinit 10o WAIT -1 4096 28k
7 5324 //1/bin/ksh 10o WAIT -1 47k 118k
7 14198 //1/bin/sin 10o REPLY 1 45k 49k

Just wondering what your thoughts are on this.

Len.

Hugh Brown

Re: Network Problems.

Post by Hugh Brown » Tue Nov 04, 2003 8:28 pm

OK, I forgot about delay() creating timers, so this is what is causing the
timer count to increase.

If this is a show-stopper for you, I suggest that you contact your sales
rep. and request the source for the Ether1000 driver.

"Len Meakin" <len.m@incubus.co.uk_REMOVE> wrote in message
news:bo89vn$50o$1@inn.qnx.com...
Hugh Brown wrote:
This is NOT Net.ether1000 that is causing the problem. As I said before,
neither the network drivers nor Net create any timers. All Net services,
divers and Tcpip are all aliased to Net, so it appears as though Net.is
creating the timers, when in fact it is Tcpip that is creating the
timers.
You will have to slay Net to remove all the timers.


Just for your information, I have been running the following script,
note just starting Net then starting and stopping the Net.ether1000
driver. Timers are still growing for the Net process and Socklet is NOT
running neither are any network services as far as I can see.


#---------------------------------------------------------------------------
--
echo "Stopping Currently Running Network Drivers..."
slay Net Air350 Socklet pccard SMBfsys inetd 1>/dev/null 2>&1
sleep 2

echo "Starting pccard Server..."
pccard
sleep 5

echo "Starting Net Server..."
Net -T -d3 &

echo "Starting Ether1000 Driver..."
Net.ether1000 -p280 -i0 -l1 &


#---------------------------------------------------------------------------
--
nettry=20
while [ nettry -gt 0 ]; do
if [ "$(sin | grep -sc Net\.*RECV)" -ge "2" ]; then
break;
fi
let nettry=nettry-1
sleep 1
done

loop=1
while true ; do
echo "*** Loop $loop ***"
let loop=loop+1

slay Net.ether1000
sleep 1
Net.ether1000 -p280 -i0 -l1 &
sleep 2
echo "Number of Net Timers: $(sin rt | grep -sc Net)"
done


#---------------------------------------------------------------------------
--

Output from sin:
SID PID PROGRAM PRI STATE BLK CODE DATA
-- -- Microkernel --- ----- --- 10537 0
0 1 sys/Proc32 30f READY --- 118k 864k
0 2 sys/Slib32 10r RECV 0 53k 4096
0 4 /bin/Fsys 29r RECV 0 77k 13758k
0 5 /bin/Fsys.eide 22r RECV 0 61k 114k
0 8 idle 0r READY --- 0 1351k
0 16 //1/bin/Dev32 24f RECV 0 32k 86k
0 19 //1/bin/Dev32.ansi 20r RECV 0 40k 126k
0 34 //1/bin/Dev32.pty 20r RECV 0 12k 32k
0 36 //1/bin/Pipe 10r RECV 0 16k 40k
0 39 //1/bin/tinit 10o WAIT -1 4096 28k
1 49 //1/bin/ksh 10o REPLY 16 47k 118k
0 255 //1/usr/bin/int10 24r RECV 0 65k 65k
0 256 //1/bin/Dev32.ser 20r RECV 0 16k 32k
0 262 //1/bin/tinit 10o WAIT -1 4096 28k
0 264 //1/bin/tinit 10o WAIT -1 4096 28k
2 474 //1/bin/login 10o REPLY 16 4915 24k
3 475 //1/bin/login 10o REPLY 16 4915 24k
4 476 //1/bin/login 10o REPLY 16 4915 24k
5 477 //1/bin/login 10o REPLY 16 4915 24k
6 478 //1/bin/login 10o REPLY 16 4915 24k
0 5323 //1/bin/tinit 10o WAIT -1 4096 28k
7 5324 //1/bin/ksh 10o WAIT -1 47k 118k
7 14198 //1/bin/sin 10o REPLY 1 45k 49k

Just wondering what your thoughts are on this.

Len.

Len Meakin

Re: Network Problems.

Post by Len Meakin » Fri Nov 14, 2003 7:59 am

Hugh Brown wrote:
OK, I forgot about delay() creating timers, so this is what is causing the
timer count to increase.

If this is a show-stopper for you, I suggest that you contact your sales
rep. and request the source for the Ether1000 driver.
Thank you for all your help in this matter. I have now written a driver
that solves the issues I was having. Now the only thing that I'm having
problems with is that my driver will only accept packets if I put the
NIC in promiscuous mode. Now this doesn't really affect it for what we
are using it with (only one thing on it's network), but I would like to
know how to solve this (don't like leaving things unfinished).

I'm setting the Multicast Address to
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
and the Receive Configuration Register [0x0C] to 0x04 (Accept Broadcast)

I have also tried setting the Receive Configuration Register to 0x0C
(Accept Broadcast | Accept Multicast)

But the only thing that seems to work is 0x1C (Accept Broadcast | Accept
Multicast | Promiscuous Physical).

Once again thanks for your time.
Len.

Len Meakin

Re: Network Problems.

Post by Len Meakin » Mon Nov 17, 2003 8:04 am

Len Meakin wrote:
Hugh Brown wrote:

OK, I forgot about delay() creating timers, so this is what is causing
the
timer count to increase.

If this is a show-stopper for you, I suggest that you contact your sales
rep. and request the source for the Ether1000 driver.


Thank you for all your help in this matter. I have now written a driver
that solves the issues I was having. Now the only thing that I'm having
problems with is that my driver will only accept packets if I put the
NIC in promiscuous mode. Now this doesn't really affect it for what we
are using it with (only one thing on it's network), but I would like to
know how to solve this (don't like leaving things unfinished).

I'm setting the Multicast Address to
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
and the Receive Configuration Register [0x0C] to 0x04 (Accept Broadcast)

I have also tried setting the Receive Configuration Register to 0x0C
(Accept Broadcast | Accept Multicast)

But the only thing that seems to work is 0x1C (Accept Broadcast | Accept
Multicast | Promiscuous Physical).

Once again thanks for your time.
Len.
It's OK I have now sorted it ... here ends this thread =))

Len.

Post Reply

Return to “qdn.public.qnx4”