Marvell 88E8056 gigabit ethernet controller

Marvell 88E8056 gigabit ethernet controller

[Kevin E]

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


       
____________________________________________________________________________________
Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. 
http://answers.yahoo.com/dir/?link=list&sid=396545433

Re: Marvell 88E8056 gigabit ethernet controller

[Stephen Hemminger]

On Fri, 17 Aug 2007 05:42:13 -0700 (PDT)
Kevin E <kevin360@yahoo.com> 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?

Re: Marvell 88E8056 gigabit ethernet controller

[Willy Tarreau]

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 <kevin360@yahoo.com> 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.

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

Re: Marvell 88E8056 gigabit ethernet controller

[Kevin E]

[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]


--- 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/

[-- Attachment #2: 2173274505-working-MB.gz --]
[-- Type: application/gzip, Size: 2549 bytes --]

[-- Attachment #3: 2522529575-broken-MB.gz --]
[-- Type: application/gzip, Size: 2906 bytes --]

Re: Marvell 88E8056 gigabit ethernet controller

[Willy Tarreau]

On Sat, Aug 18, 2007 at 04:45:26AM -0700, Kevin E wrote:
> 
> --- 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.

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

Re: Marvell 88E8056 gigabit ethernet controller

[Kevin E]

--- 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/

Re: Marvell 88E8056 gigabit ethernet controller

[Stephen Hemminger]

On Sat, 18 Aug 2007 06:59:08 -0700 (PDT)
Kevin E <kevin360@yahoo.com> wrote:

> --- 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 ?
> 

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.

Re: Marvell 88E8056 gigabit ethernet controller

[Kevin E]

--- Stephen Hemminger
<shemminger@linux-foundation.org> 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/

[RFT] sky2: yukon-ec-u phy power problems

[Stephen Hemminger]

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);
 

Re: [RFT] sky2: yukon-ec-u phy power problems

[Kevin E]

--- Stephen Hemminger
<shemminger@linux-foundation.org> wrote:

> 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);
>  

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 

Re: Marvell 88E8056 gigabit ethernet controller

[Stephen Hemminger]

The driver prints some chip version info at startup, that might
be helpful in disambiguating good/bad versions:

	dmesg | grep sky2

Re: Marvell 88E8056 gigabit ethernet controller

[Kevin E]

--- Stephen Hemminger
<shemminger@linux-foundation.org> wrote:

> The driver prints some chip version info at startup,
> that might
> be helpful in disambiguating good/bad versions:
> 
> 	dmesg | grep sky2

Here's the output from the working MB:

sky2 0000:04:00.0: v1.14 addr 0xf8000000 irq 16
Yukon-EC Ultra (0xb4) rev 3
sky2 eth0: addr 00:1a:4d:42:61:46
sky2 eth0: enabling interface
sky2 eth0: ram buffer 0K
sky2 eth0: Link is up at 100 Mbps, full duplex, flow
control both

The broken MB there's no output in dmesg but there is
in /var/log/messages (I just rebooted the machine to
get the output):

Aug 19 14:56:42 www kernel: sky2 0000:04:00.0: v1.14
addr 0xf8000000 irq 16 Yukon-EC Ultra (0xb4) rev 3
Aug 19 14:56:42 www kernel: sky2 eth1: addr
00:1a:4d:82:11:02




       
____________________________________________________________________________________
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games.
http://sims.yahoo.com/  

Re: Marvell 88E8056 gigabit ethernet controller

[Eric Preston]

On 19-Aug-07, at 2:34 PM, Stephen Hemminger wrote:

> The driver prints some chip version info at startup, that might
> be helpful in disambiguating good/bad versions:
>
> 	dmesg | grep sky2

sky2 0000:03:00.0: v1.16 addr 0xfa000000 irq 16 Yukon-EC Ultra (0xb4)  
rev 2
sky2 eth0: addr XX:XX:XX:XX:XX
sky2 eth0: enabling interface
sky2 eth0: ram buffer 0K
sky2 eth0: disabling interface

-E

---
Eric Preston, RHCA, RHCSS, RHCE
Open Source Software Consultant // Administrator, Developer, Trainer
514-312-7072

Re: Marvell 88E8056 gigabit ethernet controller

[Kevin E]

Someone wrote me with a solution to try and so far
it's working.  They suggested I try the driver up on
Marvell's website but to make sure I powered off the
machine completely and when it rebooted to not have
any of the regular kernel drivers for the Marvell
chipset to load.  They had found that letting the sky2
load and then unloading the module would mean the
vendor's driver wouldn't work.

So I got down the latest driver package they have
(10.0.5.3).  At first I couldn't get it compiled
against kernel 2.6.22.3 that I'm running, but I have
it compiled with the 2.6.21.5 kernel, which is what
the machine is running now.  And I'm happy to say that
it's working fine so far.  I've transfered about 4G
over the link and it's still working fine.

Since Marvell's driver seems to be working for the
88E8056 chipset and from what I've looked at the code
it's marked as GPL, could it be rolled into the kernel
for those of us that have 88E8056 chipsets that are
working to use? 



       
____________________________________________________________________________________
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games.
http://sims.yahoo.com/  

Re: Marvell 88E8056 gigabit ethernet controller

[Stephen Hemminger]

On Sun, 19 Aug 2007 18:15:47 -0700 (PDT)
Kevin E <kevin360@yahoo.com> wrote:

> Someone wrote me with a solution to try and so far
> it's working.  They suggested I try the driver up on
> Marvell's website but to make sure I powered off the
> machine completely and when it rebooted to not have
> any of the regular kernel drivers for the Marvell
> chipset to load.  They had found that letting the sky2
> load and then unloading the module would mean the
> vendor's driver wouldn't work.
> 
> So I got down the latest driver package they have
> (10.0.5.3).  At first I couldn't get it compiled
> against kernel 2.6.22.3 that I'm running, but I have
> it compiled with the 2.6.21.5 kernel, which is what
> the machine is running now.  And I'm happy to say that
> it's working fine so far.  I've transfered about 4G
> over the link and it's still working fine.
> 
> Since Marvell's driver seems to be working for the
> 88E8056 chipset and from what I've looked at the code
> it's marked as GPL, could it be rolled into the kernel
> for those of us that have 88E8056 chipsets that are
> working to use? 
> 

Submit for code review, and cleanup the resulting comments.
Good luck.

-- 
Stephen Hemminger <shemminger@linux-foundation.org>

Re: Marvell 88E8056 gigabit ethernet controller

[Eric Preston]

 > 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)

Just to add a bit more information, I've just build up a GA-965P-DS3  
with a Q6600 and the onboard Marvell doesn't seem to be working  
either with 2.6.21.3, 2.6.23-rc3 or a recent gentoo-sources kernel.

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

I've attached the lspci -vvv. I haven't had a chance to do much  
investigation since I just threw an 10/100 in for the time being. Let  
me know if I can provide any assistance in diagnosing or testing.

-E

---
Eric Preston, RHCA, RHCSS, RHCE
Open Source Software Consultant // Administrator, Developer, Trainer
514-312-7072