Hi!
You are optimistic :o)
That´s a good starting point, I think - otherwise I would have thrown my
Equipment out of a window many times already ;)
I can get a fine 100Mb/s with this equipment + poor cables (a few tens of
meters + same path as the power distribution). With this setup,
Dennis [EMAIL PROTECTED] :
[...]
Anyhow, I copied the folder under shell with scp. Under KDE 3.4 with
konqueror and fish-protocol (which is ssh as far as I know), it still
took much longer.
So it´s a question of protocol?!?
I will not comment the efficiency of modern desktop applications.
On Tue, Aug 23, 2005 at 05:28:00PM -0400, Mike Kershaw wrote:
Very small patch to allow setting of the link type of the virtual tapX
interfaces in tun/tap. Needed for writing packets of other arp link
types to tap, ie 80211 wireless frames.
Implemented as a simple IOCTL to set the arptype.
Do you need to do some range validation on arg before setting tun-dev-type?
I shouldn't think so, the worst you could do is set it to a link type
nothing understands, and then they just either go to cooked socket
(pcap) or confuse the app (anything that looks at type directly) or
nothing
From: Ben Greear [EMAIL PROTECTED]
Date: Wed, 24 Aug 2005 10:14:22 -0700
I was thinking about somehow instrumenting dev_get and dev_put
(and __dev_get and __dev_put, I suppose) to keep a list of all
that have got and put, but that will be very invasive and time
consuming I fear...
That's how
I hadn't realized the mdio spin-wait could take 100us on this chip. In
that case it makes sense to use the chip's MII status registers instead.
At the same time, now that Andy Fleming's PHY abstraction code is
available, the MII support should probably be changed over as BenH
suggested.
This
This fixes an rtnl deadlock problem when flush_scheduled_work() is
called from bnx2_close(). In rare cases, linkwatch_event() may be on
the workqueue from a previous close of a different device and it will
try to get the rtnl lock which is already held by dev_close().
The fix is to set a flag if
This speeds up link-up time on 5706 SerDes if the link partner does
not autoneg, a rather common scenario in blade servers. Some blade
servers use IPMI for keyboard input and it's important to minimize
link disruptions.
The speedup is achieved by shortening the timer to (HZ / 3) during
the
Remove atomic operations in the fast tx path. Expensive atomic
operations were used to keep track of the number of available tx
descriptors. This uses the difference between the consumer and
producer index to determine the number of free tx descriptors.
Signed-off-by: Michael Chan [EMAIL
Update version and add 2 minor fixes: check for a valid ethernet
address before setting it and zero out bp-regview if init_one
encounters an error and unmaps the IO address. The 2nd fix prevents
remove_one from unmapping again.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff -rup
Change all locks from spin_lock_irqsave() to spin_lock_bh(). All
places that require spinlocks are in BH context.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff -rup d/drivers/net/bnx2.c e/drivers/net/bnx2.c
--- d/drivers/net/bnx2.c2005-08-24 07:24:37.0 -0700
+++
I see in ipv4/devinet.c there is a call to register_gifconf which
registers a SIOCGIFCONF handler for the IPV4 protocol. There is no such
registration for ipv6. As a result, SIOCGIFCONF doesn't work for ipv6.
Is this intentional, or an oversight?
If its an oversight, I can work up a patch to
Michael Chan wrote:
This fixes an rtnl deadlock problem when flush_scheduled_work() is
called from bnx2_close(). In rare cases, linkwatch_event() may be on
the workqueue from a previous close of a different device and it will
try to get the rtnl lock which is already held by dev_close().
The
Michael Chan wrote:
@@ -3906,6 +3923,11 @@ bnx2_open(struct net_device *dev)
return rc;
}
+ init_timer(bp-timer);
+ bp-timer.expires = RUN_AT(bp-timer_interval);
+ bp-timer.data = (unsigned long) bp;
+ bp-timer.function = bnx2_timer;
+
rc =
Michael Chan wrote:
diff -rup c/drivers/net/bnx2.c d/drivers/net/bnx2.c
--- c/drivers/net/bnx2.c2005-08-24 07:22:12.0 -0700
+++ d/drivers/net/bnx2.c2005-08-24 07:24:37.0 -0700
@@ -107,6 +107,15 @@ static struct flash_spec flash_table[] =
Michael Chan wrote:
Change all locks from spin_lock_irqsave() to spin_lock_bh(). All
places that require spinlocks are in BH context.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
Seems OK
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
Michael Chan wrote:
Update version and add 2 minor fixes: check for a valid ethernet
address before setting it and zero out bp-regview if init_one
encounters an error and unmaps the IO address. The 2nd fix prevents
remove_one from unmapping again.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
Michael Chan wrote:
David, a set of patches for bnx2 in netdev-2.6.14 will follow. The first
patch fixes a rare rtnl deadlock problem when flush_scheduled_work() is
called in the driver's close function. It looks like this may affect a
number of other drivers as well.
Misc unrelated comments:
From: Steven Dake [EMAIL PROTECTED]
Date: Wed, 24 Aug 2005 12:41:25 -0700
Is this intentional, or an oversight?
It is intentional, BSD ioctls for configuration are
deprecated, use netlink instead.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to
From: Jeff Garzik [EMAIL PROTECTED]
Date: Wed, 24 Aug 2005 16:02:46 -0400
* I really like the fact that basically -nothing- happens in bnx2_msi()
or bnx2_interrupt(). I'm glad to see that all the interrupt processing
occurs from bnx2_poll(). I wish more drivers were written that way.
tg3
From: Michael Chan [EMAIL PROTECTED]
Date: Wed, 24 Aug 2005 11:33:19 -0700
On Wed, 2005-08-24 at 15:52 -0400, Jeff Garzik wrote:
2) Would prefer to follow the generic net stack and other areas of the
kernel, for the last piece of quoted code. net stack used to loop on
Richard Dawe [EMAIL PROTECTED] :
[...]
Attached is a patch against 2.6.13-rc6 that converts the r8169 driver to
use constants from linux/mii.h for the MII registers, instead of using
its own enums.
Bye, Rich =]
r8169: Use constants from linux/mii.h
Signed-off-by: Richard Dawe [EMAIL
PCI ID for the Linksys EG1032
Credit goes to Bob Wilson [EMAIL PROTECTED] for the report.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
diff -puN drivers/net/r8169.c~r8169-680 drivers/net/r8169.c
--- a/drivers/net/r8169.c~r8169-680 2005-08-23 23:45:46.019410112 +0200
+++
Use the MII definitions which are available in include/linux/mii.h instead
of the redundant ones which are brought by the r8169 driver.
While at it:
- PHY_Cap_Null is not really useful;
- PHY_Auto_Neco_Comp (i.e. BMSR_ANEGCOMPLETE) is not used at all (uh...);
No functional change.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
diff -puN drivers/net/r8169.c~r8169-710 drivers/net/r8169.c
--- a/drivers/net/r8169.c~r8169-710 2005-08-24 21:54:03.760014518 +0200
+++ b/drivers/net/r8169.c 2005-08-24 21:54:03.786010300 +0200
@@ -444,11 +444,6 @@ static const u16
These defines look generic but they are just a shift of the real mii
defines.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
diff -puN drivers/net/r8169.c~r8169-700 drivers/net/r8169.c
--- a/drivers/net/r8169.c~r8169-700 2005-08-24 21:54:02.302251050 +0200
+++ b/drivers/net/r8169.c
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
diff -puN drivers/net/r8169.c~r8169-730 drivers/net/r8169.c
--- a/drivers/net/r8169.c~r8169-730 2005-08-24 21:54:06.195619312 +0200
+++ b/drivers/net/r8169.c 2005-08-24 21:54:06.222614932 +0200
@@ -398,7 +398,7 @@ struct rtl8169_private {
phy_auto_nego_reg/phy_1000_ctrl_reg shadow some registers which could
be read through the (g)mii interface. Before they will be removed, one
notices that there are not even required in rtl8169_set_speed:
- if rtl8169_set_speed follows an invocation of rtl8169_set_speed_xmii,
the test against
Nothing fancy: the phy id is almost hardcoded per spec and
__mdio_{read/write} wrap around the existing mii access helpers.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
diff -puN drivers/net/r8169.c~r8169-760 drivers/net/r8169.c
--- a/drivers/net/r8169.c~r8169-760 2005-08-24
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
diff -puN drivers/net/r8169.c~r8169-750 drivers/net/r8169.c
--- a/drivers/net/r8169.c~r8169-750 2005-08-24 21:54:10.027997437 +0200
+++ b/drivers/net/r8169.c 2005-08-24 21:54:10.065991272 +0200
@@ -444,37 +444,34 @@ static const u16
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
diff -puN drivers/net/r8169.c~r8169-780 drivers/net/r8169.c
--- a/drivers/net/r8169.c~r8169-780 2005-08-24 23:11:15.947273681 +0200
+++ b/drivers/net/r8169.c 2005-08-24 23:11:15.991266546 +0200
@@ -857,6 +857,13 @@ static void
This fixes an rtnl deadlock problem when flush_scheduled_work() is
called from bnx2_close(). In rare cases, linkwatch_event() may be on
the workqueue from a previous close of a different device and it will
try to get the rtnl lock which is already held by dev_close().
The fix is to set a flag if
This speeds up link-up time on 5706 SerDes if the link partner does
not autoneg, a rather common scenario in blade servers. Some blade
servers use IPMI for keyboard input and it's important to minimize
link disruptions.
The speedup is achieved by shortening the timer to (HZ / 3) during
the
Update version and add 4 minor fixes, the last 2 were suggested by
Jeff Garzik:
1. check for a valid ethernet address before setting it
2. zero out bp-regview if init_one encounters an error and unmaps
the IO address. This prevents remove_one from unmapping again.
3. use netif_rx_schedule()
This patch adds back the code that was taken out, thus re-enabling:
* The PHY Layer to initialize without crashing
* Drivers to actually connect to PHYs
* The entire PHY Control Layer
This patch is used by the gianfar driver, and other drivers which are in
development.
Signed-off-by: Andy
On Wed, Aug 24, 2005 at 01:44:09PM -0700, David S. Miller wrote:
It is intentional, BSD ioctls for configuration are
deprecated, use netlink instead.
will they go away completely at some point? lots of things that (for
example) set interface addresses i bet use the ioctls and are not
netlink
Danial Thom wrote:
I think the concensus is that 2.6 has made trade
offs that lower raw throughput, which is what a
networking device needs. So as a router or
network appliance, 2.6 seems less suitable. A raw
bridging test on a 2.0Ghz operton system:
FreeBSD 4.9: Drops no packets at 900K pps
37 matches
Mail list logo
