[haiku-bugs] Re: [Haiku] #8454: Very low network performance with a Marvell Yukon card.

  • From: "bga" <trac@xxxxxxxxxxxx>
  • Date: Wed, 11 Apr 2012 22:38:43 -0000

#8454: Very low network performance with a Marvell Yukon card.
   Reporter:  bga                            |      Owner:  nobody
       Type:  bug                            |     Status:  new
   Priority:  high                           |  Milestone:  R1
  Component:  Drivers/Network/marvell_yukon  |    Version:  R1/Development
 Resolution:                                 |   Keywords:
 Blocked By:                                 |   Blocking:
Has a Patch:  0                              |   Platform:  All

Comment (by bga):

 looks like the concept of "status" is a bit overloaded in this driver.
 There seem to be at least 2 interrupt handlers:

 static void
 msk_intr_phy(struct msk_if_softc *sc_if)
         uint16_t status;

         msk_phy_readreg(sc_if, PHY_ADDR_MARV, PHY_MARV_INT_STAT);
         status = msk_phy_readreg(sc_if, PHY_ADDR_MARV, PHY_MARV_INT_STAT);
         /* Handle FIFO Underrun/Overflow? */
         if ((status & PHY_M_IS_FIFO_ERROR))
                     "PHY FIFO underrun/overflow.\n");


 static void
 msk_intr_gmac(struct msk_if_softc *sc_if)
         struct msk_softc *sc;
         uint8_t status;

         sc = sc_if->msk_softc;
         status = CSR_READ_1(sc, MR_ADDR(sc_if->msk_port, GMAC_IRQ_SRC));

         /* GMAC Rx FIFO overrun. */
         if ((status & GM_IS_RX_FF_OR) != 0)
                 CSR_WRITE_4(sc, MR_ADDR(sc_if->msk_port, RX_GMF_CTRL_T),
         /* GMAC Tx FIFO underrun. */
         if ((status & GM_IS_TX_FF_UR) != 0) {
                 CSR_WRITE_4(sc, MR_ADDR(sc_if->msk_port, TX_GMF_CTRL_T),
                 device_printf(sc_if->msk_if_dev, "Tx FIFO underrun!\n");
                  * XXX
                  * In case of Tx underrun, we may need to flush/reset
                  * Tx MAC but that would also require resynchronization
                  * with status LEs. Reinitializing status LEs would
                  * affect other port in dual MAC configuration so it
                  * should be avoided as possible as we can.
                  * Due to lack of documentation it's all vague guess but
                  * it needs more investigation.

 As you can see, status is 8 bits in one, 16 bits in the other and the last
 CL changed the status somewhere else to 32 bits. i wonder if this is not
 causing the issues.

 In any case, I am not familiar with the FreeBSD compatibility layer. Any
 ideas which of the interrupt handlers should I be checking the status in?
 My guess would be the second one.

Ticket URL: <http://dev.haiku-os.org/ticket/8454#comment:9>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.

Other related posts: