From owner-freebsd-stable@FreeBSD.ORG  Sat Feb  8 17:02:33 2014
Return-Path: <owner-freebsd-stable@FreeBSD.ORG>
Delivered-To: freebsd-stable@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
 (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id 5C5911C4
 for <freebsd-stable@freebsd.org>; Sat,  8 Feb 2014 17:02:33 +0000 (UTC)
Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com
 [IPv6:2001:470:88e6:3::232])
 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mx1.freebsd.org (Postfix) with ESMTPS id F15F31C5B
 for <freebsd-stable@freebsd.org>; Sat,  8 Feb 2014 17:02:32 +0000 (UTC)
Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com
 [IPv6:2001:470:88e6:3::239]) (authenticated bits=128)
 by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s18H2U8X084030;
 Sat, 8 Feb 2014 12:02:30 -0500 (EST)
 (envelope-from curtis@ipv6.occnc.com)
Message-Id: <201402081702.s18H2U8X084030@maildrop2.v6ds.occnc.com>
To: pyunyh@gmail.com
From: Curtis Villamizar <curtis@ipv6.occnc.com>
Subject: Re: Any news about "msk0 watchdog timeout" regression in 10-RELEASE?
In-reply-to: Your message of "Fri, 07 Feb 2014 14:10:40 +0900."
 <20140207051040.GB1369@michelle.cdnetworks.com>
Date: Sat, 08 Feb 2014 12:02:30 -0500
Cc: freebsd-stable@freebsd.org, Vitaly Magerya <vmagerya@gmail.com>,
 curtis@ipv6.occnc.com
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: curtis@ipv6.occnc.com
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-stable>,
 <mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
 <mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Feb 2014 17:02:33 -0000


In message <20140207051040.GB1369@michelle.cdnetworks.com>
Yonghyeon PYUN writes:
 
> On Sat, Jan 25, 2014 at 09:50:50PM +0200, Vitaly Magerya wrote:
> > On 01/25/14 21:35, Curtis Villamizar wrote:
> > > When I'm no longer quite so swamped I'll look at this again.  It seems
> > > we are the only two reporting this problem.
> > 
> > To everyone reading this list: if you have an msk(4) NIC that doesn't
> > work on 10-RELEASE, now is the time to speak up.
> > 
> > > Please send lines of these form from dmesg:
> > > 
> > >   mskc0: <Marvell Yukon 88E8057 Gigabit Ethernet> port 0xe800-0xe8ff
> > >   mem 0xfebfc000-0xfebfffff irq 19 at deviceD 0.0 on pci2
> > > 
> > >   msk0: <Marvell Technology Group Ltd. Yukon Ultra 2 Id 0xba Rev 0x00>
> > >   on mskc0
> > > 
> > > That may indicate we have very similar chips.  If not, this msk
> > > problem may be more widespread.
> > 
> > Mine goes like this:
> > 
> >   mskc0: <Marvell Yukon 88E8040 Fast Ethernet> port 0x2000-0x20ff
> >   mem 0xf0200000-0xf0203fff irq 18 at device 0.0 on pci9
> > 
> >   msk0: <Marvell Technology Group Ltd. Yukon FE+ Id 0xb8 Rev 0x00>
> >   on mskc0
> > 
> > Pretty different chips it seems.
>  
> Please try r261577.


Yonghyeon,

OK.  I assumed that you meant only sys/dev/msk and to use svn update
-r261577 in "head".  The only diff of any consequence relative to the
stable-10 branch is:

@@ -3749,9 +3750,6 @@
        if ((status & Y2_IS_STAT_BMU) != 0 && domore == 0)
                CSR_WRITE_4(sc, STAT_CTRL, SC_STAT_CLR_IRQ);
 
-       /* Clear TWSI IRQ. */
-       if ((status & Y2_IS_TWSI_RDY) != 0)
-               CSR_WRITE_4(sc, B2_I2C_IRQ, 1);
        /* Reenable interrupts. */
        CSR_WRITE_4(sc, B0_Y2_SP_ICR, 2);

I used the r261577 in "head" and this failed on first reboot.  That
was after a long power down (shut off power strip).

I reboot with the kernel that I had been using and it worked on first
reboot with no power down.

Rather limited testing but the fail on first reboot tells us what we
need to know.

Thanks for your continued interest in this.

Curtis