Bug 136158 - eth0 error: Cannot read VPD keys (Marvell chipset)
Summary: eth0 error: Cannot read VPD keys (Marvell chipset)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 4
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dave Jones
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-10-18 13:24 UTC by Luke Hutchison
Modified: 2015-01-04 22:10 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2005-10-28 00:13:14 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Luke Hutchison 2004-10-18 13:24:39 UTC
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?

Comment 1 Luke Hutchison 2004-11-05 14:36:26 UTC
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.

Comment 2 François Jan 2004-12-05 23:04:12 UTC
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.

Comment 3 Luke Hutchison 2004-12-06 06:31:35 UTC
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!

Comment 4 Luke Hutchison 2005-02-05 20:59:51 UTC
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..

Comment 5 Kenneth Porter 2005-06-28 00:20:16 UTC
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.

Comment 6 Kenneth Porter 2005-06-28 00:31:27 UTC
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.

Comment 7 Dave Jones 2005-07-15 18:24:31 UTC
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.

Comment 8 Luke Hutchison 2005-07-15 20:55:06 UTC
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.

Comment 9 Dave Jones 2005-07-15 21:54:52 UTC
[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.


Comment 10 Luke Hutchison 2005-07-16 01:20:04 UTC
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.


Comment 11 Need Real Name 2005-07-23 22:24:40 UTC
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

Comment 12 josip 2005-09-09 09:01:35 UTC
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


Comment 13 josip 2005-09-11 14:34:00 UTC
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?

Comment 14 Dave Jones 2005-09-12 03:05:03 UTC
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


Comment 15 Paul Hanson 2005-09-29 01:38:30 UTC
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!


Comment 16 Luke Hutchison 2005-09-29 03:44:14 UTC
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).

Comment 17 Dave Jones 2005-09-30 06:41:34 UTC
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.


Comment 18 Luke Hutchison 2005-09-30 12:24:25 UTC
I don't believe the update fixes the issue, but I can't test as I patched my VPD.


Comment 19 Need Real Name 2005-10-02 06:44:04 UTC
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


Comment 20 josip 2005-10-04 14:41:41 UTC
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.

Comment 21 Luke Hutchison 2005-10-04 23:53:37 UTC
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?


Comment 22 Dave Jones 2005-10-05 22:29:06 UTC
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


Comment 23 Kevin Larkin 2005-10-17 05:09:36 UTC
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


Comment 24 Need Real Name 2005-10-27 05:01:38 UTC
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


Comment 25 Kevin Larkin 2006-02-07 00:26:34 UTC
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

Comment 26 Luke Hutchison 2006-02-07 06:35:27 UTC
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.)


Note You need to log in before you can comment on or make changes to this bug.