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
Msg: Vpd Cannot read VPD keys
I found the following related problems in many pages for the ASUS
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
I also reported this to kernel bugzilla, bug number 3598. No response
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
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:
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?
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):
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'.
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
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
[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 v220.127.116.11" 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
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
It's an easy fix, someone just has to do it :-) There's a patch here:
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 (18.104.22.168). 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.
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
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
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
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.)