Description of problem: I have installed RHEL-4 Update 3 on an Shuttle-SB83G5 , which has the Marvell 88E8001 gigabit ethernet chip in it. When inserting the sk98lin module, the kernel gives the following error every second or two: May 8 10:59:25 localhost kernel: eth0: -- ERROR -- May 8 10:59:25 localhost kernel: Class: internal Software error May 8 10:59:25 localhost kernel: Nr: 0x19e May 8 10:59:25 localhost kernel: Msg: Vpd: Cannot read VPD keys Version-Release number of selected component (if applicable): 2.6.9-34.EL How reproducible: always Steps to Reproduce: 1. Install RHEL-4.U3 on hardware with Marvell 88E8001 hardware... 2. Look at the system logs Actual results: May 8 10:59:25 localhost kernel: eth0: -- ERROR -- May 8 10:59:25 localhost kernel: Class: internal Software error May 8 10:59:25 localhost kernel: Nr: 0x19e May 8 10:59:25 localhost kernel: Msg: Vpd: Cannot read VPD keys Expected results: no errors Additional info: This is also being addressed in Fedora Core as bugzilla #136158
Created attachment 128822 [details] Force sk98lin to ignore VPD checksum errors Marvell is publishing a 2.6 kernel patch for the sk98lin v2.6 driver. The only change they recommend is to comment out the section of code that checks for Vital Product Data (VPD) checksum errors... The sk98lin driver in RHEL-4.U3 is significantly older, but the attached patch makes the same (narrowly-focused) change to the current 2.6.9-34.EL kernel.
Please try the skge driver in the kernels here: http://people.redhat.com/linville/kernels/rhel4/ I would prefer not to take any patches for sk98lin if at all possible.
I understand. But my perspective is that of a conservative sys-admin, not a vendor or a kernel developer. If I have to diverge from a stock released kernel, I want to do so minimally. That way I stay very close to your well-tested path.
OK...then please try the skge driver in U4 when it becomes available?
Yes. Definitely. Is there a tentative date for U4 yet?
U4 should be out now...can you try the skge driver? thanks!
Closed due to lack of response. Please reopen (if appropriate) when the requested information becomes available...thanks!