Are you able to configure the Broadcom switch? It might be that the switch
is sending vlan packets or jumbo frames to the driver.

-- 
Hugh Brown
QNX Software Systems Limited
175 Terence Matthews Crescent,
Ottawa. ON. K2M 1W8.
Telephone: 613-591-0931







On 11-11-01 11:13 AM, "Joe Krachey" <community-noreply@qnx.com> wrote:

>I confirmed that our card functions correctly using both the e1000 and
>i82544 drivers in a different chassis that contains a different network
>switch. (Kontron uTCA Chassis)
>
>I've also confirmed that the Linux is able to correctly use the network
>interface on the Performance Technologies uTCA Chassis (AMP5070 - the
>chassis where QNX hangs).   Our card used to function properly until the
>network card in the AMP5070 was changed to the broadcom 5396 in the
>latest version of this chassis.  Since our QNX port does not hang until
>I plug the ethernet cable in, I would guess the hang occurs when trying
>trying to parse the data packets being received from the ethernet
>switch.  My guess is that the Broadcom switch is sending data in a
>format that the e1000 andn i82544 drivers are not expecting.
>
>Do you have any recommendations for printing out the data packets as
>they are received to determine where the driver is dying?
>
>-Joe
>
>
>On Thursday, October 27, 2011 12:08:35 PM, Joe Krachey wrote:
>>
>> The -i0 did not work. I think it tries to create two instances of the
>> driver because the 82546 is a dual port GBE controller.
>>
>> I'm able to successfully load the e1000 driver if I un-plug the
>> ethernet cable from the RJ45 Jack. As soon as I plug the ethernet
>> cable in, the board hangs. The same thing happens with thh i82544
>> driver. The other thing to note is that we are using the fiber
>> interfaces on the 82456.
>>
>> FYI... I'm only in the office on Tuesday/Thursday mornings, so I won't
>> be able to run any additional tests until next week.
>>
>> -Joe
>>
>> On Thursday, October 27, 2011 11:30:24 AM, Hugh Brown wrote:
>>>
>>>
>>> It appears that there is something wrong on the PCI bus, as the
>>> driver is
>>> trying to start 2 instances of itself on the same device. I think
>>> that the
>>> command line option is '-i0' to only start the first instance of the
>>> driver.
>>>
>>
>>
>>
>
>
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post89805
>

There are some configuration settings we can change to configure the 
switch.   we are checking with our customer if they have any 
requirements to use VLANs or jumbo frames...

On Tuesday, November 01, 2011 10:24:47 AM, Hugh Brown wrote:
> Are you able to configure the Broadcom switch? It might be that the switch
> is sending vlan packets or jumbo frames to the driver.
>

Hugh,

We finally were able to get the proper cabling allowing us to configure 
the the switch.  Jumbo Frames were disabled by default.  This made no 
difference, the card still hung.  The switch is configured so that all 
ports are on a single VLAN.  How would this make a difference to the 
e1000 driver?

Is there a way to provide any extra debugging information for you to 
take a look at?  We are also open to allowing remote access to the 
system if that would help.

-Joe

On 11/1/2011 10:24 AM, Hugh Brown wrote:
> Are you able to configure the Broadcom switch? It might be that the switch
> is sending vlan packets or jumbo frames to the driver.
>

You said in a previous post that the driver works in a different chassis,
so that is where I would start looking. What are the differences between
the 2 chassis? I am still convinced that this is an interrupt problem.

It isn't much use giving me remote access if the machine hangs when the
driver is started. The fact that the machine doesn't hang when the cable
is removed is because the driver isn't receiving any interrupts. As soon
as you plug the cable in, the driver receives a link interrupt, so that is
why I am saying the the problem is most probably that the driver is
getting an incorrect interrupt assigned to it.

-- 
Hugh Brown
QNX Software Systems Limited
175 Terence Matthews Crescent,
Ottawa. ON. K2M 1W8.
Telephone: 613-591-0931







On 11-11-11 6:34 PM, "Joe Krachey" <community-noreply@qnx.com> wrote:

>Hugh,
>
>We finally were able to get the proper cabling allowing us to configure
>the the switch.  Jumbo Frames were disabled by default.  This made no
>difference, the card still hung.  The switch is configured so that all
>ports are on a single VLAN.  How would this make a difference to the
>e1000 driver?
>
>Is there a way to provide any extra debugging information for you to
>take a look at?  We are also open to allowing remote access to the
>system if that would help.
>
>-Joe
>
>On 11/1/2011 10:24 AM, Hugh Brown wrote:
>> Are you able to configure the Broadcom switch? It might be that the
>>switch
>> is sending vlan packets or jumbo frames to the driver.
>>
>
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post90058
>

I'm looking into the differences in the network switches with the 
chassis vendor.

I don't think this is an interrupt issue.  The switch that changed is 
external to our card.   Its only connection to our card is through a 
PHY, so the network packets it sends would have no interrupt information 
to contained in them.  If it was an interrupt issue,  both of these 
drivers would fail when connecting to any external switch, which is not 
the case.  It would also not explain why the monitor and linux function 
correctly in the same chassis.

-Joe

On 11/14/2011 6:49 AM, Hugh Brown wrote:
> You said in a previous post that the driver works in a different chassis,
> so that is where I would start looking. What are the differences between
> the 2 chassis? I am still convinced that this is an interrupt problem.
>
> It isn't much use giving me remote access if the machine hangs when the
> driver is started. The fact that the machine doesn't hang when the cable
> is removed is because the driver isn't receiving any interrupts. As soon
> as you plug the cable in, the driver receives a link interrupt, so that is
> why I am saying the the problem is most probably that the driver is
> getting an incorrect interrupt assigned to it.
>

Please can you give me a better explanation of your setup. Are your
processor board and Ethernet adapter(s) in the new chassis? Is the e1000
adapter on your processor board or is it on the backplane of the new
chassis? Is the switch part of the chassis or is a separate device? What
is the difference between the old chassis and the new one?

The e1000 driver has been tested on multiple platforms as well as with
multiple different e1000 adapters, so that is why I don't think that this
is a driver related problem.

Thanks, Hugh.
 
-- 
Hugh Brown
QNX Software Systems Limited
175 Terence Matthews Crescent,
Ottawa. ON. K2M 1W8.
Telephone: 613-591-0931







On 11-11-17 9:21 AM, "Joe Krachey" <community-noreply@qnx.com> wrote:

>I'm looking into the differences in the network switches with the
>chassis vendor.
>
>I don't think this is an interrupt issue.  The switch that changed is
>external to our card.   Its only connection to our card is through a
>PHY, so the network packets it sends would have no interrupt information
>to contained in them.  If it was an interrupt issue,  both of these
>drivers would fail when connecting to any external switch, which is not
>the case.  It would also not explain why the monitor and linux function
>correctly in the same chassis.
>
>-Joe
>
>On 11/14/2011 6:49 AM, Hugh Brown wrote:
>> You said in a previous post that the driver works in a different
>>chassis,
>> so that is where I would start looking. What are the differences between
>> the 2 chassis? I am still convinced that this is an interrupt problem.
>>
>> It isn't much use giving me remote access if the machine hangs when the
>> driver is started. The fact that the machine doesn't hang when the cable
>> is removed is because the driver isn't receiving any interrupts. As soon
>> as you plug the cable in, the driver receives a link interrupt, so that
>>is
>> why I am saying the the problem is most probably that the driver is
>> getting an incorrect interrupt assigned to it.
>>
>
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post90150
>

Our card, the XPedite6244, is a mezzanine card based on a MPC7448 with 
an dual Intel 82546 Network controller and MV64460 Gig Ethernet Phys 
that are routed to the backplane.

Our card then plugs into a PTI5071 uTCA chassis.  The PTI50701 has built 
in 16 port Broadcom BCM5396 ethernet switch which is routes 2 of those 
ports to the mezzaine slot of our card.  One for each  ethernet port.

 From the PTI FAE (we have a meeting later today to discuss this in more 
detail):
To answer your high level question the main difference in the 5070 and 
5071 is the fact that the 5071 has a 16 port switch vs. 8 port on 5070. 
This means that dual GigE connections are routed to each AMC bay on 
5071, compared to single GigE connection to AMCs on 5070.

The e1000/i82544 driver is loaded on the XPedite6244.  The driver works 
correctly when communicating with the older version of the external BCM 
8 port ethernet switch.  When we attempt to connect to the 16 port 
BCM5396, the driver causes the card hang.  Both connections are mode 
over the PHY as they are both external to the card running the e1000 driver.



-Joe

On 11/17/2011 9:47 AM, Hugh Brown wrote:
> Please can you give me a better explanation of your setup. Are your
> processor board and Ethernet adapter(s) in the new chassis? Is the e1000
> adapter on your processor board or is it on the backplane of the new
> chassis? Is the switch part of the chassis or is a separate device? What
> is the difference between the old chassis and the new one?
>
> The e1000 driver has been tested on multiple platforms as well as with
> multiple different e1000 adapters, so that is why I don't think that this
> is a driver related problem.
>
> Thanks, Hugh.
>

Just to clarify, there is only a single Intel 82546 Network controller, 
but it has two ports.

Since both ports are routed to the same VLAN on the external ethernet 
switch (i.e. the same subnet for each port) does this cause problems for 
the driver even if if_up has not been called?  This causes problems in 
Linux, but only if both ports are brought up at the same time)

-Joe

On 11/17/2011 10:10 AM, Joe Krachey wrote:
> Our card, the XPedite6244, is a mezzanine card based on a MPC7448 with 
> an dual Intel 82546 Network controller and MV64460 Gig Ethernet Phys 
> that are routed to the backplane.
>
> Our card then plugs into a PTI5071 uTCA chassis.  The PTI50701 has 
> built in 16 port Broadcom BCM5396 ethernet switch which is routes 2 of 
> those ports to the mezzaine slot of our card.  One for each  ethernet 
> port.
>
> From the PTI FAE (we have a meeting later today to discuss this in 
> more detail):
> To answer your high level question the main difference in the 5070 and 
> 5071 is the fact that the 5071 has a 16 port switch vs. 8 port on 
> 5070. This means that dual GigE connections are routed to each AMC bay 
> on 5071, compared to single GigE connection to AMCs on 5070.
>
> The e1000/i82544 driver is loaded on the XPedite6244.  The driver 
> works correctly when communicating with the older version of the 
> external BCM 8 port ethernet switch.  When we attempt to connect to 
> the 16 port BCM5396, the driver causes the card hang.  Both 
> connections are mode over the PHY as they are both external to the 
> card running the e1000 driver.
>
>
>
> -Joe
>
> On 11/17/2011 9:47 AM, Hugh Brown wrote:
>> Please can you give me a better explanation of your setup. Are your
>> processor board and Ethernet adapter(s) in the new chassis? Is the e1000
>> adapter on your processor board or is it on the backplane of the new
>> chassis? Is the switch part of the chassis or is a separate device? What
>> is the difference between the old chassis and the new one?
>>
>> The e1000 driver has been tested on multiple platforms as well as with
>> multiple different e1000 adapters, so that is why I don't think that this
>> is a driver related problem.
>>
>> Thanks, Hugh.
>>
>

Both interfaces being on the same VLAN shouldn't cause a problem for the
driver, but will cause a problem for io-pkt. This still shouldn't cause
the driver to lock up. If you only start one port (io-pkt-v4 -de1000
pci=0) does the driver still hang? Sorry if I have asked this before, but
it has been a while!

-- 
Hugh Brown
QNX Software Systems Limited
175 Terence Matthews Crescent,
Ottawa. ON. K2M 1W8.
Telephone: 613-591-0931







On 11-11-17 11:21 AM, "Joe Krachey" <community-noreply@qnx.com> wrote:

>Just to clarify, there is only a single Intel 82546 Network controller,
>but it has two ports.
>
>Since both ports are routed to the same VLAN on the external ethernet
>switch (i.e. the same subnet for each port) does this cause problems for
>the driver even if if_up has not been called?  This causes problems in
>Linux, but only if both ports are brought up at the same time)
>
>-Joe
>
>On 11/17/2011 10:10 AM, Joe Krachey wrote:
>> Our card, the XPedite6244, is a mezzanine card based on a MPC7448 with
>> an dual Intel 82546 Network controller and MV64460 Gig Ethernet Phys
>> that are routed to the backplane.
>>
>> Our card then plugs into a PTI5071 uTCA chassis.  The PTI50701 has
>> built in 16 port Broadcom BCM5396 ethernet switch which is routes 2 of
>> those ports to the mezzaine slot of our card.  One for each  ethernet
>> port.
>>
>> From the PTI FAE (we have a meeting later today to discuss this in
>> more detail):
>> To answer your high level question the main difference in the 5070 and
>> 5071 is the fact that the 5071 has a 16 port switch vs. 8 port on
>> 5070. This means that dual GigE connections are routed to each AMC bay
>> on 5071, compared to single GigE connection to AMCs on 5070.
>>
>> The e1000/i82544 driver is loaded on the XPedite6244.  The driver
>> works correctly when communicating with the older version of the
>> external BCM 8 port ethernet switch.  When we attempt to connect to
>> the 16 port BCM5396, the driver causes the card hang.  Both
>> connections are mode over the PHY as they are both external to the
>> card running the e1000 driver.
>>
>>
>>
>> -Joe
>>
>> On 11/17/2011 9:47 AM, Hugh Brown wrote:
>>> Please can you give me a better explanation of your setup. Are your
>>> processor board and Ethernet adapter(s) in the new chassis? Is the
>>>e1000
>>> adapter on your processor board or is it on the backplane of the new
>>> chassis? Is the switch part of the chassis or is a separate device?
>>>What
>>> is the difference between the old chassis and the new one?
>>>
>>> The e1000 driver has been tested on multiple platforms as well as with
>>> multiple different e1000 adapters, so that is why I don't think that
>>>this
>>> is a driver related problem.
>>>
>>> Thanks, Hugh.
>>>
>>
>
>
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post90158
>

It still hangs. This is the command line I used to bring the driver up. 

# slay io-net 
# slay dhcp.client 
# io-net -d mv64360 memrange=0xf1000000,deviceindex=0,verbose=4 -io-pkt-v4 -d e1000 -vvvv duplex=1,speed=1000 -ptcpip 
pci=0 
# 
Shutdown[0,0] S/C/F=5/2/6 C/D=00207970/0026277c state(cdfd4)= now lock exit 4 
QNX Version 6.3.2 Release 2006/03/16-14:18:26EST 
[0]PID-TID=1-1? P/T FL=00019001/08000000 "proc/boot/procnto-600" 
[0]ASPACE PID=40967 PF=00401010 "proc/boov`-net" 
ppcbe context[036d9080]: 
0000: 40000000 036d9130 00267658 40000010 00000002 31000024 00000000 00000000 
0020: 00000002 00000004 00000000 00000003 73297a40 00269610 00000062 00000000 
0040: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00262778 
0060: 00008000 00000001 002621f8 00000000 0000f000 000cdfd3 036d9140 0f7f56f0 
0080: 002444c4 0f7e9040 00021032 0f7e90dc 44000000 20000000 00000000 00000000 
00a0: 00000000 
instruction[0f7e90dc]: 
0f 7f 56 f0 00 24 44 c4 0f 7e 98 bc 00 20 90 32 00 23 e7 b8 44 00 00 00 20 00 
stack[036d9130]: 
0000: 00000000 00000000 00000000 00000000 00009032 036d91f0 00267658 0f7eb650 
0020: 00000000 0000000f 00000000 311003c0 00000002 00000004 00000000 00000003 
0040: 73297a40 00269610 00000062 0f7eb650 00000000 00000000 00000000 00000000 
0060: 00000000 00000000 00000000 00262778 00008000 00000001 002621f8 00000000 


----- Original Message -----

From: "Hugh Brown" <community-noreply@qnx.com> 
To: "drivers-networking" <post90159@community.qnx.com> 
Sent: Thursday, November 17, 2011 10:26:31 AM 
Subject: Re: devn-i82544 hang 

Both interfaces being on the same VLAN shouldn't cause a problem for the 
driver, but will cause a problem for io-pkt. This still shouldn't cause 
the driver to lock up. If you only start one port (io-pkt-v4 -de1000 
pci=0) does the driver still hang? Sorry if I have asked this before, but 
it has been a while! 

-- 
Hugh Brown 
QNX Software Systems Limited 
175 Terence Matthews Crescent, 
Ottawa. ON. K2M 1W8. 
Telephone: 613-591-0931 







On 11-11-17 11:21 AM, "Joe Krachey" <community-noreply@qnx.com> wrote: 

>Just to clarify, there is only a single Intel 82546 Network controller, 
>but it has two ports. 
> 
>Since both ports are routed to the same VLAN on the external ethernet 
>switch (i.e. the same subnet for each port) does this cause problems for 
>the driver even if if_up has not been called? This causes problems in 
>Linux, but only if both ports are brought up at the same time) 
> 
>-Joe 
> 
>On 11/17/2011 10:10 AM, Joe Krachey wrote: 
>> Our card, the XPedite6244, is a mezzanine card based on a MPC7448 with 
>> an dual Intel 82546 Network controller and MV64460 Gig Ethernet Phys 
>> that are routed to the backplane. 
>> 
>> Our card then plugs into a PTI5071 uTCA chassis. The PTI50701 has 
>> built in 16 port Broadcom BCM5396 ethernet switch which is routes 2 of 
>> those ports to the mezzaine slot of our card. One for each ethernet 
>> port. 
>> 
>> From the PTI FAE (we have a meeting later today to discuss this in 
>> more detail): 
>> To answer your high level question the main difference in the 5070 and 
>> 5071 is the fact that the 5071 has a 16 port switch vs. 8 port on 
>> 5070. This means that dual GigE connections are routed to each AMC bay 
>> on 5071, compared to single GigE connection to AMCs on 5070. 
>> 
>> The e1000/i82544 driver is loaded on the XPedite6244. The driver 
>> works correctly when communicating with the older version of the 
>> external BCM 8 port ethernet switch. When we attempt to connect to 
>> the 16 port BCM5396, the driver causes the card hang. Both 
>> connections are mode over the PHY as they are both external to the 
>> card running the e1000 driver. 
>> 
>>...

Please don't start any other drivers. Just run "io-pkt-v4 -de1000
verbose=4,pci=0".

-- 
Hugh Brown
QNX Software Systems Limited
175 Terence Matthews Crescent,
Ottawa. ON. K2M 1W8.
Telephone: 613-591-0931







On 11-11-17 11:54 AM, "Joe Krachey" <community-noreply@qnx.com> wrote:

>It still hangs. This is the command line I used to bring the driver up.
>
># slay io-net 
># slay dhcp.client
># io-net -d mv64360 memrange=0xf1000000,deviceindex=0,verbose=4
>-io-pkt-v4 -d e1000 -vvvv duplex=1,speed=1000 -ptcpip pci=0
># 
>Shutdown[0,0] S/C/F=5/2/6 C/D=00207970/0026277c state(cdfd4)= now lock
>exit 4 
>QNX Version 6.3.2 Release 2006/03/16-14:18:26EST
>[0]PID-TID=1-1? P/T FL=00019001/08000000 "proc/boot/procnto-600"
>[0]ASPACE PID=40967 PF=00401010 "proc/boov`-net"
>ppcbe context[036d9080]:
>0000: 40000000 036d9130 00267658 40000010 00000002 31000024 00000000
>00000000 
>0020: 00000002 00000004 00000000 00000003 73297a40 00269610 00000062
>00000000 
>0040: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>00262778 
>0060: 00008000 00000001 002621f8 00000000 0000f000 000cdfd3 036d9140
>0f7f56f0 
>0080: 002444c4 0f7e9040 00021032 0f7e90dc 44000000 20000000 00000000
>00000000 
>00a0: 00000000 
>instruction[0f7e90dc]:
>0f 7f 56 f0 00 24 44 c4 0f 7e 98 bc 00 20 90 32 00 23 e7 b8 44 00 00 00
>20 00 
>stack[036d9130]: 
>0000: 00000000 00000000 00000000 00000000 00009032 036d91f0 00267658
>0f7eb650 
>0020: 00000000 0000000f 00000000 311003c0 00000002 00000004 00000000
>00000003 
>0040: 73297a40 00269610 00000062 0f7eb650 00000000 00000000 00000000
>00000000 
>0060: 00000000 00000000 00000000 00262778 00008000 00000001 002621f8
>00000000 
>
>
>----- Original Message -----
>
>From: "Hugh Brown" <community-noreply@qnx.com>
>To: "drivers-networking" <post90159@community.qnx.com>
>Sent: Thursday, November 17, 2011 10:26:31 AM
>Subject: Re: devn-i82544 hang
>
>Both interfaces being on the same VLAN shouldn't cause a problem for the
>driver, but will cause a problem for io-pkt. This still shouldn't cause
>the driver to lock up. If you only start one port (io-pkt-v4 -de1000
>pci=0) does the driver still hang? Sorry if I have asked this before, but
>it has been a while!
>
>-- 
>Hugh Brown 
>QNX Software Systems Limited
>175 Terence Matthews Crescent,
>Ottawa. ON. K2M 1W8.
>Telephone: 613-591-0931
>
>
>
>
>
>
>
>On 11-11-17 11:21 AM, "Joe Krachey" <community-noreply@qnx.com> wrote:
>
>>Just to clarify, there is only a single Intel 82546 Network controller,
>>but it has two ports.
>> 
>>Since both ports are routed to the same VLAN on the external ethernet
>>switch (i.e. the same subnet for each port) does this cause problems for
>>the driver even if if_up has not been called? This causes problems in
>>Linux, but only if both ports are brought up at the same time)
>> 
>>-Joe 
>> 
>>On 11/17/2011 10:10 AM, Joe Krachey wrote:
>>> Our card, the XPedite6244, is a mezzanine card based on a MPC7448 with
>>> an dual Intel 82546 Network controller and MV64460 Gig Ethernet Phys
>>> that are routed to the backplane.
>>> 
>>> Our card then plugs into a PTI5071 uTCA chassis. The PTI50701 has
>>> built in 16 port Broadcom BCM5396 ethernet switch which is routes 2 of
>>> those ports to the mezzaine slot of our card. One for each ethernet
>>> port. 
>>> 
>>> From the PTI FAE (we have a meeting later today to discuss this in
>>> more detail): 
>>> To answer your high level question the main difference in the 5070 and
>>> 5071 is the fact that the...

This is the output. Note that en0, and en0 are the front panel ethernet interfaces. The back panel interfaces should be 
en2 and en3. This did not hang the card, but it also didn't find the network ports. 

# io-pkt-v4 -de1000 verbose=4,pci=0 
ksh: io-pkt-v4: not found 
# io-net -io-pkt-v4 -de1000 verbose=4,pci=0 
# 
# 
# 
# 
# 
# ls /dev/io-net/* 
/dev/io-net/en0 /dev/io-net/ip0 
/dev/io-net/en1 /dev/io-net/ip_en 

I probably won't have much time to work on this until next week, but if I find out anything noteworthy before then, I 
will send it your way. 


----- Original Message -----

From: "Hugh Brown" <community-noreply@qnx.com> 
To: "drivers-networking" <post90162@community.qnx.com> 
Sent: Thursday, November 17, 2011 11:03:05 AM 
Subject: Re: devn-i82544 hang 

Please don't start any other drivers. Just run "io-pkt-v4 -de1000 
verbose=4,pci=0". 

-- 
Hugh Brown 
QNX Software Systems Limited 
175 Terence Matthews Crescent, 
Ottawa. ON. K2M 1W8. 
Telephone: 613-591-0931 







On 11-11-17 11:54 AM, "Joe Krachey" <community-noreply@qnx.com> wrote: 

>It still hangs. This is the command line I used to bring the driver up. 
> 
># slay io-net 
># slay dhcp.client 
># io-net -d mv64360 memrange=0xf1000000,deviceindex=0,verbose=4 
>-io-pkt-v4 -d e1000 -vvvv duplex=1,speed=1000 -ptcpip pci=0 
># 
>Shutdown[0,0] S/C/F=5/2/6 C/D=00207970/0026277c state(cdfd4)= now lock 
>exit 4 
>QNX Version 6.3.2 Release 2006/03/16-14:18:26EST 
>[0]PID-TID=1-1? P/T FL=00019001/08000000 "proc/boot/procnto-600" 
>[0]ASPACE PID=40967 PF=00401010 "proc/boov`-net" 
>ppcbe context[036d9080]: 
>0000: 40000000 036d9130 00267658 40000010 00000002 31000024 00000000 
>00000000 
>0020: 00000002 00000004 00000000 00000003 73297a40 00269610 00000062 
>00000000 
>0040: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
>00262778 
>0060: 00008000 00000001 002621f8 00000000 0000f000 000cdfd3 036d9140 
>0f7f56f0 
>0080: 002444c4 0f7e9040 00021032 0f7e90dc 44000000 20000000 00000000 
>00000000 
>00a0: 00000000 
>instruction[0f7e90dc]: 
>0f 7f 56 f0 00 24 44 c4 0f 7e 98 bc 00 20 90 32 00 23 e7 b8 44 00 00 00 
>20 00 
>stack[036d9130]: 
>0000: 00000000 00000000 00000000 00000000 00009032 036d91f0 00267658 
>0f7eb650 
>0020: 00000000 0000000f 00000000 311003c0 00000002 00000004 00000000 
>00000003 
>0040: 73297a40 00269610 00000062 0f7eb650 00000000 00000000 00000000 
>00000000 
>0060: 00000000 00000000 00000000 00262778 00008000 00000001 002621f8 
>00000000 
> 
> 
>----- Original Message ----- 
> 
>From: "Hugh Brown" <community-noreply@qnx.com> 
>To: "drivers-networking" <post90159@community.qnx.com> 
>Sent: Thursday, November 17, 2011 10:26:31 AM 
>Subject: Re: devn-i82544 hang 
> 
>Both interfaces being on the same VLAN shouldn't cause a problem for the 
>driver, but will cause a problem for io-pkt. This still shouldn't cause 
>the driver to lock up. If you only start one port (io-pkt-v4 -de1000 
>pci=0) does the driver still hang? Sorry if I have asked this before, but 
>it has been a while! 
> 
>-- 
>Hugh Brown 
>QNX Software Systems Limited 
>175 Terence Matthews Crescent, 
>Ottawa. ON. K2M 1W8. 
>Telephone: 613-591-0931 
> 
> 
> 
> 
> 
> 
> 
>On 11-11-17 11:21 AM, "Joe Krachey" <community-noreply@qnx.com> wrote: 
> 
>>Just to clarify, there is only a single Intel 82546 Network controller, 
>>but it has two ports. 
>> 
>>Since both ports are routed to the same VLAN on the external ethernet 
>>switch (i.e. the same subnet for each port) does this cause problems for 
>>the driver even if if_up has not been called? This causes problems in 
>>Linux, but only if both ports...

The io-pkt driver should create wm0/1 interfaces. io-net creates en0/1
interfaces. So are the 2 e1000 interfaces connected to the back panel? If
so, they should be wm0 and wm1 if you run nicinfo.

-- 
Hugh Brown
QNX Software Systems Limited
175 Terence Matthews Crescent,
Ottawa. ON. K2M 1W8.
Telephone: 613-591-0931







On 11-11-17 12:21 PM, "Joe Krachey" <community-noreply@qnx.com> wrote:

>This is the output. Note that en0, and en0 are the front panel ethernet
>interfaces. The back panel interfaces should be en2 and en3. This did not
>hang the card, but it also didn't find the network ports.
>
># io-pkt-v4 -de1000 verbose=4,pci=0
>ksh: io-pkt-v4: not found
># io-net -io-pkt-v4 -de1000 verbose=4,pci=0
># 
># 
># 
># 
># 
># ls /dev/io-net/*
>/dev/io-net/en0 /dev/io-net/ip0
>/dev/io-net/en1 /dev/io-net/ip_en
>
>I probably won't have much time to work on this until next week, but if I
>find out anything noteworthy before then, I will send it your way.
>
>
>----- Original Message -----
>
>From: "Hugh Brown" <community-noreply@qnx.com>
>To: "drivers-networking" <post90162@community.qnx.com>
>Sent: Thursday, November 17, 2011 11:03:05 AM
>Subject: Re: devn-i82544 hang
>
>Please don't start any other drivers. Just run "io-pkt-v4 -de1000
>verbose=4,pci=0". 
>
>-- 
>Hugh Brown 
>QNX Software Systems Limited
>175 Terence Matthews Crescent,
>Ottawa. ON. K2M 1W8.
>Telephone: 613-591-0931
>
>
>
>
>
>
>
>On 11-11-17 11:54 AM, "Joe Krachey" <community-noreply@qnx.com> wrote:
>
>>It still hangs. This is the command line I used to bring the driver up.
>> 
>># slay io-net 
>># slay dhcp.client
>># io-net -d mv64360 memrange=0xf1000000,deviceindex=0,verbose=4
>>-io-pkt-v4 -d e1000 -vvvv duplex=1,speed=1000 -ptcpip pci=0
>># 
>>Shutdown[0,0] S/C/F=5/2/6 C/D=00207970/0026277c state(cdfd4)= now lock
>>exit 4 
>>QNX Version 6.3.2 Release 2006/03/16-14:18:26EST
>>[0]PID-TID=1-1? P/T FL=00019001/08000000 "proc/boot/procnto-600"
>>[0]ASPACE PID=40967 PF=00401010 "proc/boov`-net"
>>ppcbe context[036d9080]:
>>0000: 40000000 036d9130 00267658 40000010 00000002 31000024 00000000
>>00000000 
>>0020: 00000002 00000004 00000000 00000003 73297a40 00269610 00000062
>>00000000 
>>0040: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>>00262778 
>>0060: 00008000 00000001 002621f8 00000000 0000f000 000cdfd3 036d9140
>>0f7f56f0 
>>0080: 002444c4 0f7e9040 00021032 0f7e90dc 44000000 20000000 00000000
>>00000000 
>>00a0: 00000000 
>>instruction[0f7e90dc]:
>>0f 7f 56 f0 00 24 44 c4 0f 7e 98 bc 00 20 90 32 00 23 e7 b8 44 00 00 00
>>20 00 
>>stack[036d9130]: 
>>0000: 00000000 00000000 00000000 00000000 00009032 036d91f0 00267658
>>0f7eb650 
>>0020: 00000000 0000000f 00000000 311003c0 00000002 00000004 00000000
>>00000003 
>>0040: 73297a40 00269610 00000062 0f7eb650 00000000 00000000 00000000
>>00000000 
>>0060: 00000000 00000000 00000000 00262778 00008000 00000001 002621f8
>>00000000 
>> 
>> 
>>----- Original Message -----
>> 
>>From: "Hugh Brown" <community-noreply@qnx.com>
>>To: "drivers-networking" <post90159@community.qnx.com>
>>Sent: Thursday, November 17, 2011 10:26:31 AM
>>Subject: Re: devn-i82544 hang
>> 
>>Both interfaces being on the same VLAN shouldn't cause a problem for the
>>driver, but will cause a problem for io-pkt. This still shouldn't cause
>>the driver to lock up. If you only start one port (io-pkt-v4 -de1000
>>pci=0) does the driver still hang? Sorry if I have asked...

Hugh,

It looks like the driver cannot handle two network interfaces connected 
to the same subnet.  I was able to use the shelf management software to 
remove one of the ports from the VLAN and both the e1000 and i82544 
drivers worked as expected.  If I add the second network port back to 
the VLAN, the driver causes the card to crash.

I was not able to find a way to have both network ports enabled but load 
the driver for only one of them.

-Joe

On 11/17/2011 12:57 PM, Hugh Brown wrote:
> The io-pkt driver should create wm0/1 interfaces. io-net creates en0/1
> interfaces. So are the 2 e1000 interfaces connected to the back panel? If
> so, they should be wm0 and wm1 if you run nicinfo.
>

Joe,

Having two interfaces on the same subnet shouldn't cause the driver/card
to crash. Can you start the e1000 driver without any command line
arguments (io-pkt-v4 -de1000) and with both interfaces disconnected. Then
ifconfig both interfaces (ifconfig wm? up) and capture the output from
nicinfo and send it to me. Also the output from 'pidin irq'.

Thanks, Hugh.

-- 
Hugh Brown
QNX Software Systems Limited
175 Terence Matthews Crescent,
Ottawa. ON. K2M 1W8.
Telephone: 613-591-0931







On 11-11-22 10:42 AM, "Joe Krachey" <community-noreply@qnx.com> wrote:

>Hugh,
>
>It looks like the driver cannot handle two network interfaces connected
>to the same subnet.  I was able to use the shelf management software to
>remove one of the ports from the VLAN and both the e1000 and i82544
>drivers worked as expected.  If I add the second network port back to
>the VLAN, the driver causes the card to crash.
>
>I was not able to find a way to have both network ports enabled but load
>the driver for only one of them.
>
>-Joe
>
>On 11/17/2011 12:57 PM, Hugh Brown wrote:
>> The io-pkt driver should create wm0/1 interfaces. io-net creates en0/1
>> interfaces. So are the 2 e1000 interfaces connected to the back panel?
>>If
>> so, they should be wm0 and wm1 if you run nicinfo.
>>
>
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post90238
>

Here are the results as you requested, without loading the marvel system controller driver, I would assume the two 
backplane ethernet interfaces will not be discovered. 
# slay io-net 
# slay dhcp.client 
# io-net -io-pkt-v4 
# 
# 
# ls /dev/io-net/ 
ls: No such file or directory (/dev/io-net/) 
# ls /dev/io-net 
ls: No such file or directory (/dev/io-net) 
# ls /dev/net-io 
ls: No such file or directory (/dev/net-io) 
# ls /dev 
console fs0p1 mem sem shmem tty 
fs0 fs0p2 null ser1 slog tymem 
fs0p0 i2c0 pci ser2 text zero 
# 
# 
# nicinfo 
nicinfo: Could not open: /dev/io-net/en0, (No such file or directory) 
# pidin -irq 
pidin: illegal option -- i 
# pidin irq 
pid tid name 
1 1 procnto 
0 0x80000000 0 --- @0x22ea14:0x0 
1 2 procnto 
1 3 procnto 
1 4 procnto 
1 5 procnto 
1 6 procnto 
1 7 procnto 
1 8 procnto 
2 1 roc/boot/heartbeat 
3 1 proc/boot/slogger 
4 1 ot/devc-sermv64x60 
4 2 ot/devc-sermv64x60 
1 0x24 553 --- =INTR 
4 3 ot/devc-sermv64x60 
2 0x26 1 --- =INTR 
5 1 c/boot/i2c-mv64460 
6 1 oc/boot/pci-mv_pmc 
12297 1 /boot/devf-generic 
12297 2 /boot/devf-generic 
12297 3 /boot/devf-generic 
16394 1 proc/boot/ksh 
40967 1 proc/boot/io-net 
40967 3 proc/boot/io-net 
40967 4 proc/boot/io-net 
94216 1 proc/boot/pidin 


Here are the results with arguments 
# slay io-net 
# slay dhcp.client 
# io-net -d mv64360 memrange=0xf1000000,deviceindex=0,verbose=4 -d mv64360 memrange=0xf1000000,deviceindex=1,verbose=4 -
d e1000 duplex=1,speed=1000 -ptcpip 
# 
# 
# 
# 
# 
# 
# ifconfig en2 up 
# ifconfig 
lo0: flags=8009<UP,LOOPBACK,MULTICAST> mtu 33212 
capabilities=7<IP4CSUM,TCP4CSUM,UDP4CSUM> 
enabled=0<> 
inet 127.0.0.1 netmask 0xff000000 
en0: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 
capabilities rx=7<IP4CSUM,TCP4CSUM,UDP4CSUM> 
capabilities tx=0<> 
enabled=0<> 
address: 00:17:3c:00:81:90 
en1: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 
capabilities rx=7<IP4CSUM,TCP4CSUM,UDP4CSUM> 
capabilities tx=0<> 
enabled=0<> 
address: 00:17:3c:00:81:91 
en2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 
capabilities=7<IP4CSUM,TCP4CSUM,UDP4CSUM> 
enabled=0<> 
address: 00:17:3c:00:81:92 
en3: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 
capabilities=7<IP4CSUM,TCP4CSUM,UDP4CSUM> 
enabled=0<> 
address: 00:17:3c:00:81:93 
# nicinfo 
Marvell MV64460 (GMII/MII) Ethernet Controller 

Link is DOWN 

Physical Node ID ........................... 00173C 008190 
Current Physical Node ID ................... 00173C 008190 
Current Operation Rate ..................... Unknown 
Active Interface Type ...................... MII 
Active PHY address ....................... 4 
Maximum Transmittable data Unit ............ 1514 
Maximum Receivable data Unit ............... 1514 
Hardware Interrupt ......................... 0x20 
Memory Aperture ............................ 0xf1000000 
Promiscuous Mode ........................... Off 
Multicast Support .......................... Enabled 

Packets Transmitted OK ..................... 0 
Bytes Transmitted OK ....................... 0 
Broadcast Packets Transmitted OK ........... 0 
Multicast Packets Transmitted OK ........... 0 

Packets Received OK ........................ 0 
Bytes Received OK .......................... 0 
Broadcast Packets Received OK .............. 0 
Multicast Packets Received OK .............. 0 

Late Collision on Transmit errors .......... 0 
Jabber detected ............................ 0 
Received packets with CRC errors ........... 0 
Packets Dropped on receive ................. 0 
Oversized Packets received ................. 0 
Short packets .............................. 0 
Total Frames experiencing Collison(s) ...... 0 
# 
# 
# pidin irq 
pid tid name 
1 1 procnto 
0 0x80000000 0 --- @0x22ea14:0x0 
1 2...

I forgot that you were running io-net and not io-pkt. The information that
you have sent doesn't help me at all, so please will you run the following:

slay io-net dhcp.client
io-net -de1000
ifconfig en0 up
ifconfig en1 up
nicinfo > file
pidin irq >> file

Send me the output 'file'. If you don't have a file system on your
unit,then you can capture the serial output and send it to me.

Thanks, Hugh.

-- 
Hugh Brown
QNX Software Systems Limited
175 Terence Matthews Crescent,
Ottawa. ON. K2M 1W8.
Telephone: 613-591-0931







On 11-11-22 12:42 PM, "Joe Krachey" <community-noreply@qnx.com> wrote:

>Here are the results as you requested, without loading the marvel system
>controller driver, I would assume the two backplane ethernet interfaces
>will not be discovered.
># slay io-net 
># slay dhcp.client
># io-net -io-pkt-v4
># 
># 
># ls /dev/io-net/ 
>ls: No such file or directory (/dev/io-net/)
># ls /dev/io-net 
>ls: No such file or directory (/dev/io-net)
># ls /dev/net-io 
>ls: No such file or directory (/dev/net-io)
># ls /dev 
>console fs0p1 mem sem shmem tty
>fs0 fs0p2 null ser1 slog tymem
>fs0p0 i2c0 pci ser2 text zero
># 
># 
># nicinfo 
>nicinfo: Could not open: /dev/io-net/en0, (No such file or directory)
># pidin -irq 
>pidin: illegal option -- i
># pidin irq 
>pid tid name 
>1 1 procnto 
>0 0x80000000 0 --- @0x22ea14:0x0
>1 2 procnto 
>1 3 procnto 
>1 4 procnto 
>1 5 procnto 
>1 6 procnto 
>1 7 procnto 
>1 8 procnto 
>2 1 roc/boot/heartbeat
>3 1 proc/boot/slogger
>4 1 ot/devc-sermv64x60
>4 2 ot/devc-sermv64x60
>1 0x24 553 --- =INTR
>4 3 ot/devc-sermv64x60
>2 0x26 1 --- =INTR
>5 1 c/boot/i2c-mv64460
>6 1 oc/boot/pci-mv_pmc
>12297 1 /boot/devf-generic
>12297 2 /boot/devf-generic
>12297 3 /boot/devf-generic
>16394 1 proc/boot/ksh
>40967 1 proc/boot/io-net
>40967 3 proc/boot/io-net
>40967 4 proc/boot/io-net
>94216 1 proc/boot/pidin
>
>
>Here are the results with arguments
># slay io-net 
># slay dhcp.client
># io-net -d mv64360 memrange=0xf1000000,deviceindex=0,verbose=4 -d
>mv64360 memrange=0xf1000000,deviceindex=1,verbose=4 -d e1000
>duplex=1,speed=1000 -ptcpip
># 
># 
># 
># 
># 
># 
># ifconfig en2 up 
># ifconfig 
>lo0: flags=8009<UP,LOOPBACK,MULTICAST> mtu 33212
>capabilities=7<IP4CSUM,TCP4CSUM,UDP4CSUM>
>enabled=0<> 
>inet 127.0.0.1 netmask 0xff000000
>en0: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>capabilities rx=7<IP4CSUM,TCP4CSUM,UDP4CSUM>
>capabilities tx=0<>
>enabled=0<> 
>address: 00:17:3c:00:81:90
>en1: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>capabilities rx=7<IP4CSUM,TCP4CSUM,UDP4CSUM>
>capabilities tx=0<>
>enabled=0<> 
>address: 00:17:3c:00:81:91
>en2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>capabilities=7<IP4CSUM,TCP4CSUM,UDP4CSUM>
>enabled=0<> 
>address: 00:17:3c:00:81:92
>en3: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>capabilities=7<IP4CSUM,TCP4CSUM,UDP4CSUM>
>enabled=0<> 
>address: 00:17:3c:00:81:93
># nicinfo 
>Marvell MV64460 (GMII/MII) Ethernet Controller
>
>Link is DOWN 
>
>Physical Node ID ........................... 00173C 008190
>Current Physical Node ID ................... 00173C 008190
>Current Operation Rate ..................... Unknown
>Active Interface Type ...................... MII
>Active PHY address ....................... 4
>Maximum Transmittable data Unit ............ 1514
>Maximum Receivable data Unit ............... 1514
>Hardware Interrupt...

Here you go. en0 and en1 are front panel ethernet interfaces that do not connect to the chassis. en2 and en3 normally 
represent the back plane network connections to the chassis. 

# slay io-net dhcp.client 
# io-net -de1000 
# ifconfig en0 up 
ifconfig: socket: Address family not supported by protocol family 
# ifconfig en1 up 
ifconfig: socket: Address family not supported by protocol family 
# ifconfig en2 up 
ifconfig: socket: Address family not supported by protocol family 
# ifconfig en3 up 
ifconfig: socket: Address family not supported by protocol family 
# nicinfo 
INTEL PRO/1000 Gigabit (Copper) Ethernet Controller 

Physical Node ID ........................... 00173C 008192 
Current Physical Node ID ................... 00173C 008192 
Current Operation Rate ..................... 1000.00 Mb/s full-duplex 
Active Interface Type ...................... MII 
Active PHY address ....................... 1 
Maximum Transmittable data Unit ............ 1514 
Maximum Receivable data Unit ............... 1514 
Hardware Interrupt ......................... 0x61 
Memory Aperture ............................ 0x80000000 - 0x8001ffff 
Promiscuous Mode ........................... Off 
Multicast Support .......................... Enabled 

Packets Transmitted OK ..................... 0 
Bytes Transmitted OK ....................... 0 
Broadcast Packets Transmitted OK ........... 0 
Multicast Packets Transmitted OK ........... 0 
Memory Allocation Failures on Transmit ..... 0 

Packets Received OK ........................ 116 
Bytes Received OK .......................... 9503 
Broadcast Packets Received OK .............. 116 
Multicast Packets Received OK .............. 0 
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 
No Carrier on Transmit ..................... 0 
Receive Alignment errors ................... 0 
Received packets with CRC errors ........... 0 
Packets Dropped on receive ................. 0 
# pidin irq 
pid tid name 
1 1 procnto 
0 0x80000000 0 --- @0x22ea14:0x0 
1 2 procnto 
1 3 procnto 
1 4 procnto 
1 5 procnto 
1 6 procnto 
1 7 procnto 
1 8 procnto 
2 1 roc/boot/heartbeat 
3 1 proc/boot/slogger 
4 1 ot/devc-sermv64x60 
4 2 ot/devc-sermv64x60 
1 0x24 1215 --- =INTR 
4 3 ot/devc-sermv64x60 
2 0x26 1 --- =INTR 
5 1 c/boot/i2c-mv64460 
6 1 oc/boot/pci-mv_pmc 
12297 1 /boot/devf-generic 
12297 2 /boot/devf-generic 
12297 3 /boot/devf-generic 
16394 1 proc/boot/ksh 
98311 1 proc/boot/io-net 
3 0x61 0 TP- =PULSE 0x40000006:21 0x5a:0 
4 0x62 0 TP- =PULSE 0x4000000a:21 0x5a:0 
98311 2 proc/boot/io-net 
98311 3 proc/boot/io-net 
98311 4 proc/boot/io-net 
98311 5 proc/boot/io-net 
98311 6 proc/boot/io-net 
143368 1 proc/boot/pidin 
# 

----- Original Message -----

From: "Hugh Brown" <community-noreply@qnx.com> 
To: "drivers-networking" <post90247@community.qnx.com> 
Sent: Tuesday, November 22, 2011 12:05:13 PM 
Subject: Re: devn-i82544 hang 

I forgot that you were running io-net and not io-pkt. The information that 
you have sent doesn't help me at all, so please will you run the following: 

slay io-net dhcp.client 
io-net -de1000 
ifconfig en0 up 
ifconfig en1 up 
nicinfo > file 
pidin irq >> file 

Send me the output 'file'. If you don't have a file system on your 
unit,then you can capture the serial output and send it to me. 

Thanks, Hugh. 

-- 
Hugh Brown 
QNX Software Systems Limited 
175 Terence Matthews Crescent, 
Ottawa. ON. K2M 1W8. 
Telephone: 613-591-0931 







On 11-11-22 12:42 PM, "Joe Krachey" <community-noreply@qnx.com> wrote: 

>Here are the results as you requested, without loading the marvel system 
>controller driver, I would assume the two backplane ethernet...

Looking at the nicinfo output, it appears that the driver is receiving
messages fine. If you leave the driver running for some time and then run
nicinfo, do you see any "Packets dropped on receive" count? Can you run
"dhcp.client -ien0" and get an IP address?

When you say that en0 and en1 are the front panel interfaces, do these
connect to the Intel chip or to another on-board chip? The first driver to
start will allocate en0 and en1 and any subsequent drivers will continue
allocating from en2 up. If you are only running the e1000 driver, then the
2 interfaces will be en0 and en1.

-- 
Hugh Brown
QNX Software Systems Limited
175 Terence Matthews Crescent,
Ottawa. ON. K2M 1W8.
Telephone: 613-591-0931







On 11-11-29 10:40 AM, "Joe Krachey" <community-noreply@qnx.com> wrote:

>Here you go. en0 and en1 are front panel ethernet interfaces that do not
>connect to the chassis. en2 and en3 normally represent the back plane
>network connections to the chassis.
>
># slay io-net dhcp.client
># io-net -de1000 
># ifconfig en0 up 
>ifconfig: socket: Address family not supported by protocol family
># ifconfig en1 up 
>ifconfig: socket: Address family not supported by protocol family
># ifconfig en2 up 
>ifconfig: socket: Address family not supported by protocol family
># ifconfig en3 up 
>ifconfig: socket: Address family not supported by protocol family
># nicinfo 
>INTEL PRO/1000 Gigabit (Copper) Ethernet Controller
>
>Physical Node ID ........................... 00173C 008192
>Current Physical Node ID ................... 00173C 008192
>Current Operation Rate ..................... 1000.00 Mb/s full-duplex
>Active Interface Type ...................... MII
>Active PHY address ....................... 1
>Maximum Transmittable data Unit ............ 1514
>Maximum Receivable data Unit ............... 1514
>Hardware Interrupt ......................... 0x61
>Memory Aperture ............................ 0x80000000 - 0x8001ffff
>Promiscuous Mode ........................... Off
>Multicast Support .......................... Enabled
>
>Packets Transmitted OK ..................... 0
>Bytes Transmitted OK ....................... 0
>Broadcast Packets Transmitted OK ........... 0
>Multicast Packets Transmitted OK ........... 0
>Memory Allocation Failures on Transmit ..... 0
>
>Packets Received OK ........................ 116
>Bytes Received OK .......................... 9503
>Broadcast Packets Received OK .............. 116
>Multicast Packets Received OK .............. 0
>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
>No Carrier on Transmit ..................... 0
>Receive Alignment errors ................... 0
>Received packets with CRC errors ........... 0
>Packets Dropped on receive ................. 0
># pidin irq 
>pid tid name 
>1 1 procnto 
>0 0x80000000 0 --- @0x22ea14:0x0
>1 2 procnto 
>1 3 procnto 
>1 4 procnto 
>1 5 procnto 
>1 6 procnto 
>1 7 procnto 
>1 8 procnto 
>2 1 roc/boot/heartbeat
>3 1 proc/boot/slogger
>4 1 ot/devc-sermv64x60
>4 2 ot/devc-sermv64x60
>1 0x24 1215 --- =INTR
>4 3 ot/devc-sermv64x60
>2 0x26 1 --- =INTR
>5 1 c/boot/i2c-mv64460
>6 1 oc/boot/pci-mv_pmc
>12297 1 /boot/devf-generic
>12297 2 /boot/devf-generic
>12297 3 /boot/devf-generic
>16394 1 proc/boot/ksh
>98311 1 proc/boot/io-net
>3 0x61 0 TP- =PULSE 0x40000006:21 0x5a:0
>4 0x62 0 TP- =PULSE 0x4000000a:21 0x5a:0
>98311 2 proc/boot/io-net
>98311 3 proc/boot/io-net
>98311 4 proc/boot/io-net
>98311 5 proc/boot/io-net
>98311 6...

The two front panel ethernet interfaces connect through two external Finisar SFP devices.

I went an re-enabled the second vlan to put us back in the state where the card would fail. Running the same command you
 sent causes the card to crash. I had forgotten to add the 2nd back plane ethernet interface back to the vlan when I 
sent the results before.

System page at phys:0000c000 user:0000c000 kern:0000c000
Starting next program at v0022a240
Welcome to QNX Neutrino on the X-ES XPedite6244!
Bringing up Ethernet interface en0...
if_up: retries exhausted
lo0: flags=8009<UP,LOOPBACK,MULTICAST> mtu 33212
capabilities=7<IP4CSUM,TCP4CSUM,UDP4CSUM>
enabled=0<>
inet 127.0.0.1 netmask 0xff000000
en0: flags=8c43<UP,BROADCAST,RUNNING,OACTIVE,SIMPLEX,MULTICAST> mtu 1500 
capabilities rx=7<IP4CSUM,TCP4CSUM,UDP4CSUM>
capabilities tx=0<>
enabled=0<>
address: 00:17:3c:00:81:90
inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
en1: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
capabilities rx=7<IP4CSUM,TCP4CSUM,UDP4CSUM>
capabilities tx=0<>
enabled=0<>
address: 00:17:3c:00:81:91

Board temperature: 44ø C
Core0 temperature (w/ ideality): 55ø C
Core1 temperature (w/ ideality): -5ø C
# slay io-net dhcp.client
# io-net -de1000
# ifconfig en0 up
ifconfig: socket: Address family not supported by protocol family
# ifconfig en1 up
Shutdown[0,0] S/C/F=5/2/6 C/D=00207970/0026277c state(136f3)= now lock exit specret 3
QNX Version 6.3.2 Release 2006/03/16-14:18:26EST
[0]PID-TID=1-1? P/T FL=00019001/08000000 "proc/boot/procnto-600"
[0]ASPACE PID=32775 PF=00401010 "proc/boov`-net"
ppcbe context[0e5be370]:
0000: 40000000 0e5be420 00267658 40000010 00000002 31000024 00000000 00000000
0020: 00000002 00000004 00000000 00000003 4389b480 00269610 00000062 00000000
0040: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00262778
0060: 00008000 00000001 002621f8 00000000 0000f000 000136f2 0e5be430 0f7f56f0
0080: 002444c4 0f7e9040 00021032 0f7e90dc 44000000 20000000 00000000 00000000
00a0: 00000000
instruction[0f7e90dc]:
0f 7f 56 f0 00 24 44 c4 0f 7e 98 bc 00 20 90 32 00 23 e7 b8 44 00 00 00 20 00
stack[0e5be420]:
0000: 00000000 00000000 00000000 00000000 00009032 0e5be4e0 00267658 0f7eb650
0020: 00000000 0000000f 00000000 311003c0 00000002 00000004 00000000 00000003
0040: 4389b480 00269610 00000062 0f7eb650 00000000 00000000 00000000 00000000
0060: 00000000 00000000 00000000 00262778 00008000 00000001 002621f8 00000000

----- Original Message -----

From: "Hugh Brown" <community-noreply@qnx.com>
To: "drivers-networking" <post90345@community.qnx.com>
Sent: Tuesday, November 29, 2011 9:59:53 AM
Subject: Re: devn-i82544 hang

Looking at the nicinfo output, it appears that the driver is receiving
messages fine. If you leave the driver running for some time and then run
nicinfo, do you see any "Packets dropped on receive" count? Can you run
"dhcp.client -ien0" and get an IP address?

When you say that en0 and en1 are the front panel interfaces, do these
connect to the Intel chip or to another on-board chip? The first driver to 
start will allocate en0 and en1 and any subsequent drivers will continue
allocating from en2 up. If you are only running the e1000 driver, then the 
2 interfaces will be en0 and en1.

--
Hugh Brown
QNX Software Systems Limited
175 Terence Matthews Crescent,
Ottawa. ON. K2M 1W8.
Telephone: 613-591-0931







On 11-11-29 10:40 AM, "Joe Krachey" <community-noreply@qnx.com> wrote:

>Here you go. en0 and en1 are front panel ethernet interfaces that do not
>connect to the chassis. en2 and en3 normally represent the back plane
>network connections to the chassis.
>
># slay io-net dhcp.client
># io-net -de1000
># ifconfig en0 up
>ifconfig: socket: Address family not supported by protocol family
># ifconfig en1...

From the dump it appears that memory is being corrupted somehow, but
without the hardware, there isn't much more that I can do.
I have looked at the driver initialization and cannot see any place that
the driver could be out of sequence with the hardware.

Hugh.

-- 
Hugh Brown
QNX Software Systems Limited
175 Terence Matthews Crescent,
Ottawa. ON. K2M 1W8.
Telephone: 613-591-0931







On 11-11-29 12:09 PM, "Joe Krachey" <community-noreply@qnx.com> wrote:

>The two front panel ethernet interfaces connect through two external
>Finisar SFP devices.
>
>I went an re-enabled the second vlan to put us back in the state where
>the card would fail. Running the same command you sent causes the card to
>crash. I had forgotten to add the 2nd back plane ethernet interface back
>to the vlan when I sent the results before.
>
>System page at phys:0000c000 user:0000c000 kern:0000c000
>Starting next program at v0022a240
>Welcome to QNX Neutrino on the X-ES XPedite6244!
>Bringing up Ethernet interface en0...
>if_up: retries exhausted
>lo0: flags=8009<UP,LOOPBACK,MULTICAST> mtu 33212
>capabilities=7<IP4CSUM,TCP4CSUM,UDP4CSUM>
>enabled=0<>
>inet 127.0.0.1 netmask 0xff000000
>en0: flags=8c43<UP,BROADCAST,RUNNING,OACTIVE,SIMPLEX,MULTICAST> mtu 1500
>capabilities rx=7<IP4CSUM,TCP4CSUM,UDP4CSUM>
>capabilities tx=0<>
>enabled=0<>
>address: 00:17:3c:00:81:90
>inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
>en1: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>capabilities rx=7<IP4CSUM,TCP4CSUM,UDP4CSUM>
>capabilities tx=0<>
>enabled=0<>
>address: 00:17:3c:00:81:91
>
>Board temperature: 44ø C
>Core0 temperature (w/ ideality): 55ø C
>Core1 temperature (w/ ideality): -5ø C
># slay io-net dhcp.client
># io-net -de1000
># ifconfig en0 up
>ifconfig: socket: Address family not supported by protocol family
># ifconfig en1 up
>Shutdown[0,0] S/C/F=5/2/6 C/D=00207970/0026277c state(136f3)= now lock
>exit specret 3
>QNX Version 6.3.2 Release 2006/03/16-14:18:26EST
>[0]PID-TID=1-1? P/T FL=00019001/08000000 "proc/boot/procnto-600"
>[0]ASPACE PID=32775 PF=00401010 "proc/boov`-net"
>ppcbe context[0e5be370]:
>0000: 40000000 0e5be420 00267658 40000010 00000002 31000024 00000000
>00000000
>0020: 00000002 00000004 00000000 00000003 4389b480 00269610 00000062
>00000000
>0040: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>00262778
>0060: 00008000 00000001 002621f8 00000000 0000f000 000136f2 0e5be430
>0f7f56f0
>0080: 002444c4 0f7e9040 00021032 0f7e90dc 44000000 20000000 00000000
>00000000
>00a0: 00000000
>instruction[0f7e90dc]:
>0f 7f 56 f0 00 24 44 c4 0f 7e 98 bc 00 20 90 32 00 23 e7 b8 44 00 00 00
>20 00
>stack[0e5be420]:
>0000: 00000000 00000000 00000000 00000000 00009032 0e5be4e0 00267658
>0f7eb650
>0020: 00000000 0000000f 00000000 311003c0 00000002 00000004 00000000
>00000003
>0040: 4389b480 00269610 00000062 0f7eb650 00000000 00000000 00000000
>00000000
>0060: 00000000 00000000 00000000 00262778 00008000 00000001 002621f8
>00000000
>
>----- Original Message -----
>
>From: "Hugh Brown" <community-noreply@qnx.com>
>To: "drivers-networking" <post90345@community.qnx.com>
>Sent: Tuesday, November 29, 2011 9:59:53 AM
>Subject: Re: devn-i82544 hang
>
>Looking at the nicinfo output, it appears that the driver is receiving
>messages fine. If you leave the driver running for some time and then run
>nicinfo, do you see any "Packets dropped on receive" count? Can you run
>"dhcp.client -ien0" and get an IP address?
>
>When you say that en0 and en1 are the front panel interfaces, do these
>connect to the Intel chip or to...