Project Home
Project Home
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
BroadcastCommunity.qnx.com will be offline from May 31 6:00pm until June 2 12:00AM for upcoming system upgrades. For more information please go to https://community.qnx.com/sf/discussion/do/listPosts/projects.bazaar/discussion.bazaar.topc28418
Forum Topic - Udp packet lost: Page 1 of 2 (51 Items)
   
Udp packet lost  
Hello Friends.

I had very strange issue recently. I have two embedded computers (vp7 and vp9). Vp9 machine have intel i82544 network 
adapter , on the vp7 machine - pcnet32.
Qnx version 6.4.0.

On the vp9 machine I don't lost udp packets, but on vp7 I regulary lost packets.

If I invoke "pidin -p io-pkt-v4-hc mem" I see , that pcnet32 network driver (devn-pcnet.so) is work via devnp-shim.so. 
But on vp9 machine network adapter (devnp-i82544.so) work without devnp-shim.so. May be this is a core of the problem???
 And how I can play with network adapter options??????????
Re: Udp packet lost  
The devnp-shim.so is required for the pcnet driver as is is an io-net
driver. The e1000 driver is an io-pkt driver and doesn't require the shim.
The pcnet driver is a 10/100 driver, so if you are trying to push lots of
UDP packets through it, you could quite easily drop packets.




On 2012-11-27 9:35 PM, "Oleg Gopov" <community-noreply@qnx.com> wrote:

>Hello Friends.
>
>I had very strange issue recently. I have two embedded computers (vp7 and
>vp9). Vp9 machine have intel i82544 network adapter , on the vp7 machine
>- pcnet32.
>Qnx version 6.4.0.
>
>On the vp9 machine I don't lost udp packets, but on vp7 I regulary lost
>packets.
>
>If I invoke "pidin -p io-pkt-v4-hc mem" I see , that pcnet32 network
>driver (devn-pcnet.so) is work via devnp-shim.so. But on vp9 machine
>network adapter (devnp-i82544.so) work without devnp-shim.so. May be this
>is a core of the problem??? And how I can play with network adapter
>options??????????
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post97532
>To cancel your subscription to this discussion, please e-mail
>drivers-networking-unsubscribe@community.qnx.com

Re: Udp packet lost  
I see nicinfo output - > pcnet32 network adapter work in half-duplex. How I can lost packets??? I don't understand.
Re: Udp packet lost  
And out traffic is light.
Re: Udp packet lost  
And our network traffic is light
Re: Udp packet lost  
Oleg,

please provide a kernel trace showing the status of the interrupt used 
by the ethernet driver (and probably shared by other devices).

--Armin



Oleg Gopov wrote:
> And our network traffic is light
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post97595
> To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com
>

Re: Udp packet lost  
> 
> Oleg,
> 
> please provide a kernel trace showing the status of the interrupt used 
> by the ethernet driver (and probably shared by other devices).
> 
> --Armin
> 
> 
> 
> Oleg Gopov wrote:
> > And our network traffic is light
> >
> >
> >
> > _______________________________________________
> >
> > Networking Drivers
> > http://community.qnx.com/sf/go/post97595
> > To cancel your subscription to this discussion, please e-mail drivers-
> networking-unsubscribe@community.qnx.com
> >
> 

How I can make kernel trace????? Please, suggest.
Re: Udp packet lost  
Oleg Gopov wrote:
>> How I can make kernel trace????? Please, suggest.

Please RTFM -> tracelogger 
->http://www.qnx.com/developers/docs/6.4.1/neutrino/utilities/t/tracelogger.html

--Armin

Re: Udp packet lost  
I had write kernel log. I attach tracebuffer.kev file.

I noticed another feature. If I invoke "sloginfo -w -c" then I have three times in second 
message -> "pcnet memory error" 
Attachment: Text tracebuffer.kev 11.66 MB
Re: Udp packet lost  
Maybe someone have pcnet32 network adapter sources. What is the case when "pcnet memory error" message generated?????? 
Re: Udp packet lost  
I invoke "top" command and see that 28M of memory are available.
Re: Udp packet lost  
Oleg Gopov wrote:
> I had write kernel log. I attach tracebuffer.kev file.
>
> I noticed another feature. If I invoke "sloginfo -w -c" then I have three times in second
> message -> "pcnet memory error"

You have a corrupted board sharing the same IRQ with io-usb -> that's 
the best wayto loose interrupts.
io-usb is known for blocking/disabling its (shared) interrupt for a 
longer time !

--Armin

Re: Udp packet lost  
Ok, Armin. I will try to "slay io-usb" or disable usb from bios. I will write results to this post.
Re: Udp packet lost  
Oleg Gopov wrote:
> Ok, Armin. I will try to "slay io-usb" or disable usb from bios. I will write results to this post.
     Yes, this would be very interesting !

--Armin

>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post98301
> To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com
>

Re: Udp packet lost  
> You have a corrupted board sharing the same IRQ with io-usb -> that's 
> the best wayto loose interrupts.
> io-usb is known for blocking/disabling its (shared) interrupt for a 
> longer time !
> 
> --Armin
> 
But, Armin. How You conclude this??? You find out issue in tracebuffer.kev file??????????
I analyze tracelog and see that io-usb thread eat processor time only ~ 30us. Nothing criminal in that.
 
Re: Udp packet lost  
Oleg Gopov wrote:
>> You have a corrupted board sharing the same IRQ with io-usb -> that's
>> the best wayto loose interrupts.
>> io-usb is known for blocking/disabling its (shared) interrupt for a
>> longer time !
>>
>> --Armin
>>
> But, Armin. How You conclude this??? You find out issue in tracebuffer.kev file??????????
> I analyze tracelog and see that io-usb thread eat processor time only ~ 30us.
Using the CPU has nothing to with a false handling of the interrupt !!!!
A disabled interrupt remains disabled if you use the CPU ot not ...

Yes, USB is not very active in your case ... but what about the error 
messages related to the hardware of ethernet board ????
Isn't it criminal ??

> Nothing criminal in that.
>   
>
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post98305
> To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com
>

Re: Udp packet lost  
> Using the CPU has nothing to with a false handling of the interrupt !!!!
> A disabled interrupt remains disabled if you use the CPU ot not ...
> 
> Yes, USB is not very active in your case ... but what about the error 
> messages related to the hardware of ethernet board ????
> Isn't it criminal ??

Ok. Then, How you conclude that io-usb share interrupt with network driver?????????

Re: Udp packet lost  
Oleg Gopov wrote:
>> Using the CPU has nothing to with a false handling of the interrupt !!!!
>> A disabled interrupt remains disabled if you use the CPU ot not ...
>>
>> Yes, USB is not very active in your case ... but what about the error
>> messages related to the hardware of ethernet board ????
>> Isn't it criminal ??
> Ok. Then, How you conclude that io-usb share interrupt with network driver?????????

t:0xe875a9f0 CPU:00 INT_ENTR:0x00000000 (0)       IP:0xf007dbd6
t:0xe875ab69 CPU:00 INT_HANDLER_ENTR:0x00000000 (0)       pkt-mgr 
IP:0x080b7a34 AREA:0x0812baa0
t:0xe875af0f CPU:00 INT_HANDLER_EXIT:0x00000000 (0) SIGEVENT:NONE
t:0xe875b1b2 CPU:00 INT_HANDLER_ENTR:0x00000000 (0)       PID:1 
IP:0xf0052620 AREA:0x00000000
t:0xe875b545 CPU:00 INT_HANDLER_EXIT:0x00000000 (0) SIGEVENT:NONE
t:0xe875b82e CPU:00 INT_EXIT:0x00000000 (0) inkernel:0x00000001
t:0xe87d4ed9 CPU:00 INT_ENTR:0x00000000 (0)       IP:0xf007dbd6
t:0xe87d4ff7 CPU:00 INT_HANDLER_ENTR:0x00000000 (0)       pkt-mgr 
IP:0x080b7a34 AREA:0x0812baa0
t:0xe87d52e5 CPU:00 INT_HANDLER_EXIT:0x00000000 (0) SIGEVENT:NONE
t:0xe87d5527 CPU:00 INT_HANDLER_ENTR:0x00000000 (0)       PID:1 
IP:0xf0052620 AREA:0x00000000
t:0xe87d597e CPU:00 INT_HANDLER_EXIT:0x00000000 (0) SIGEVENT:NONE
t:0xe87d5c2d CPU:00 INT_EXIT:0x00000000 (0) inkernel:0x00000001
t:0xe87d6313 CPU:00 THREAD  :THRUNNING     io-usb tid:5
t:0xe87d6468 CPU:00 THREAD  :THREADY       pid:1 tid:1
t:0xe87d8885 CPU:00 KER_CALL:TIMER_TIMEOUT/75 timeout_flags:0x00001000 
ntime(sec):0
t:0xe87d8b05 CPU:00 THREAD  :THNANOSLEEP   io-usb tid:5
t:0xe87d8e4b CPU:00 THREAD  :THRUNNING     pid:1 tid:1
t:0xe884f46d CPU:00 INT_ENTR:0x00000000 (0)       IP:0xf007dbd6
t:0xe884f5e3 CPU:00 INT_HANDLER_ENTR:0x00000000 (0)       pkt-mgr 
IP:0x080b7a34 AREA:0x0812baa0
t:0xe884f90c CPU:00 INT_HANDLER_EXIT:0x00000000 (0) SIGEVENT:NONE
t:0xe884fb6c CPU:00 INT_HANDLER_ENTR:0x00000000 (0)       PID:1 
IP:0xf0052620 AREA:0x00000000
t:0xe8850138 CPU:00 INT_HANDLER_EXIT:0x00000000 (0) SIGEVENT:NONE
t:0xe8850419 CPU:00 INT_EXIT:0x00000000 (0) inkernel:0x00000001



>
>
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post98307
> To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com
>

Re: Udp packet lost  
Armin, What is IRQ that shared???? I don't understand. In tracelog that you present I see that trigger IRQ 0 ( timer ) 
and scheduler change state of io-usb to RUNNING. And all. 
Re: Udp packet lost  
Oleg Gopov wrote:
> Armin, What is IRQ that shared???? I don't understand. In tracelog that you present I see that trigger IRQ 0 ( timer )
 and scheduler change state of io-usb to RUNNING.

Seems so that io-usb is using InterruptAttachEvent ??

>   And all.
  IRQ

   0:    IO-APIC-*edge*   timer
   1:    IO-APIC-*edge*   i8042

Only these interupts are active in your kernel trace ... I don't see any real PCI interrupts!
Is your Ethernet board broken ????????????

One of the shared interrupts is just the IRQ 0 ....


>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post98310
> To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com
>

Attachment: HTML sf-attachment-mime8625 1.7 KB
Re: Udp packet lost  
> Seems so that io-usb is using InterruptAttachEvent ??

As you remember, USB subsystem is not interrupt-driven. Poll engine is the base of USB.
Io-usb simply wake up every 100 ms (as say tracebuffer.kev) and all. And I have no usb devices inserted to my computer.
> Is your Ethernet board broken ????????????
Yes of course. "Pcnet memory error" message just overload (3 times in second) my slog. Therefore I lost packets. 
Re: Udp packet lost  
Oleg Gopov wrote:
>> Seems so that io-usb is using InterruptAttachEvent ??
> As you remember, USB subsystem is not interrupt-driven. Poll engine is the base of USB.

AFAIK ... every UHCI controller works interrupt based!

> Io-usb simply wake up every 100 ms (as say tracebuffer.kev) and all. And I have no usb devices inserted to my computer
.
>> Is your Ethernet board broken ????????????
> Yes of course. "Pcnet memory error" message just overload (3 times in second) my slog. Therefore I lost packets.
>
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post98312
> To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com
>

Re: Udp packet lost  
>   IRQ
> 
>    0:    IO-APIC-*edge*   timer
>    1:    IO-APIC-*edge*   i8042
Hello Armin. Please say, where you get this. In /proc ????????? 

Re: Udp packet lost  
Oleg Gopov wrote:
>>    IRQ
>>
>>     0:    IO-APIC-*edge*   timer
>>     1:    IO-APIC-*edge*   i8042
> Hello Armin. Please say, where you get this. In /proc ?????????

These are the interrupts of my host OS (Suse 12.1/ 32bit) mapped to the 
interrupts of QNX 6.5) (-> *virtualized version* 6.5SP1 as provided by 
QSS !!

What *host OS* are you using ?
Could it be that the UDP packets are lost by the host OS ? ( Windows ?)
Are you using NAT or bridging with your guest OS (QNX) ?

Here are my results after a ftp transfer from the host to the guest:

# nicinfo
en0:
*AMD PCNET-32 Ethernet Controller*

   Physical Node ID ........................... 000C29 794934
   Current Physical Node ID ................... 000C29 794934
   Current Operation Rate ..................... 10.00 Mb/s
   Active Interface Type ...................... UTP
   Maximum Transmittable data Unit ............ 1514
   Maximum Receivable data Unit ............... 1514
   Hardware Interrupt ......................... 0xa
   I/O Aperture ............................... 0x2000 - 0x207f
   Memory Aperture ............................ 0x0
   Promiscuous Mode ........................... Off
   Multicast Support .......................... Enabled

   Packets Transmitted OK ..................... 99
   Bytes Transmitted OK ....................... 8003
   Memory Allocation Failures on Transmit ..... 0

   Packets Received OK ........................ 603
   Bytes Received OK .......................... 251077
   Memory Allocation Failures on Receive ...... 0

   Single Collisions on Transmit .............. 0
   Deferred Transmits ......................... 0
   Late Collision on Transmit errors .......... 0
   Transmits aborted (excessive collisions) ... 0
   Transmit Underruns ......................... 0
   No Carrier on Transmit ..................... 0
   Receive Alignment errors ................... 0
   Received packets with CRC errors ........... 0
   Packets Dropped on receive ................. 0

No errors at all ...





Attachment: HTML sf-attachment-mime8638 2.98 KB
Re: Udp packet lost  
Hello Armin. I use native OS. There is neither host OS nor guest OS.

I try to "slay io-usb", there is no effect.
Re: Udp packet lost  
I find excerpt of pcnet driver

/*
 * pcn_intr:
 *
 *	Interrupt service routine.
 */
static int
pcn_intr(void *arg)
{
	struct pcn_softc *sc = arg;
	struct ifnet *ifp = &sc->sc_ethercom.ec_if;
	uint32_t csr0;
	int wantinit, handled = 0;

	for (wantinit = 0; wantinit == 0;) {
		csr0 = pcn_csr_read(sc, LE_CSR0);
		if ((csr0 & LE_C0_INTR) == 0)
			break;

#if NRND > 0
		if (RND_ENABLED(&sc->rnd_source))
			rnd_add_uint32(&sc->rnd_source, csr0);
#endif

		/* ACK the bits and re-enable interrupts. */
		pcn_csr_write(sc, LE_CSR0, csr0 &
		    (LE_C0_INEA|LE_C0_BABL|LE_C0_MISS|LE_C0_MERR|LE_C0_RINT|
		     LE_C0_TINT|LE_C0_IDON));

		handled = 1;

		if (csr0 & LE_C0_RINT) {
			PCN_EVCNT_INCR(&sc->sc_ev_rxintr);
			wantinit = pcn_rxintr(sc);
		}

		if (csr0 & LE_C0_TINT) {
			PCN_EVCNT_INCR(&sc->sc_ev_txintr);
			pcn_txintr(sc);
		}

		if (csr0 & LE_C0_ERR) {
			if (csr0 & LE_C0_BABL) {
				PCN_EVCNT_INCR(&sc->sc_ev_babl);
				ifp->if_oerrors++;
			}
			if (csr0 & LE_C0_MISS) {
				PCN_EVCNT_INCR(&sc->sc_ev_miss);
				ifp->if_ierrors++;
			}
			if (csr0 & LE_C0_MERR) {
				PCN_EVCNT_INCR(&sc->sc_ev_merr);
				printf("%s: memory error\n",
				    sc->sc_dev.dv_xname);
				wantinit = 1;
				break;
			}
		}

		if ((csr0 & LE_C0_RXON) == 0) {
			printf("%s: receiver disabled\n",
			    sc->sc_dev.dv_xname);
			ifp->if_ierrors++;
			wantinit = 1;
		}

		if ((csr0 & LE_C0_TXON) == 0) {
			printf("%s: transmitter disabled\n",
			    sc->sc_dev.dv_xname);
			ifp->if_oerrors++;
			wantinit = 1;
		}
	}

	if (handled) {
		if (wantinit)
			pcn_init(ifp);

		/* Try to get more packets going. */
#ifdef __QNXNTO__
                NW_SIGLOCK(&ifp->if_snd_ex, iopkt_selfp);
#endif
		pcn_start(ifp);
	}

	return (handled);
}




*******************************************************
There is place in driver when "pcnet memory error" occur

			if (csr0 & LE_C0_MERR) {
				PCN_EVCNT_INCR(&sc->sc_ev_merr);
				printf("%s: memory error\n",
				    sc->sc_dev.dv_xname);
				wantinit = 1;
				break;
			}



Re: Udp packet lost  
Oleg Gopov wrote:
> I find excerpt of pcnet driver
>
> /*
>   * pcn_intr:
>   *
>   *	Interrupt service routine.
>   */
> static int
> pcn_intr(void *arg)
> {
> 	struct pcn_softc *sc = arg;
> 	struct ifnet *ifp = &sc->sc_ethercom.ec_if;
> 	uint32_t csr0;
> 	int wantinit, handled = 0;
>
> 	for (wantinit = 0; wantinit == 0;) {
> 		csr0 = pcn_csr_read(sc, LE_CSR0);
> 		if ((csr0 & LE_C0_INTR) == 0)
> 			break;
>
> #if NRND > 0
> 		if (RND_ENABLED(&sc->rnd_source))
> 			rnd_add_uint32(&sc->rnd_source, csr0);
> #endif
>
> 		/* ACK the bits and re-enable interrupts. */
> 		pcn_csr_write(sc, LE_CSR0, csr0 &
> 		    (LE_C0_INEA|LE_C0_BABL|LE_C0_MISS|LE_C0_MERR|LE_C0_RINT|
> 		     LE_C0_TINT|LE_C0_IDON));
>
> 		handled = 1;
>
> 		if (csr0 & LE_C0_RINT) {
> 			PCN_EVCNT_INCR(&sc->sc_ev_rxintr);
> 			wantinit = pcn_rxintr(sc);
> 		}
>
> 		if (csr0 & LE_C0_TINT) {
> 			PCN_EVCNT_INCR(&sc->sc_ev_txintr);
> 			pcn_txintr(sc);
> 		}
>
> 		if (csr0 & LE_C0_ERR) {
> 			if (csr0 & LE_C0_BABL) {
> 				PCN_EVCNT_INCR(&sc->sc_ev_babl);
> 				ifp->if_oerrors++;
> 			}
> 			if (csr0 & LE_C0_MISS) {
> 				PCN_EVCNT_INCR(&sc->sc_ev_miss);
> 				ifp->if_ierrors++;
> 			}
> 			if (csr0 & LE_C0_MERR) {
> 				PCN_EVCNT_INCR(&sc->sc_ev_merr);
> 				printf("%s: memory error\n",
> 				    sc->sc_dev.dv_xname);
> 				wantinit = 1;
> 				break;
> 			}
> 		}
>
> 		if ((csr0 & LE_C0_RXON) == 0) {
> 			printf("%s: receiver disabled\n",
> 			    sc->sc_dev.dv_xname);
> 			ifp->if_ierrors++;
> 			wantinit = 1;
> 		}
>
> 		if ((csr0 & LE_C0_TXON) == 0) {
> 			printf("%s: transmitter disabled\n",
> 			    sc->sc_dev.dv_xname);
> 			ifp->if_oerrors++;
> 			wantinit = 1;
> 		}
> 	}
>
> 	if (handled) {
> 		if (wantinit)
> 			pcn_init(ifp);
>
> 		/* Try to get more packets going. */
> #ifdef __QNXNTO__
>                  NW_SIGLOCK(&ifp->if_snd_ex, iopkt_selfp);
> #endif
> 		pcn_start(ifp);
> 	}
>
> 	return (handled);
> }
>
>
>
>
> *******************************************************
> There is place in driver when "pcnet memory error" occur
>
> 			if (csr0 & LE_C0_MERR) {
> 				PCN_EVCNT_INCR(&sc->sc_ev_merr);
> 				printf("%s: memory error\n",
> 				    sc->sc_dev.dv_xname);
> 				wantinit = 1;
> 				break;
> 			}
>
LINUX:

         if (csr0 & LE_C0_MERR) {
                 printk("%s: *Bus master arbitration failure*, status 
%4.4x.\n",
                        dev->name, csr0);
                 /* Restart the chip. */
                 WRITERDP(lp, LE_C0_STRT);
         }




>
>
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post98334
> To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com
>

Attachment: HTML sf-attachment-mime8657 3.95 KB
Re: Udp packet lost  
Oleg Gopov wrote:
LINUX:

         if (csr0 & LE_C0_MERR) {
                 printk("%s: *Bus master arbitration failure*, status 
%4.4x.\n",
                        dev->name, csr0);
                 /* Restart the chip. */
                 WRITERDP(lp, LE_C0_STRT);
         }

Reasons:  an other PCI device blocks the PCI bus or the bus request for 
more than 50us  or the PCI slot doesn't support bus mastering !


>
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post98334
> To cancel your subscription to this discussion, please e-maildrivers-networking-unsubscribe@community.qnx.com
>

Attachment: HTML sf-attachment-mime8660 1.9 KB
Re: Udp packet lost  
Hello Armin. Happy New Year. Thanks for answers.


I locate a problem. My Application work with pci-to-vme bridge Tundra Universe II. 
"pcnet memory error" occur when I try read/write to no-exist address on vme bus. (my applicatoin act as pci target) 
Re: Udp packet lost  
Hello Oleg,

all the best in 2013 !

is the bridge "Tundra Iniverse II" fully supported ?

--Armin

Oleg Gopov wrote:
> Hello Armin. Happy New Year. Thanks for answers.
>
>
> I locate a problem. My Application work with pci-to-vme bridge Tundra Universe II.
> "pcnet memory error" occur when I try read/write to no-exist address on vme bus. (my applicatoin act as pci target)
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post98367
> To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com
>

Re: Udp packet lost  
> is the bridge "Tundra Iniverse II" fully supported ?

No , I wrote myself this driver. 
Re: Udp packet lost  
> Reasons:  an other PCI device blocks the PCI bus or the bus request for 
> more than 50us  or the PCI slot doesn't support bus mastering !
I want to mention , that BIOS distribute to PCNET NIC -> IRQ 7, PCI2VME BRIDGE - IRQ 11.

One moment bothers me, how write/read action to pci2vme bridge cause interrupt generation on my nic driver. I don't 
understant. 
Re: Udp packet lost  
Because "pcnet memory error" generate in interrupt handler of pcnet driver. I am right?????????
Re: Udp packet lost  
Oleg Gopov wrote:
>> Reasons:  an other PCI device blocks the PCI bus or the bus request for
>> more than 50us  or the PCI slot doesn't support bus mastering !
> I want to mention , that BIOS distribute to PCNET NIC -> IRQ 7,

  ... and the IRQ 7 isn't shared by an other device ?

>   PCI2VME BRIDGE - IRQ 11.

That means all VME device are trigering the IRQ 11 ?

>
> One moment bothers me, how write/read action to pci2vme bridge cause interrupt generation on my nic driver. I don't 
understant.

Is it really the pci2vme bridge or is it an other PCI device ??

--Armin

>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post98397
> To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com
>

Re: Udp packet lost  
>   ... and the IRQ 7 isn't shared by an other device ?
There is no devices , that shared IRQ 7
> That means all VME device are trigering the IRQ 11 ?
I think YES.

> Is it really the pci2vme bridge or is it an other PCI device ??
Yes. It is realy pci2vme bridge - Tundra Universe II.
Re: Udp packet lost  
Oleg,

I hope you are not using QNX6.5 ... it well known for its esoteric PCI 
problems !

Oleg Gopov wrote:
>>    ... and the IRQ 7 isn't shared by an other device ?
> There is no devices , that shared IRQ 7
>> That means all VME device are trigering the IRQ 11 ?
> I think YES.
>
>> Is it really the pci2vme bridge or is it an other PCI device ??
> Yes. It is realy pci2vme bridge - Tundra Universe II.
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post98400
> To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com
>

Re: Udp packet lost  
> 
> Oleg,
> 
> I hope you are not using QNX6.5 ... it well known for its esoteric PCI 
> problems !
> 

I point in the first post , that I use 6.4.0 version
 

Re: Udp packet lost  
Oleg Gopov wrote:
>> Oleg,
>>
>> I hope you are not using QNX6.5 ... it well known for its esoteric PCI
>> problems !
>>
> I point in the first post , that I use 6.4.0 version

OK.
Could this be helpful?
http://community.qnx.com/sf/discussion/do/listPosts/projects.bsp/discussion.bsp.topc3672?_pagenum=1

>   
>
>
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post98402
> To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com
>

Re: Udp packet lost  
Thanks Armin. I will study info under links you suggest and surely write results to this post.
Re: Udp packet lost  
> OK.
> Could this be helpful?
> http://community.qnx.com/sf/discussion/do/listPosts/projects.bsp/discussion.
> bsp.topc3672?_pagenum=1
One thing I may write that this post is not my case. Our system work for years and we don't have problems with 
allocating Tundra base address. All more difficult. Only one board (vp7) with only one NIC (amd pcnet32) cause problem 
as I wrote on the first post.
Re: Udp packet lost  
You know it ?

http://www.tldp.org/HOWTO/VME-HOWTO.html#toc4

Oleg Gopov wrote:
>>    ... and the IRQ 7 isn't shared by an other device ?
> There is no devices , that shared IRQ 7
>> That means all VME device are trigering the IRQ 11 ?
> I think YES.
>
>> Is it really the pci2vme bridge or is it an other PCI device ??
> Yes. It is realy pci2vme bridge - Tundra Universe II.
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post98400
> To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com
>

Re: Udp packet lost  
> You know it ?
> 
> http://www.tldp.org/HOWTO/VME-HOWTO.html#toc4
> 

I already learn this linux driver for vme bridge. I try some things after holidays and write to this topic.



Re: Udp packet lost  
Hello Armin. Our investigation is continue))))))))))))
Please, what you say???????

> Reasons:  an other PCI device blocks the PCI bus or the bus request for 
> more than 50us  or the PCI slot doesn't support bus mastering !

Where you take 50us from???????????? What is the time??????????????


Re: Udp packet lost  
Oleg Gopov wrote:
> Hello Armin. Our investigation is continue))))))))))))
> Please, what you say???????
>
>> Reasons:  an other PCI device blocks the PCI bus or the bus request for
>> more than 50us  or the PCI slot doesn't support bus mastering !
> Where you take 50us from????????????

   Should be specified by the PCI standard.

> What is the time??????????????

tineout for requesting as a master the bus.

Do you have a corrupted keyboard ??????????????????????????????

>
>
>
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post98560
> To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com
>

Re: Udp packet lost  
> Do you have a corrupted keyboard ??????????????????????????????

Keyboard work properly.
Re: Udp packet lost  
Armin, I prepare some sweets)))))))

Please see to attachment.

Armin, what you say??????????
Attachment: Image Issue.jpg 519.63 KB
Re: Udp packet lost  
Oleg Gopov wrote:
> Armin, I prepare some sweets)))))))
>
> Please see to attachment.
>
> Armin, what you say??????????
Interesting !
Are there any hardware related delays or was the IRQ 9 disabled for lots 
of us ?

Is the IRQ 2 used ? If yes, you shouldn't use IRQ 9 ...

--Armin

>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post98571
> To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

Re: Udp packet lost  
> or was the IRQ 9 disabled for lots 
> of us ?
How I can figure out this????????



> Is the IRQ 2 used ? If yes, you shouldn't use IRQ 9 ...
No. I don't use IRQ 2.
Re: Udp packet lost  
Oleg Gopov wrote:
>> You have a corrupted board sharing the same IRQ with io-usb -> that's
>> the best wayto loose interrupts.
>> io-usb is known for blocking/disabling its (shared) interrupt for a
>> longer time !
>>
>> --Armin
>>
> But, Armin. How You conclude this??? You find out issue in tracebuffer.kev file??????????

Yes ... you can see that io-usb is sharing the same interrupt ... that 
means in all cases of an active interrupt is the ISR of io-usb active!!!!


> I analyze tracelog and see that io-usb thread eat processor time only ~ 30us. Nothing criminal in that.

Handling - that means disabling/enabling - of interrupts are normally 
done in the ISR! Should be critical enough .... even if there is no data 
traffic.

--Armin

>   
>
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post98305
> To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com
>

Re: Udp packet lost  
Oleg,

UDP is a unsecure protocol ... that means when the driver is loosing 
interrupts it will loose packets.

This can happen if the interrupt is shared by other devices and one of 
these device driver is disabling the shared interrupt for a longer time.
We had a similar problem with a CAN communication ( similar to UDP 
communication) and there was interrupt disabled for ~8ms !!

Best Regards

Armin Steinhoff

http://www.steinhoff-automation.com


Oleg Gopov wrote:
> I see nicinfo output - > pcnet32 network adapter work in half-duplex. How I can lost packets??? I don't understand.
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post97593
> To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com
>