netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yan Seiner <yan@seiner.com>
To: Gene Heskett <gene.heskett@verizon.net>
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	aabdulla@nvidia.com
Subject: Re: mcp55 forcedeth woes
Date: Tue, 14 Apr 2009 07:35:50 -0700	[thread overview]
Message-ID: <49E49F46.8030509@seiner.com> (raw)
In-Reply-To: <200904132224.13716.gene.heskett@verizon.net>

Gene Heskett wrote:
> On Monday 13 April 2009, Yan Seiner wrote:
>   
>> Gene Heskett wrote:
>>     
>>> On Monday 13 April 2009, Yan Seiner wrote:
>>>       
>>>> I have a few Asus M2N-SLI deluxe mobos.  These mobos have the MCP55
>>>> chipset and two 1gb ethernet ports.  Occasionally, and for no reason that
>>>> I can figure out, these ports will die.  There are various ways to try
>>>> and fix these; they seem to be about 50% effective, and approach
>>>> something akin to voodoo.
>>>>
>>>> Based on this discussion here:
>>>>
>>>> http://patchwork.kernel.org/patch/16212/
>>>>
>>>> I've gotten the ability to turn the ports on and off somewhat.
>>>>
>>>> For port 0,
>>>>
>>>> ethtool -s eth0 autoneg off speed 10 duplex full
>>>>
>>>> turns on the link, and gets me half-duplex, 10mb/sec. Not much, granted.
>>>>
>>>> ethtool -s eth0 autoneg off speed 100 duplex full
>>>>
>>>> causes the link to go up and down on about a 2 second cycle.
>>>>
>>>> ethtool -s eth0 autoneg on
>>>>
>>>> causes the link to drop.
>>>>
>>>> For port 1, the behavior is similar, except that I can get a stable 100
>>>> mbit connection.
>>>>
>>>> So the problem is in the autoneg code. It's a driver issue as this is
>>>> reported widely to work under windows of various flavors.
>>>>
>>>> I'm running 2.6.29.1; I'm ok with patching and building kernels, but I'm
>>>> not a kernel hacker.
>>>>
>>>> What, if anything, can I provide and do to fix this?
>>>>         
>>> It was in 2.6.29-rc8 or 9 that they finally got the ability to turn them
>>> back on on my identical mobo.  Through most of the 29-rcx series we had
>>> the choice of rebooting with the reset button, or powering everything
>>> associated with the ports down for about 2 minutes so they would forget
>>> they were turned off by a graceful shutdown.  Now they are turned off (and
>>> I've still NDI why) and back on like they are supposed to be.   I called
>>> that a PIMA.
>>>       
>> Yeah, I've been fighting this for a while....  The boards are rock-solid
>> under load, which is why I like them.... But this is a PITA.
>>
>> This board worked fine, then I shutdown and the ports have not come back
>> since.  I'm running 2.6.29.1 - no joy on the ports.
>>
>>     
>
> Shut it down, including removing the power cord, and unplug all ethernet 
> cables attached, give it time to fully discharge all stored power in the caps, 
> at least 30 secs, I usually go make a cup of tea in the microwave, so its 
> about 3 minutes.  Plug everything back in and power it up, they should work 
> again.
>
> However, I've been running 2.6.29.1-rc2, and that has not been a problem, I 
> can see the leds on the ports go plumb dark at it runs the shutdown, and come 
> back on about 15 seconds before the init.d/network script runs as it boots up.
>  
>   
>> I'm building forcedeth from .30-rc1 - we'll see if that helps.
>> Something like 15% of the driver changed, so it's still in very heavy
>> development.
>>     
>
> Wow!  Like you, I'm using forcedeth. 2.6.29.1-rc1 did have a short uptime for 
> forcedeth bug IIRC, but so far, -rc2 has lasted longer than KDE-4.2.1 on this 
> F10 system will, I had an 8 day uptime at first, and I'm in the 5th day again.  
> I killed it the first time screwing with some worthless bluetooth dongles I 
> got from USBGear.  Locked it up tighter than a Nebraska bulls ass in flytime.  
> Had to use the reset button. :(
>   
I followed Gene's advice and got some progress....

port 0 is now fully functional.  Port 1, however, remains in its 
semi-zombie state.  Maybe I'll take the machine off-line longer next 
time.   Maybe I'll sacrifice a black and white chicken at the same time.

I also back-ported 2.9.30-rc1 forcedeth.c to my 2.6.29.1 kernel; no 
difference whatsoever.

One other observation:

On the switch, the status LEDs glow with half-brightness when I enable 
port 1 using ethtool...  This leads me to suspect that the voltage 
levels on the port aren't normal.  Not being a hardware engineer, I have 
no idea what importance this has; I am offering this as an observation.

--Yan

-- 
Yan Seiner 

Support my bid for the 4J School Board.
Visit http://www.seiner.com/schoolboard

  parent reply	other threads:[~2009-04-14 14:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <e3e0f4f0ca9fdce35c24b30559d10f31.squirrel@www.datavault.us>
2009-04-13 23:45 ` mcp55 forcedeth woes Andrew Morton
2009-04-15 13:54   ` Yan Seiner
     [not found] ` <200904132100.58056.gene.heskett@verizon.net>
     [not found]   ` <49E3EF9F.6090600@seiner.com>
     [not found]     ` <200904132224.13716.gene.heskett@verizon.net>
2009-04-14 14:35       ` Yan Seiner [this message]
2009-04-14 16:34         ` John Stoffel
2009-04-14 16:47           ` Yan Seiner
2009-04-14 18:27           ` Gene Heskett

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49E49F46.8030509@seiner.com \
    --to=yan@seiner.com \
    --cc=aabdulla@nvidia.com \
    --cc=gene.heskett@verizon.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).