Re: 2.6.37 vlans on bnx2 not functional, panic with tcpdump

On Fri, 2011-01-07 at 00:57 -0800, selsinork wrote:

On Fri, Jan 7, 2011 at 12:46 AM, Michael Chan [off-list ref]
wrote:
        
        
        May be you have management firmware running on your devices
        that can
        change the behavior.  Can you provide ethtool -i eth0 on both
        bnx2
        devices on your system?

This particular system has four onboard ports, a two port add-in card
and a single port fiber card all using bnx2, so I have some options to
try different devices if there's something different about them.
Details of all of them below.

Booting the same system back to 2.6.36 with the patch I mentioned
previously leaves me with a functioning network, so given it could be
management firmware related, why does it work on .36 but not .37 ?  

Management firmware affects the stripping/unstripping of VLAN tags.  If
management firmware is enabled, we need to configure the chip to always
strip the VLAN tag, otherwise management firmware will not receive the
packets properly.

The kernel has undergone major VLAN changes at this time, so there may
be a problem depending on what stripping mode we're in.  The tg3 driver
is having some similar problems that haven't been completely resolved
yet.

Anyway, I'll wait for you to narrow this down further.  I'll also try to
do some additional testing myself.

You have management firmware (NCSI) enabled on eth0 and eth1, but not
the other devices (the firmware shown is NVRAM firmware).  If it's still
a problem, please see if there's a difference in behavior between the
devices with NCSI enabled and disabled.

Thanks.

 The install is very stripped down, there's no udev or /sbin/hotplug
loading firmware behind my back as neither are installed. So firmware
is whatever comes with the kernel. Just having had a look, I see the
firmware provided with the kernel has changed in .37, but the output
of ethtool -i shows the same firmware being used with .36 and .37

Iain

02:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709
Gigabit Ethernet (rev 20)
02:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709
Gigabit Ethernet (rev 20)
03:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709
Gigabit Ethernet (rev 20)
03:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709
Gigabit Ethernet (rev 20)
04:00.0 RAID bus controller: Hewlett-Packard Company Smart Array G6
controllers (rev 01)
07:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709
Gigabit Ethernet (rev 20)
07:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709
Gigabit Ethernet (rev 20)
0a:00.0 PCI bridge: Broadcom EPB PCI-Express to PCI-X Bridge (rev c3)
0b:00.0 Ethernet controller: Broadcom Corporation NetXtreme II
BCM5708S Gigabit Ethernet (rev 12)

from 2.6.37:

root@64bit:~# ethtool -i eth0
driver: bnx2
version: 2.0.17
firmware-version: bc 5.2.2 NCSI 2.0.6
bus-info: 0000:02:00.0
root@64bit:~# ethtool -i eth1
driver: bnx2
version: 2.0.17
firmware-version: bc 5.2.2 NCSI 2.0.6
bus-info: 0000:02:00.1
root@64bit:~# ethtool -i eth2
driver: bnx2
version: 2.0.17
firmware-version: bc 5.2.2
bus-info: 0000:03:00.0
root@64bit:~# ethtool -i eth3
driver: bnx2
version: 2.0.17
firmware-version: bc 5.2.2
bus-info: 0000:03:00.1
root@64bit:~# ethtool -i eth4
driver: bnx2
version: 2.0.17
firmware-version: bc 5.2.2
bus-info: 0000:07:00.0
root@64bit:~# ethtool -i eth5
driver: bnx2
version: 2.0.17
firmware-version: bc 5.2.2
bus-info: 0000:07:00.1
root@64bit:~# ethtool -i eth6
driver: bnx2
version: 2.0.17
firmware-version: bc 1.9.6
bus-info: 0000:0b:00.0
 
from 2.6.36:

 ethtool -i eth1
driver: bnx2
version: 2.0.17
firmware-version: bc 5.2.2 NCSI 2.0.6
bus-info: 0000:02:00.1

Michael Chan wrote:

The kernel has undergone major VLAN changes at this time, so there may
be a problem depending on what stripping mode we're in.  The tg3 driver
is having some similar problems that haven't been completely resolved
yet.

It seems to be related to generic vlan changes, I've duplicated it on an Intel 82547L nic in a completely different system connected to a different switch.

So you can consider any bnx2 cause for this closed. I'll get back to the list if I can come up with any more useful info.

Thanks for your help,
Iain

Iain Paton wrote:
...

So you can consider any bnx2 cause for this closed. I'll get back to the
list if I can come up with any more useful info.

Hi Iain,
If it's not a problem, please try if the attached debugging patch
(not tested) can change anything.

Thanks,
Jarek P.

Jarek Poplawski wrote:

Iain Paton wrote:
...

quoted

So you can consider any bnx2 cause for this closed. I'll get back to the
list if I can come up with any more useful info.

Hi Iain,
If it's not a problem, please try if the attached debugging patch
(not tested) can change anything.

No problem testing with the patch installed, however I'm now unable to duplicate the problem with a rebuilt kernel, with or without the patch.

The original kernel build I did still fails repeatably, but something as simple as erasing the directory, unpacking the same source tarball and re-compiling using the same config file gets me a working kernel.

This is somewhat troubling as there must have been some initial cause, but I'm unable to pin it down. Have spent the last day or so checking toolchain versions, running hardware tests on the physical build server and have come up completely empty.

I think we can safely ignore this now as it appears to be a one-off bad compile, for reasons unknown, but totally unrepeatable.

Thanks to all for your help, and apologies for the noise.

Iain