Brian Haley wrote:
> jamal wrote:
>> On Wed, 2006-24-05 at 12:14 -0700, Phil Dibowitz wrote:
>>
>>> Right, I'm aware there are other ways of doing this - I've written
>>> scripts to
>>> record a hundreds of numbers, and then subtract them from each other.
>>> But
>>> those scripts are work arounds
>-Original Message-
>From: David Miller [mailto:[EMAIL PROTECTED]
>Sent: Friday, May 26, 2006 4:24 AM
>To: #ZHOU BIN#
>Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
netdev@vger.kernel.org
>Subject: Re: [PATCH] TCP Veno module for kernel 2.6.16.13
>
>
>From: "#ZHOU BIN#" <[E
Stephen, Roland,
Thanks a lot for feedback.
We'll implement the minor changes rightaway and post an update. We are also
thinking about what's the best way to incorporate the data structure changes
you have suggested. Will post a reply on that too soon.
-Amit
On Thursday 25 May 2006 16:15, Lin
In article <[EMAIL PROTECTED]> (at Fri, 26 May 2006 02:24:19 +0300 (EEST)),
Meelis Roos <[EMAIL PROTECTED]> says:
>
> (To YOSHIFUJI Hideaki: this is about the
> http://comments.gmane.org/gmane.linux.network/35262 thread)
>
> Tracked it down to IPV6 merge at 2006-03-21:
> commit cd85f6e2f5828218
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Fri, 26 May 2006 10:43:24 +1000
> On Thu, May 25, 2006 at 03:16:02PM -0700, David Miller wrote:
> >
> > Perhaps RTN_BROADCAST should take precedence over IFF_NOARP
> > (but not IFF_LOOPBACK)? I'm talking about the code in
> > net/ipv4/arp.c that causes
On Thu, May 25, 2006 at 03:16:02PM -0700, David Miller wrote:
>
> Perhaps RTN_BROADCAST should take precedence over IFF_NOARP
> (but not IFF_LOOPBACK)? I'm talking about the code in
> net/ipv4/arp.c that causes this behavior.
Sure, I don't see any harm in that.
However, I'm curious as to the pu
Jiri Slaby wrote:
gt96100eth avoid pci_find_device
Change pci_find_device to safer pci_get_device.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
commit f656671e9da9d33bd7a2fb3f5c0d0f7009925698
tree b92c808b6a9eecce58b0f7b0ffe1237631dbd65a
parent 1d3b6caf027fe53351c645523587aeac40bc3e47
aut
Jiri Slaby wrote:
bcm43xx avoid pci_find_device
Change pci_find_device to safer pci_get_device with support for more
devices.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
---
commit 1d3b6caf027fe53351c645523587aeac40bc3e47
tree ae37c86b633442cdf8a7a19ac287542724081c90
parent ab3443d79c94d0ae6
Hello,
there are some patches to avoid pci_find_device in drivers, next will come in
future.
Take #2.
It's against 2.6.17-rc4-mm3 tree.
01-i2c-scx200-acb-avoid-pci-find-device.patch
02-bcm43xx-avoid-pci-find-device.patch
03-gt96100eth-avoid-pci-find-device.patch
i2c/busses/scx200_acb.c
On Thu, 25 May 2006, Paul Moore wrote:
> This patch introduces a new kernel feature designed to support labeled
> networking protocols such as RIPSO and CIPSO. These protocols are required to
> interoperate with existing "trusted" operating systems such as Trusted
> Solaris.
A few initial commen
(To YOSHIFUJI Hideaki: this is about the
http://comments.gmane.org/gmane.linux.network/35262 thread)
Tracked it down to IPV6 merge at 2006-03-21:
commit cd85f6e2f58282186ad720fc18482be228f0b972 is good (right before
the bunch of patches)
commit b00055aacdb172c05067612278ba27265fcd05ce is bad (r
During a code scan for another change I discovered that this call to
pcnet32_free_ring must be removed. If the open fails due to a lack of
memory all the ring structures are removed via the call to free_ring
and a subsequent call to open will dereference a null pointer in
pcnet32_init_ring.
Pleas
From: Samuel Ortiz <[EMAIL PROTECTED]>
Date: Thu, 25 May 2006 06:20:52 +
> This patch gets rid of the old power management code and now uses the
> device model for the ali-ircc driver.
>
> Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]>
Enhancement, thus applied to net-2.6.18
Thanks.
-
To u
From: Samuel Ortiz <[EMAIL PROTECTED]>
Date: Thu, 25 May 2006 06:19:44 +
> stir4200 uses a kernel thread for its TX/RX operations, and it is now
> converted to the kernel kthread API.
> Tested on an STIR4200 based dongle.
>
> Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
> Signed-off-b
From: Samuel Ortiz <[EMAIL PROTECTED]>
Date: Thu, 25 May 2006 06:19:27 +
> The MosChip MCS7780 chipset is an IrDA USB bridge that
> doesn't conform with the IrDA-USB standard and thus needs
> its separate driver.
> Tested on an actual MCS7780 based dongle.
>
> Original implementation by Brian
From: Samuel Ortiz <[EMAIL PROTECTED]>
Date: Thu, 25 May 2006 06:18:51 +
> If a SIR dongle is built in the kernel while IRTTY_SIR is built
> as a module, kernel compilation will fail.
> Thus, the SIR dongle config should depend on the IRTTY_SIR.
>
> Closes kernel bug# 6512
> (http://bugzilla.
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 24 May 2006 10:12:16 -0700
> Some stuff for 2.6.18. The most important is adding netlink
> support for managing interfaces; this allows building STP
> as an application.
Applied to net-2.6.18, thanks Stephen.
-
To unsubscribe from this list:
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 24 May 2006 11:10:54 +1000
> David Miller <[EMAIL PROTECTED]> wrote:
> > From: Andrew Morton <[EMAIL PROTECTED]>
> > Date: Tue, 23 May 2006 16:31:42 -0700
> >
> >> >Summary: dummy interface broadcast destination hardware
> >> > address
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Tue, 23 May 2006 17:04:14 -0700
> I want to use AF_LLC and SOCK_DGRAM for handling Spanning
> Tree Protocol packets in user space. The existing code doesn't work
> and also doesn't support multicast. These basic problems and
> add some cleanups.
A
From: "Caitlin Bestler" <[EMAIL PROTECTED]>
Date: Thu, 25 May 2006 14:11:03 -0700
> The *desirability* of using this data is debatable, but it most
> certainly is possible.
Right, I don't think these kinds of schemes scale very well
personally.
I think TCP can certainly infer these attributes us
On Thursday 25 May 2006 02:45, you wrote:
> Jiri Slaby wrote:
> > bcm43xx kill pci_find_device
> >
> > Change pci_find_device to safer pci_get_device.
> >
> > Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
> >
> > ---
> > commit 75664d3c6fe1d8d00b87e42cc001cb5d90613dae
> > tree ebcec31955a991f166
Stephen Hemminger wrote:
On Thu, 25 May 2006 16:06:01 -0400
Paul Moore <[EMAIL PROTECTED]> wrote:
This patch introduces a new kernel feature designed to support labeled
networking protocols such as RIPSO and CIPSO. These protocols are required to
interoperate with existing "trusted" operating s
Jeff,
Please queue the 'e1000: add shutdown handler back for WoL' for 2.6.17rc's.
Since this fix is already committed to jgarzik/netdev-2.6#upstream, you can
cherrypick it into #upstream-fixes:
$ git-cherry-pick c653e6351e371b33b29871e5eedf610ffb3be037
Cheers,
Auke
e1000: add shutdown han
[EMAIL PROTECTED] wrote:
> On Thu, 25 May 2006 13:23:50 -0700 (PDT) David Miller
> <[EMAIL PROTECTED]> wrote:
>
>> From: "#ZHOU BIN#" <[EMAIL PROTECTED]>
>> Date: Thu, 25 May 2006 16:30:48 +0800
>>
>>> Yes, I agree. Actually the main contribution of TCP Veno is not in
>>> this AI phase. No matte
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Thu, 25 May 2006 13:50:11 -0700
> The general idea of resetting cwnd to an estimate of capacity seems to
> be a general feature of Westwood, Veno, Compound and Africa. Also FreeBSD
> does the same thing, but they don't have a cool name.
Interestin
From: Phil Dibowitz <[EMAIL PROTECTED]>
Date: Thu, 25 May 2006 14:04:12 -0700
> why would specifically not support a _feature_ of the hardware.
Sparc64 chips support a hash table like hw assist feature for TLB
reloading, I didn't use it for 8+ years and went with a virtual page
table approach ins
On Thu, May 25, 2006 at 01:29:28PM -0700, David Miller wrote:
> From: Phil Dibowitz <[EMAIL PROTECTED]>
> Date: Thu, 25 May 2006 12:22:39 -0700
>
> > So at least, for the _current_ implimentations, this should have no
> > performance impacts.
>
> Regardless, I think this is something that userspa
On Thu, 25 May 2006 16:06:01 -0400
Paul Moore <[EMAIL PROTECTED]> wrote:
> This patch introduces a new kernel feature designed to support labeled
> networking protocols such as RIPSO and CIPSO. These protocols are required to
> interoperate with existing "trusted" operating systems such as Truste
On Thu, 25 May 2006 13:23:50 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: "#ZHOU BIN#" <[EMAIL PROTECTED]>
> Date: Thu, 25 May 2006 16:30:48 +0800
>
> > Yes, I agree. Actually the main contribution of TCP Veno is not in
> > this AI phase. No matter the ABC is added or not, TCP Veno
The existing code did a 64 bit divide directly, which won't work on
32 bit platforms. This is what I am testing, it uses math similar to
TCP CUBIC to do a quad root. It seemed more efficient to just do
one operation rather than two square roots.
-
diff --git a/net/ipv4/tcp_compound.c b/ne
From: Phil Dibowitz <[EMAIL PROTECTED]>
Date: Thu, 25 May 2006 12:22:39 -0700
> So at least, for the _current_ implimentations, this should have no
> performance impacts.
Regardless, I think this is something that userspace _can_
take care of reasonably and therefore has no buisness in the
kernel
Hi,
This is another resend of patches sent earlier by Jeff Kirsher and
completes the resend for 1.0.104-kX.
Summary:
[1] add performance enhancements to the buffer_info struct
[2] implement copybreak
[3] increment version to 1.0.104-k4
These changes are available through git.
git pull git:/
Increment the driver version to 1.0.104-k4
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
Signed-off-by: John Ronciak <[EMAIL PROTECTED]>
---
drivers/net/ixgb/ixgb_main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_
o modify the rx refill logic and tail bump
o add counter for failures
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
Signed-off-by: John Ronciak <[EMAIL PROTECTED]>
---
drivers/net/ixgb/ixgb.h |1 +
drivers/net/ixgb/ixgb_main.c | 74 ++
o use rx copybreak/skb recycle
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
Signed-off-by: John Ronciak <[EMAIL PROTECTED]>
---
drivers/net/ixgb/ixgb_main.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --
From: "#ZHOU BIN#" <[EMAIL PROTECTED]>
Date: Thu, 25 May 2006 16:30:48 +0800
> Yes, I agree. Actually the main contribution of TCP Veno is not in
> this AI phase. No matter the ABC is added or not, TCP Veno can
> always improve the performance over wireless networks, according to
> our tests.
It
Santiago Leon wrote:
Jeff,
Can you consider applying this patch? I haven't received any feedback
from netdev, but the changes are pretty straightforward (the majority of
the patch is setting up the sysfs interface).
It's already in netdev-2.6.git#upstream...
-
To unsubscribe from this lis
On my home 6to4 gw, ipv6 routing seems to be broken and everything is sent
to 6to4 tunnel (the default route). It worked with fine for a long time and
with 2.6.17-rc2-g4d5c34ec and it's broken with vmlinuz-2.6.17-rc3-g3cd73eed
and 2.6.17-rc4-g9be2f7c3 (yesterdays kernel).
So far I have narrowe
http://bugzilla.kernel.org/show_bug.cgi?id=6613
Meelis, it would really help if you could try 2.6.16 and in case
that doesn't work 2.6.15 to give an idea about whether this is a
recent regression or an old problem. We had a number of changes
in this area in the last two kernel versions that coul
Signed-off-by: Wong Hoi Sing Edison <[EMAIL PROTECTED]>
---
diff -urpN linux-2.6.16.14/net/ipv4/tcp_lp.c linux/net/ipv4/tcp_lp.c
--- linux-2.6.16.14/net/ipv4/tcp_lp.c 1970-01-01 08:00:00.0 +0800
+++ linux/net/ipv4/tcp_lp.c 2006-05-07 01:41:33.0 +0800
@@ -0,0 +1,343 @@
+/*
+
TCP Low Priority is a distributed algorithm whose goal is to utilize only
the excess network bandwidth as compared to the ``fair share`` of
bandwidth as targeted by TCP. Available from:
http://www.ece.rice.edu/~akuzma/Doc/akuzma/TCP-LP.pdf
Original Author:
Aleksandar Kuzmanovic <[EMAIL PROTECTED
This patch adds new device ids for MCP61 and MCP65 chips.
Signed-Off-By: Ayaz Abdulla <[EMAIL PROTECTED]>
--- a/include/linux/pci_ids.h 2006-05-25 13:02:56.0 -0400
+++ b/include/linux/pci_ids.h 2006-05-25 13:03:09.0 -0400
@@ -1182,6 +1182,14 @@
#define PCI_DEVICE_ID_NVIDIA_Q
This patch adds support for the new chips MCP61 and MCP65.
Signed-Off-By: Ayaz Abdulla <[EMAIL PROTECTED]>
--- orig-2.6/drivers/net/forcedeth.c2006-05-25 13:01:03.0 -0400
+++ new-2.6/drivers/net/forcedeth.c 2006-05-25 13:02:23.0 -0400
@@ -109,6 +109,7 @@
* 0.54: 21
This patch adds NetLabel support to SELinux.
hooks.c| 64 ++-
include/security.h |6 +
ss/ebitmap.c | 155 +++
ss/ebitmap.h |6 +
ss/mls.c | 160
ss/mls.h | 25
ss/services.c
This patch adds some documentation for NetLabel which include an overview on
how it works and it's intended use by LSM developers. A copy of the CIPSO
IETF draft is also included as since it is an expired draft it can be hard
to find.
CREDITS |
This patch introduces a new kernel feature designed to support labeled
networking protocols such as RIPSO and CIPSO. These protocols are required to
interoperate with existing "trusted" operating systems such as Trusted Solaris.
I am posting the patch now not because I feel it is ready for inclus
On Thu, May 25, 2006 at 01:41:41PM -0500, Brent Cook wrote:
> On Thursday 25 May 2006 12:59, Phil Dibowitz wrote:
> > On Thu, May 25, 2006 at 08:05:37AM -0500, Brent Cook wrote:
> > > > I'll admit to not knowing all the intricacies of the kernel coding
> > > > involved, but I don't offhand see how
Meelis, it would really help if you could try 2.6.16 and in case
that doesn't work 2.6.15 to give an idea about whether this is a
recent regression or an old problem. We had a number of changes
in this area in the last two kernel versions that could be related.
Yes, I'm still compiling 2.6.16, s
On Thu, 25 May 2006 11:39:49 -0700 Jean Tourrilhes wrote:
> On Thu, May 25, 2006 at 11:09:21AM -0700, Randy.Dunlap wrote:
> > From: Randy Dunlap <[EMAIL PROTECTED]>
> >
> > Fix section mismatch warning:
> > WARNING: drivers/net/wireless/wavelan.o - Section mismatch: reference to
> > .init.text: f
Andrew Morton wrote:
> [EMAIL PROTECTED] wrote:
>
>>http://bugzilla.kernel.org/show_bug.cgi?id=6613
>>
>> Summary: iptables broken on 32-bit PReP (ARCH=ppc)
>>Kernel Version: 2.6.17-rc4
>>Status: NEW
>> Severity: normal
>> Owner: [EMAIL PROTECTED]
>>
On Thursday 25 May 2006 12:59, Phil Dibowitz wrote:
> On Thu, May 25, 2006 at 08:05:37AM -0500, Brent Cook wrote:
> > > I'll admit to not knowing all the intricacies of the kernel coding
> > > involved, but I don't offhand see how zeroing the stats would be
> > > significantly more complex than upd
On Thu, May 25, 2006 at 11:09:21AM -0700, Randy.Dunlap wrote:
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> Fix section mismatch warning:
> WARNING: drivers/net/wireless/wavelan.o - Section mismatch: reference to
> .init.text: from .text between 'init_module' (at offset 0x371e) and
> 'cleanup_modul
Jeff,
Can you consider applying this patch? I haven't received any feedback
from netdev, but the changes are pretty straightforward (the majority of
the patch is setting up the sysfs interface).
This patch provides a sysfs interface to change some properties of the
ibmveth buffer pools (si
On Thu, May 25, 2006 at 10:59:40AM -0700, Olof Johansson wrote:
> Is there a specific reason for why you chose to export 3 different
> memcpu calls? They're all just wrapped to the same internals.
>
> It would seem to make sense to have the client do their own
> page_address(page) + offset calcula
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix section mismatch warning:
WARNING: drivers/net/wireless/wavelan.o - Section mismatch: reference to
.init.text: from .text between 'init_module' (at offset 0x371e) and
'cleanup_module'
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
drivers/net/wirel
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix section mismatch warnings:
WARNING: drivers/net/wireless/arlan.o - Section mismatch: reference to
.init.text:arlan_probe from .text between 'init_module' (at offset
0x3526) and 'cleanup_module'
WARNING: drivers/net/wireless/arlan.o - Section mismatch: ref
On Thu, 25 May 2006 06:19:44 +
Samuel Ortiz <[EMAIL PROTECTED]> wrote:
> stir4200 uses a kernel thread for its TX/RX operations, and it is now
> converted to the kernel kthread API.
> Tested on an STIR4200 based dongle.
>
> Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
> Signed-off-by:
Hi,
Minor nitpick below:
On Tue, May 23, 2006 at 05:20:13PM -0700, Chris Leech wrote:
> +static int enumerate_dma_channels(struct ioat_device *device)
[...]
> + enumerate_dma_channels(device);
Return value is never used, might as well change the function
declaration to void.
-Olof
-
To
Hi,
On Tue, May 23, 2006 at 05:20:12PM -0700, Chris Leech wrote:
> +EXPORT_SYMBOL(dma_async_memcpy_buf_to_buf);
> +EXPORT_SYMBOL(dma_async_memcpy_buf_to_pg);
> +EXPORT_SYMBOL(dma_async_memcpy_pg_to_pg);
Is there a specific reason for why you chose to export 3 different
memcpu calls? They're all
On Thu, May 25, 2006 at 08:05:37AM -0500, Brent Cook wrote:
> > I'll admit to not knowing all the intricacies of the kernel coding
> > involved, but I don't offhand see how zeroing the stats would be
> > significantly more complex than updating the stats during normal usage.
> > But I'll have to l
> +void netxen_delay(int value)
> +{
> + unsigned long remainder;
> +
> + remainder = value / 5;
> + do {
> + if (remainder > 1000) {
> + udelay(1000);
> + remainder -= 1000;
> + } else {
> + udelay
The object factoring is a mess here. You have too many allocations
and indirections. My expectation would be:
1. One PCI device maps to one board and that is the adapter structure
allocated with kzalloc. (You are doing this right)
2. An adapter can have up to four ports. Each of these should
Why is this necessary. Additional private API seems like leftover
debug code.
> +int
> +netxen_nic_do_ioctl(struct netxen_adapter *adapter, void *u_data,
> + struct netxen_port *port)
> +{
> + struct netxen_nic_ioctl_data data;
> + struct netxen_nic_ioctl_data *up_data;
>
Can you ask internally on how openview would handle this? It carriers the
major chunk of management tools market so it may provide good insight.
I've asked the question in an internal, informal communications channel.
No guarantees it will reach any OpenView types, but if it does I'll
try to
> +static int __devinit
> +netxen_nic_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
> +#if defined(CONFIG_PCI_MSI)
> +adapter->flags |= NETXEN_NIC_MSI_ENABLED;
> +if (pci_enable_msi(pdev)) {
> +adapter->flags &= ~NETXEN_NIC_MSI_ENABLED;
> +pri
On Thu, 25 May 2006 03:51:03 -0700 (PDT)
"Linsys Contractor Amit S. Kale" <[EMAIL PROTECTED]> wrote:
> diff -Naru linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic.h
> linux-2.6.16.18/drivers/net/netxen/netxen_nic.h
> --- linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic.h 1969-12-31
> 16
Minor nits.
On Thu, 25 May 2006 03:48:38 -0700 (PDT)
"Linsys Contractor Amit S. Kale" <[EMAIL PROTECTED]> wrote:
> +/*
> + * Note: This change will be reflected in all the four ports as there is
> + * only one common adapter.
> + */
> +static int
> +netxen_nic_set_ringparam(struct net_device *de
There are several bugs in error handling in br_add_bridge:
- when dev_alloc_name fails, allocated net_device is not freed
- unregister_netdev is called when rtnl lock is held
- free_netdev is called before netdev_run_todo has a chance to be run after
unregistering net_device
This patch should fi
On Thu, 25 May 2006, Brent Cook wrote:
> On Thursday 25 May 2006 02:23, Bill Fink wrote:
> > On Wed, 24 May 2006, Jeff Garzik wrote:
> > > Brent Cook wrote:
> > > > Note that this is just clearing the hardware statistics on the
> > > > interface, and would not require any kind of atomic_increment
On Thu, 2006-25-05 at 12:53 +0200, Simon Oosthoek wrote:
>
> I agree with your analysis, and recently I read an interesting interview
> with her (I think it was linked from slashdot, an interview with the
> "mother of the Internet ;-) I'm not sure her work (I don't exactly
> recall the specifi
On Wed, 2006-24-05 at 13:25 -0700, Rick Jones wrote:
> The lanadmin (think ethtool) command of HP-UX has had a way to clear the
> statistics reported by lanadmin. I do not know however, if that affects
> the stats in the actual SNMP interface MIBs as I've never had occasion
> to look.
>
> I s
Use radiobtn interface for radio hardware button support in rt2x00
Signed-off-by: Ivo van Doorn <[EMAIL PROTECTED]>
diff -uprN wireless-dev/drivers/net/wireless/d80211/rt2x00/Kconfig
wireless-dev-radiobtn/drivers/net/wireless/d80211/rt2x00/Kconfig
--- wireless-dev/drivers/net/wireless/d80211/rt2
Hi,
As discussed previously on this list hardware button support
for wireless cards and Bluetooth devices could use a seperate
generalized driver.
I have made a first attempt to do this with the suggestions from the
discussion. This means that in all cases the hardware will be requested
to enable
Add radiobtn driver.
This driver creates an iput device for each registered button
and will poll the device frequently to check the latest status of the button.
Once the status has changed it will try to enable or disable the radio
and send an event to the input device.
Signed-off-by: Ivo van Door
There are several bugs in error handling in br_add_bridge:
- when dev_alloc_name fails, allocated net_device is not freed
- unregister_netdev is called when rtnl lock is held
- free_netdev is called before netdev_run_todo has a chance to be run after
unregistering net_device
This patch should fi
On Thu, 25 May 2006 15:31:24 +0200, Jiri Benc wrote:
> err2:
> - free_netdev(dev);
> + unregister_netdevice(dev);
> err1:
> rtnl_unlock();
> + free_netdev(dev);
> return ret;
Sorry, this is wrong. I didn't notice that br_dev_setup sets
dev->destructor to free_netdev. Co
[EMAIL PROTECTED] wrote:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=6613
>
>Summary: iptables broken on 32-bit PReP (ARCH=ppc)
> Kernel Version: 2.6.17-rc4
> Status: NEW
> Severity: normal
> Owner: [EMAIL PROTECTED]
> Submitter: [EMAI
On Thu, 2006-05-25 at 03:23 -0400, Bill Fink wrote:
> likely problem areas. The human mind (at least speaking for myself) is
> not nearly as adept when having to deal with deltas. Yes, you can record
> the initial state of all the devices, run the stress test, record the new
> state of all the de
There are several problems in error handling in br_add_bridge:
- when dev_alloc_name fails, allocated net_device is not freed
- unregister_netdev is called when rtnl lock is held
- free_netdev is called before netdev_run_todo has a chance to be run after
unregistering net_device
This patch shoul
On Thursday 25 May 2006 02:23, Bill Fink wrote:
> On Wed, 24 May 2006, Jeff Garzik wrote:
> > Brent Cook wrote:
> > > Note that this is just clearing the hardware statistics on the
> > > interface, and would not require any kind of atomic_increment addition
> > > for interfaces that support that. I
Phil Dibowitz <[EMAIL PROTECTED]> :
[...]
> Right. I think the point here is that it does _NOT_ inherently break
> things. If you don't like the behavior, don't run "ethtool -z eth0",
> it's that simple.
It would be better to explain why several sysadmins want this feature
and why it can't be done
From: Angelo P. Castellani <[EMAIL PROTECTED]>
TCP Compound is a sender-side only change to TCP that uses
a mixed Reno/Vegas approach to calculate the cwnd.
For further details look here:
ftp://ftp.research.microsoft.com/pub/tr/TR-2005-86.pdf
Signed-off-by: Angelo P. Castellani <[EMAIL PROTECT
Daniel J Blueman wrote:
> On 25/05/06, Patrick McHardy <[EMAIL PROTECTED]> wrote:
>
>> Daniel, is there an easy way to reproduce the checksum failure?
>
>
> In short, no. This was seen when packets may have been truncated by
> large MTU (eg 9000) problems in the sky2 driver transmit path.
>
> T
diff -Naru linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_niu.c
linux-2.6.16.18/drivers/net/netxen/netxen_nic_niu.c
--- linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_niu.c1969-12-31
16:00:00.0 -0800
+++ linux-2.6.16.18/drivers/net/netxen/netxen_nic_niu.c 2006-05-25
02:43:22.
diff -Naru linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_main.c
linux-2.6.16.18/drivers/net/netxen/netxen_nic_main.c
--- linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_main.c 1969-12-31
16:00:00.0 -0800
+++ linux-2.6.16.18/drivers/net/netxen/netxen_nic_main.c2006-05-25
diff -Naru linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_init.c
linux-2.6.16.18/drivers/net/netxen/netxen_nic_init.c
--- linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_init.c 1969-12-31
16:00:00.0 -0800
+++ linux-2.6.16.18/drivers/net/netxen/netxen_nic_init.c2006-05-25
diff -Naru linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_ioctl.h
linux-2.6.16.18/drivers/net/netxen/netxen_nic_ioctl.h
--- linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_ioctl.h 1969-12-31
16:00:00.0 -0800
+++ linux-2.6.16.18/drivers/net/netxen/netxen_nic_ioctl.h 2006-05-2
On 25/05/06, Patrick McHardy <[EMAIL PROTECTED]> wrote:
Stephen Hemminger wrote:
> On Wed, 24 May 2006 10:28:52 +0100
> "Daniel J Blueman" <[EMAIL PROTECTED]> wrote:
>
>>Having done some more stress testing with sky2 1.4 (in 2.6.17-rc4) and
>>the latest patch, I have found problems when streaming
diff -Naru linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_hw.h
linux-2.6.16.18/drivers/net/netxen/netxen_nic_hw.h
--- linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_hw.h 1969-12-31
16:00:00.0 -0800
+++ linux-2.6.16.18/drivers/net/netxen/netxen_nic_hw.h 2006-05-25
02:43:22.00
diff -Naru linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_hw.c
linux-2.6.16.18/drivers/net/netxen/netxen_nic_hw.c
--- linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_hw.c 1969-12-31
16:00:00.0 -0800
+++ linux-2.6.16.18/drivers/net/netxen/netxen_nic_hw.c 2006-05-25
02:43:22.00
jamal wrote:
Essentially you are extending the broadcast domain i.e a bridge within
on top of a bridge. I would question the scalability of such a beast
in the presence of many nodes. Also take a look at some of the work
Radia Perlman (who invented bridging really) is up to these days.
Hi J
diff -Naru linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_hdr.h
linux-2.6.16.18/drivers/net/netxen/netxen_nic_hdr.h
--- linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_hdr.h1969-12-31
16:00:00.0 -0800
+++ linux-2.6.16.18/drivers/net/netxen/netxen_nic_hdr.h 2006-05-25
02:43:22.
diff -Naru linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic.h
linux-2.6.16.18/drivers/net/netxen/netxen_nic.h
--- linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic.h1969-12-31
16:00:00.0 -0800
+++ linux-2.6.16.18/drivers/net/netxen/netxen_nic.h 2006-05-25
02:43:22.
diff -Naru linux-2.6.16.18.orig/drivers/net/Kconfig
linux-2.6.16.18/drivers/net/Kconfig
--- linux-2.6.16.18.orig/drivers/net/Kconfig2006-05-24 06:57:55.0
-0700
+++ linux-2.6.16.18/drivers/net/Kconfig 2006-05-24 07:00:29.0 -0700
@@ -2313,6 +2313,11 @@
If in doubt, s
Hi,
I'll be sending a NetXen (formerly Universal Network Machines) 1G/10G in
subsequent emails. This is a revised version of the UNM driver posted
earlier. We have tried to make changes as per the feedback received.
We would like this driver to be inluded in mainline kernel.
Kindly review it and
Stephen Hemminger wrote:
> On Wed, 24 May 2006 10:28:52 +0100
> "Daniel J Blueman" <[EMAIL PROTECTED]> wrote:
>
>
>>Having done some more stress testing with sky2 1.4 (in 2.6.17-rc4) and
>>the latest patch, I have found problems when streaming lots of data
>>out of the sky2 interface (eg via samb
On Wed, 24 May 2006, Phil Dibowitz wrote:
On Wed, May 24, 2006 at 02:23:05PM -0400, Jeff Garzik wrote:
I disagree that we should bother about clearing statistics. It always
adds more complication than necessary. Few (if any) other statistics in
Linux permit easy clearing, often because adding
Hi Pavel
(I've removed linux-kernel from CC, this is only network related and
added Herman to the CC, since he's not subscribed)
Pavel Machek wrote:
Hi!
FLAME stands for "Forwarding Layer for Meshing"
FLAME provides an intermediate layer between the network
layer (e.g. IPv4/IPv6) and the
Hi Stephen,
Thanks for your feedback.
On 24/05/06, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
"Daniel J Blueman" <[EMAIL PROTECTED]> wrote:
> Having done some more stress testing with sky2 1.4 (in 2.6.17-rc4) and
> the latest patch, I have found problems when streaming lots of data
> out of t
Benjamin Herrenschmidt wrote:
> On Wed, 2006-05-24 at 10:04 +0200, Brice Goglin wrote:
>
>
>> I am not sure what you mean.
>> The only ppc64 with PCI-E that we have seen so far (a G5) couldn't do
>> write combining according to Apple.
>>
>
> That is not 100% true I don't know what apple
1 - 100 of 107 matches
Mail list logo
