Re: 82559ER receive stall state - VxWorks

This is a discussion on Re: 82559ER receive stall state - VxWorks ; Reyhan Wrote: > Hi, > When there is a high ethernet trafic btw my target and host, I have a > problem with the 82559ER receiver: the receiver stops receiving > packets. (I capture ethernet packet sent to my target ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Re: 82559ER receive stall state

  1. Re: 82559ER receive stall state


    Reyhan Wrote:
    > Hi,
    > When there is a high ethernet trafic btw my target and host, I have a
    > problem with the 82559ER receiver: the receiver stops receiving
    > packets. (I capture ethernet packet sent to my target using etherpeek
    > sw but I see that device doesn't receive packet by calling ifShow
    > "fei")
    > As a work around, I disable and than enable again the 82559ER
    > interrupt then receiver starts receiving again.
    >
    > I have used WRS fei82557 driver as it is.
    > I have WRS PPMC8245 reference board and under same circumstances I
    > haven't got this problem with PPMC8245 (MPC845@300Mhz, has 82559, and
    > not other pci device)
    > I have the problem on my target (MPC8245@250MHz or 350Mhz) which has
    > 82559ER and also universe vme bridge on the pci.
    >
    > The 82557 driver debug code doesn't indicate any failure, and network
    > stack status seems fine.
    >
    > I will appreciate any comments about the problem.
    >
    > Kind regards, reyhan



    Hi,

    I am currently experiencing the same problem you describe. I've
    unsuccesfully thusfar been looking for the problem but am not making
    any headway. Did you find a solution to this issue ?

    Regards,
    Randall


    --
    rmichau
    posted via http://sysdminforum.com


  2. Re: 82559ER receive stall state

    Hi!

    I have used the 82557End driver for a while, both with an MPC755 and MPC8245
    with several problems. We are using Tornado2.0.2 (VxWorks 5.4). We have
    ended up
    porting the VxWorks 5.5 driver, added some fixes and now I have not seen any
    problems
    for about a year.
    The following fix has been reported to wrs. Maybe it will help you
    Here is my description previously sent to WindRiver:
    In the time since my last email to you I have also stumbled into another
    error in that driver. I managed to get the command unit (CU) of the network
    controller in idle state while the receive unit (RU) was OK in ready state.
    It
    was then impossible to start up the CU again. When checking if the CU unit
    is in idle state in fei82557Action(), only bit 6 and 7 of 'scbStatus' must
    be used
    otherwise the wanted command may not be executed:

    /* check CU operation -- kick if needed */

    CSR_WORD_RD (CSR_STAT_OFFSET, scbStatus);

    if ((scbStatus & SCB_S_CUMASK) != SCB_S_CUACTIVE)
    {
    if ((scbStatus & SCB_S_CUMASK) == SCB_S_CUIDLE) <= CHANGED
    LINE!!!!!!
    {
    if (fei82557SCBCommand (pDrvCtrl, SCB_C_CUSTART, TRUE, pCFD) ==
    ERROR)
    {
    DRV_LOG (DRV_DEBUG_START,
    ("fei82557SCBCommand: command failed\n"),
    0, 0, 0, 0, 0, 0);
    }
    }
    else
    {
    if (fei82557SCBCommand (pDrvCtrl, SCB_C_CURESUME, FALSE, 0x0) ==
    ERROR)
    {
    DRV_LOG (DRV_DEBUG_START,
    ("fei82557SCBCommand: command failed\n"),
    0, 0, 0, 0, 0, 0);
    }
    }
    }

    BT


    "rmichau" wrote in message
    news:rmichau.1y6c8z@nomx.sysadminforum.com...
    >
    > Reyhan Wrote:
    >> Hi,
    >> When there is a high ethernet trafic btw my target and host, I have a
    >> problem with the 82559ER receiver: the receiver stops receiving
    >> packets. (I capture ethernet packet sent to my target using etherpeek
    >> sw but I see that device doesn't receive packet by calling ifShow
    >> "fei")
    >> As a work around, I disable and than enable again the 82559ER
    >> interrupt then receiver starts receiving again.
    >>
    >> I have used WRS fei82557 driver as it is.
    >> I have WRS PPMC8245 reference board and under same circumstances I
    >> haven't got this problem with PPMC8245 (MPC845@300Mhz, has 82559, and
    >> not other pci device)
    >> I have the problem on my target (MPC8245@250MHz or 350Mhz) which has
    >> 82559ER and also universe vme bridge on the pci.
    >>
    >> The 82557 driver debug code doesn't indicate any failure, and network
    >> stack status seems fine.
    >>
    >> I will appreciate any comments about the problem.
    >>
    >> Kind regards, reyhan

    >
    >
    > Hi,
    >
    > I am currently experiencing the same problem you describe. I've
    > unsuccesfully thusfar been looking for the problem but am not making
    > any headway. Did you find a solution to this issue ?
    >
    > Regards,
    > Randall
    >
    >
    > --
    > rmichau
    > posted via http://sysdminforum.com
    >




  3. Re: 82559ER receive stall state

    Hi again,

    Thanks you so much for the assistence. I tried the fix and it
    unfortunately didnt solve my problems. I'm now busy looking at the
    mechanics of the driver and this is proving to be a slow process since
    I dont have that much experience in driver development for VxWorks.

    We have found the following problems with the driver.
    When sending small data frames over the link the target will receive
    the data up to a certain point and then the receive stops. We looked at
    the interrupt handler and this is not invoked when the receiver stalls.
    Ive tried enabling and disabling the interrupt but his doesnt help. The
    problem is even worse at high data throughput as the receiver will
    stall after only 2 to 5 message transfers. what is puzzling is that
    there is no common factor between the tests were running. On one
    occasion the receiver might stall after two messages and on another
    after a thousand messages. This is the same even for same length
    message transfers.

    I also found that the CU of the 82559 gets suspended. Why would the CU
    get suspended?
    We have also checked the driver memory pools and this seems to be fine
    as we arent running out of resources. It therefore seems that the
    memory management of the driver is working okay. As you might tell, I
    am now at a desperate stage.

    Anyone any ideas?



    HB wrote:
    > Hi!
    >
    > I have used the 82557End driver for a while, both with an MPC755 and MPC8245
    > with several problems. We are using Tornado2.0.2 (VxWorks 5.4). We have
    > ended up
    > porting the VxWorks 5.5 driver, added some fixes and now I have not seen any
    > problems
    > for about a year.
    > The following fix has been reported to wrs. Maybe it will help you
    > Here is my description previously sent to WindRiver:
    > In the time since my last email to you I have also stumbled into another
    > error in that driver. I managed to get the command unit (CU) of the network
    > controller in idle state while the receive unit (RU) was OK in ready state.
    > It
    > was then impossible to start up the CU again. When checking if the CU unit
    > is in idle state in fei82557Action(), only bit 6 and 7 of 'scbStatus' must
    > be used
    > otherwise the wanted command may not be executed:
    >
    > /* check CU operation -- kick if needed */
    >
    > CSR_WORD_RD (CSR_STAT_OFFSET, scbStatus);
    >
    > if ((scbStatus & SCB_S_CUMASK) != SCB_S_CUACTIVE)
    > {
    > if ((scbStatus & SCB_S_CUMASK) == SCB_S_CUIDLE) <= CHANGED
    > LINE!!!!!!
    > {
    > if (fei82557SCBCommand (pDrvCtrl, SCB_C_CUSTART, TRUE, pCFD) ==
    > ERROR)
    > {
    > DRV_LOG (DRV_DEBUG_START,
    > ("fei82557SCBCommand: command failed\n"),
    > 0, 0, 0, 0, 0, 0);
    > }
    > }
    > else
    > {
    > if (fei82557SCBCommand (pDrvCtrl, SCB_C_CURESUME, FALSE, 0x0) ==
    > ERROR)
    > {
    > DRV_LOG (DRV_DEBUG_START,
    > ("fei82557SCBCommand: command failed\n"),
    > 0, 0, 0, 0, 0, 0);
    > }
    > }
    > }
    >
    > BT
    >
    >
    > "rmichau" wrote in message
    > news:rmichau.1y6c8z@nomx.sysadminforum.com...
    > >
    > > Reyhan Wrote:
    > >> Hi,
    > >> When there is a high ethernet trafic btw my target and host, I have a
    > >> problem with the 82559ER receiver: the receiver stops receiving
    > >> packets. (I capture ethernet packet sent to my target using etherpeek
    > >> sw but I see that device doesn't receive packet by calling ifShow
    > >> "fei")
    > >> As a work around, I disable and than enable again the 82559ER
    > >> interrupt then receiver starts receiving again.
    > >>
    > >> I have used WRS fei82557 driver as it is.
    > >> I have WRS PPMC8245 reference board and under same circumstances I
    > >> haven't got this problem with PPMC8245 (MPC845@300Mhz, has 82559, and
    > >> not other pci device)
    > >> I have the problem on my target (MPC8245@250MHz or 350Mhz) which has
    > >> 82559ER and also universe vme bridge on the pci.
    > >>
    > >> The 82557 driver debug code doesn't indicate any failure, and network
    > >> stack status seems fine.
    > >>
    > >> I will appreciate any comments about the problem.
    > >>
    > >> Kind regards, reyhan

    > >
    > >
    > > Hi,
    > >
    > > I am currently experiencing the same problem you describe. I've
    > > unsuccesfully thusfar been looking for the problem but am not making
    > > any headway. Did you find a solution to this issue ?
    > >
    > > Regards,
    > > Randall
    > >
    > >
    > > --
    > > rmichau
    > > posted via http://sysdminforum.com
    > >



  4. Re: 82559ER receive stall state

    Hi all,

    I forgot to mention we are using VxWorks5.5 with a PPC.

    regards,
    Randall


  5. Re: 82559ER receive stall state

    I belive the CU is set to be suspended after the laste packet is
    transmitted.
    The "S" bit in the command is set for the last packet to be sendt.

    BT

    wrote in message
    news:1132128378.467084.75740@g43g2000cwa.googlegro ups.com...
    > Hi again,
    >
    > Thanks you so much for the assistence. I tried the fix and it
    > unfortunately didnt solve my problems. I'm now busy looking at the
    > mechanics of the driver and this is proving to be a slow process since
    > I dont have that much experience in driver development for VxWorks.
    >
    > We have found the following problems with the driver.
    > When sending small data frames over the link the target will receive
    > the data up to a certain point and then the receive stops. We looked at
    > the interrupt handler and this is not invoked when the receiver stalls.
    > Ive tried enabling and disabling the interrupt but his doesnt help. The
    > problem is even worse at high data throughput as the receiver will
    > stall after only 2 to 5 message transfers. what is puzzling is that
    > there is no common factor between the tests were running. On one
    > occasion the receiver might stall after two messages and on another
    > after a thousand messages. This is the same even for same length
    > message transfers.
    >
    > I also found that the CU of the 82559 gets suspended. Why would the CU
    > get suspended?
    > We have also checked the driver memory pools and this seems to be fine
    > as we arent running out of resources. It therefore seems that the
    > memory management of the driver is working okay. As you might tell, I
    > am now at a desperate stage.
    >
    > Anyone any ideas?
    >
    >
    >
    > HB wrote:
    >> Hi!
    >>
    >> I have used the 82557End driver for a while, both with an MPC755 and
    >> MPC8245
    >> with several problems. We are using Tornado2.0.2 (VxWorks 5.4). We have
    >> ended up
    >> porting the VxWorks 5.5 driver, added some fixes and now I have not seen
    >> any
    >> problems
    >> for about a year.
    >> The following fix has been reported to wrs. Maybe it will help you
    >> Here is my description previously sent to WindRiver:
    >> In the time since my last email to you I have also stumbled into another
    >> error in that driver. I managed to get the command unit (CU) of the
    >> network
    >> controller in idle state while the receive unit (RU) was OK in ready
    >> state.
    >> It
    >> was then impossible to start up the CU again. When checking if the CU
    >> unit
    >> is in idle state in fei82557Action(), only bit 6 and 7 of 'scbStatus'
    >> must
    >> be used
    >> otherwise the wanted command may not be executed:
    >>
    >> /* check CU operation -- kick if needed */
    >>
    >> CSR_WORD_RD (CSR_STAT_OFFSET, scbStatus);
    >>
    >> if ((scbStatus & SCB_S_CUMASK) != SCB_S_CUACTIVE)
    >> {
    >> if ((scbStatus & SCB_S_CUMASK) == SCB_S_CUIDLE) <= CHANGED
    >> LINE!!!!!!
    >> {
    >> if (fei82557SCBCommand (pDrvCtrl, SCB_C_CUSTART, TRUE, pCFD)
    >> ==
    >> ERROR)
    >> {
    >> DRV_LOG (DRV_DEBUG_START,
    >> ("fei82557SCBCommand: command failed\n"),
    >> 0, 0, 0, 0, 0, 0);
    >> }
    >> }
    >> else
    >> {
    >> if (fei82557SCBCommand (pDrvCtrl, SCB_C_CURESUME, FALSE, 0x0)
    >> ==
    >> ERROR)
    >> {
    >> DRV_LOG (DRV_DEBUG_START,
    >> ("fei82557SCBCommand: command failed\n"),
    >> 0, 0, 0, 0, 0, 0);
    >> }
    >> }
    >> }
    >>
    >> BT
    >>
    >>
    >> "rmichau" wrote in message
    >> news:rmichau.1y6c8z@nomx.sysadminforum.com...
    >> >
    >> > Reyhan Wrote:
    >> >> Hi,
    >> >> When there is a high ethernet trafic btw my target and host, I have a
    >> >> problem with the 82559ER receiver: the receiver stops receiving
    >> >> packets. (I capture ethernet packet sent to my target using etherpeek
    >> >> sw but I see that device doesn't receive packet by calling ifShow
    >> >> "fei")
    >> >> As a work around, I disable and than enable again the 82559ER
    >> >> interrupt then receiver starts receiving again.
    >> >>
    >> >> I have used WRS fei82557 driver as it is.
    >> >> I have WRS PPMC8245 reference board and under same circumstances I
    >> >> haven't got this problem with PPMC8245 (MPC845@300Mhz, has 82559, and
    >> >> not other pci device)
    >> >> I have the problem on my target (MPC8245@250MHz or 350Mhz) which has
    >> >> 82559ER and also universe vme bridge on the pci.
    >> >>
    >> >> The 82557 driver debug code doesn't indicate any failure, and network
    >> >> stack status seems fine.
    >> >>
    >> >> I will appreciate any comments about the problem.
    >> >>
    >> >> Kind regards, reyhan
    >> >
    >> >
    >> > Hi,
    >> >
    >> > I am currently experiencing the same problem you describe. I've
    >> > unsuccesfully thusfar been looking for the problem but am not making
    >> > any headway. Did you find a solution to this issue ?
    >> >
    >> > Regards,
    >> > Randall
    >> >
    >> >
    >> > --
    >> > rmichau
    >> > posted via http://sysdminforum.com
    >> >

    >




  6. Re: 82559ER receive stall state


    HB Wrote:
    > Hi!
    >
    > I have used the 82557End driver for a while, both with an MPC755 and
    > MPC8245
    > with several problems. We are using Tornado2.0.2 (VxWorks 5.4). We
    > have
    > ended up
    > porting the VxWorks 5.5 driver, added some fixes and now I have not
    > seen any
    > problems
    > for about a year.


    Hi HB,

    Would it be a problem for you to send me this driver (5.5 ported to
    5.4)? I am getting stalls all the time and I narrowed it down to the
    END driver. I applied your change to the FEI driver, and, although it
    improved a little, it didn't fix the problem.

    Regards,

    Rafael


    --
    Rafael Pinto
    posted via http://sysdminforum.com


  7. Re: 82559ER receive stall state


    "Rafael Pinto" wrote in message
    news:Rafael.Pinto.21620z@nomx.sysadminforum.com...
    >
    > HB Wrote:
    >> Hi!
    >>
    >> I have used the 82557End driver for a while, both with an MPC755 and
    >> MPC8245
    >> with several problems. We are using Tornado2.0.2 (VxWorks 5.4). We
    >> have
    >> ended up
    >> porting the VxWorks 5.5 driver, added some fixes and now I have not
    >> seen any
    >> problems
    >> for about a year.

    >
    > Hi HB,
    >
    > Would it be a problem for you to send me this driver (5.5 ported to
    > 5.4)? I am getting stalls all the time and I narrowed it down to the
    > END driver. I applied your change to the FEI driver, and, although it
    > improved a little, it didn't fix the problem.
    >
    > Regards,
    >
    > Rafael
    >


    Hi

    I have got these driver from VxWorks. I am not allowed to distribute these.
    Tried to reply direct to you but the I failed. Is your email not valid?
    I can send you info. so you may contact WindRiver and get the driver files.

    HB



+ Reply to Thread