Description of problem: Running dev kernel rpm "kernel-smp-2.6.15-1.1958.2.1_FC5.jwltest.11.i686.rpm" on Intel mboard "D925XBC" with onboard Marvell Yukon 2 ethernet chip "88E8050" has problem when "sky2" kernel module is used in conjunction with VLANs bound to eth0. Ie: without VLANs, the sky2 driver works nicely with the 88E8050 ship, and IP comms between eth0 and the remainder of my devices and the rest of the world works fine - but I require VLANs exclusively. When a VLAN "eth0.5" is configured on eth0, then the sky2 driver doesn't even put a packet on the wire which is recognisable by the switch, so the switch never forwards any of the sky2's packets to any other nodes. On the other hand, when the same PC loads the FC4.91 released kernel, rebuilt with the sk98lin kernel patch added, when I use the old syskonnect sk98lin driver, built with a kernel recompile ######################################## ######################################## ######################################## Version-Release number of selected component (if applicable): kernel-smp-2.6.15-1.1958.2.1_FC5.jwltest.11.i686.rpm syskonnect_marvell_ver20060118_sk98lin_kernel_patch(aka_install-b8.31.2.3).zip ######################################## ######################################## ######################################## How reproducible: Steps to Reproduce: 1. Install dev kernel into FC4.91 (FC5 test 2) typethis# rpm -ivh kernel-smp-2.6.15-1.1958.2.1_FC5.jwltest.11.i686.rpm 2. Configure grub to boot this new kernel as default (no fear!) 3. Configure sky2 kernel module to bind to eth0 typethis# cat /etc/modprobe.conf | grep eth0 alias eth0 sky2 4. Reboot 5. Configure vlan 5 on eth0 with IP = 1.1.1.1, and default route ie: typethis# ifconfig eth0 0.0.0.0 netmask 0.0.0.0 up typethis# vconfig add eth0 5 typethis# ifconfig eth0.5 1.1.1.1 netmask 255.255.255.0 up typethis# route add -net 0.0.0.0 netmask 0.0.0.0 gw 1.1.1.2 6. Ping the default gateway 1.1.1.2 7. Run ethereal and capture all packets on eth0 and eth0.5. 8. Repeat for sk98lin and rebuilt kernel FC4.91 (FC5 test 2) as released. ######################################## ######################################## ######################################## Actual results: After install new dev kernel, config sky2 to load, reboot, configure vlan... typethis# lsmod | grep sky2 sky2 41157 0 typethis# ping 1.1.1.2 PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data From 1.1.1.1 icmp_seq=2 Destination Host Unreachable (many times) Using ethereal I observed that ARP requests weren't being understood by the switch I decided to set the arp (arp -s) and then start issuing pings. typethis# echo 'kitten 1.1.1.2' >> /etc/hosts typethis# arp -s kitten 00:0E:0C:6E:83:ED typethis# ping 1.1.1.2 PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data From 1.1.1.1 icmp_seq=2 Destination Host Unreachable (many times) Using ethereal to compare the "sky2" ping packets to the "sk98lin" ping packets I noted the following structural differences: sky2: protocols in frame = eth:ip:icmp:data first six octets of entire packet = destination MAC address (eg: 00 0e 0c 6e 83 ed) next six octets of entire packet = source MAC address (eg: 00 11 11 24 69 00) sk98lin: protocols in frame = sll:ip:icmp:data first two octets of entire packet = packet type: sent by us (eg: 00 04) next two octets of entire packet = link layer address type: 1 (eg: 00 01) next two octets of entire packet = link layer address length: 6 (eg: 00 06) next six octets of entire packet = source MAC address (eg: 00 11 11 24 69 00) next two octets of entire packet = Protocol IP (eg: 08 00) ...blah... ...blah... From this I can see that the sky2 VLAN packet with non-working VLANs looks very different to the packet assembled by sk98lin, with working VLANs. Secondly, I noticed that ARP requests sent by the sky2 driver received no responses from the switch or default gateway. Thirdly, I guessed that the sky2 driver wasn't VLANing the packets properly so I plugged the Yukon controller ethernet cable into a "non-VLAN" port on the switch. Interesting! Arp requests issued by the sky2 driver now started receiving responses from the switch/upstream nodes, BUT the sky2 driver didn't acknowledge them and continued issuing Arp requests. ######################################## ######################################## ######################################## Expected results: typethis# lsmod | grep sky2 sky2 41157 0 typethis# ping 1.1.1.2 PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data 64 bytes from 1.1.1.2: icmp_seq=0 ttl=64 time=0.035 ms 64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=0.031 ms (many times) Additional info:
If you need me (peterg) to do sk98lin packet captures to provide you with the packet assembly details of the VLAN'd packets as assembled by the sk98lin driver, then I'm ready to go, just describe the packets you want and I'll add them as attachments to the bug. Note that I'm in Australia so if you're in the US then please tolerate an overnight lag in getting the results. If you'd like me to test any kernels before you post them on... http://people.redhat.com/linville/kernels/fc5/ ...then you can definitely email me any kernel rpms, or email me a URL to a "dev" web page or FTP site ? FYI, I'll test any new "sky2 VLAN" i686smp kernels which appear on... http://people.redhat.com/linville/kernels/fc5/ ... by installing them on my Intel D925XBC mboards (with Marvell Yukon 88E8050 eth controller).
Test kernels w/ sky2 version 1.0-pre1 available here: http://people.redhat.com/linville/kernels/fc5/ Please give those a try and post the results here...thanks!
I tested kernel kernel-smp-2.6.15-1.2009.2.1_FC5.jwltest.12.i686.rpm with the new sky2-1.0-pre1 driver and my VLANs all communicate fine (several hours average throughput - a lot of NFS, a little ssh) That's enough to close this ticket. You are scholars and gentlemen. .....pete
Correction: The sky2 driver works fine with VLANs because SFTP (not NFS) file transfers have been working fine for several hours, including large file transfer > 1GB each. Actually NFS is crashing after around 200KB file transfers - but I'm convinced that's due to the new kernel's NFS client, not the sky2 driver. I'll open a new ticket on the NFS client, so go ahead and close this one relating to sky2.
That sky2 driver probably won't be upstream until 2.6.17...I dunno if davej wants to carry the patch in FC5...hmmm... Well, if nothing else I'll carry the patch in my FC5 test kernels. It will be in FC5.netdev when they start as well...
Thanks for keeping it in train in netdev. I really do need this patch in FC5. In fact I need sky2 to work with VLANs in the xen hypervisor kernel, and if it doesn't get incorporated in FC5 then it's going to be much more difficult to convince the xen team to consider supporting it until, as you suggest, after it gets mainlined around 2.6.17. As a result I created bug 184221 against the FC5test3 kernel, as below: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184221 which reports the same problem with the FC5test3 smp kernel 2.6.15-1.1955_FC5. I also copied DaveJ in. I didn't want to be a pain to seemingly report the same problem twice, but I also wanted the bug to be recorded against the stock kernel line, in case my request for VLANs in sky2 was categorised as tinkering. I've tried to break the sky2-1.0-pre1 patch but I can't. I think it's a cracker, and it would be a shame if it missed FC5.
You solved it in FC5 ! Well done. The sky2 driver in FC5 works with VLANs on my 88E8050 hardware (m'board = Intel D925XBC) just perfectly. Go ahead and close this ticket. Thanks......pete