netdev - planned driver updates for 2.4.35

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Mon, 29 Jan 2007 22:01:13 +0100
From:	Willy Tarreau <w@....eu>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org,
	Jesse Brandeburg <jesse.brandeburg@...il.com>,
	Stephen Hemminger <shemminger@...l.org>
Subject: planned driver updates for 2.4.35

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

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html