Kok, Auke <[EMAIL PROTECTED]> wrote:
> Dave Jones wrote:
>> Last night, I hit this bug during boot up..
>> http://www.codemonkey.org.uk/junk/e100-2.jpg
>>
>> This morning, I got a mail from a Fedora user of the same
>> .23-rc8 based kernel that has seen a different trace
>> also implicating e100..
(warning, adjusted CC's and added netdev mailing list)
David Miller wrote:
From: [EMAIL PROTECTED]
Date: Wed, 26 Sep 2007 18:14:42 -0700
From: Yinghai Lu <[EMAIL PROTECTED]>
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
Cc: Christoph Lameter <[EMAIL PROTECTED]>
Cc: Andy Whitcroft <[EMAIL PR
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Wed, 26 Sep 2007 21:54:47 -0600
>
> Denis V. Lunev <[EMAIL PROTECTED]> noticed that the locking rules
> for the network namespace list are over complicated and broken.
>
> In particular the current register_netdev_notifier currently
> does not ta
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 26 Sep 2007 17:22:46 -0700
> Since hardware header operations are part of the protocol class
> not the device instance, make them into a separate object and
> save memory.
>
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
I applied th
Eric W. Biederman wrote:
> Denis V. Lunev <[EMAIL PROTECTED]> noticed that the locking rules
> for the network namespace list are over complicated and broken.
>
> In particular the current register_netdev_notifier currently
> does not take any lock making the for_each_net iteration racy
> with net
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 26 Sep 2007 17:21:37 -0700
> Wrap the hard_header_parse function to simplify next step
> of header_ops conversion.
>
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Applied.
-
To unsubscribe from this list: send the line "unsubscribe
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 26 Sep 2007 17:21:29 -0700
>
> Add inline for common usage of hardware header creation, and
> fix bug in IPV6 mcast where the assumption about negative return is
> an errno. Negative return from hard_header means not enough space
> was availa
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Wed, 26 Sep 2007 18:00:20 -0600
>
> This patch makes loopback_dev per network namespace. Adding
> code to create a different loopback device for each network
> namespace and adding the code to free a loopback device
> when a network namespace exi
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Wed, 26 Sep 2007 17:58:21 -0600
>
> Now that multiple loopback devices are becoming possible it makes
> the code a little cleaner and more maintainable to test if a deivice
> is th a loopback device by testing dev->flags & IFF_LOOPBACK instead
> o
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Wed, 26 Sep 2007 17:55:29 -0600
>
> Currently we never call unregister_netdev for the loopback device so
> it is impossible for us to reach inetdev_destroy with the loopback
> device. So the test in inetdev_destroy is unnecessary.
>
> Further wh
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Wed, 26 Sep 2007 17:53:40 -0600
>
> This patch add support for dynamically allocating the statistics counters
> for the loopback device and adds appropriate device methods for allocating
> and freeing the loopback device.
>
> This completes suppo
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Wed, 26 Sep 2007 17:49:54 -0600
>
> This patch allows you to create a new network namespace
> using sys_clone, or sys_unshare.
>
> As the network namespace is still experimental and under development
> clone and unshare support is only made avail
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Wed, 26 Sep 2007 17:48:10 -0600
>
> When sysfs support is compiled out the kernel still keeps and maintains
> the kobject tree. So it is not safe to skip our kobject reference counting
> or
> to avoid becoming members of the kobject tree. It i
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Wed, 26 Sep 2007 17:07:04 +0300 (EEST)
> Hmm, thought a bit more about it... How about this then? No additional
> counter. Compile tested. Not that I see a large benefit from it, in theory
> could help logging in some malicious attempt cases; we sa
Hi,
We have observed 40ms latency spikes in TCP connections in "burst" type of
traffic. This affects regular TCP sockets. We observed this issue in kernels of
2.4.21 and kernel 2.6.5.
Aparently, this seems to be fixed in 2.6.19.
Can someone throw some light on this?
Is this a congestion
Denis V. Lunev <[EMAIL PROTECTED]> noticed that the locking rules
for the network namespace list are over complicated and broken.
In particular the current register_netdev_notifier currently
does not take any lock making the for_each_net iteration racy
with network namespace creation and destruct
Shutdown no longer powers off, something changed. 2.6.23-rc8 works
fine, but net-2.6.24 gets to shutting off the disks and never finishes.
Any ideas before I go on a bisect hunt?
--
Stephen Hemminger <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the
The Yukon FE+ chip appears to have a hardware glitch that causes bogus
receive status values to be posted. The data in the packet is good, but
the status value is random garbage. As a temporary workaround until the
problem is better understood, implement the workaround the vendor driver
used of ig
Wrap the hard_header_parse function to simplify next step
of header_ops conversion.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/include/linux/netdevice.h 2007-09-26 16:26:03.0 -0700
+++ b/include/linux/netdevice.h 2007-09-26 16:26:04.0 -0700
@@ -657,7 +657,7 @@ stru
Add inline for common usage of hardware header creation, and
fix bug in IPV6 mcast where the assumption about negative return is
an errno. Negative return from hard_header means not enough space
was available,(ie -N bytes).
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/include/linu
On Wed, 26 Sep 2007 17:48:10 -0600
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
>
> When sysfs support is compiled out the kernel still keeps and maintains
> the kobject tree. So it is not safe to skip our kobject reference counting
> or
> to avoid becoming members of the kobject tree. It is
This patch makes loopback_dev per network namespace. Adding
code to create a different loopback device for each network
namespace and adding the code to free a loopback device
when a network namespace exits.
This patch modifies all users the loopback_dev so they
access it as init_net.loopback_de
Now that multiple loopback devices are becoming possible it makes
the code a little cleaner and more maintainable to test if a deivice
is th a loopback device by testing dev->flags & IFF_LOOPBACK instead
of dev == loopback_dev.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
net/ipv4/de
Currently we never call unregister_netdev for the loopback device so
it is impossible for us to reach inetdev_destroy with the loopback
device. So the test in inetdev_destroy is unnecessary.
Further when testing with my network namespace patches removing
unregistering the loopback device and cal
This patch add support for dynamically allocating the statistics counters
for the loopback device and adds appropriate device methods for allocating
and freeing the loopback device.
This completes support for creating multiple instances of the loopback
device, in preparation for creating per net
This patch allows you to create a new network namespace
using sys_clone, or sys_unshare.
As the network namespace is still experimental and under development
clone and unshare support is only made available when CONFIG_NET_NS is
selected at compile time.
As this patch introduces network namespac
When sysfs support is compiled out the kernel still keeps and maintains
the kobject tree. So it is not safe to skip our kobject reference counting or
to avoid becoming members of the kobject tree. It is safe to not add
the networking specific sysfs attributes.
This patch removes the sysfs spec
David Miller <[EMAIL PROTECTED]> writes:
> I've put these patches into the just-rebased net-2.6.24 tree.
>
> I made a minor modification to the second patch, the
> out_free_netdev: code in loopback_init() ended like this:
>
> out_free_netdev:
> free_netdev(dev);
> goto out;
> ret
From: Olof Johansson <[EMAIL PROTECTED]>
Date: Wed, 26 Sep 2007 16:22:00 -0500
> [PATCH] [1/6] pasemi_mac: fix build break in pasemi_mac_probe()
> [PATCH] [2/6] pasemi_mac: fix build break in pasemi_mac_clean_rx()
> [PATCH] [3/6] pasemi_mac: set interface speed correctly on XAUI ports
> [PATCH] [4
From: Olof Johansson <[EMAIL PROTECTED]>
Date: Wed, 26 Sep 2007 16:23:06 -0500
> pasemi_mac: fix build break in pasemi_mac_clean_rx()
>
> Fix breakage caused by the unification of stats structs.
>
>
> Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Jeff, I added this to my net-2.6.24 tree be
From: Olof Johansson <[EMAIL PROTECTED]>
Date: Wed, 26 Sep 2007 16:22:43 -0500
> pasemi_mac: fix build break in pasemi_mac_probe()
>
> Fix breakage caused by recent unification of print_mac() stuff.
>
>
> Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
This one is in net-2.6.24 already, than
pasemi_mac: pass in count of buffers to replenish rx ring with
Refactor replenish_rx_ring to take an argument for how many entries to
fill. Since it's normally available from where it's called anyway, this
is just simpler. It also removes the awkward logic to try to figure out
if we're filling for
pasemi_mac: don't enable rx before there are buffers on the ring
Reorder initialization of the DMA channels and the interface. Before there
was a time window when the interface was enabled before DMA was enabled.
Also, now there will always be RX buffers available at the time the
MAC interface is
pasemi_mac: flags as passed to spin_*_irqsave() should be unsigned long.
Signed-off-by: Tony Breeds <[EMAIL PROTECTED]>
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
---
Found trying to build a -rt kernel, which has a BUILD_BUG_ON(), in this
caswe.
drivers/net/pasemi_mac.c |4 ++--
1 fi
pasemi_mac: set interface speed correctly on XAUI ports
Set interface speed for XAUI to 10G per default, not 1G.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Index: 2.6.23/drivers/net/pasemi_mac.c
===
--- 2.6.23.orig/drivers/ne
pasemi_mac: fix build break in pasemi_mac_clean_rx()
Fix breakage caused by the unification of stats structs.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Index: k.org/drivers/net/pasemi_mac.c
===
--- k.org.orig/drivers/net/pa
Hi,
Following patches are for various bug fixes against current netdev-2.6.24
upstream branch. Please apply.
[PATCH] [1/6] pasemi_mac: fix build break in pasemi_mac_probe()
[PATCH] [2/6] pasemi_mac: fix build break in pasemi_mac_clean_rx()
[PATCH] [3/6] pasemi_mac: set interface speed correctly
pasemi_mac: fix build break in pasemi_mac_probe()
Fix breakage caused by recent unification of print_mac() stuff.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
Index: k.org/drivers/net/pasemi_mac.c
===
--- k.org.orig/drivers/ne
From: "John W. Linville" <[EMAIL PROTECTED]>
Date: Wed, 26 Sep 2007 08:46:49 -0400
> On Tue, Sep 25, 2007 at 11:33:44PM -0700, David Miller wrote:
>
> > John, one patch didn't go in cleanly after I removed the
> > Z1211 driver. I put it here for your consideration so it
> > doesn't get lost:
> >
Rolan/Sean,
What do you all think?
Steve.
Steve Wise wrote:
iw_cxgb3: Support "iwarp-only" interfaces to avoid 4-tuple conflicts.
Version 3:
- don't use list_del_init() where list_del() is sufficient.
Version 2:
- added a per-device mutex for the address and listening endpoints lists.
-
Herbert Xu wrote:
> Stephen Hemminger <[EMAIL PROTECTED]> wrote:
>> The bug http://bugzilla.kernel.org/show_bug.cgi?id=5731
>> describes an issue where write() can't be used to generate a zero-length
>> datagram (but send, and sendto do work).
>>
>> I think the following is needed:
>>
>> --- a/net/
On Wed, Sep 26, 2007 at 11:10:11AM -0700, Kok, Auke wrote:
> Dave Jones wrote:
> > Last night, I hit this bug during boot up..
> > http://www.codemonkey.org.uk/junk/e100-2.jpg
> >
> > This morning, I got a mail from a Fedora user of the same
> > .23-rc8 based kernel that has seen a different
Dave Jones wrote:
> Last night, I hit this bug during boot up..
> http://www.codemonkey.org.uk/junk/e100-2.jpg
>
> This morning, I got a mail from a Fedora user of the same
> .23-rc8 based kernel that has seen a different trace
> also implicating e100..
>
> http://www.codemonkey.org.uk/junk/e100.
Herbert Xu wrote:
Stephen Hemminger <[EMAIL PROTECTED]> wrote:
The bug http://bugzilla.kernel.org/show_bug.cgi?id=5731
describes an issue where write() can't be used to generate a zero-length
datagram (but send, and sendto do work).
I think the following is needed:
--- a/net/socket.c 200
Last night, I hit this bug during boot up..
http://www.codemonkey.org.uk/junk/e100-2.jpg
This morning, I got a mail from a Fedora user of the same
.23-rc8 based kernel that has seen a different trace
also implicating e100..
http://www.codemonkey.org.uk/junk/e100.jpg
It may be that the two proble
On Tue, 25 Sep 2007, David Miller wrote:
> From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
> Date: Mon, 24 Sep 2007 12:04:07 +0300
>
> > In case of ACK reordering, the SACK block might be valid in it's
> > time but is already obsoleted since we've received another kind
> > of confirmation about arrival
On Wed, 2007-26-09 at 10:12 +0800, John Ye wrote:
> cpu hash (srcip + dstip) % nr_cpus, plus checking cpu balance periodically,
> shift cpu by an extra seed value?
That may work maybe even add ipproto as a 3rd tuple; experiments will
tell - you need to be able to generate a random enough traffic
Hi Jamal.
On Wed, Sep 26, 2007 at 09:08:45AM -0400, jamal ([EMAIL PROTECTED]) wrote:
> Those numbers look impressive. How mysterious do things get in SMP?
> Sorry havent had time to stare at the code. How do you measure cpu you
> quoted?
I did not checked how netchannels and userspace stack behav
On Tue, 2007-25-09 at 19:28 -0700, David Miller wrote:
> I've applied this to net-2.6.24, although I want to study more deeply
> the implications of this change myself at some point :)
sounds reasonable. Ive done a lot of testing with my 2-3 NIC variants;
ive cced whoever i thought was a stakehol
On Tue, Sep 25, 2007 at 11:33:44PM -0700, David Miller wrote:
> John, one patch didn't go in cleanly after I removed the
> Z1211 driver. I put it here for your consideration so it
> doesn't get lost:
>
> http://vger.kernel.org/~davem/0433-Z1211-Fix-TX-status-reports.patch
>
> What probabl
Evgeniy,
Those numbers look impressive. How mysterious do things get in SMP?
Sorry havent had time to stare at the code. How do you measure cpu you
quoted?
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majo
David Miller wrote:
> From: Vlad Yasevich <[EMAIL PROTECTED]>
> Date: Mon, 24 Sep 2007 16:59:25 -0400
>
>> Can you please pull the following changes since commit
>> a41d3015c11a4e864b95cb57f579f2d8f40cd41b:
>
> I had to apply this by hand because:
>
>> David S. Miller (1):
>> Revert "
On 9/26/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> > > http://tservice.net.ru/~s0mbre/blog/devel/networking/2006_10_26.html
> > > http://tservice.net.ru/~s0mbre/blog/devel/networking/2006_12_21.html
> > >
> >
> > Very interesting. Are there any details of your benchmarking available,
> > nam
(Resend to netdev; already sent to relevant individuals.)
Here's a possible fix for the p[] array issues akpm noticed.
This replaces them with calls to a new mdio_write_bits function.
Boot-tested, passes net traffic, and mii-tool and mii-diag produce sensible
output (including noticing link statu
Hi Francois,
this is what I found and sent:
The error exists from patch 2 on. I did some network testing with
patch 1 and currently use it and have no errors so far.
>From my experiences up to now patch 1 should be error free.
Do you need additional info?
2007/9/12, Francois Romieu <[EMAIL PROT
On Tue, 25 Sep 2007 10:39:17 +0200
Hannes Reinecke <[EMAIL PROTECTED]> wrote:
> Hi Tomo,
>
> FUJITA Tomonori wrote:
> > On Sat, 8 Sep 2007 13:00:36 +0100
> > Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> >
> >> On Sat, Sep 08, 2007 at 07:32:27AM -0400, Jeff Garzik wrote:
> >>> FUJITA Tomonori w
Hi Robert.
On Tue, Sep 25, 2007 at 09:20:44PM +0200, Robert Iakobashvili ([EMAIL
PROTECTED]) wrote:
> > 3. Gigabit send/recv benchmark for netchannels and sockets using small
> > packets.
> > http://tservice.net.ru/~s0mbre/blog/devel/networking/2006_10_26.html
> > http://tservice.net.ru/~s0mbre/b
On Tue, Sep 25, 2007 at 12:34:44PM -0700, Stephen Hemminger ([EMAIL PROTECTED])
wrote:
> > It was proven [3] that unetstack can be *much* faster than vanilla TCP
> > stack (mainly because of heavily reduced number of syscalls, different
> > congestion control algorithm and other features).
>
> I
On Tue, 2007-09-25 at 23:33 -0700, David Miller wrote:
> http://vger.kernel.org/~davem/0433-Z1211-Fix-TX-status-reports.patch
>
> What probably needs to happen is some other changes that
> were in z1211 need to go into the non-mac80211 driver and
> then this patch applies correctly.
>
> I
59 matches
Mail list logo
