Any news about "msk0 watchdog timeout" regression in 10-RELEASE?

[Curtis Villamizar]

In message <20140207051040.GB1369 at 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