Mario Charest
10/03/2008 10:54 AM
post14421
|
What is going on when:
Coming from the computer doing a pidin -n ...
03103902(L4): l4_tx_timeout(): timeout: nd 40 sc 1 dc 1 ss 1941 tk 18443 ct 18445
03103902(L4): l4_tx_rx_ack_r_nack(): unkn tx: nd:40 dc:1 seq:1941
03103902(L4): l4_tx_timeout(): timeout: nd 40 sc 1 dc 1 ss 1990 tk 18446 ct 18448
03103902(L4): l4_tx_rx_ack_r_nack(): unkn tx: nd:40 dc:1 seq:1990
03103904(L4): l4_tx_timeout(): timeout: nd 40 sc 1 dc 1 ss 2697 tk 18457 ct 18459
03103904(L4): l4_tx_rx_ack_r_nack(): unkn tx: nd:40 dc:1 seq:2697
03103940(L4): l4_tx_timeout(): timeout: nd 40 sc 1 dc 1 ss 3292 tk 18635 ct 18637
03103940(L4): l4_tx_rx_ack_r_nack(): unkn tx: nd:40 dc:1 seq:3292
03103941(L4): l4_tx_timeout(): timeout: nd 40 sc 1 dc 1 ss 3306 tk 18638 ct 18640
03103941(L4): l4_tx_rx_ack_r_nack(): unkn tx: nd:40 dc:1 seq:3306
03103941(L4): l4_tx_timeout(): timeout: nd 40 sc 1 dc 1 ss 3319 tk 18641 ct 18643
03103941(L4): l4_tx_rx_ack_r_nack(): unkn tx: nd:40 dc:1 seq:3319
03103942(L4): l4_tx_timeout(): timeout: nd 40 sc 1 dc 1 ss 3326 tk 18644 ct 18646
03103942(L4): l4_tx_rx_ack_r_nack(): unkn tx: nd:40 dc:1 seq:3326
03103942(L4): l4_tx_timeout(): timeout: nd 40 sc 1 dc 1 ss 3342 tk 18647 ct 18649
03103942(L4): l4_tx_rx_ack_r_nack(): unkn tx: nd:40 dc:1 seq:3342
03103943(L4): l4_tx_timeout(): timeout: nd 40 sc 1 dc 1 ss 3343 tk 18650 ct 18652
03103943(L4): l4_tx_rx_ack_r_nack(): unkn tx: nd:40 dc:1 seq:3343
03103944(L4): l4_tx_timeout(): timeout: nd 40 sc 1 dc 1 ss 3357 tk 18654 ct 18656
03103944(L4): l4_tx_rx_ack_r_nack(): unkn tx: nd:40 dc:1 seq:3357
03103944(L4): l4_tx_timeout(): timeout: nd 40 sc 1 dc 1 ss 3361 tk 18657 ct 18659
03103944(L4): l4_tx_rx_ack_r_nack(): unkn tx: nd:40 dc:1 seq:3361
03104009(L4): l4_tx_timeout(): timeout: nd 40 sc 1 dc 1 ss 3381 tk 18778 ct 18780
03104009(L4): l4_tx_rx_ack_r_nack(): unkn tx: nd:40 dc:1 seq:3381
03104011(L4): l4_tx_timeout(): timeout: nd 40 sc 1 dc 1 ss 3475 tk 18788 ct 18790
03104011(L4): l4_tx_rx_ack_r_nack(): unkn tx: nd:40 dc:1 seq:3475
03104017(L4): l4_tx_timeout(): timeout: nd 40 sc 1 dc 1 ss 3495 tk 18819 ct 18821
03104017(L4): l4_tx_rx_ack_r_nack(): unkn tx: nd:40 dc:1 seq:3495
03104419(L4): l4_tx_timeout(): timeout: nd 40 sc 1 dc 1 ss 3611 tk 20030 ct 20032
03104419(L4): l4_tx_rx_ack_r_nack(): unkn tx: nd:40 dc:1 seq:3611
and coming being inquired about
3224734(QOS): qos_verify_rx_conn_seq(): rxd old dup (3961/3961) nd 1 rx conn 1
3224734(QOS): rx_user_data(): bad conn/seq rxd from nd 1
3224735(QOS): qos_verify_rx_conn_seq(): rxd old dup (4210/4210) nd 1 rx conn 1
3224735(QOS): rx_user_data(): bad conn/seq rxd from nd 1
3224736(QOS): qos_verify_rx_conn_seq(): rxd old dup (4269/4269) nd 1 rx conn 1
3224736(QOS): rx_user_data(): bad conn/seq rxd from nd 1
3224736(QOS): qos_verify_rx_conn_seq(): rxd old dup (4308/4308) nd 1 rx conn 1
3224736(QOS): rx_user_data(): bad conn/seq rxd from nd 1
3224737(QOS): qos_verify_rx_conn_seq(): rxd old dup (4368/4368) nd 1 rx conn 1
3224737(QOS): rx_user_data(): bad conn/seq rxd from nd 1
3224738(QOS): qos_verify_rx_conn_seq(): rxd old dup (4378/4378) nd 1 rx conn 1
3224738(QOS): rx_user_data(): bad conn/seq rxd from nd 1
3224738(QOS): qos_verify_rx_conn_seq(): rxd old dup (4440/4440) nd 1 rx conn 1
3224738(QOS): rx_user_data(): bad conn/seq rxd from nd 1
3224739(QOS): qos_verify_rx_conn_seq(): rxd old dup (4466/4466) nd 1 rx conn 1
3224739(QOS): rx_user_data(): bad conn/seq rxd from nd 1
3224759(QOS): qos_verify_rx_conn_seq(): rxd old dup (4509/4509) nd 1 rx conn 1
3224759(QOS): rx_user_data(): bad conn/seq rxd from nd 1
3224759(QOS): qos_verify_rx_conn_seq(): rxd old dup (4519/4519) nd 1 rx conn 1
3224759(QOS): rx_user_data(): bad conn/seq rxd from nd 1
3224800(QOS): qos_verify_rx_conn_seq(): rxd old dup (4565/4565) nd 1 rx conn 1
3224800(QOS): rx_user_data(): bad conn/seq rxd from nd 1
3224801(QOS): qos_verify_rx_conn_seq(): rxd old dup (4572/4572) nd 1 rx conn 1
3224801(QOS):...
View Full Message
|
|
|
Andrew Boyd(deleted)
10/03/2008 11:04 AM
post14422
|
Qnet is timing out too early on transmit, in your
network. Try increasing the timeout, or try to
get rid of the delay, which can be caused simply
by scheduling latency eg high cpu utilization at
high priority.
--
aboyd
|
|
|
Mario Charest
10/03/2008 11:35 AM
post14428
|
>
> Qnet is timing out too early on transmit, in your
> network. Try increasing the timeout, or try to
> get rid of the delay, which can be caused simply
> by scheduling latency eg high cpu utilization at
> high priority.
>
The two machines were connected via a switch, I changed it to a direct link with cross cable, same thing. Can't do
better then that for reducing the delay.
As for high cpu utilization, both machine are a 2 Core Xeon at 3Gig and while running piding CPU usage is .4% for the
machine begin pidined and 1.2% for the machine running pidin. Got the .key file to prove it ;-)
Looking at the .kev file I find it odd that interrupt 3 ( the one io-net is connected to) are happening only every 100ms
or so. There is only io-net connected to irq 3 ( and yes the com ports have been disabled).
I guess it sounds like I'll have to get in touch with our account manager and send you some hardware. This is not
defective hardware, I have 12 machines doing the same thing.
> --
> aboyd
|
|
|
Mario Charest
10/03/2008 11:42 AM
post14430
|
> I guess it sounds like I'll have to get in touch with our account manager and
> send you some hardware.
By send you, I meant send QSSL ;-)
|
|
|
Andrew Boyd(deleted)
10/03/2008 11:52 AM
post14432
|
> I find it odd that interrupt 3 ( the one io-net is connected to)
> are happening only every 100ms or so.
Likely that is causing the qnet timeout.
Are you sure that this interrupt isn't being shared? Sharing
interrupts can cause all sorts of undesirable latencies.
Also, some network cards can be programmed to limit the number
of interrupts per second - perhaps an erroneously (huge) delay
could have been introduced that way?
--
aboyd
|
|
|
Mario Charest
|
Re: RE: RE: interpretation
|
Mario Charest
10/03/2008 1:26 PM
post14441
|
Re: RE: RE: interpretation
>
> > I find it odd that interrupt 3 ( the one io-net is connected to)
> > are happening only every 100ms or so.
>
> Likely that is causing the qnet timeout.
>
> Are you sure that this interrupt isn't being shared? Sharing
> interrupts can cause all sorts of undesirable latencies.
Well there is latencies and there is latencies ;-) Pidin takes about 6 seconds to run.
>
> Also, some network cards can be programmed to limit the number
> of interrupts per second - perhaps an erroneously (huge) delay
> could have been introduced that way?
Don't know. We are using Net.e1000 (build for 6.3.2), and Net.i82540 shows the same behavior. Drivers are started with
priority=100 that's all.
>
> --
> aboyd
|
|
|
Andrew Boyd(deleted)
|
RE: RE: RE: interpretation
|
Andrew Boyd(deleted)
10/03/2008 1:31 PM
post14443
|
RE: RE: RE: interpretation
FYI: I think it's 80% probability that the delay
is on the rx side (ie the packet is in the rx descr
ring, but the driver and hence qnet doesn't know
about it until after the long-delayed interrupt) but ...
There is a 20% chance that the delay is coming
from the transmit side. That is, the driver puts
the packet information in the tx descr entry, but
for some reason the transmitting nic does not learn
about it for quite some time, and that's where the
delay is coming from.
You've got a driver/hardware problem.
--
aboyd
|
|
|
Mario Charest
|
Re: RE: RE: RE: interpretation
|
Mario Charest
10/03/2008 3:47 PM
post14452
|
Re: RE: RE: RE: interpretation
>
> FYI: I think it's 80% probability that the delay
> is on the rx side (ie the packet is in the rx descr
> ring, but the driver and hence qnet doesn't know
> about it until after the long-delayed interrupt) but ...
>
> There is a 20% chance that the delay is coming
> from the transmit side. That is, the driver puts
> the packet information in the tx descr entry, but
> for some reason the transmitting nic does not learn
> about it for quite some time, and that's where the
> delay is coming from.
>
> You've got a driver/hardware problem.
Tried with 6.4 M8 and same thing. Thanks for the information.
>
> --
> aboyd
|
|
|
Mario Charest
|
Re: RE: RE: RE: interpretation
|
Mario Charest
10/06/2008 1:20 PM
post14537
|
Re: RE: RE: RE: interpretation
> >
> > FYI: I think it's 80% probability that the delay
> > is on the rx side (ie the packet is in the rx descr
> > ring, but the driver and hence qnet doesn't know
> > about it until after the long-delayed interrupt) but ...
> >
> > There is a 20% chance that the delay is coming
> > from the transmit side. That is, the driver puts
> > the packet information in the tx descr entry, but
> > for some reason the transmitting nic does not learn
> > about it for quite some time, and that's where the
> > delay is coming from.
> >
> > You've got a driver/hardware problem.
>
> Tried with 6.4 M8 and same thing. Thanks for the information.
Tried it with QNX4 and it works fine.
>
> >
> > --
> > aboyd
>
>
|
|
|
Andrew Boyd(deleted)
|
RE: RE: RE: RE: interpretation
|
Andrew Boyd(deleted)
10/06/2008 1:27 PM
post14540
|
RE: RE: RE: RE: interpretation
> > You've got a driver/hardware problem.
>
> Tried it with QNX4 and it works fine.
Sigh. Sure looks like a driver mis-configuration
of your nic. Problem is, there are over SIXTY
hardware variants of the i82544, and trying to
write a "golden" driver which perfectly initializes
all variants, can be quite difficult.
I'm surprised the recently ported Intel driver didn't
work, either - you would have thought it should have
handled all of the possible variants correctly.
What is your DID?
--
aboyd
|
|
|
Mario Charest
|
Re: RE: RE: RE: RE: interpretation
|
Mario Charest
10/06/2008 4:53 PM
post14550
|
Re: RE: RE: RE: RE: interpretation
> > > You've got a driver/hardware problem.
> >
> > Tried it with QNX4 and it works fine.
>
> Sigh.
I know the feeling ;-)
> Sure looks like a driver mis-configuration
> of your nic. Problem is, there are over SIXTY
> hardware variants of the i82544, and trying to
> write a "golden" driver which perfectly initializes
> all variants, can be quite difficult.
I sympathize
>
> I'm surprised the recently ported Intel driver didn't
> work, either - you would have thought it should have
> handled all of the possible variants correctly.
Indeed, we've have had problem with the Intel card and QNX6 since the beginning. Unfortunately we have no real
alternative for now.
>
> What is your DID?
10b9. Hugh once told me he tested the driver with this same DID ;-(
>
> --
> aboyd
|
|
|
Robert Craig
|
RE: RE: RE: RE: RE: interpretation
|
Robert Craig
10/06/2008 4:56 PM
post14551
|
RE: RE: RE: RE: RE: interpretation
That's really weird. I've got that DID in my machine (it's a PCI
Express card) and there haven't been any problems with it. There's a
little bit of me saying that it's unlikely to be a driver problem.
Can you post the output from "pidin irq" for us to have a look at? If
the NIC isn't built in, can you move it to a different slot and see if
that has any effect?
R.
-----Original Message-----
From: Mario Charest [mailto:community-noreply@qnx.com]
Sent: Monday, October 06, 2008 4:53 PM
To: technology-networking
Subject: Re: RE: RE: RE: RE: interpretation
> > > You've got a driver/hardware problem.
> >
> > Tried it with QNX4 and it works fine.
>
> Sigh.
I know the feeling ;-)
> Sure looks like a driver mis-configuration
> of your nic. Problem is, there are over SIXTY
> hardware variants of the i82544, and trying to
> write a "golden" driver which perfectly initializes
> all variants, can be quite difficult.
I sympathize
>
> I'm surprised the recently ported Intel driver didn't
> work, either - you would have thought it should have
> handled all of the possible variants correctly.
Indeed, we've have had problem with the Intel card and QNX6 since the
beginning. Unfortunately we have no real alternative for now.
>
> What is your DID?
10b9. Hugh once told me he tested the driver with this same DID ;-(
>
> --
> aboyd
_______________________________________________
Technology
http://community.qnx.com/sf/go/post14550
|
|
|
Andrew Boyd(deleted)
|
RE: RE: RE: RE: RE: interpretation
|
Andrew Boyd(deleted)
10/07/2008 8:35 AM
post14573
|
RE: RE: RE: RE: RE: interpretation
> I've got that DID in my machine (it's a PCI Express card)
Ah ha. It's PCI-X - I've experienced some really bizarre
and flaky problems with PCI-X on some motherboards. Another
thing to check is that you aren't running an ancient version
of pci server. Also, try running a NON PCI-X (ie a simple PCI)
i82544 card - I'll bet your problems completely go away.
P.S. With Rob's setup - with the same PCI-X cards as you -
we are seeing superb performance numbers, with io-pkt.
--
aboyd
|
|
|
Mario Charest
|
Re: RE: RE: RE: RE: RE: interpretation
|
Mario Charest
10/07/2008 9:19 AM
post14588
|
Re: RE: RE: RE: RE: RE: interpretation
>
> > I've got that DID in my machine (it's a PCI Express card)
>
> Ah ha. It's PCI-X - I've experienced some really bizarre
> and flaky problems with PCI-X on some motherboards.
We have that problem on various model of motherboard
> Another
> thing to check is that you aren't running an ancient version
> of pci server.
As I said the problem is present with M8.
> Also, try running a NON PCI-X (ie a simple PCI)
> i82544 card - I'll bet your problems completely go away.
I wish be we can't...
>
> P.S. With Rob's setup - with the same PCI-X cards as you -
> we are seeing superb performance numbers, with io-pkt.
>
You're a tease, lol! Not that for sustain operation it's not bad at all for us, it's for small transcation, like pidin
that it gets awfully slow. A copy a file will go as fast at the HD will allow ( 50M/sec ).
> --
> aboyd
|
|
|
Andrew Boyd(deleted)
|
RE: RE: RE: RE: RE: RE: interpretation
|
Andrew Boyd(deleted)
10/07/2008 9:28 AM
post14591
|
RE: RE: RE: RE: RE: RE: interpretation
> it's for small transcation, like pidin that it
> gets awfully slow.
Sure sounds like an rx interrupt problem :-(
> A copy a file will go as fast at the HD will
> allow ( 50M/sec ).
With your card - the PCI-X i28544 - we're seeing
950 mbits/sec (pretty much wire rate) user tcp
throughput with io-pkt, using a fraction of the
cpu, with only 2K user transfer size - it's flat
after that, with bigger sizes.
--
aboyd
|
|
|
Mario Charest
|
Re: RE: RE: RE: RE: RE: interpretation
|
Mario Charest
10/07/2008 9:24 AM
post14590
|
Re: RE: RE: RE: RE: RE: interpretation
> That's really weird. I've got that DID in my machine (it's a PCI
> Express card) and there haven't been any problems with it. There's a
> little bit of me saying that it's unlikely to be a driver problem.
>
> Can you post the output from "pidin irq" for us to have a look at?
File attached.
> the NIC isn't built in, can you move it to a different slot and see if
> that has any effect?
No it's not built in. I will try that after I'm done with the bnx driver.
That being said I'm working on sending QSS the hardware because i've spend a huge amount of time on this over the past
months and it's now time we get to the bottom of this. This is a very critical issue for us.
>
>
>
>
>
> -----Original Message-----
> From: Mario Charest [mailto:community-noreply@qnx.com]
> Sent: Monday, October 06, 2008 4:53 PM
> To: technology-networking
> Subject: Re: RE: RE: RE: RE: interpretation
>
> > > > You've got a driver/hardware problem.
> > >
> > > Tried it with QNX4 and it works fine.
> >
> > Sigh.
>
> I know the feeling ;-)
>
> > Sure looks like a driver mis-configuration
> > of your nic. Problem is, there are over SIXTY
> > hardware variants of the i82544, and trying to
> > write a "golden" driver which perfectly initializes
> > all variants, can be quite difficult.
>
> I sympathize
>
> >
> > I'm surprised the recently ported Intel driver didn't
> > work, either - you would have thought it should have
> > handled all of the possible variants correctly.
>
> Indeed, we've have had problem with the Intel card and QNX6 since the
> beginning. Unfortunately we have no real alternative for now.
>
> >
> > What is your DID?
>
> 10b9. Hugh once told me he tested the driver with this same DID ;-(
>
> >
> > --
> > aboyd
>
>
>
>
> _______________________________________________
> Technology
> http://community.qnx.com/sf/go/post14550
|
|
|
Andrew Boyd(deleted)
|
RE: RE: RE: RE: RE: RE: interpretation
|
Andrew Boyd(deleted)
10/07/2008 9:32 AM
post14593
|
RE: RE: RE: RE: RE: RE: interpretation
> File attached.
Gosh, that sure looks clean for interrupts.
Shot in the dark: try running non-SMP. Does
that make a difference?
--
aboyd www.PoweredByQNX.com
|
|
|
Robert Craig
|
RE: RE: RE: RE: RE: RE: interpretation
|
Robert Craig
10/07/2008 10:07 AM
post14600
|
RE: RE: RE: RE: RE: RE: interpretation
There's certainly nothing obvious in the pidin. I look at that 0x3 IRQ
and immediately think serial port even though there's none running and
I'm sure it's disabled in the BIOS. On top of Andrew's non-SMP, how
about preventing IRQ3 from being used in the BIOS (reserving it) and see
if that changes things.
As you can tell, we're grasping at straws here (!).
One final question... Is this with io-net or io-pkt? We've got some
tuning options in the io-pkt driver that we could play with that affects
the interrupt capabilities...
Robert.
-----Original Message-----
From: Mario Charest [mailto:community-noreply@qnx.com]
Sent: Tuesday, October 07, 2008 9:25 AM
To: technology-networking
Subject: Re: RE: RE: RE: RE: RE: interpretation
> That's really weird. I've got that DID in my machine (it's a PCI
> Express card) and there haven't been any problems with it. There's a
> little bit of me saying that it's unlikely to be a driver problem.
>
> Can you post the output from "pidin irq" for us to have a look at?
File attached.
> the NIC isn't built in, can you move it to a different slot and see if
> that has any effect?
No it's not built in. I will try that after I'm done with the bnx
driver.
That being said I'm working on sending QSS the hardware because i've
spend a huge amount of time on this over the past months and it's now
time we get to the bottom of this. This is a very critical issue for
us.
>
>
>
>
>
> -----Original Message-----
> From: Mario Charest [mailto:community-noreply@qnx.com]
> Sent: Monday, October 06, 2008 4:53 PM
> To: technology-networking
> Subject: Re: RE: RE: RE: RE: interpretation
>
> > > > You've got a driver/hardware problem.
> > >
> > > Tried it with QNX4 and it works fine.
> >
> > Sigh.
>
> I know the feeling ;-)
>
> > Sure looks like a driver mis-configuration
> > of your nic. Problem is, there are over SIXTY
> > hardware variants of the i82544, and trying to
> > write a "golden" driver which perfectly initializes
> > all variants, can be quite difficult.
>
> I sympathize
>
> >
> > I'm surprised the recently ported Intel driver didn't
> > work, either - you would have thought it should have
> > handled all of the possible variants correctly.
>
> Indeed, we've have had problem with the Intel card and QNX6 since the
> beginning. Unfortunately we have no real alternative for now.
>
> >
> > What is your DID?
>
> 10b9. Hugh once told me he tested the driver with this same DID ;-(
>
> >
> > --
> > aboyd
>
>
>
>
> _______________________________________________
> Technology
> http://community.qnx.com/sf/go/post14550
_______________________________________________
Technology
http://community.qnx.com/sf/go/post14590
|
|
|
Andrew Boyd(deleted)
|
Re: RE: RE: RE: RE: RE: RE: interpretation
|
Andrew Boyd(deleted)
10/07/2008 10:21 AM
post14603
|
Re: RE: RE: RE: RE: RE: RE: interpretation
Mario: shot in the dark #2: try this experimental driver:
www.pittspecials.com/etc/devnp-i82544.so
--
aboyd
|
|
|
Colin Burgess(deleted)
10/07/2008 10:22 AM
post14605
|
The acrobatics this team goes through to bring you a working driver! :-)
Andrew Boyd wrote:
> Mario: shot in the dark #2: try this experimental driver:
>
> www.pittspecials.com/etc/devnp-i82544.so
>
> --
> aboyd
>
> _______________________________________________
> Technology
> http://community.qnx.com/sf/go/post14603
>
--
cburgess@qnx.com
|
|
|
Robert Craig
10/07/2008 10:29 AM
post14606
|
We fly through hoops to take care of our customers!
-----Original Message-----
From: Colin Burgess [mailto:community-noreply@qnx.com]
Sent: Tuesday, October 07, 2008 10:23 AM
To: technology-networking
Subject: Re: interpretation
The acrobatics this team goes through to bring you a working driver! :-)
Andrew Boyd wrote:
> Mario: shot in the dark #2: try this experimental driver:
>
> www.pittspecials.com/etc/devnp-i82544.so
>
> --
> aboyd
>
> _______________________________________________
> Technology
> http://community.qnx.com/sf/go/post14603
>
--
cburgess@qnx.com
_______________________________________________
Technology
http://community.qnx.com/sf/go/post14605
|
|
|
Andrew Boyd(deleted)
10/07/2008 10:33 AM
post14607
|
Sorry, I haven't a clue how/where to officially post
experimental binaries (red face) so it's faster for
me to just use my website.
P.S. My kid is really enamoured of this one:
which is fun to fly, but a tad hard on fuel.
--
aboyd
|
|
|
Mario Charest
|
Re: RE: RE: RE: RE: RE: RE: interpretation
|
Mario Charest
10/07/2008 11:13 AM
post14609
|
Re: RE: RE: RE: RE: RE: RE: interpretation
> Mario: shot in the dark #2: try this experimental driver:
>
> www.pittspecials.com/etc/devnp-i82544.so
>
No change, I also tried with non-SMP that also didn't help.
> --
> aboyd
|
|
|
Andrew Boyd(deleted)
|
RE: RE: RE: RE: RE: RE: RE: interpretation
|
Andrew Boyd(deleted)
10/07/2008 11:14 AM
post14610
|
RE: RE: RE: RE: RE: RE: RE: interpretation
What about a different interrupt?
--
aboyd
|
|
|
Mario Charest
|
Re: RE: RE: RE: RE: RE: RE: interpretation
|
Mario Charest
10/07/2008 11:17 AM
post14612
|
Re: RE: RE: RE: RE: RE: RE: interpretation
> There's certainly nothing obvious in the pidin. I look at that 0x3 IRQ
> and immediately think serial port even though there's none running and
> I'm sure it's disabled in the BIOS. On top of Andrew's non-SMP, how
> about preventing IRQ3 from being used in the BIOS (reserving it) and see
> if that changes things.
I already tried it by forcing the slots to IRQ5, no change. The onboard ethernet device Broadcom 5708 which are
disabled use the same interrupt as the PCI-e slot. I have no control over that.
>
> As you can tell, we're grasping at straws here (!).
>
> One final question... Is this with io-net or io-pkt? We've got some
> tuning options in the io-pkt driver that we could play with that affects
> the interrupt capabilities...
With both. However my gut feeling tells me trying various option will not fix the root of the problem.
>
> Robert.
>
> -----Original Message-----
> From: Mario Charest [mailto:community-noreply@qnx.com]
> Sent: Tuesday, October 07, 2008 9:25 AM
> To: technology-networking
> Subject: Re: RE: RE: RE: RE: RE: interpretation
>
> > That's really weird. I've got that DID in my machine (it's a PCI
> > Express card) and there haven't been any problems with it. There's a
> > little bit of me saying that it's unlikely to be a driver problem.
> >
> > Can you post the output from "pidin irq" for us to have a look at?
>
> File attached.
>
> > the NIC isn't built in, can you move it to a different slot and see if
> > that has any effect?
>
> No it's not built in. I will try that after I'm done with the bnx
> driver.
>
> That being said I'm working on sending QSS the hardware because i've
> spend a huge amount of time on this over the past months and it's now
> time we get to the bottom of this. This is a very critical issue for
> us.
>
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Mario Charest [mailto:community-noreply@qnx.com]
> > Sent: Monday, October 06, 2008 4:53 PM
> > To: technology-networking
> > Subject: Re: RE: RE: RE: RE: interpretation
> >
> > > > > You've got a driver/hardware problem.
> > > >
> > > > Tried it with QNX4 and it works fine.
> > >
> > > Sigh.
> >
> > I know the feeling ;-)
> >
> > > Sure looks like a driver mis-configuration
> > > of your nic. Problem is, there are over SIXTY
> > > hardware variants of the i82544, and trying to
> > > write a "golden" driver which perfectly initializes
> > > all variants, can be quite difficult.
> >
> > I sympathize
> >
> > >
> > > I'm surprised the recently ported Intel driver didn't
> > > work, either - you would have thought it should have
> > > handled all of the possible variants correctly.
> >
> > Indeed, we've have had problem with the Intel card and QNX6 since the
> > beginning. Unfortunately we have no real alternative for now.
> >
> > >
> > > What is your DID?
> >
> > 10b9. Hugh once told me he tested the driver with this same DID ;-(
> >
> > >
> > > --
> > > aboyd
> >
> >
> >
> >
> > _______________________________________________
> > Technology
> > http://community.qnx.com/sf/go/post14550
>
>
>
>
> _______________________________________________
> Technology
> http://community.qnx.com/sf/go/post14590
|
|
|
|