Project Home
Project Home		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
Networking/Discussion/Technology/interpretation/List of Posts
Forum Topic - interpretation: Page 1 of 2 (37 Items)
   
Update
Mario Charest
10/03/2008 10:54 AM
post14421
interpretation   
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
RE: interpretation   
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
Re: RE: interpretation   
> 
> 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
Re: RE: interpretation   
> 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
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.

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
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)
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
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
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)
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
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
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)
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
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)
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
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
Attachment: Text pidin.txt 2.6 KB
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
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)
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
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
Robert Craig
10/07/2008 10:29 AM
post14606
RE: interpretation   
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
RE: interpretation   
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:

  http://www.pittspecials.com/images/eric_l39.jpg

which is fun to fly, but a tad hard on fuel.

--
aboyd
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)
10/07/2008 11:14 AM
post14610
RE: RE: RE: RE: RE: RE: RE: interpretation   
What about a different interrupt?

--
aboyd
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
12Next

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems