Re: Marvell 88E8056 gigabit ethernet controller

On Fri, 17 Aug 2007 05:42:13 -0700 (PDT)
Kevin E [off-list ref] wrote:

Hi all,

	I've read where the onboard Marvell lan controller on
some Gigabyte boards don't work.  I've got two systems
using the same Gigabyte board, on one the LAN works on
the other it dies like described by others.  Here's
the systems:


Working system:
Gigabyte 965P-DS3 rev 3.3  (BIOS F10)
Core2 Q6600
2GB Corsair XMS2 memory
kernel 2.6.22.3

lspci for LAN controller:
04:00.0 Ethernet controller: Marvell Technology Group
Ltd. 88E8056 PCI-E Gigabit Ethernet Controller (rev
14)


Broken system:
Gigabyte 965P-DS3 rev 3.3  (BIOS F10)
Core2 E4400
2GB Corsair XMS2 memory
kernel 2.6.22.3

lspci for LAN controller:
03:00.0 Ethernet controller: Marvell Technology Group
Ltd. Unknown device 4364 (rev 12)


	The BIOS for the two systems are setup the same and
the config for the kernels are the same too.  I've
actually tried taking the kernel from the working
system and booting it on the broken one but still the
LAN dies after a couple of seconds.  The working
system has one card plugged in (nvidia based PCI-X
video card), I've taken that card and plugged into the
broken system, booted the same kernel, and it still
dies after a while.

	I will gladly provide any info needed if it can help
in getting this chipset working on the Gigabyte
boards.

	Thanks,
	Kevin

I maintain the sky2 driver, and have one of the (buggy) Gigabyte motherboards.
It is interesting that the problem seems to track with video card.
Are you using the Nvidia binary driver?
The video card in the system I have troubles with is:
	ATI Technologies Inc RV370 [Radeon X300SE]

Surprisingly, using other PCI-E cards with same driver (different Marvell chips)
has no problem.  Vendor version of sk98lin driver has same failure mode
on the buggy hardware.

You might want to look at lspci -vvv output on two system to see if there
are differences. Perhaps there is a CPU speed dependency?

On Fri, Aug 17, 2007 at 05:03:41PM -0700, Stephen Hemminger wrote:

On Fri, 17 Aug 2007 05:42:13 -0700 (PDT)
Kevin E [off-list ref] wrote:

quoted

Hi all,

	I've read where the onboard Marvell lan controller on
some Gigabyte boards don't work.  I've got two systems
using the same Gigabyte board, on one the LAN works on
the other it dies like described by others.  Here's
the systems:


Working system:
Gigabyte 965P-DS3 rev 3.3  (BIOS F10)
Core2 Q6600
2GB Corsair XMS2 memory
kernel 2.6.22.3

lspci for LAN controller:
04:00.0 Ethernet controller: Marvell Technology Group
Ltd. 88E8056 PCI-E Gigabit Ethernet Controller (rev
14)


Broken system:
Gigabyte 965P-DS3 rev 3.3  (BIOS F10)
Core2 E4400
2GB Corsair XMS2 memory
kernel 2.6.22.3

lspci for LAN controller:
03:00.0 Ethernet controller: Marvell Technology Group
Ltd. Unknown device 4364 (rev 12)


	The BIOS for the two systems are setup the same and
the config for the kernels are the same too.  I've
actually tried taking the kernel from the working
system and booting it on the broken one but still the
LAN dies after a couple of seconds.  The working
system has one card plugged in (nvidia based PCI-X
video card), I've taken that card and plugged into the
broken system, booted the same kernel, and it still
dies after a while.

	I will gladly provide any info needed if it can help
in getting this chipset working on the Gigabyte
boards.

	Thanks,
	Kevin

I maintain the sky2 driver, and have one of the (buggy) Gigabyte motherboards.
It is interesting that the problem seems to track with video card.

No Stephen, look again, he says that moving the video card into the broken
system does not change anything.

Are you using the Nvidia binary driver?
The video card in the system I have troubles with is:
	ATI Technologies Inc RV370 [Radeon X300SE]

Surprisingly, using other PCI-E cards with same driver (different Marvell chips)
has no problem.  Vendor version of sk98lin driver has same failure mode
on the buggy hardware.

You might want to look at lspci -vvv output on two system to see if there
are differences. Perhaps there is a CPU speed dependency?

I don't understand why the working one is on PCI bus 3 while the other
is on PCI bus 4. It's just as if the chip embedded a PCI bridge. Maybe
those chips are just cheaper dual-channel controllers with one faulty
controller disabled. It would also explain why the PCI ID is different.

Willy

--- Willy Tarreau <w@1wt.eu> wrote:

No Stephen, look again, he says that moving the
video card into the broken
system does not change anything.

Correct, I've used three different video cards in the
broken machine.  I've used an old PCI vid card, the
PCI-X vid card from the working machine, and now PCI-X
card I just bought yesterday (nvidia based).  None
have affected whether the Marvell chipset works or
not.  

Also, the broken machine is a server so I don't start
X on it.  It just sits in console mode all the time. 
The CPU (Core2 E4400) used to be in the working
machine, then upgraded it to the Q6600 and put the old
E4400 in the new MB that became the broken machine. 
Memory was brand new out of the package.  So I've used
the E4400 in a MB that worked fine.

I don't understand why the working one is on PCI bus
3 while the other
is on PCI bus 4. It's just as if the chip embedded a
PCI bridge. Maybe
those chips are just cheaper dual-channel
controllers with one faulty
controller disabled. It would also explain why the
PCI ID is different.

I've attached the "lspci -vvv" output for the two
machines, if it doesn't come through just let me know
how I can get it to you.

Thanks,
Kevin


       
____________________________________________________________________________________Ready for the edge of your seat? 
Check out tonight's top picks on Yahoo! TV. 
http://tv.yahoo.com/

On Sat, Aug 18, 2007 at 04:45:26AM -0700, Kevin E wrote:

OK, in this trace, both controllers are on the same bus. The broken
one has 'Capabilities: [100] Advanced Error Reporting' the other
does not have, and the bridge to this bus has two more capabilities :
'Capabilities: [100] Virtual Channel' and 'Capabilities: [180] Unknown (5)'.

I don't know whether it can jutify a different behaviour. Also, maybe this
is caused by a minuscule difference in the BIOS setup ?

Regards,
Willy

--- Willy Tarreau <w@1wt.eu> wrote:

OK, in this trace, both controllers are on the same
bus. The broken
one has 'Capabilities: [100] Advanced Error
Reporting' the other
does not have, and the bridge to this bus has two
more capabilities :
'Capabilities: [100] Virtual Channel' and
'Capabilities: [180] Unknown (5)'.

I don't know whether it can jutify a different
behaviour. Also, maybe this
is caused by a minuscule difference in the BIOS
setup ?

I just checked the BIOS' between the two machines and
there was one slight difference.  Working machine I
had serial port turned off and the parallel port setup
differently, so I made changes to the broken machines
BIOS so they are identical.  After making the change I
checked 'lspci -vvv' on the broken one and it's the
same output as before.  

I tested the Marvell interface to see if it made any
difference and the line died after about a second of
transfering data.  dmesg reported this:

sky2 eth1: enabling interface
sky2 eth1: ram buffer 0K
sky2 eth1: Link is up at 100 Mbps, full duplex, flow
control both
sky2 0000:04:00.0: error interrupt status=0x80000000
sky2 eth1: hw error interrupt status 0x8
sky2 eth1: MAC parity error
sky2 0000:04:00.0: error interrupt status=0x80000000
sky2 eth1: hw error interrupt status 0x8
sky2 eth1: MAC parity error
sky2 eth1: disabling interface


Kevin


       
____________________________________________________________________________________Ready for the edge of your seat? 
Check out tonight's top picks on Yahoo! TV. 
http://tv.yahoo.com/

On Sat, 18 Aug 2007 06:59:08 -0700 (PDT)
Kevin E [off-list ref] wrote:

The working board has a different version of the Marvell chip:

$ grep Marvell working-MB 
04:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller (rev 14)
$ grep Marvell broken-MB 
04:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller (rev 12)

Not sure if that completely explains the problem because the broken chip on my
system is:
06:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller (rev 14)

I don't know what the differences are between versions.

--- Stephen Hemminger

[off-list ref] wrote:

The working board has a different version of the
Marvell chip:

$ grep Marvell working-MB 
04:00.0 Ethernet controller: Marvell Technology
Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller
(rev 14)
$ grep Marvell broken-MB 
04:00.0 Ethernet controller: Marvell Technology
Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller
(rev 12)

Not sure if that completely explains the problem
because the broken chip on my
system is:
06:00.0 Ethernet controller: Marvell Technology
Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller
(rev 14)

I don't know what the differences are between
versions.

Since I have a rev 14 that works and you have a rev 14
that doesn't work, is there any other info I can
provide to you that would maybe help in figuring out
how you can get your board working?



       
____________________________________________________________________________________
Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase.
http://farechase.yahoo.com/

The sky2 driver clears some bits in the PHY control register, that cause
the PHY interface to get changed.  Some of these deal with voltage and power
savings as well. This may explain some of the failures on Gigabyte DS-3 motherboard.

The clue to possible problem was looking at why loading/unloading sky2 would
break vendor sk98lin driver (ie what registers changed).

--- a/drivers/net/sky2.c	2007-08-21 09:53:41.000000000 -0700
+++ b/drivers/net/sky2.c	2007-08-21 09:53:43.000000000 -0700

@@ -696,8 +696,8 @@ static void sky2_mac_init(struct sky2_hw
 	int i;
 	const u8 *addr = hw->dev[port]->dev_addr;
 
-	sky2_write32(hw, SK_REG(port, GPHY_CTRL), GPC_RST_SET);
-	sky2_write32(hw, SK_REG(port, GPHY_CTRL), GPC_RST_CLR);
+	sky2_write8(hw, SK_REG(port, GPHY_CTRL), GPC_RST_SET);
+	sky2_write8(hw, SK_REG(port, GPHY_CTRL), GPC_RST_CLR);
 
 	sky2_write8(hw, SK_REG(port, GMAC_CTRL), GMC_RST_CLR);
 

--- Stephen Hemminger

[off-list ref] wrote:

This appears to have fixed the problem!  I made the
change to the kernel on the broken MB and the link
stayed up.  So I went ahead and made the change to the
kernel on the working one too.   Right now I'm using
netcat to saturate the link and make sure it stays up.
 So far it's looking good, if I have any problems I'll
let you know.

Thanks,
Kevin



       
____________________________________________________________________________________
Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.
http://smallbusiness.yahoo.com/webhosting