* Linux 2.6.11-rc2 Got IPv6 Ready Logo Phase-1
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2005-05-19 10:32 UTC (permalink / raw)
To: usagi-announce, netdev, linux-kernel; +Cc: torvalds, davem, usagi-core
[-- Attachment #1: Type: Text/Plain, Size: 1302 bytes --]
Dear all,
USAGI Project is pleased to announce a special news.
The Linux mainline kernel (version 2.6.11-rc2) is approved by IPv6 Forum
in IPv6 Ready Logo Phase-1 Program <http://www.ipv6ready.org>.
[Approved Document]
o Host Role - LogoID 01-000276
<http://www.ipv6ready.org/logo_db/logo_search2.php?logoid_number=01-000276>
o Router Role - LogoID 01-000275
<http://www.ipv6ready.org/logo_db/logo_search2.php?logoid_number=01-000275>
*) For router role, radvd in usagi-tools was used at the certification.
The version of usagi-tools is sV6READYP1-20050121_20050124.
[Sources]
o Linux-2.6.11-rc2
<ftp://ftp.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.11-rc2.tar.bz2>
(36,966,213 Bytes, md5sum: f18456c9da900820fba98576832d598c)
o USAGI tools (sV6READYP1-20050121_20050124)
<ftp://ftp.linux-ipv6.org/pub/usagi/snap/split/usagi-tool-sV6READYP1-20050121_20050124.tar.bz2>
(6,024,344 Bytes, md5sum: 199fd40a6caa80990efb61cd5f8cfbae)
Although we are allowed to use the Logo only for the certified version,
of course you can use the functionalities with the later versions,
such as 2.6.11.
Thank you.
--
Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@linux-ipv6.org>
USAGI Project: http://www.linux-ipv6.org
GPG FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* ip logging function help
From: cranium2003 @ 2005-05-19 12:19 UTC (permalink / raw)
To: net dev
hello,
By adding iptable rule
iptable -A OUTPUT -j LOG
I am able to check log of each outgoing packets. But
i want to know who is actually calling ipt_log_target
function defined in ipt_LOG.c as
static unsigned int
ipt_log_target(struct sk_buff **pskb,
unsigned int hooknum,
const struct net_device *in,
const struct net_device *out,
const void *targinfo,
void *userinfo)
I want to know which file in source code has pointer
to call ipt_log_target function? I want instance/copy
of const struct net_device *out to my function in
kernel to know that eth0 or eth1 is transmitting
packet.
Thanks in advance.
regards,
cranium
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Thomas Graf @ 2005-05-19 12:23 UTC (permalink / raw)
To: Herbert Xu; +Cc: Rick Jones, netdev
In-Reply-To: <E1DYWM2-0004jM-00@gondolin.me.apana.org.au>
* Herbert Xu <E1DYWM2-0004jM-00@gondolin.me.apana.org.au> 2005-05-19 07:45
> Rick Jones <rick.jones2@hp.com> wrote:
> > If we ass-u-me that the sender is indeed using a random IP ID assignment
> > mechanism, 30000 is probably too many. There are only 65536 possible ID's, and
> > if we "choose" 30000 of them there will undoubtedly be many duplicated. Someone
> > who didn't fall asleep too often in ProbStats (unlike myself) can probably tell
> > us just how many.
>
> IMHO hosts using purely random IDs all the time are fundamentally broken
> for applications such as NFS over UDP over gigabit. However, in order
> to handle such hosts we should make this threshold configurable and
> then those who need it can set it to a value like 600 which gives a
> collision probability with the first fragment of just less than 1%.
I agree, however defining a value of 600 system wide is horrible for
all hosts that behave "correctly". So what we could do is take probes
of the id distribution and define the threshold on a per peer scope.
Example: Once in a while we start a probe and set a bit in a bitmap
for every id that matches a defined window. Not sure about the size of
that bitmap yet but 2048 bits might be a good start. The first fragment
id received during the probe defines the lower bound of the window and
the probe lasts until we received 2048 fragment ids. Once the probe
is finished we calculate the ratio between set and unset bits and
calculate the threshold. Additionaly we can define a threshold of bits
set to figure out if the peer is likely to use a counter for id
generation, if so we can set a flag which switches from counting
fragment ids to calculating the delta between the fragment id subject
to expiration and the current last fragment id. So basically we
would have two different modes, the "difficult peer"-mode for peers
using random ids or if we only see a very small portion of the effective
id space and a "counters"-mode for all peers using counters.
The "counters"-mode can offer a nearly perfect solution to detect
wraps without suffering from side effects such as droping perfectly
legal fragments.
This idea relies on the fact that the result of the probe stays
true for some time which might not be true but is probably fair
enough.
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Herbert Xu @ 2005-05-19 12:48 UTC (permalink / raw)
To: Thomas Graf; +Cc: Rick Jones, netdev
In-Reply-To: <20050519122319.GH15391@postel.suug.ch>
On Thu, May 19, 2005 at 02:23:19PM +0200, Thomas Graf wrote:
>
> I agree, however defining a value of 600 system wide is horrible for
> all hosts that behave "correctly". So what we could do is take probes
> of the id distribution and define the threshold on a per peer scope.
>
> Example: Once in a while we start a probe and set a bit in a bitmap
> for every id that matches a defined window. Not sure about the size of
> that bitmap yet but 2048 bits might be a good start. The first fragment
Sorry, but this scheme is way too complex for a problem that only affects
a tiny section of the community. If you really want to do this then
do it as a static route flag instead of something that the system tries
to auto-detect.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Fw: 2.6.12-rc4-mm[12] - ULOG problem
From: James Morris @ 2005-05-19 13:16 UTC (permalink / raw)
To: Andrew Morton; +Cc: Herbert Xu, netdev, Evgeniy Polyakov
In-Reply-To: <20050518222729.007887b8.akpm@osdl.org>
On Wed, 18 May 2005, Andrew Morton wrote:
> cn_init() uses NETLINK_NFLOG. Peculiar.
I raised this some time ago, and it was never fixed by the author.
- James
--
James Morris
<jmorris@redhat.com>
^ permalink raw reply
* Re: Fw: 2.6.12-rc4-mm[12] - ULOG problem
From: James Morris @ 2005-05-19 13:19 UTC (permalink / raw)
To: Andrew Morton; +Cc: johnpol, herbert, netdev, davem
In-Reply-To: <20050519000809.2fca25c5.akpm@osdl.org>
On Thu, 19 May 2005, Andrew Morton wrote:
> We should remove the feature. If there is demonstrated need for multiple
> instances then it should be done by more conventional means - syscall,
> allocation of a device major then use the minor as a selector or whatever.
I'd suggest removing the connector code completely.
- James
--
James Morris
<jmorris@redhat.com>
^ permalink raw reply
* Re: igmp snooping?
From: jamal @ 2005-05-19 13:43 UTC (permalink / raw)
To: Jonathan Day; +Cc: David Stevens, Lennert Buytenhek, netdev
In-Reply-To: <20050519050958.86591.qmail@web31503.mail.mud.yahoo.com>
On Wed, 2005-18-05 at 22:09 -0700, Jonathan Day wrote:
> mentation-dependent.
>
> Now, in 99.99% of all cases, you're not going to have
> any significant IGMPv3 traffic, as barely anyone uses
> it yet and IGMP specifies that the highest common
> version will be used in a group.
A significant amount of video type apps that i have seen lately
try to use IGMPv3 and then fallback to IGMPv2. I think that this may be
aggravated due to our friends at MS discovering IGMPv3.
cheers,
jamal
^ permalink raw reply
* Re: Fw: 2.6.12-rc4-mm[12] - ULOG problem
From: jamal @ 2005-05-19 13:46 UTC (permalink / raw)
To: James Morris; +Cc: Andrew Morton, Herbert Xu, netdev, Evgeniy Polyakov
In-Reply-To: <Xine.LNX.4.44.0505190915010.15522-100000@thoron.boston.redhat.com>
On Thu, 2005-19-05 at 09:16 -0400, James Morris wrote:
> On Wed, 18 May 2005, Andrew Morton wrote:
>
> > cn_init() uses NETLINK_NFLOG. Peculiar.
>
> I raised this some time ago, and it was never fixed by the author.
>
Sharing as was done here is not proper; perhaps the suggestion from
Andrew is the way to go.
The other thing we could do is allocate a set of IDs for private use
(as in private IPs).
However, something like connector should only get one ID and it can do
its own multiplexing based on "units".
cheers,
jamal
^ permalink raw reply
* Delivery Failure: Multi-Kulturell = Multi-Kriminell
From: smtprelay @ 2005-05-19 14:36 UTC (permalink / raw)
To: netdev
Your message could not be sent.
A transcript of the attempts to send the message follows.
The number of attempts made: 1
Addressed To: 3a2e568b.cdcded44@derkreis.de
Thursday, 19 May 2005, 15:36:10
(2) Failed to send to identified host,
3a2e568b.cdcded44@derkreis.de: [80.237.235.60], <3a2e568b.cdcded44@derkreis.de>: Recipient address rejected: User unknown in virtual alias table
--- Message non-deliverable.
^ permalink raw reply
* Re: [PATCH] Ethernet Bridging: Enable Hardware Checksumming
From: Nivedita Singhvi @ 2005-05-19 15:10 UTC (permalink / raw)
To: Herbert Xu; +Cc: Jon Mason, shemminger, netdev
In-Reply-To: <E1DYayB-0005Sk-00@gondolin.me.apana.org.au>
Herbert Xu wrote:
> Jon Mason <jdmason@us.ibm.com> wrote:
>
>>checksum and scatter gather as features of the bridge device. In the
>>case that the physical ethernet device does not support scatter
>>gather or hardware checksum, dev_queue_xmit() will check the
>>dev->features and do the necessary linearization and calculate the
>>checksum.
>
>
> Unfortunately skb_linearize is a lot more expensive than not
> generating the non-linear skb's in the first place.
>
> So this is going to hurt people using the bridge devices over
> physical devices that don't support SG.
Fair point - though I would argue that devices that
support SG are much more common now - so optimizing
for the more common case might be preferable - since
people using bridging with devices that support
checksum offload are taking quite a hit when they
do bridging - perhaps this could be a conditional?
thanks,
Nivedita
^ permalink raw reply
* Re: [PATCH] Ethernet Bridging: Enable Hardware Checksumming
From: Nivedita Singhvi @ 2005-05-19 15:13 UTC (permalink / raw)
To: David S. Miller; +Cc: jdmason, shemminger, netdev
In-Reply-To: <20050518.220031.75189050.davem@davemloft.net>
David S. Miller wrote:
>>I think this is a good thing to have, gives us performance
>>gain (equivalent to using/not using checksum offload) and
>>has very little impact on the bridging layer, and is
>>independent of the virtualization stuff..
>
>
> I agree but keep in mind that when bridging over non-checksumming
> devices it will be more expensive. Especially for TCP.
Yep - as I just said to Herbert - perhaps worthwhile then
conditional upon support of checksum offload & SG?
thanks,
Nivedita
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Thomas Graf @ 2005-05-19 15:19 UTC (permalink / raw)
To: Herbert Xu; +Cc: Rick Jones, netdev
In-Reply-To: <20050519124821.GA686@gondor.apana.org.au>
* Herbert Xu <20050519124821.GA686@gondor.apana.org.au> 2005-05-19 22:48
> On Thu, May 19, 2005 at 02:23:19PM +0200, Thomas Graf wrote:
> >
> > I agree, however defining a value of 600 system wide is horrible for
> > all hosts that behave "correctly". So what we could do is take probes
> > of the id distribution and define the threshold on a per peer scope.
> >
> > Example: Once in a while we start a probe and set a bit in a bitmap
> > for every id that matches a defined window. Not sure about the size of
> > that bitmap yet but 2048 bits might be a good start. The first fragment
>
> Sorry, but this scheme is way too complex for a problem that only affects
> a tiny section of the community. If you really want to do this then
> do it as a static route flag instead of something that the system tries
> to auto-detect.
Yes, it's currently quite complex, I'm trying to reduce it to something
simpler. If we do the route flag thing then we should allow the same flag
for permanent neighbours as well.
^ permalink raw reply
* [PATCH] [BRIDGE] Set features based on slave's ones (was Ethernet Bridging: Enable Hardware Checksumming)
From: Catalin(ux aka Dino) BOIE @ 2005-05-19 15:28 UTC (permalink / raw)
To: netdev; +Cc: davem
[-- Attachment #1: Type: TEXT/PLAIN, Size: 394 bytes --]
Hello!
The attached patch, makes the bridge to select features (almost all) only
if _all_ devices supports them.
The patch was tested (create a bridge, add an interface, remove the
interface and always check features flags).
What do you think?
Signed-off-by: Catalin(ux aka Dino) BOIE <catab at umbrella.ro>
---
Catalin(ux aka Dino) BOIE
catab at deuroconsult.ro
http://kernel.umbrella.ro/
[-- Attachment #2: Type: TEXT/PLAIN, Size: 2195 bytes --]
--- bridge1/net/bridge/br_private.h 2005-03-02 09:37:50.000000000 +0200
+++ linux/net/bridge/br_private.h 2005-05-19 18:00:05.000000000 +0300
@@ -27,6 +27,10 @@
#define BR_PORT_BITS 10
#define BR_MAX_PORTS (1<<BR_PORT_BITS)
+#define BR_FEAT_MASK (NETIF_F_HW_CSUM | NETIF_F_SG \
+ | NETIF_F_FRAGLIST | NETIF_F_IP_CSUM \
+ | NETIF_F_HIGHDMA | NETIF_F_TSO)
+
typedef struct bridge_id bridge_id;
typedef struct mac_addr mac_addr;
typedef __u16 port_id;
--- bridge1/net/bridge/br_device.c 2005-03-02 09:37:30.000000000 +0200
+++ linux/net/bridge/br_device.c 2005-05-19 17:14:21.000000000 +0300
@@ -107,4 +107,5 @@ void br_dev_setup(struct net_device *dev
dev->tx_queue_len = 0;
dev->set_mac_address = NULL;
dev->priv_flags = IFF_EBRIDGE;
+ dev->features = BR_FEAT_MASK;
}
--- bridge1/net/bridge/br_if.c 2005-03-02 09:38:33.000000000 +0200
+++ linux/net/bridge/br_if.c 2005-05-19 18:21:39.000000000 +0300
@@ -314,6 +314,27 @@ int br_min_mtu(const struct net_bridge *
return mtu;
}
+/*
+ * If slave device (@dev) doesn't support special features,
+ * turn them off globally.
+ */
+static inline void br_features_change(struct net_bridge *br, struct net_device *dev)
+{
+ br->dev->features &= dev->features | ~BR_FEAT_MASK;
+}
+
+/*
+ * Recomputes features using slave's features
+ */
+static void br_features_recompute(struct net_bridge *br)
+{
+ struct net_bridge_port *p;
+
+ br->dev->features |= BR_FEAT_MASK;
+ list_for_each_entry(p, &br->port_list, list)
+ br_features_change(br, p->dev);
+}
+
/* called with RTNL */
int br_add_if(struct net_bridge *br, struct net_device *dev)
{
@@ -332,9 +353,10 @@ int br_add_if(struct net_bridge *br, str
if (IS_ERR(p = new_nbp(br, dev, br_initial_port_cost(dev))))
return PTR_ERR(p);
+ br_features_change(br, dev);
+
if ((err = br_fdb_insert(br, p, dev->dev_addr, 1)))
destroy_nbp(p);
-
else if ((err = br_sysfs_addif(p)))
del_nbp(p);
else {
@@ -368,6 +390,7 @@ int br_del_if(struct net_bridge *br, str
spin_lock_bh(&br->lock);
br_stp_recalculate_bridge_id(br);
+ br_features_recompute(br);
spin_unlock_bh(&br->lock);
return 0;
^ permalink raw reply
* Re: [PATCH] [BRIDGE] Set features based on slave's ones (was Ethernet Bridging: Enable Hardware Checksumming)
From: Nivedita Singhvi @ 2005-05-19 15:59 UTC (permalink / raw)
To: Catalin(ux aka Dino) BOIE; +Cc: netdev, davem
In-Reply-To: <Pine.LNX.4.62.0505191654400.24043@webhosting.rdsbv.ro>
Catalin(ux aka Dino) BOIE wrote:
> Hello!
>
> The attached patch, makes the bridge to select features (almost all)
> only if _all_ devices supports them.
> The patch was tested (create a bridge, add an interface, remove the
> interface and always check features flags).
>
> What do you think?
While this is generally a cleaner thing to do - it breaks
what we need - Jon's patch adds the checksum offload/SG
unconditionally precisely because we don't want it to be
an all or nothing - we'd like to utilize offload on those
devices that do support it..
thanks,
Nivedita
> ------------------------------------------------------------------------
>
> --- bridge1/net/bridge/br_private.h 2005-03-02 09:37:50.000000000 +0200
> +++ linux/net/bridge/br_private.h 2005-05-19 18:00:05.000000000 +0300
> @@ -27,6 +27,10 @@
> #define BR_PORT_BITS 10
> #define BR_MAX_PORTS (1<<BR_PORT_BITS)
>
> +#define BR_FEAT_MASK (NETIF_F_HW_CSUM | NETIF_F_SG \
> + | NETIF_F_FRAGLIST | NETIF_F_IP_CSUM \
> + | NETIF_F_HIGHDMA | NETIF_F_TSO)
> +
> typedef struct bridge_id bridge_id;
> typedef struct mac_addr mac_addr;
> typedef __u16 port_id;
> --- bridge1/net/bridge/br_device.c 2005-03-02 09:37:30.000000000 +0200
> +++ linux/net/bridge/br_device.c 2005-05-19 17:14:21.000000000 +0300
> @@ -107,4 +107,5 @@ void br_dev_setup(struct net_device *dev
> dev->tx_queue_len = 0;
> dev->set_mac_address = NULL;
> dev->priv_flags = IFF_EBRIDGE;
> + dev->features = BR_FEAT_MASK;
> }
> --- bridge1/net/bridge/br_if.c 2005-03-02 09:38:33.000000000 +0200
> +++ linux/net/bridge/br_if.c 2005-05-19 18:21:39.000000000 +0300
> @@ -314,6 +314,27 @@ int br_min_mtu(const struct net_bridge *
> return mtu;
> }
>
> +/*
> + * If slave device (@dev) doesn't support special features,
> + * turn them off globally.
> + */
> +static inline void br_features_change(struct net_bridge *br, struct net_device *dev)
> +{
> + br->dev->features &= dev->features | ~BR_FEAT_MASK;
> +}
> +
> +/*
> + * Recomputes features using slave's features
> + */
> +static void br_features_recompute(struct net_bridge *br)
> +{
> + struct net_bridge_port *p;
> +
> + br->dev->features |= BR_FEAT_MASK;
> + list_for_each_entry(p, &br->port_list, list)
> + br_features_change(br, p->dev);
> +}
> +
> /* called with RTNL */
> int br_add_if(struct net_bridge *br, struct net_device *dev)
> {
> @@ -332,9 +353,10 @@ int br_add_if(struct net_bridge *br, str
> if (IS_ERR(p = new_nbp(br, dev, br_initial_port_cost(dev))))
> return PTR_ERR(p);
>
> + br_features_change(br, dev);
> +
> if ((err = br_fdb_insert(br, p, dev->dev_addr, 1)))
> destroy_nbp(p);
> -
> else if ((err = br_sysfs_addif(p)))
> del_nbp(p);
> else {
> @@ -368,6 +390,7 @@ int br_del_if(struct net_bridge *br, str
>
> spin_lock_bh(&br->lock);
> br_stp_recalculate_bridge_id(br);
> + br_features_recompute(br);
> spin_unlock_bh(&br->lock);
>
> return 0;
^ permalink raw reply
* Re: [PATCH] [BRIDGE] Set features based on slave's ones (was Ethernet Bridging: Enable Hardware Checksumming)
From: Jon Mason @ 2005-05-19 16:06 UTC (permalink / raw)
To: Catalin(ux aka Dino) BOIE; +Cc: netdev, davem
In-Reply-To: <Pine.LNX.4.62.0505191654400.24043@webhosting.rdsbv.ro>
This patch only enables the features which are common between all of the
bridged devices (at the time of their addition to the bridge). It overlooks
the cases where not all of the adapters have the same features, or where the
user has changed the enablement of a certain feature (via ethtool).
Thanks,
Jon
On Thursday 19 May 2005 10:28 am, Catalin(ux aka Dino) BOIE wrote:
> Hello!
>
> The attached patch, makes the bridge to select features (almost all) only
> if _all_ devices supports them.
> The patch was tested (create a bridge, add an interface, remove the
> interface and always check features flags).
>
> What do you think?
>
> Signed-off-by: Catalin(ux aka Dino) BOIE <catab at umbrella.ro>
> ---
> Catalin(ux aka Dino) BOIE
> catab at deuroconsult.ro
> http://kernel.umbrella.ro/
^ permalink raw reply
* Re: Fw: 2.6.12-rc4-mm[12] - ULOG problem
From: Andrew Morton @ 2005-05-19 16:53 UTC (permalink / raw)
To: James Morris; +Cc: johnpol, herbert, netdev, davem
In-Reply-To: <Xine.LNX.4.44.0505190918430.15522-100000@thoron.boston.redhat.com>
James Morris <jmorris@redhat.com> wrote:
>
> On Thu, 19 May 2005, Andrew Morton wrote:
>
> > We should remove the feature. If there is demonstrated need for multiple
> > instances then it should be done by more conventional means - syscall,
> > allocation of a device major then use the minor as a selector or whatever.
>
> I'd suggest removing the connector code completely.
>
How come? It seems sensible to have library code which consoldates the
common netlink setup and teardown stuff and which offers a higher-level
messaging API, although connector may be a bit overdesigned for that. The
fork connector guys seemed to find it useful?
^ permalink raw reply
* Re: [RFC/PATCH] "strict" ipv4 reassembly
From: Rick Jones @ 2005-05-19 17:02 UTC (permalink / raw)
To: netdev
In-Reply-To: <20050519122319.GH15391@postel.suug.ch>
> I agree, however defining a value of 600 system wide is horrible for
> all hosts that behave "correctly". So what we could do is take probes
> of the id distribution and define the threshold on a per peer scope.
Why would 600 penalize a host behaving "correctly?" I mean, what are the
chances of a datagram's being reassembled, if 600 subsent datagrams have arrived
from that same host?
rick
^ permalink raw reply
* Re: Fw: 2.6.12-rc4-mm[12] - ULOG problem
From: James Morris @ 2005-05-19 17:09 UTC (permalink / raw)
To: Andrew Morton; +Cc: johnpol, herbert, netdev, davem
In-Reply-To: <20050519095334.018dd674.akpm@osdl.org>
On Thu, 19 May 2005, Andrew Morton wrote:
> How come? It seems sensible to have library code which consoldates the
> common netlink setup and teardown stuff and which offers a higher-level
> messaging API, although connector may be a bit overdesigned for that. The
> fork connector guys seemed to find it useful?
I don't think it's the right implementation, and providing feedback on it
has proven frustrating and unfruitful.
- James
--
James Morris
<jmorris@redhat.com>
^ permalink raw reply
* Re: Network card driver problem (znb.o/tulip)
From: Ben Greear @ 2005-05-19 17:14 UTC (permalink / raw)
To: Kosta Todorovic; +Cc: jgarzik, tulip-users, netdev
In-Reply-To: <efe3b00605051901022854653a@mail.gmail.com>
Kosta Todorovic wrote:
> Whats the best 4-port NIC currently available? I'm interested in
> purchasing 10 4-port NICs as a replacement for my current cards.
>
> I am looking for 10/100Mbps and a good driver for linux (2.4.x and
> 2.6.x). Preferably a mainstream company but thats not priority.
>
> Could the community please recommend the best card available? Money is
> not an issue since im really interested in the best of the best.
Get an Intel 4-port GigE NIC. It will do 10/100/1000, and if you really
want to use all 4 ports at even 100Mbps, you need the 64-bit PCI bus...
I have been getting mine from silicom-usa.com lately. They also have
6-port NICs, and 4-port broadcom GigE nics that can be used in 32-bit
PCI slots. (The Intel 4-port NICs will only work in 64-bit PCI slots.)
If you really want 10/100 nics, try the p430tx from aei:
http://www.aei-it.com/hardware/fastenet/p430tx.htm
These are like the old DFE570tx NICs, and use the tulip driver. They
are almost as expensive as the GigE NICs though...
Thanks,
Ben
>
> Any suggestions?
>
> Regards,
> Kosta
>
>
>
> On 3/11/05, Kosta Todorovic <kostodo@gmail.com> wrote:
>
>>My company has recently purchased several ZNYX ZX274 network cards.
>>These cards are Four Channel, 10/100 PCI Adapters. They use Intel chipsets.
>>
>>Unfortunately there exists no drivers for linux amd64 architecture.
>>There are 32bit drivers found at:
>>http://www.znyx.com/support/drivers/ZX374_drivers.htm but naturally
>>they wont compile under my amd64 system.
>>
>>The driver itself is called znb.o and can be downloaded from ZNYX's
>>website. I spoke to support staff there but they told me they have
>>discontinued support and development for this series of cards.
>>
>>The system I am running gentoo and have tried both 2.4.x and 2.6.x
>>kernels but no luck.
>>
>>Unfortunately there is NO 64bit drivers available for ANY platform. not even MS.
>>
>>Does anyone know of a customised znb.o driver built for amd64?
>>Is there any chance of anyone modifying the source code of the driver
>>to compile under a amd64 system?
>>
>>I've noticed that "tulip" drivers get loaded as a module at boot time.
>>but they dont function correctly. (lets you start the device and
>>attach ips but cant talk through it)
>>
>>Is there any variants of the tulip driver that will work for this?
>>
>>Help much appreciated.
>>
>>
>>/proc/pci extract for network cards:
>>
>> Bus 5, device 5, function 0:
>> Ethernet controller: Digital Equipment Corporation DECchip
>>21142/43 (#30) (rev 65).
>> IRQ 30.
>> Master Capable. Latency=128. Min Gnt=20.Max Lat=40.
>> I/O at 0x0 [0x7f].
>> Non-prefetchable 32 bit memory at 0xfa1ff400 [0xfa1ff7ff].
>> Bus 5, device 4, function 0:
>> Ethernet controller: Digital Equipment Corporation DECchip
>>21142/43 (#29) (rev 65).
>> IRQ 29.
>> Master Capable. No bursts. Min Gnt=20.Max Lat=40.
>> I/O at 0x0 [0x7f].
>> Non-prefetchable 32 bit memory at 0xf9f00000 [0xf9f003ff].
>>
>
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] [BRIDGE] Set features based on slave's ones (was Ethernet Bridging: Enable Hardware Checksumming)
From: Catalin(ux aka Dino) BOIE @ 2005-05-19 17:22 UTC (permalink / raw)
To: Jon Mason; +Cc: netdev, davem
In-Reply-To: <200505191106.53136.jdmason@us.ibm.com>
On Thu, 19 May 2005, Jon Mason wrote:
> This patch only enables the features which are common between all of the
> bridged devices (at the time of their addition to the bridge). It overlooks
> the cases where not all of the adapters have the same features, or where the
> user has changed the enablement of a certain feature (via ethtool).
>
> Thanks,
> Jon
I agree that the patch doesn't take care of ethtool oprations.
I will correct this.
But, it doesn't overlook the case when "not all of the adapters have the
same features". If all devices have a feature, it is enabled on the bridge
interface. Else, it is cleared. Am I missing your point?
Thank you very much for looking over the patch!
> On Thursday 19 May 2005 10:28 am, Catalin(ux aka Dino) BOIE wrote:
>> Hello!
>>
>> The attached patch, makes the bridge to select features (almost all) only
>> if _all_ devices supports them.
>> The patch was tested (create a bridge, add an interface, remove the
>> interface and always check features flags).
>>
>> What do you think?
>>
>> Signed-off-by: Catalin(ux aka Dino) BOIE <catab at umbrella.ro>
>> ---
>> Catalin(ux aka Dino) BOIE
>> catab at deuroconsult.ro
>> http://kernel.umbrella.ro/
>
---
Catalin(ux aka Dino) BOIE
catab at deuroconsult.ro
http://kernel.umbrella.ro/
^ permalink raw reply
* Re: [PATCH] [BRIDGE] Set features based on slave's ones (was Ethernet Bridging: Enable Hardware Checksumming)
From: Jon Mason @ 2005-05-19 17:47 UTC (permalink / raw)
To: Catalin(ux aka Dino) BOIE; +Cc: netdev, davem
In-Reply-To: <Pine.LNX.4.62.0505192019090.8076@webhosting.rdsbv.ro>
On Thursday 19 May 2005 12:22 pm, Catalin(ux aka Dino) BOIE wrote:
> On Thu, 19 May 2005, Jon Mason wrote:
> > This patch only enables the features which are common between all of the
> > bridged devices (at the time of their addition to the bridge). It
> > overlooks the cases where not all of the adapters have the same features,
> > or where the user has changed the enablement of a certain feature (via
> > ethtool).
> >
> > Thanks,
> > Jon
>
> I agree that the patch doesn't take care of ethtool oprations.
> I will correct this.
I think trying to correct this could be a bear of a problem. Good luck.
> But, it doesn't overlook the case when "not all of the adapters have the
> same features". If all devices have a feature, it is enabled on the bridge
> interface. Else, it is cleared. Am I missing your point?
My point is that some features the user might want enabled regardless of
whether all devices support them. An example of this is where a system has
hardware checksum support for all devices except one. In this case, it would
be benefitial to have this device do the checksum in software (via
skb_checksum_help() call in dev_queue_xmit()).
> Thank you very much for looking over the patch!
I really like your patch, and I'm working on combining the two so that we have
the best of both worlds. I'll submit it once I have tested it, and we'll see
who likes it.
Thanks,
Jon
^ permalink raw reply
* Re: Linux 2.6.11-rc2 Got IPv6 Ready Logo Phase-1
From: Peter Bieringer @ 2005-05-19 17:58 UTC (permalink / raw)
To: netdev; +Cc: YOSHIFUJI Hideaki / 吉藤英明, usagi-core
In-Reply-To: <20050519.193225.19442831.yoshfuji@linux-ipv6.org>
--On Thursday, May 19, 2005 07:32:25 PM +0900 "YOSHIFUJI Hideaki /
=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=" <yoshfuji@linux-ipv6.org> wrote:
> Dear all,
>
>
> USAGI Project is pleased to announce a special news.
>
> The Linux mainline kernel (version 2.6.11-rc2) is approved by IPv6 Forum
> in IPv6 Ready Logo Phase-1 Program <http://www.ipv6ready.org>.
Congratulation for the hard work!
Peter
--
Dr. Peter Bieringer http://www.bieringer.de/pb/
GPG/PGP Key 0x958F422D mailto: pb at bieringer dot de
Deep Space 6 Co-Founder and Core Member http://www.deepspace6.net/
^ permalink raw reply
* Re: 2.6.12-rc4-mm[12] - ULOG problem
From: David S. Miller @ 2005-05-19 18:42 UTC (permalink / raw)
To: johnpol; +Cc: akpm, herbert, netdev
In-Reply-To: <1116486385.21310.82.camel@uganda>
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Date: Thu, 19 May 2005 11:06:25 +0400
> It was created to be able to load several different connector devices
> from different modules [basically it was module1.ko unit=10, module2.ko
> unit=11 and so on].
That's bogus, each connector will need to allocate it's own
specific define in the netlink header, and we're about to
run out of numbers.
Please redesign the connector so that it doesn't eat more than
one netlink number, we're running out of them soon.
^ permalink raw reply
* Re: 2.6.12-rc4-mm[12] - ULOG problem
From: David S. Miller @ 2005-05-19 18:44 UTC (permalink / raw)
To: akpm; +Cc: johnpol, herbert, netdev
In-Reply-To: <20050518234552.4aef6d02.akpm@osdl.org>
From: Andrew Morton <akpm@osdl.org>
Date: Wed, 18 May 2005 23:45:52 -0700
> > Should I ask David Miller to allocate new one specially for connector?
>
> Dave?
Giving the connector a single value 10 is OK, the rest of
what the connector is doing in this area is not.
I wish you hadn't put the connector into -mm, it's really
in need of several fixups still. The bogus reuse of the
ULOG netlink number is simply indicative of that.
^ permalink raw reply
* Re: 2.6.12-rc4-mm[12] - ULOG problem
From: David S. Miller @ 2005-05-19 18:48 UTC (permalink / raw)
To: jmorris; +Cc: akpm, johnpol, herbert, netdev
In-Reply-To: <Xine.LNX.4.44.0505190918430.15522-100000@thoron.boston.redhat.com>
From: James Morris <jmorris@redhat.com>
Date: Thu, 19 May 2005 09:19:33 -0400 (EDT)
> On Thu, 19 May 2005, Andrew Morton wrote:
>
> > We should remove the feature. If there is demonstrated need for multiple
> > instances then it should be done by more conventional means - syscall,
> > allocation of a device major then use the minor as a selector or whatever.
>
> I'd suggest removing the connector code completely.
I totally agree, it's crap at the current time and the author doesn't
fix the problems being shown in it, in fact he defends some of them
even this one. It needs lots of work still.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox