Most recent kernel where this bug did not occur: - Distribution: Red Hat Enterprise 4 Hardware Environment: HP BL460c, BL480c (tested with switches: Cisco 3750, Nortel 8600) Software Environment: Problem Description: bnx2 driver needs delay between bringing up eth0 and its tagged VLAN interfaces Steps to reproduce: 1. Configure a switchport for the server as a VLAN trunk with 802.1q tagging 2. Bring the server's network interface(s) down, remove VLANs from it 3. Execute the following commands in a script (without delay between the commands): ifconfig eth0 up vconfig add eth0 10 (or some other VLAN you allowed on the switch) ifconfig eth0.10 x.x.x.x netmask y.y.y.y up 4. Try to ping something on VLAN10 (it doesn't work, eth0.10 can't transmit packets) But it will work if you modify the script like this: ifconfig eth0 up sleep 5 vconfig add eth0 10 ifconfig eth0.10 x.x.x.x netmask y.y.y.y up
I was unable to reproduce this problem on 2.6.21.5. Please provide more information, such as dmesg log, ethtool -S, etc.
Please show 'ifconfig -a' for the physical interface and the vlan interface in the failure case. As Michael mentioned, show is 'dmesg' and maybe 'tail -100 /var/log/messages' as well. There may be error messages there that help explain the problem.
Created attachment 11934 [details] bnx2 driver problem circumstances see good.sh, bad.sh
Unfortunately I had to build a new test system for taking the logs you'd asked for. The configuration is almost identical (HP BL460c, some options differ), but it behaves differently than the previous. It doesn't produce the bug with 2.6.21.5 any more (the previous system did with the same binary kernel), but it produces the bug with the standard RH4 kernel (I know...) and the latest bnx2 driver module from HP (bnx2-1.4.52d). The new test system also requires reboot between tests ("unregister_netdevice: waiting for ..."). The reason why I didn't take logs from the previous system is that there wasn't any difference between working and nonworking state (the entire sysctl, ifconfig, vconfig, ethtool flags were exactly the same, and they looked good). One exception: vlan TX counters remained 0, it didn't even reply to ARP (but tcpdump showed the incoming ARP requests). I don't think it's hardware error, I've seen this problem in 2 other systems. 5 seconds delay solved the problem in those cases. The logs I have now are not really relevant, and they show some diff because of the reboot, but they might help. I'll take more logs if I meet the problem again.
Is this still an issue? Please provide an update.
(In reply to comment #5) > Is this still an issue? Please provide an update. I haven't experienced it on other systems. Maybe it was a problem with the environment.