Red Hat Bugzilla – Bug 136158
eth0 error: Cannot read VPD keys (Marvell chipset)
Last modified: 2015-01-04 17:10:54 EST
Description of problem: I installed fedora-development on an Shuttle-SN95G5 nForce3 250 system, which has a Marvell Yukon gigabit ethernet chip in it. When inserting the sk98lin module, the kernel gives the following error every second or two: Class: internal Software error Nr: 0x19e Msg: Vpd Cannot read VPD keys I found the following related problems in many pages for the ASUS K8VSE mobos: http://kerneltrap.org/node/view/3419 http://lkml.org/lkml/2004/4/6/317 http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-03/5484.html It seems that the Shuttle BIOS may be having the same problem. My questions are: (1) is it possible to have the kernel report this error once, rather than every couple of seconds, so that the logs don't fill up? (2) is there a way I can determine what the current VPD data is, and what it should be, so I can write a fix similar to the one described in the links above? (3) is it true this is a BIOS problem in the first place? (4) should I report this upstream to get a workaround in place? (5) should I report this to Shuttle? It seems ethernet works fine, despite the error messages, although apparently people with the problem on Asus boards have a limited subset of features available without the workaround. I haven't tested extensively enough to know yet. The other interesting thing is that I did a network install of Fedora, and the installer didn't seem to report any errors during the install. Does the installer have a different version of sk98lin?
I figured out that the reason I get the error every second is because nifd is checking the interface status at 1 sec intervals. I disabled the nifd service. I still get the error on startup and shutdown, but at least my logs are not getting long. Data transfer on the interface seems flawless. I also reported this to kernel bugzilla, bug number 3598. No response there yet.
Thank you for your additional comment Luke. I am in the exactually same situation and I couldn't find any way to tell shuttle or marvell... I hope something can be done about that problem.
François -- more progress is being made in the corresponding Kernel Bugzilla entry: http://bugme.osdl.org/show_bug.cgi?id=3598 For now, just do the following as root: chkconfig --del nifd service nifd stop And at least your logs don't fill up. You'll just get the error twice on shutdown, and occasionally if you run ethernet tools. Otherwise everything seems to work fine, and as long as you don't need nifd (i.e. if you're not constantly plugging and unplugging network connections), everything should seem fine. Still, it is a nuicance!
I emailed Shuttle and got a reply from them as to how to fix the problem. They sent me the Yukon Manufacturer's Tools, that you can run to re-calculate the checksum. This permanently rewrites the VPD data, so I don't see the problem any more. I attached these files to the bugzilla.kernel.org bug I created: http://bugzilla.kernel.org/show_bug.cgi?id=3598 This still doesn't actually fix the kernel problem of constantly generating the error on machines that haven't been patched though. RedHat guys -- since the other bug exists, should I just close this bug? Thanks..
I just ran into this with FC4 (Version for this bug needs updating) on a DFI LANPARTY UT nF4 Ultra-D motherboard (Marvell 88E8001 Yukon chip): http://www.dfi.com.tw/Product/xx_product_spec_details_r_us.jsp?PRODUCT_ID=3471&CATEGORY_TYPE=LP&SITE=NA Before I found this bug listing I "fixed" the problem by moving the cable to the other NIC, which uses a different chipset.
The kernel.org bugzilla has a lot of useful information. This bug can cause kernel pauses that result in DVD playback skip. A replacement "experimental" SKGE module is available in the -mm kernel.
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you.
I can't test this any more, because I patched my NIC so the VPD checksum is correct. However, a previous reporter (Comment #5) said this is broken on FC4. Updating version field as per request.
[This comment has been added as a mass update for all FC4 kernel bugs. If you have migrated this bug from an FC3 bug today, ignore this comment.] Please retest your problem with todays 2.6.12-1.1398_FC4 update. If your problem involved being unable to boot, or some hardware not being detected correctly, please make sure your /etc/modprobe.conf is correct *BEFORE* installing any kernel updates. If in doubt, you can recreate this file using.. mv /etc/sysconfig/hwconf /etc/sysconfig/hwconf.bak mv /etc/modprobe.conf /etc/modprobe.conf.bak kudzu Thank you.
Can anyone else still duplicate this? As stated before I changed this to an FC4 bug, I can't test this on my system anymore.
The problem still exists with the latest kernel: [root@gnome ~]# uname -a Linux gnome 2.6.12-1.1398_FC4 #1 Fri Jul 15 00:51:38 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux [root@gnome ~]# tail -4 /var/log/messages Jul 23 15:22:21 gnome kernel: eth0: -- ERROR -- Jul 23 15:22:21 gnome kernel: Class: internal Software error Jul 23 15:22:21 gnome kernel: Nr: 0x19e Jul 23 15:22:21 gnome kernel: Msg: Vpd: Cannot read VPD keys
I have the same problem with D-Link DGE-530T card and the latest kernel 2.6.12-1.1447_FC4smp. Kernel's sk98lin is ancient, but using SysKonnect's driver "sk98lin: Network Device Driver v8.23.1.3" dated Jun-20-2005 doesn't help much: numerous failed attempts to read VPD keys are reported. Oh, yes, D-Link's own sk98lin dates back to Jun-23-2003 and doesn't compile at all under 2.6 kernels. So much for D-Link's Linux support... The problem is that the D-Link card doesn't seem to have a readable VPD at all. Failed attempts to read the VPD can temporarily stall the system. Here is what debugging skvpd.c produced: Sep 9 01:42:49 h kernel: list VPD keys .. VpdInit ... VPD read block, addr = 0x0, len = 256 Sep 9 01:42:49 h kernel: VPD wait for Read Sep 9 01:42:49 h kernel: state = 0, event 0 Sep 9 01:42:50 h last message repeated 27 times Sep 9 01:42:50 h kernel: vent 0 Sep 9 01:42:50 h kernel: state = 84, event 0 Sep 9 01:42:50 h last message repeated 59 times Sep 9 01:42:50 h kernel: state = 8084, event 0 [...numerous attempts to read VPD omitted...] Sep 9 01:42:50 h kernel: state = 80fc, event 0 Sep 9 01:42:50 h kernel: VPD find para RV .. Error: 0x82 missing Sep 9 01:42:50 h kernel: Encoding Error: RV Tag not found Sep 9 01:42:50 h kernel: VPD Init Error, terminated Sep 9 01:42:50 h kernel: eth1: -- ERROR -- Sep 9 01:42:50 h kernel: Class: internal Software error Sep 9 01:42:50 h kernel: Nr: 0x19e Sep 9 01:42:50 h kernel: Msg: Vpd: Cannot read VPD keys
One solution: Install skge driver and use skge instead of sk98lin. The skge driver is a standard part of kernel 2.6.13 from kernel.org and it performs very well with D-Link DGE-530T. In fact, it may be good if all Marvell chips which have problems with sk98lin (because of missing or corrupt VPD) switch to using the skge driver. Can this change be made in future Fedora & Red Hat kernels?
That's exactly what I did recently for rawhide kernels. For FC3/FC4 updates however, its tricky, as peoples systems would stop working if their netdriver disappeared, and they had to rewrite their modprobe.conf
Same problem here, ordered the D-Link DGE-530T for my mythbox with out looking into it first :( [root@tube ~]# uname -r 2.6.12-1.1456_FC4smp Output from /var/log/messages kernel: eth1: -- ERROR -- kernel: Class: internal Software error kernel: Nr: 0x19e kernel: Msg: Vpd: Cannot read VPD keys Is there a solution to this (other than disabling nifd), that doesnt involve recompling the kernel? Anyway to just install the skge driver in the 2.6.12 kernel? Thanks!
It's an easy fix, someone just has to do it :-) There's a patch here: http://bugme.osdl.org/show_bug.cgi?id=3598#c14 However I think a better solution is to actually set a flag the first time the warning is reported, and check it every time the warning is about to be reported. If the warning has already been reported, do nothing. Reporting the warning once is fine, every couple of seconds is not :P There may be something else going on though too -- interrupts seem to lock up for as much as 250ms during the failed VPD check for some reason, so the whole codepath needs to be looked at to see why this is happening (it's not just due to the warning being added to /var/log/messages).
Mass update to all FC4 bugs: An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream kernel (2.6.13.2). As there were ~3500 changes upstream between this and the previous kernel, it's possible your bug has been fixed already. Please retest with this update, and update this bug if necessary. Thanks.
I don't believe the update fixes the issue, but I can't test as I patched my VPD.
Problem still exists with latest kernel: [root@gnome ~]# tail -4 /var/log/messages Oct 1 23:44:24 gnome kernel: eth0: -- ERROR -- Oct 1 23:44:24 gnome kernel: Class: internal Software error Oct 1 23:44:24 gnome kernel: Nr: 0x19e Oct 1 23:44:24 gnome kernel: Msg: Vpd: Cannot read VPD keys [root@gnome ~]# uname -a Linux gnome 2.6.13-1.1526_FC4 #1 Wed Sep 28 19:15:04 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux
Use skge instead of sk98lin driver to get rid of this bug. Skge is present in 2.6.13-1.1526_FC4 and it works fine on my system.
Are there any relative advantages to the sk98lin driver at all? skge was "experimental" a while ago, but a lot of people use it now. Has anyone compared the two drivers in terms of features, reported stability, etc.? Is sk98lin going to be removed at some point in the future? (I understand it is no longer being developed?) If so, could skge somehow be made the "default" when Yukon h/w is detected by the kernel?
For FC5, sk98lin isn't even compiled anymore, and kudzu etc will use skge as the default for this hardware. It should be feature complete, and actually more stable than sk98lin is/was
I just ran into this problem on fc4. It happened right after I added the line "load "v4l" and forgot to comment out "load "glx" when installing the nvidia driver. I have this exact same error message: MSG: Vpd: Cannot read VPD keys Class: internal Software error nr: 0x19e This is an older athlon 1700xp box, kt400 or kt600 chipset, with a 6600 nvidia gt, dlink dge-530t and the 2.6.13-1.526_fc4 kernel
Horray! Fixed for me in kernel-2.6.13-1.1532_FC4. [greg@gnome ~]$ uname -a Linux gnome 2.6.13-1.1532_FC4 #1 Thu Oct 20 01:28:35 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux
This problem just happened to me using a DFI lanparty nf4 motherboard with a marvel NIC. Using the latest kernel to date. Feb 6 16:24:29 hondatestlinux kernel: eth0: -- ERROR -- Feb 6 16:24:29 hondatestlinux kernel: Class: internal Software error Feb 6 16:24:29 hondatestlinux kernel: Nr: 0x19e Feb 6 16:24:29 hondatestlinux kernel: Msg: Vpd: Cannot read VPD keys [root@hondatestlinux ~]# uname -a Linux hondatestlinux 2.6.15-1.1830_FC4smp #1 SMP Thu Feb 2 17:39:38 EST 2006 i686 athlon i386 GNU/Linux
Kevin -- try installing FC5 when it comes out (or upgrade to fedora-development RPMs for a beta version). It should fix your problem. (See Comment #22.)