msk(4) stops working.
Pyun YongHyeon
pyunyh at gmail.com
Fri Dec 26 01:56:32 UTC 2008
On Wed, Dec 24, 2008 at 12:43:56PM +0200, Ian FREISLICH wrote:
> Pyun YongHyeon wrote:
> >
> > On Wed, Dec 24, 2008 at 08:54:26AM +0200, Ian FREISLICH wrote:
> > > "Sam Fourman Jr." wrote:
> > > > >> About 2-3 months ago I committed workaround for Yukon silicon bug.
> > > > >> Do you use latest CURRENT?
> > > > >
> > > > > Yes, this is on yesterday's sources. It was better for a month or
> > > > > so, but over the last month it's been really bad. Now I can provoke
> > > > > this condition in under 1 minute of uptime.
> > > > >
> > > > I have a few msk cards, and I could stand to install -CURRENT on a syste
> m
> > > > how do I reproduce your problem?
> > >
> > > I induce it by scp-ing a large (several GB) file from one host to
> > > another. I only have one interface msk interface in my laptop, but
> > > it's an SMP system. Maybe that has something to do with it.
> > >
> >
> > Would you show me the output of "sysctl dev.msk.0.stats" before and
> > after the watchdog timeouts after appling attached patch?
>
> Before:
> dev.msk.0.stats.rx.ucast_frames: 0
> dev.msk.0.stats.rx.bcast_frames: 4
> dev.msk.0.stats.rx.pause_frames: 0
> dev.msk.0.stats.rx.mcast_frames: 0
[...]
> dev.msk.0.stats.tx.single_colls: 0
> dev.msk.0.stats.tx.underflows: 0
>
Thanks for testing and I don't see unusual things from the output.
I still can't reproduce this but would you try attached patch? Also
show me dmesg output to see controller revision.
> > BTW, did you intentionally disable MSI?
>
> No, MSI is enabled.
>
Ok.
--
Regards,
Pyun YongHyeon
-------------- next part --------------
Index: sys/dev/msk/if_msk.c
===================================================================
--- sys/dev/msk/if_msk.c (revision 186497)
+++ sys/dev/msk/if_msk.c (working copy)
@@ -1355,27 +1355,25 @@
CSR_WRITE_4(sc, STAT_LIST_ADDR_HI, MSK_ADDR_HI(addr));
/* Set the status list last index. */
CSR_WRITE_2(sc, STAT_LAST_IDX, MSK_STAT_RING_CNT - 1);
- if (sc->msk_hw_id == CHIP_ID_YUKON_EC &&
- sc->msk_hw_rev == CHIP_REV_YU_EC_A1) {
- /* WA for dev. #4.3 */
- CSR_WRITE_2(sc, STAT_TX_IDX_TH, ST_TXTH_IDX_MASK);
- /* WA for dev. #4.18 */
- CSR_WRITE_1(sc, STAT_FIFO_WM, 0x21);
- CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x07);
- } else {
- CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a);
- CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10);
- if (sc->msk_hw_id == CHIP_ID_YUKON_XL &&
- sc->msk_hw_rev == CHIP_REV_YU_XL_A0)
- CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04);
- else
- CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10);
- CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, 0x0190);
- }
/*
- * Use default value for STAT_ISR_TIMER_INI, STAT_LEV_TIMER_INI.
+ * Interrupt moderation and coalescing frames should be
+ * controllable with sysctl variables or loader tunables
+ * but the relationship between status updates and
+ * interrupt moderation are not clear. Some hardware
+ * revisions seem to very sensitive to these parameters
+ * and could be resulted in poor performance as well as
+ * non-working situation if improper values were chosen.
*/
+ CSR_WRITE_2(sc, STAT_TX_IDX_TH, 0x0a);
+ CSR_WRITE_1(sc, STAT_FIFO_WM, 0x10);
+ if (sc->msk_hw_id == CHIP_ID_YUKON_XL &&
+ sc->msk_hw_rev == CHIP_REV_YU_XL_A0)
+ CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x04);
+ else
+ CSR_WRITE_1(sc, STAT_FIFO_ISR_WM, 0x10);
CSR_WRITE_4(sc, STAT_TX_TIMER_INI, MSK_USECS(sc, 1000));
+ CSR_WRITE_4(sc, STAT_ISR_TIMER_INI, MSK_USECS(sc, 30));
+ CSR_WRITE_4(sc, STAT_LEV_TIMER_INI, MSK_USECS(sc, 50));
/* Enable status unit. */
CSR_WRITE_4(sc, STAT_CTRL, SC_STAT_OP_ON);
@@ -3586,6 +3584,10 @@
domore = msk_handle_events(sc);
if ((status & Y2_IS_STAT_BMU) != 0)
CSR_WRITE_4(sc, STAT_CTRL, SC_STAT_CLR_IRQ);
+ if (CSR_READ_1(sc, STAT_TX_TIMER_CTRL) == TIM_START) {
+ CSR_WRITE_1(sc, STAT_TX_TIMER_CTRL, TIM_STOP);
+ CSR_WRITE_1(sc, STAT_TX_TIMER_CTRL, TIM_START);
+ }
if (ifp0 != NULL && (ifp0->if_drv_flags & IFF_DRV_RUNNING) != 0 &&
!IFQ_DRV_IS_EMPTY(&ifp0->if_snd))
More information about the freebsd-current
mailing list