OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Ben Greear (greearbcandelatech.com)
Date: Sat Feb 23 2002 - 23:31:22 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    >>>>eth1: Tx error, status 1 (FID=0212)
    >>>>eth1: Tx error, status 1 (FID=0264)
    >>>>eth1: Tx error, status 1 (FID=02FD)
    >>>>eth1: Tx error, status 1 (FID=018E)
    >>>>eth1: Tx error, status 1 (FID=037B)
    >>>>eth1: Tx error, status 1 (FID=01F4)
    >>>>eth1: Tx error, status 1 (FID=025F)
    >>>>eth1: Tx error, status 1 (FID=0314)
    >>>>eth1: Tx error, status 1 (FID=02E0)
    >>>>
    >>>>
    >>>Looks like one of the all-too-numerous generic errors we're fighting
    >>>at the moment :-(
    >>>
    >>
    >>Is there anywhere I can look to see what 'status 1' might mean?
    >>I got over my fear of hacking drivers (hopefully that is a good
    >>thing :))
    >>
    >
    > Status 1 is a "retry error" which I believe means that the firmware
    > has retransmitted the packet as many times as it's going to, hasn't
    > gotten an acknowledgement, and so has given up.

    I added some __packed__ attributes to some structures, and now I
    rarely get this error above (and it works fine on the strongarm
    w/out compiling with the compile hack!)

    I still get shitty (200kbps) rates when transferring with both
    adapters in 'auto' mode. However, if I fix it at 11Mbps, it runs
    at almost 900Mbps.

    I walked my laptop out of range, however, and the cube started spitting
    out this error:
    eth1: Error -110 writing Tx descriptor to BAP
    eth1: Error -110 writing Tx descriptor to BAP
    eth1: Error -110 writing Tx descriptor to BAP
    eth1: Error -110 writing Tx descriptor to BAP
    eth1: Error -110 writing Tx descriptor to BAP
    eth1: Error -110 writing Tx descriptor to BAP

    The error was still spewing down the console after walking
    the laptop back to the cube...

    This seems to mean timeout... So, I'm thinking that we
    should probably reset or otherwise kick the *** out of
    the chipset when this happens (or perhaps only when it happens
    several times in a row...)

    What do you think about the forced reset? (And how would
    you suggest doing it...I'll try it out..)

    Thanks,
    Ben

    -- 
    Ben Greear <greearbcandelatech.com>       <Ben_Greear AT excite.com>
    President of Candela Technologies Inc      http://www.candelatech.com
    ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear