> -----Original Message-----
> From: Hugh Brown [mailto:community-noreply@qnx.com]
> Sent: May-04-09 9:19 AM
> To: general-networking
> Subject: RE: How to find out if that's a HW fault?
> 
> The 2 drivers are there for users still using the i82544 driver.
> Eventually the i82544 driver will be dropped and the just the e1000
> driver included.
> 

Are you saying devnp-i82544 is e1000?  Because I don't see any e1000 driver in M4.

> 
> -----Original Message-----
> From: Mario Charest [mailto:community-noreply@qnx.com]
> Sent: Monday, May 04, 2009 9:17 AM
> To: general-networking
> Subject: RE: How to find out if that's a HW fault?
> 
> I was told a while ago that the e1000 driver would be available on
> 6.4.?
> Now in M4 I noticed there is a devn-i82544.so and a devnp-i82544.so.
> Why the two flavour?
> 
> > -----Original Message-----
> > From: Andrew Boyd [mailto:community-noreply@qnx.com]
> > Sent: May-04-09 9:12 AM
> > To: general-networking
> > Subject: RE: How to find out if that's a HW fault?
> >
> >
> > > Please define later version.
> >
> > For io-pkt, see r746 on 2009-01-16
> >
> > --
> > aboyd
> >
> >
> > _______________________________________________
> > General
> > http://community.qnx.com/sf/go/post28600
> >
> 
> 
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post28601
> 
> 
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post28604
> 

> -----Original Message-----
> From: Andrew Boyd [mailto:community-noreply@qnx.com]
> Sent: May-04-09 9:21 AM
> To: general-networking
> Subject: RE: How to find out if that's a HW fault?
> 
> In the past, people have whined (with some merit) that
> there weren't enough drivers for QNX.
> 
> At least with respect to intel i82544, this is no longer
> the case.  Off the top of my head there chronologically are:
> 
> devn-i82544.so    (io-net and under shim for io-pkt)
> devnp-i82544.so   (native io-pkt)
> devnp-wm.so       (BSD io-pkt_
> devn-e1000.so     (io-net port of intel source)
> devnp-e1000.so    (native io-pkt port of intel source)
> 
> I probably have forgotten some.
> 
> Going forward, we hope 

I hope too because this is killing us  (over dramatic).

If only there was another 1G alternative.

> that the e1000 driver
> variants can provide the performance, reliability
> and efficiency that people need.  They should work
> with all hardware variants - which is a very big
> deal with i82544.


> 
> --
> aboyd
> 
> 
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post28605
> 

> Please can you supply me with the 'pci -v' output as well as how to
> reproduce the problem.
> 
I do not have "pci -v" output yet, but this is what I've been told.

For 1 month the machine was running fine while en0 was used for network (QNet + TCP). We also used exactly the same 
computer configuration in previous installations. Then we had to add a driver that needs to communicate with hardware by
 UDP broadcasts and we had to make dedicated connection to it. However there were configuration limitations in the 
driver and we could not put it on en1. Instead we have moved main network to en1 and configured hardware device on en0.
First of all, there was a problem that when the hardware-dedicated ethernet (EN0) was not plugged in the network started
 to return "no buffer space available" on broadcast attempts. As soon as we have plugged in a cable and inserted it into
 an empty switch those errors were gone.
But also, since the time of employing en1, it started to go offline every few hours. Well, I suspect it was that way 
ever, we just never used and never checked if it was alive.
The last few days machine was running with our hardware driver disabled and EN0 unplugged (so that there was no traffic 
on it), but still there problem with EN1 dropping offline did not go away.  Even more, we have moved main network back 
to en0 and just connected a cable to en1 now and then to see if it still functioning, but the problem remained.
The new driver did not solve it and what's a little bit strange, even after restoring original /etc/system/enum/devices/
net back to have i82544 loaded for device again, the connection was slow after fault again, as if the server was 
overloaded. However this was just one test and I can't be sure that there was not some mistake and that the information 
about slowdown remaining after rollback to old driver is correct.
That's all I can tell about how the problem can be reproduced. There are no specific actions we could do to make it 
fault.

Hi Hugh,

At last, they've sent me the 'pci -v' output. Here it is

=================================

PCI version    = 3.00

Class          = Bridge (Host/PCI)
Vendor ID      = 8086h, Intel Corporation 
Device ID      = 2970h,  Memory Controller Hub
PCI index      = 0h
Class Codes    = 060000h
Revision ID    = 2h
Bus number     = 0
Device number  = 0
Function num   = 0
Status Reg     = 2090h
Command Reg    = 106h
Header type    = 0h Single-function
BIST           = 0h Build-in-self-test not supported
Latency Timer  = 0h
Cache Line Size= 0h 
Subsystem Vendor ID = 15d9h
Subsystem ID        = b580h
Max Lat        = 0ns
Min Gnt        = 0ns
PCI Int Pin    = NC
Interrupt line = 0
CPU Interrupt  = 0h
Capabilities Pointer = e0h
Capability ID        = 9h - Vendor Specific
Capabilities         = 9109h - cb000368h

Class          = Display (VGA)
Vendor ID      = 8086h, Intel Corporation 
Device ID      = 2972h,  Integrated Graphics Controller
PCI index      = 0h
Class Codes    = 030000h
Revision ID    = 2h
Bus number     = 0
Device number  = 2
Function num   = 0
Status Reg     = 90h
Command Reg    = 7h
Header type    = 0h Single-function
BIST           = 0h Build-in-self-test not supported
Latency Timer  = 0h
Cache Line Size= 0h 
PCI Mem Address = d0000000h 32bit length 1048576 enabled
PCI Mem Address = c0000000h prefetchable 64bit length 268435456 enabled
PCI IO Address  = 30c0h length 8 enabled
Subsystem Vendor ID = 15d9h
Subsystem ID        = b580h
Max Lat        = 0ns
Min Gnt        = 0ns
PCI Int Pin    = INT A
Interrupt line = 10
CPU Interrupt  = ah
Capabilities Pointer = 90h
Capability ID        = 5h - Message Signaled Interrupts
Capabilities         = 0h - 0h
Capability ID        = 1h - Power Management
Capabilities         = 22h - 0h

Class          = Bridge (PCI/PCI)
Vendor ID      = 8086h, Intel Corporation 
Device ID      = 27d0h,  82801G (ICH7 Family) PCI Express Port 1
PCI index      = 0h
Class Codes    = 060400h
Revision ID    = 1h
Bus number     = 0
Device number  = 28
Function num   = 0
Status Reg     = 10h
Command Reg    = 4h
Header type    = 1h Multi-function
BIST           = 0h Build-in-self-test not supported
Latency Timer  = 0h
Cache Line Size= 8h un-cacheable
Primary Bus Number       = 0h
Secondary Bus Number     = 2h
Subordinate Bus Number   = 2h
Secondary Latency Timer  = 0h
I/O Base                 = f0h
I/O Limit                = 0h
Secondary Status         = 2000h
Memory Base              = fff0h
Memory Limit             = 0h
Prefetchable Memory Base = fff1h
Prefetchable Memory Limit= 1h
Prefetchable Base Upper 32 Bits  = 0h
Prefetchable Limit Upper 32 Bits = 0h
I/O Base Upper 16 Bits   = 0h
I/O Limit Upper 16 Bits  = 0h
Bridge Control           = 0h
PCI Int Pin              = INT A
Interrupt line           = 10
CPU Interrupt            = ah
Capabilities Pointer = 40h
Capability ID        = 10h - PCI Express
Capabilities         = 141h - fc0h
Capability ID        = 5h - Message Signaled Interrupts
Capabilities         = 0h - 0h
Capability ID        = dh - PCI Bridge Subsystem Vendor ID
Capabilities         = 0h - b58015d9h
Capability ID        = 1h - Power Management
Capabilities         = c802h - 0h

Class          = Bridge (PCI/PCI)
Vendor ID      = 8086h, Intel Corporation 
Device ID      = 27e0h,  82801GR/GH/GHM (ICH7 Family) PCI Express Port 5
PCI index      = 0h
Class Codes    = 060400h
Revision ID    = 1h
Bus number     = 0
Device number  = 28
Function num   = 4
Status Reg     = 10h
Command Reg    = 7h
Header type    = 1h Multi-function
BIST           = 0h Build-in-self-test not supported
Latency Timer  = 0h
Cache Line Size= 8h un-cacheable
Primary Bus Number       = 0h
Secondary Bus Number     = 6h
Subordinate Bus Number   = 6h
Secondary Latency Timer  = 0h
I/O Base                 = 40h
I/O Limit                = 40h
Secondary Status         = 2000h
Memory Base           ...