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

> 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

OK...  Let's try something a bit different.  What's TCP performance
like?  If you do a flood ping to a board and take a kernel trace, does
your interrupt still only go off every 100ms?

	What type of board is it?

	Robert.


-----Original Message-----
From: Mario Charest [mailto:community-noreply@qnx.com] 
Sent: Tuesday, October 07, 2008 11:18 AM
To: technology-networking
Subject: 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
> > 
>...

For those who are still interested...

What we've found is related to the receive path.  We get an interrupt from the card saying that a packet has been 
received and, in our interrupt handler, we go through and check to see if any receive descriptors are available for 
processing and then process them.  It appears that we quite frequently end up with the scenario where the Rx interrupt 
goes off BUT none of the descriptors are marked as ready to be processed, so, of course, we don't do anything.  Shortly 
after this, a descriptor gets updated as ready for processing but, of course, it's already too late since we've checked 
and not found any that are ready.  This means that we often end up with the situation in which packets are left in the 
receive queue, potentially for long periods of time (depending upon the network traffic patterns).

	We're still trying to figure out what to do about this.  We don't know if it's something fundamental to the way that 
PCI Express works or if it's a card configuration issue.  We're investigating :>


	Robert.