netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org,
	Jesse Brandeburg <jesse.brandeburg@gmail.com>,
	Stephen Hemminger <shemminger@osdl.org>
Subject: planned driver updates for 2.4.35
Date: Mon, 29 Jan 2007 22:01:13 +0100	[thread overview]
Message-ID: <20070129210113.GA17816@1wt.eu> (raw)

Hi David,

As stated with the 2.4.34 announcement, I planned to perform a few
updates in two network drivers for 2.4.35 :

  - e1000: the cards equipped with the not-so old 82546EB chips
    have completely disappeared from the earth surface, and
    people replacing hardware are experiencing trouble with the
    new chip (82546GB) which is not supported by the old driver.
    I know that Red Hat merged support for this chip in RHEL3
    recently too (U8) by upgrading from v6 to v7.

    Jesse Brandeburg from Intel offered to update the driver to
    the more recent branch (7.3), which will make further
    maintenance easier for him. I personnally use 7.3 on my own
    kernels, so I just know that it works well for the NICs I'm
    used to find on servers, but for the rest, I'll have to rely
    on Intel people's support.

  - sk98lin: when Stephen decided to rewrite that driver from scratch
    because the one from Marvell's site has too many bugs, I thought
    he was exagerating, till the day I noticed NFS servers taking a
    lot of time to respond and DNS servers timing out because of UDP
    packets suddenly not leaving the host anymore. I recently
    encountered a worst case at a customer's with losses, duplicates
    and truncated packets. It's clear that the driver is too buggy.
    Each time I replaced the official driver with Stephen's backport
    and it definitely fixed the problems. I proposed Stephen to merge
    his work into 2.4, and he agreed, offering to update it once it
    gets in, which I'm fine with.

    This means I would start with skge-1.4 and sky2-0.5 which I could
    not get to fault on various intensive tests nor on the one which
    trigger sk98lin's bugs. Since those drivers support cards that are
    currently only supported by the out-of-tree driver from Marvell's
    site, no compatibility is lost and users can still use their old
    driver if they prefer it (as I did till I got those bugs).

Aside that, I rejected a user's request for an update of the tg3
driver which does not support one recent chip in a notebook. I think
that a notebook is not a big enough argument to touch this driver which
works quite well IMHO. A notebook is clearly where he should use 2.6 by
default, or take the time to download and install the out-of-tree code
from broadcom's site if he absolutely wants 2.4. Maybe I'm wrong, but I
have not tested the unofficial tg3 enough to have an opinion, and I don't
want to break things that work just for this.

I'd like to get your opinion on those updates before I open 2.4.35. I
think that integrating them early is the best way to get more testing,
since people often try the first and the latest versions only.

Best regards,
Willy


                 reply	other threads:[~2007-01-29 21:01 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070129210113.GA17816@1wt.eu \
    --to=w@1wt.eu \
    --cc=davem@davemloft.net \
    --cc=jesse.brandeburg@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).