Oleg Gopov(deleted)
11/27/2012 9:35 PM
post97532
|
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??????????
|
|
|
Hugh Brown
11/28/2012 7:35 AM
post97548
|
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
|
|
|
Oleg Gopov(deleted)
11/29/2012 12:23 AM
post97593
|
I see nicinfo output - > pcnet32 network adapter work in half-duplex. How I can lost packets??? I don't understand.
|
|
|
Oleg Gopov(deleted)
11/29/2012 12:27 AM
post97594
|
And out traffic is light.
|
|
|
Oleg Gopov(deleted)
11/29/2012 12:28 AM
post97595
|
And our network traffic is light
|
|
|
Armin Steinhoff
11/29/2012 5:47 PM
post97657
|
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
>
|
|
|
Oleg Gopov(deleted)
12/18/2012 7:33 AM
post98196
|
>
> 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.
|
|
|
Armin Steinhoff
12/18/2012 9:37 AM
post98204
|
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
|
|
|
Oleg Gopov(deleted)
12/19/2012 12:08 PM
post98234
|
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"
|
|
|
Oleg Gopov(deleted)
12/19/2012 12:19 PM
post98236
|
Maybe someone have pcnet32 network adapter sources. What is the case when "pcnet memory error" message generated??????
|
|
|
Oleg Gopov(deleted)
12/19/2012 12:23 PM
post98237
|
I invoke "top" command and see that 28M of memory are available.
|
|
|
Armin Steinhoff
12/21/2012 12:24 PM
post98284
|
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
|
|
|
Oleg Gopov(deleted)
12/21/2012 10:13 PM
post98301
|
Ok, Armin. I will try to "slay io-usb" or disable usb from bios. I will write results to this post.
|
|
|
Armin Steinhoff
12/22/2012 5:07 AM
post98303
|
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
>
|
|
|
Oleg Gopov(deleted)
12/22/2012 10:42 PM
post98305
|
> 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.
|
|
|
Armin Steinhoff
12/23/2012 4:41 AM
post98306
|
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
>
|
|
|
Oleg Gopov(deleted)
12/23/2012 6:47 AM
post98307
|
> 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?????????
|
|
|
Armin Steinhoff
12/23/2012 9:05 AM
post98309
|
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
>
|
|
|
Oleg Gopov(deleted)
12/23/2012 9:45 AM
post98310
|
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.
|
|
|
Armin Steinhoff
12/23/2012 11:31 AM
post98311
|
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
>
|
|
|
Oleg Gopov(deleted)
12/23/2012 10:46 PM
post98312
|
> 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.
|
|
|
Armin Steinhoff
12/24/2012 10:07 AM
post98314
|
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
>
|
|
|
Oleg Gopov(deleted)
12/25/2012 8:45 PM
post98318
|
> IRQ
>
> 0: IO-APIC-*edge* timer
> 1: IO-APIC-*edge* i8042
Hello Armin. Please say, where you get this. In /proc ?????????
|
|
|
Armin Steinhoff
12/26/2012 8:07 AM
post98320
|
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 ...
|
|
|
Oleg Gopov(deleted)
12/26/2012 9:19 AM
post98321
|
Hello Armin. I use native OS. There is neither host OS nor guest OS.
I try to "slay io-usb", there is no effect.
|
|
|
Oleg Gopov(deleted)
12/30/2012 10:56 PM
post98334
|
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;
}
|
|
|
Armin Steinhoff
12/31/2012 6:12 AM
post98335
|
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
>
|
|
|
Armin Steinhoff
12/31/2012 6:33 AM
post98336
|
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
>
|
|
|
Oleg Gopov(deleted)
01/03/2013 8:59 PM
post98367
|
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)
|
|
|
Armin Steinhoff
01/04/2013 3:35 AM
post98369
|
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
>
|
|
|
Oleg Gopov(deleted)
01/04/2013 5:55 AM
post98372
|
> is the bridge "Tundra Iniverse II" fully supported ?
No , I wrote myself this driver.
|
|
|
Oleg Gopov(deleted)
01/05/2013 10:03 AM
post98397
|
> 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.
|
|
|
Oleg Gopov(deleted)
01/05/2013 10:05 AM
post98398
|
Because "pcnet memory error" generate in interrupt handler of pcnet driver. I am right?????????
|
|
|
Armin Steinhoff
01/05/2013 12:15 PM
post98399
|
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
>
|
|
|
Oleg Gopov(deleted)
01/05/2013 9:20 PM
post98400
|
> ... 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.
|
|
|
Armin Steinhoff
01/06/2013 7:12 AM
post98401
|
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
>
|
|
|
Oleg Gopov(deleted)
01/06/2013 8:09 AM
post98402
|
>
> 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
|
|
|
Armin Steinhoff
01/07/2013 4:33 AM
post98409
|
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
>
|
|
|
Oleg Gopov(deleted)
01/08/2013 9:27 AM
post98437
|
Thanks Armin. I will study info under links you suggest and surely write results to this post.
|
|
|
Oleg Gopov(deleted)
01/08/2013 9:45 AM
post98438
|
> 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.
|
|
|
Armin Steinhoff
01/07/2013 4:13 AM
post98408
|
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
>
|
|
|
Oleg Gopov(deleted)
01/08/2013 6:11 PM
post98448
|
> 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.
|
|
|
Oleg Gopov(deleted)
01/14/2013 10:49 PM
post98560
|
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??????????????
|
|
|
Armin Steinhoff
01/15/2013 6:00 AM
post98564
|
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
>
|
|
|
Oleg Gopov(deleted)
01/15/2013 7:26 AM
post98566
|
> Do you have a corrupted keyboard ??????????????????????????????
Keyboard work properly.
|
|
|
Oleg Gopov(deleted)
01/15/2013 10:11 AM
post98571
|
Armin, I prepare some sweets)))))))
Please see to attachment.
Armin, what you say??????????
|
|
|
Armin Steinhoff
01/15/2013 10:41 AM
post98574
|
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
|
|
|
Oleg Gopov(deleted)
01/15/2013 12:50 PM
post98585
|
> 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.
|
|
|
Armin Steinhoff
12/23/2012 8:22 AM
post98308
|
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
>
|
|
|
Armin Steinhoff
11/29/2012 4:00 AM
post97602
|
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
>
|
|
|
|