[PATCH] firewire: detect and log TSB81BA3 erratum - Kernel

This is a discussion on [PATCH] firewire: detect and log TSB81BA3 erratum - Kernel ; While testing a larger 1394b bus, I saw the following Texas Instruments TSB81BA3 hardware bug at work: On a 1394b-only bus with three or more PHYs and differing cable lengths or differing hop speeds, the PHYs repeatedly cause bus resets ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: [PATCH] firewire: detect and log TSB81BA3 erratum

  1. [PATCH] firewire: detect and log TSB81BA3 erratum

    While testing a larger 1394b bus, I saw the following Texas Instruments
    TSB81BA3 hardware bug at work: On a 1394b-only bus with three or more
    PHYs and differing cable lengths or differing hop speeds, the PHYs
    repeatedly cause bus resets during traffic on the bus, as documented in
    TI's "TSB81BA3 Errata (Rev. C)" SLLZ015C. These resets cause massive
    I/O failures.

    Self-ID complete events after such resets consistently show more than
    one self-ID zero packet with i bit set ( = initiated reset). If this
    happens, emit a warning in dmesg and suggest hardware workarounds to the
    user. (There is no software workaround.)

    The hardware bug is fixed in TSB81BA3 revision D but there are probably
    many FireWire 800 products out there which have a buggy version of this
    chip.

    Signed-off-by: Stefan Richter
    ---
    drivers/firewire/fw-topology.c | 13 ++++++++++++-
    1 file changed, 12 insertions(+), 1 deletion(-)

    Index: linux/drivers/firewire/fw-topology.c
    ================================================== =================
    --- linux.orig/drivers/firewire/fw-topology.c
    +++ linux/drivers/firewire/fw-topology.c
    @@ -179,7 +179,7 @@ static struct fw_node *build_tree(struct
    struct list_head stack, *h;
    u32 *next_sid, *end, q;
    int i, port_count, child_port_count, phy_id, parent_count, stack_depth;
    - int gap_count;
    + int gap_count, reset_initiators;
    bool beta_repeaters_present;

    local_node = NULL;
    @@ -190,6 +190,7 @@ static struct fw_node *build_tree(struct
    phy_id = 0;
    irm_node = NULL;
    gap_count = SELF_ID_GAP_COUNT(*sid);
    + reset_initiators = 0;
    beta_repeaters_present = false;

    while (sid < end) {
    @@ -285,6 +286,8 @@ static struct fw_node *build_tree(struct
    list_add_tail(&node->link, &stack);
    stack_depth += 1 - child_port_count;

    + reset_initiators += SELF_ID_PHY_INITIATOR(q);
    +
    if (node->phy_speed == SCODE_BETA &&
    parent_count + child_port_count > 1)
    beta_repeaters_present = true;
    @@ -307,6 +310,14 @@ static struct fw_node *build_tree(struct
    card->gap_count = gap_count;
    card->beta_repeaters_present = beta_repeaters_present;

    + if (reset_initiators != 1) {
    + fw_error("%d bus reset initiators, hardware bug?\n",
    + reset_initiators);
    + if (beta_repeaters_present)
    + fw_error("try cables with matched length "
    + "or add a 1394a node\n");
    + }
    +
    return local_node;
    }


    --
    Stefan Richter
    -=====-==--- =-== -=---
    http://arcgraph.de/sr/

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [PATCH] firewire: detect and log TSB81BA3 erratum

    I wrote:
    [...]
    > TI's "TSB81BA3 Errata (Rev. C)" SLLZ015C. These resets cause massive
    > I/O failures.
    >
    > Self-ID complete events after such resets consistently show more than
    > one self-ID zero packet with i bit set ( = initiated reset). If this
    > happens, emit a warning in dmesg and suggest hardware workarounds to the
    > user.


    Apparently two initiators are OK when a node joins a bus. My alarm goes
    off too quickly.
    --
    Stefan Richter
    -=====-==--- =-== -=---
    http://arcgraph.de/sr/
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread