Re: 3com 3c905c-txm

From: Donald Becker (becker@scyld.com)
Date: Sat May 13 2000 - 02:38:29 EDT

  • Next message: Matt Yourst: "Re: bugreport: pre7 NFS mmap locked in disk wait (in pre8 too)"

    On Fri, 12 May 2000, Bogdan Costescu wrote:

    > First of all thank you for Cc-ing to linux-vortex, I read l-k only as
    > KernelTraffic.

    I read linux-kernel only as a hypermail archive. That makes it a pain to
    reply, but it has long been too high-volume to be useful otherwise.

    > I'm using 3C905C for these tests.
    >
    > > This behavior might have changed with the newer chips. The Download-Stall
    > > method is no longer required, and the semantics might have been
    ..
    > I fully agree with the ideea of adding specific functions for Tornado; I
    > already started to...
    > I suspect that the place which produced the errors in my case is
    > boomerang_start_xmit; this is already after spin_lock_irqsave.

    As I mentioned in the previous reply to the linux-vortex mailing list, the
    3c59x.c code in 2.3.99 is completely bogus.
    You should ignore it completely and look at
        http://www.scyld.com/network/vortex.html
        ftp://www.scyld.com/network/3c59x.c
    as the working method for using the chip.

    The DownStall is only useful on the Boomerang, not the later chips.
    Using DownStall with later chips will result in exactly what you are seeing
    -- hundred or thousands of wasted PCI transactions for each packet.

    The later chips do not need any spinlocking with a properly designed
    transmit routine. Especially not the painfully slow 'irqsave' versions of
    the spinlocks.

    I shouldn't be pointing out specific changes that were bad, because people
    will assume that the rest of the changes were OK. Generally, if one set of
    changes are badly designed, it means that all of the changes should be
    reconsidered.

    > > The answer is that the Tx and Rx paths are very compact. They have to be
    > > that way for good performance. Having multiple functions doesn't add much
    > > to the driver size. But the large, complex media selection code is shared
    > > across generations and card types.
    >
    > Agreed, but you also have the power management routines that only apply to
    > the newer hardware; if you count them too, it might be feasible to split
    > at least in two.

    Power routines don't apply to just chips that might be used with CardBus.
    Hot-swap-PCI has many of the same requirements.

    Donald Becker becker@scyld.com
    Scyld Computing Corporation
    410 Severn Ave. Suite 210
    Annapolis MD 21403

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



    This archive was generated by hypermail 2b29 : Sat May 13 2000 - 02:46:44 EDT