Comments on: Using a Marvell LAN card with Vmware ESXi 3.5 http://www.kernelcrash.com/blog/using-a-marvell-lan-card-with-vmware-esxi-35/2009/08/14/ the difference that is no difference makes no difference Thu, 08 Jul 2010 14:50:34 +0000 http://wordpress.org/?v=2.8.4 hourly 1 By: cheelee http://www.kernelcrash.com/blog/using-a-marvell-lan-card-with-vmware-esxi-35/2009/08/14/comment-page-1/#comment-171 cheelee Thu, 08 Jul 2010 14:50:34 +0000 http://www.kernelcrash.com/blog/?p=345#comment-171 Hi, I am building a driver for the Realtek 8139 chipset using the 8139too.c source from 2.4.18 kernel. I just found out that you need to include 2 new lines into the driver for it to be recognized by the ESX kernel. You need to include: SET_MODULE_OWNER(dev); SET_NETDEV_DEV(dev, &pdev->dev); after the "alloc_etherdev()" function. Otherwise, the esxcfg-nics command will not see the NIC card and it cannot be configured. Hi, I am building a driver for the Realtek 8139 chipset using the 8139too.c source from 2.4.18 kernel. I just found out that you need to include 2 new lines into the driver for it to be recognized by the ESX kernel. You need to include:

SET_MODULE_OWNER(dev);
SET_NETDEV_DEV(dev, &pdev->dev);

after the “alloc_etherdev()” function. Otherwise, the esxcfg-nics command will not see the NIC card and it cannot be configured.

]]> By: kernel http://www.kernelcrash.com/blog/using-a-marvell-lan-card-with-vmware-esxi-35/2009/08/14/comment-page-1/#comment-165 kernel Tue, 29 Jun 2010 05:05:42 +0000 http://www.kernelcrash.com/blog/?p=345#comment-165 cheelee, thanks for the comment. I never tried doing that vmkload_mod for the drivers I've compiled where I don't have the physical card/chipset. I always assumed that it would never say anything useful. I might have to have another look at that skge driver to try that out. For that skge driver, we seem to get it working for ESXi 4, but not for ESXi 3.5. Thanks for the tips about the PCI id. Re the large object files, the build scripts I use tend to have plenty of debug turned on by default. Try editing your build...sh script and editing the CFLAGS line so that it does not include the '-g3' bit. Then recompile. For the ESXi 4 build scripts, there are two variables at the top of the scripts; DEBUG and DASHG. Just comment those line out. As for that skge-for-esxi3.5u4-0.04.tar.gz, I assumed there might me some unresolved stuff, but I didn't get any feedback about it. Like I said I might have another go now using the vmkload_mod, as per your suggestion. cheelee, thanks for the comment. I never tried doing that vmkload_mod for the drivers I’ve compiled where I don’t have the physical card/chipset. I always assumed that it would never say anything useful. I might have to have another look at that skge driver to try that out. For that skge driver, we seem to get it working for ESXi 4, but not for ESXi 3.5.

Thanks for the tips about the PCI id.

Re the large object files, the build scripts I use tend to have plenty of debug turned on by default. Try editing your build…sh script and editing the CFLAGS line so that it does not include the ‘-g3′ bit. Then recompile. For the ESXi 4 build scripts, there are two variables at the top of the scripts; DEBUG and DASHG. Just comment those line out.

As for that skge-for-esxi3.5u4-0.04.tar.gz, I assumed there might me some unresolved stuff, but I didn’t get any feedback about it. Like I said I might have another go now using the vmkload_mod, as per your suggestion.

]]> By: cheelee http://www.kernelcrash.com/blog/using-a-marvell-lan-card-with-vmware-esxi-35/2009/08/14/comment-page-1/#comment-164 cheelee Tue, 29 Jun 2010 01:33:44 +0000 http://www.kernelcrash.com/blog/?p=345#comment-164 Thanks for this blog. I had bought a Dlink DGE-528T gbit NIC which was suppose to be a Realtek 8169S card. I thought that it was going to be supported out-of-the-box by the customized oem.tgz file. But it did not work, even after I had included the PCI ID into the simple.map file. I then started pulling source codes from various sites to compile as per your instructions above but faced a lot of challenges esp the skb_ stuff. One thing I did to make things easier was to dd the installation into a USB stick. Then I kept changing the oem.tgz file and just boot it on the PC without the card install. I can then use the vmkload_mod command to try and load each module.o file to see if there are unresolved symbols in the message log. So you don't actually need the card to test for unresolved symbols. In the end, I check the source in the open-vdriver for the r8169.c file and I found that actually the PCI IDs are ALSO SET in the module source code (in a struct named pci_tbl) and if your card's id is not in there then it will NEVER detect the card even if you specified it in the simple.map file. So I made changes to the source, recompiled it and now the DGE-528T is recognized with the driver r8169 and it works. There is another way to make the change which is to do a binary replace of one of the other pre-defined pci-id in that file to fill in your PCI ID, using hexedit, I think. Hence, if you have problems in getting your card recognized and you are sure that it has a supported chipset, consider making the PCI ID change in the module file. BTW, I am also getting pretty large object files and I don't know how to shrink / reduce / minimize its size. Also I have a problem fixing the unresolved symbol kmap_skb_ and kunmap_skb_ as per your skge-for-esxi3.5u4-0.04.tar.gz source above. Did you managed to overcome these references ? Thanks for this blog. I had bought a Dlink DGE-528T gbit NIC which was suppose to be a Realtek 8169S card. I thought that it was going to be supported out-of-the-box by the customized oem.tgz file. But it did not work, even after I had included the PCI ID into the simple.map file. I then started pulling source codes from various sites to compile as per your instructions above but faced a lot of challenges esp the skb_ stuff.

One thing I did to make things easier was to dd the installation into a USB stick. Then I kept changing the oem.tgz file and just boot it on the PC without the card install. I can then use the vmkload_mod command to try and load each module.o file to see if there are unresolved symbols in the message log. So you don’t actually need the card to test for unresolved symbols.

In the end, I check the source in the open-vdriver for the r8169.c file and I found that actually the PCI IDs are ALSO SET in the module source code (in a struct named pci_tbl) and if your card’s id is not in there then it will NEVER detect the card even if you specified it in the simple.map file.

So I made changes to the source, recompiled it and now the DGE-528T is recognized with the driver r8169 and it works.

There is another way to make the change which is to do a binary replace of one of the other pre-defined pci-id in that file to fill in your PCI ID, using hexedit, I think.

Hence, if you have problems in getting your card recognized and you are sure that it has a supported chipset, consider making the PCI ID change in the module file.

BTW, I am also getting pretty large object files and I don’t know how to shrink / reduce / minimize its size.

Also I have a problem fixing the unresolved symbol kmap_skb_ and kunmap_skb_ as per your skge-for-esxi3.5u4-0.04.tar.gz source above. Did you managed to overcome these references ?

]]> By: kernel http://www.kernelcrash.com/blog/using-a-marvell-lan-card-with-vmware-esxi-35/2009/08/14/comment-page-1/#comment-115 kernel Sat, 27 Mar 2010 05:23:07 +0000 http://www.kernelcrash.com/blog/?p=345#comment-115 OK, try this 0.04 version ; <a href="/blog/wp-content/skge-for-esxi3.5u4-0.04.tar.gz" rel="nofollow">skge-for-esxi3.5u4-0.04.tar.gz</a>. Note, for Sheepless, that copy_skb_header thing highlights just how different the sk_buff struct is now. I just commented out a heap of stuff and shoved it into skge.c. Again, probably won't work, but worth a try. OK, try this 0.04 version ; skge-for-esxi3.5u4-0.04.tar.gz. Note, for Sheepless, that copy_skb_header thing highlights just how different the sk_buff struct is now. I just commented out a heap of stuff and shoved it into skge.c. Again, probably won’t work, but worth a try.

]]> By: kernel http://www.kernelcrash.com/blog/using-a-marvell-lan-card-with-vmware-esxi-35/2009/08/14/comment-page-1/#comment-114 kernel Sat, 27 Mar 2010 05:11:53 +0000 http://www.kernelcrash.com/blog/?p=345#comment-114 Oops, Am pretty sure that 0.03 version won't work. Will probably get an unresolved symbol about copy_skb_header. Oops, Am pretty sure that 0.03 version won’t work. Will probably get an unresolved symbol about copy_skb_header.

]]> By: kernel http://www.kernelcrash.com/blog/using-a-marvell-lan-card-with-vmware-esxi-35/2009/08/14/comment-page-1/#comment-113 kernel Sat, 27 Mar 2010 05:08:04 +0000 http://www.kernelcrash.com/blog/?p=345#comment-113 daymz, if you feel like trying the latest incantation of the skge driver (see comment above), please do. I suspect it won't work, but see how it goes. daymz, if you feel like trying the latest incantation of the skge driver (see comment above), please do. I suspect it won’t work, but see how it goes.

]]> By: kernel http://www.kernelcrash.com/blog/using-a-marvell-lan-card-with-vmware-esxi-35/2009/08/14/comment-page-1/#comment-112 kernel Sat, 27 Mar 2010 05:06:20 +0000 http://www.kernelcrash.com/blog/?p=345#comment-112 Sheepless, I see what you mean. I had a go at fixing those unresolved symbols, and I can get it to compile, but I suspect my compile may have the same panics as yours. Please grab the <a href="/blog/wp-content/skge-for-esxi3.5u4-0.03.tar.gz" rel="nofollow">skge-for-esxi3.5u4-0.03.tar.gz</a> tar file and see if works any better. All the changes I've made are just more routines (out of a 2.4.37 kernel) jammed into the top of the skge.c file. Sheepless, I see what you mean. I had a go at fixing those unresolved symbols, and I can get it to compile, but I suspect my compile may have the same panics as yours. Please grab the skge-for-esxi3.5u4-0.03.tar.gz tar file and see if works any better. All the changes I’ve made are just more routines (out of a 2.4.37 kernel) jammed into the top of the skge.c file.

]]> By: daymz http://www.kernelcrash.com/blog/using-a-marvell-lan-card-with-vmware-esxi-35/2009/08/14/comment-page-1/#comment-111 daymz Sat, 27 Mar 2010 01:33:51 +0000 http://www.kernelcrash.com/blog/?p=345#comment-111 Been following the ESXi 4.0 article and am definitely very interested in this, as my target ESX server can only do 32-bit. I have a DGE-530T NIC so I can definitely help in testing the driver. I am proficient in C and Ethernet as well if needed (but not in Linux drivers). Been following the ESXi 4.0 article and am definitely very interested in this, as my target ESX server can only do 32-bit. I have a DGE-530T NIC so I can definitely help in testing the driver. I am proficient in C and Ethernet as well if needed (but not in Linux drivers).

]]> By: kernel http://www.kernelcrash.com/blog/using-a-marvell-lan-card-with-vmware-esxi-35/2009/08/14/comment-page-1/#comment-107 kernel Mon, 22 Mar 2010 20:41:18 +0000 http://www.kernelcrash.com/blog/?p=345#comment-107 Thanks for trying. Thanks for listing the unresolved symbols. I'll have a closer look when I get some time. Thanks for trying. Thanks for listing the unresolved symbols. I’ll have a closer look when I get some time.

]]> By: Sheepless http://www.kernelcrash.com/blog/using-a-marvell-lan-card-with-vmware-esxi-35/2009/08/14/comment-page-1/#comment-106 Sheepless Mon, 22 Mar 2010 19:48:11 +0000 http://www.kernelcrash.com/blog/?p=345#comment-106 Having an old PC with an 88E8001, I tried your skge module with ESXi 3.5, but you still have some unresolved symbols: Warning: unresolved symbol skb_headroom Warning: unresolved symbol skb_padto Warning: unresolved symbol skb_copy_expand Warning: unresolved symbol skb_tailroom Warning: unresolved symbol jiffies_to_msecs Warning: unresolved symbol msecs_to_jiffies The time conversion ones are easy to fix: you rolled the functions into skge.c with changed names, but forgot to change some references to the original names. Unfortunately, the other problems are tougher. I started merging the relevant sk_buff-related stuff into the driver, but soon ran up against compilation problems, and a comment in VMware-esx-public-source/include/linux_skbuff.h shows why: "This is the small subset of sk_buff stuff we actually use in the vmkernel linux emulation layer". Basically, they've made changes to struct sk_buff, so changes are needed to the driver code. I've had a crack at this, but it's still panicking, and I've got a feeling there are deeper problems. Having an old PC with an 88E8001, I tried your skge module with ESXi 3.5, but you still have some unresolved symbols:

Warning: unresolved symbol skb_headroom
Warning: unresolved symbol skb_padto
Warning: unresolved symbol skb_copy_expand
Warning: unresolved symbol skb_tailroom
Warning: unresolved symbol jiffies_to_msecs
Warning: unresolved symbol msecs_to_jiffies

The time conversion ones are easy to fix: you rolled the functions into skge.c with changed names, but forgot to change some references to the original names. Unfortunately, the other problems are tougher. I started merging the relevant sk_buff-related stuff into the driver, but soon ran up against compilation problems, and a comment in VMware-esx-public-source/include/linux_skbuff.h shows why: “This is the small subset of sk_buff stuff we actually use in the vmkernel linux emulation layer”. Basically, they’ve made changes to struct sk_buff, so changes are needed to the driver code. I’ve had a crack at this, but it’s still panicking, and I’ve got a feeling there are deeper problems.

]]>