-stable review patch. If anyone has any objections, please let us know.
--
From: Stephen Hemminger <[EMAIL PROTECTED]>
Backport of commit 71749531f2d1954137a1a77422ef4ff29eb102dd
If packet larger than MTU is received, the driver uses hardware to
truncate the packet. Use the stat
-stable review patch. If anyone has any objections, please let us know.
--
From: Stephen Hemminger <[EMAIL PROTECTED]>
Backport of commit 5c11ce700f77fada15b6264417d72462da4bbb1c
This patch avoids generating another IRQ if more packets
arrive while in the NAPI poll routine. Befo
-stable review patch. If anyone has any objections, please let us know.
--
From: Stephen Hemminger <[EMAIL PROTECTED]>
backport of commit 55d7b4e6ed6ad3ec5e5e30b3b4515a0a6a53e344
Make sky2 handle carrier similar to other drivers,
eliminate some possible races in carrier state tr
-stable review patch. If anyone has any objections, please let us know.
--
From: Stephen Hemminger <[EMAIL PROTECTED]>
Backport of commit c59697e06058fc2361da8cefcfa3de85ac107582
This patch restores a couple of workarounds from 2.6.16:
* restart transmit moderation timer in cas
Hi:
Here's the back-port for 2.6.22.
[NET]: Share correct feature code between bridging and bonding
http://bugzilla.kernel.org/show_bug.cgi?id=8797 shows that the
bonding driver may produce bogus combinations of the checksum
flags and SG/TSO.
For example, if you bond devices with NETIF_F_HW_CSU
On Mon, 20 Aug 2007, Chris Snook wrote:
>
> What about barrier removal? With consistent semantics we could optimize a
> fair amount of code. Whether or not that constitutes "premature" optimization
> is open to debate, but there's no question we could reduce our register wiping
> in some places
> -Original Message-
> From: Patrick Geoffray [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 20, 2007 1:34 PM
> To: Felix Marti
> Cc: Evgeniy Polyakov; David Miller; [EMAIL PROTECTED];
> netdev@vger.kernel.org; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTE
Stephen Hemminger wrote:
> On Mon, 20 Aug 2007 13:45:36 +0530
> Varun Chandramohan <[EMAIL PROTECTED]> wrote:
>
>
>> A new function for converting timeval to time_t is added in time.h. Its a
>> common function used in different
>> places.
>>
>> Signed-off-by: Varun Chandramohan <[EMAIL PROTECTE
[TSO / LRO discussion snipped -- it's not the main point so no sense
spending energy arguing about it]
> Just be realistic and accept that RDMA is a point in time solution,
> and like any other such technology takes flexibility away from users.
>
> Horizontal scaling of cpus up to huge arity
On Tue, Aug 21, 2007 at 01:02:01AM +0200, Segher Boessenkool wrote:
> >>And no, RMW on MMIO isn't "problematic" at all, either.
> >>
> >>An RMW op is a read op, a modify op, and a write op, all rolled
> >>into one opcode. But three actual operations.
> >
> >Maybe for some CPUs, but not all. ARM f
When transferring data at full speed, the DM9000 network interface
sometimes stops sending/receiving data. Worse, ksoftirqd consumes
100% cpu and the net tx watchdog never triggers.
Fix by spin_lock_irqsave() in dm9000_start_xmit() to prevent the
interrupt handler from interfering.
Signed-off-by:
On Tuesday 21 August 2007, Linas Vepstas wrote:
>
> An intervening patch changed the init so that the
> hardware interrupts aren't enabled until after the
> request_irq, and after the poll_enable(). Thus,
> it seems this pach is no longer needed, right?
Right, the other patch that you already a
And no, RMW on MMIO isn't "problematic" at all, either.
An RMW op is a read op, a modify op, and a write op, all rolled
into one opcode. But three actual operations.
Maybe for some CPUs, but not all. ARM for instance can't use the
load exclusive and store exclusive instructions to MMIO space.
On Tue, Aug 21, 2007 at 12:04:17AM +0200, Segher Boessenkool wrote:
> And no, RMW on MMIO isn't "problematic" at all, either.
>
> An RMW op is a read op, a modify op, and a write op, all rolled
> into one opcode. But three actual operations.
Maybe for some CPUs, but not all. ARM for instance ca
On Mon, Aug 20, 2007 at 10:13:27PM +0900, Ishizaki Kou wrote:
> Please apply this to 2.6.23.
I'll review and forward shortly. Kick me if you don't see a formal
reply in a few days.
> And also, please apply the following Arnd-san's patch to fix a problem
> that spidernet driver sometimes causes a
On Thu, Jul 12, 2007 at 01:19:11AM +0200, Arnd Bergmann wrote:
> We must not call netif_poll_enable after enabling interrupts,
> because an interrupt might come in and set the __LINK_STATE_RX_SCHED
> bit before we get to clear that bit again. If that happens,
> the next call to the ->poll() functio
On Thu, Jul 12, 2007 at 01:19:11AM +0200, Arnd Bergmann wrote:
> Index: linux-2.6/drivers/net/spider_net.c
Sorry, this one got lost in my mailbox. Will attend to it shortly.
--linas
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
Such code generally doesn't care precisely when it gets the update,
just that the update is atomic, and it doesn't loop forever.
Yes, it _does_ care that it gets the update _at all_, and preferably
as early as possible.
Regardless, I'm convinced we just need to do it all in assembly.
So do y
Right. ROTFL... volatile actually breaks atomic_t instead of making
it safe. x++ becomes a register load, increment and a register store.
Without volatile we can increment the memory directly. It seems that
volatile requires that the variable is loaded into a register first
and then operated up
Felix Marti wrote:
Yes, the app will take the cache hits when accessing the data. However,
the fact remains that if there is a copy in the receive path, you
require and additional 3x memory BW (which is very significant at these
high rates and most likely the bottleneck for most current systems).
> GPUs have almost no influence on system security,
Unless you use direct rendering from user space.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
The following two patches fix:
An undocumented "feature" where the 4032 chip sets bit-7
of the opcode for an inbound completion if it's for a VLAN.
The access of stale data on a completion entry.
These patches were built and tested on 2.6.23-rc1.
Signed-off-by: Ron Mercer <[EMAIL PROTECTED]>
-
* Felix Marti <[EMAIL PROTECTED]> 2007-08-20 12:02
> These graphic adapters provide a wealth of features that you can take
> advantage of to bring these amazing graphics to life. General purpose
> CPUs cannot keep up. Chelsio offload devices do the same thing in the
> realm of networking. - Will th
On Aug 17, 2007, at 01:54, Domen Puncer wrote:
Writing BMCR_RESET bit will reset MII_BMCR to default values. This is
clearly not what we want.
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
Acked-by: Andy Fleming <[EMAIL PROTECTED]>
I could have sworn there was a patch that did this, alre
Andi Kleen wrote:
TSO is beneficial for the software again. The linux code currently
takes several locks and does quite a few function calls for each
packet and using larger packets lowers this overhead. At least with
10GbE saving CPU cycles is still quite important.
Some quick netperf TCP_RR
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andi Kleen
> Sent: Monday, August 20, 2007 11:11 AM
> To: Felix Marti
> Cc: Evgeniy Polyakov; [EMAIL PROTECTED]; netdev@vger.kernel.org;
> [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; David
Francois Romieu wrote:
The latest serie of r8169 changes is available against 2.6.23-rc3 as:
http://www.fr.zoreil.com/people/francois/misc/20070818-2.6.23-rc3-r8169-test.patch
or (tarball sits one level higher):
http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.23-rc3/r8169-20070818/
or (rebas
"Felix Marti" <[EMAIL PROTECTED]> writes:
> What I was referring to is that TSO(/LRO) have their own
> issues, some eluded to by Roland and me. In fact, customers working on
> the LSR couldn't use TSO due to the burstiness it introduces
That was in old kernels where TSO didn't honor the initial c
--- Stephen Hemminger
<[EMAIL PROTECTED]> wrote:
> On Mon, 20 Aug 2007 09:23:46 -0700 (PDT)
> James Corey <[EMAIL PROTECTED]> wrote:
>
> >
> > --- Stephen Hemminger
> > <[EMAIL PROTECTED]> wrote:
> >
> > > On Mon, 20 Aug 2007 08:42:21 -0700 (PDT)
> > > James Corey <[EMAIL PROTECTED]> wrote:
>
On Mon, 20 Aug 2007 09:21:54 -0700, "Brandeburg, Jesse" <[EMAIL PROTECTED]>
said:
> Hi Alan, I work on the team that supports e1000, I'd be interested
> in seeing the dmesg output from the machine before it crashes, maybe
> you can add that to your web collection of data below?
Don't worry - it'
> -Original Message-
> From: Evgeniy Polyakov [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 20, 2007 2:43 AM
> To: Felix Marti
> Cc: David Miller; [EMAIL PROTECTED]; netdev@vger.kernel.org;
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; linux-
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject:
On Mon, 20 Aug 2007 09:23:46 -0700 (PDT)
James Corey <[EMAIL PROTECTED]> wrote:
>
> --- Stephen Hemminger
> <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 20 Aug 2007 08:42:21 -0700 (PDT)
> > James Corey <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > --- Stephen Hemminger
> > > <[EMAIL PROTECTED]> wrote
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andi Kleen
> Sent: Monday, August 20, 2007 4:07 AM
> To: Felix Marti
> Cc: David Miller; [EMAIL PROTECTED]; netdev@vger.kernel.org;
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; linux-
> [EMAIL PROTECTED]; [EM
David Hollis wrote:
> It's a bit of a longshot, but I notice that EEPROM index 0x17 returns
> 0x580 for you, 0x180 for my devices. Based on that, my devices go
> through the "gpio phymode == 1 path" GPIO init sequence, and yours goes
> through the other path ( if ((eeprom >> 8) != 1) { ). Comme
--- Stephen Hemminger
<[EMAIL PROTECTED]> wrote:
> On Mon, 20 Aug 2007 08:42:21 -0700 (PDT)
> James Corey <[EMAIL PROTECTED]> wrote:
>
> >
> > --- Stephen Hemminger
> > <[EMAIL PROTECTED]> wrote:
> >
> > > On Thu, 16 Aug 2007 10:25:45 +0200
> > > "Michal Piotrowski"
> >
> > > Please reproduce
Alan J. Wylie wrote:
> We have been shipping Linux based servers to customers for several
> years now, with few problems. Recently, however, a single customer has
> been seeing kernel panics. Unfortunately, the customer is about 200
> miles away, so physical access is limited. There are two etherne
On Mon, 20 Aug 2007 08:42:21 -0700 (PDT)
James Corey <[EMAIL PROTECTED]> wrote:
>
> --- Stephen Hemminger
> <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 16 Aug 2007 10:25:45 +0200
> > "Michal Piotrowski"
>
> > Please reproduce with a more recent kernel?
>
> Um, I thought 2.6.23rc WAS pretty recent.
Hi all,
Here is a list of some known regressions in 2.6.23-rc3.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
List of Aces
NameRegressions fixed since 21-Jun-2007
Adrian Bunk9
Andi Kleen
Hi all,
Here is a list of some known regressions in 2.6.23-rc3
with patches available.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
List of Aces
NameRegressions fixed since 21-Jun-2007
Adrian Bunk9
When bonding enslaves non Ethernet devices it takes pointers to functions
in the module that owns the slaves. In this case it becomes unsafe
to keep the bonding master registered after last slave was unenslaved
because we don't know if the pointers are still valid. Destroying the bond
when slav
Delay sending a gratuitous_arp when LINK_STATE_LINKWATCH_PENDING bit
in dev->state field is on. This improves the chances for the arp packet to
be transmitted.
Signed-off-by: Moni Shoua <[EMAIL PROTECTED]>
---
drivers/net/bonding/bond_main.c | 24 +---
drivers/net/bonding/bo
Allow to enslave devices when the bonding device is not up. Over the discussion
held at the previous post this seemed to be the most clean way to go, where it
is not expected to cause instabilities.
Normally, the bonding driver is UP before any enslavement takes place.
Once a netdevice is UP, the
bonding sometimes uses Ethernet constants (such as MTU and address length) which
are not good when it enslaves non Ethernet devices (such as InfiniBand).
Signed-off-by: Moni Shoua <[EMAIL PROTECTED]>
---
drivers/net/bonding/bond_main.c |3 ++-
drivers/net/bonding/bond_sysfs.c | 19
--- Stephen Hemminger
<[EMAIL PROTECTED]> wrote:
> On Thu, 16 Aug 2007 10:25:45 +0200
> "Michal Piotrowski"
> <[EMAIL PROTECTED]> wrote:
>
> > [Adding Stephen and netdev to CC]
> >
> > On 15/08/07, James Corey <[EMAIL PROTECTED]>
> wrote:
> > >
> > > I tried running a D-link gig card on kernel
This patch allows for enslaving netdevices which do not support
the set_mac_address() function. In that case the bond mac address is the one
of the active slave, where remote peers are notified on the mac address
(neighbour) change by Gratuitous ARP sent by bonding when fail-over occurs
(this is al
This patch changes some of the bond netdevice attributes and functions
to be that of the active slave for the case of the enslaved device not being
of ARPHRD_ETHER type. Basically it overrides those setting done by
ether_setup(),
which are netdevice **type** dependent and hence might be not approp
IPoIB uses a two layer neighboring scheme, such that for each struct neighbour
whose device is an ipoib one, there is a struct ipoib_neigh buddy which is
created on demand at the tx flow by an ipoib_neigh_alloc(skb->dst->neighbour)
call.
When using the bonding driver, neighbours are created by the
When the bonding device senses a carrier loss of its active slave it replaces
that slave with a new one. In between the times when the carrier of an IPoIB
device goes down and ipoib_neigh is destroyed, it is possible that the
bonding driver will send a packet on a new slave that uses an old ipoib_n
When the bonding device enslaves IPoIB devices it takes pointers to
functions in the ib_ipoib module. This is fine as long as the ib_ipoib
nodule remains loaded while the references to its functions exist.
So, to help bonding do a cleanup on time, when the IPoIB net device is a
slave of a bonding
Export the call to raw_notifier_call_chain so modules can send notifications
on netdev events to the netdev_chain.
Add IFF_SLAVE_DETACH to the list of priv_flags for net_device.
This flag is set by a slave that is about to unregisster from the kernel.
Both changes are used in bonding slaves that w
This patch series is the fourth version (see below link to V3) of the
suggested changes to the bonding driver so it would be able to support
non ARPHRD_ETHER netdevices for its High-Availability (active-backup) mode.
The motivation is to enable the bonding driver on its HA mode to work with
th
On Fri, Aug 10, 2007 at 02:05:26PM -0700, [EMAIL PROTECTED] wrote:
[...]
> diff -puN drivers/net/3c59x.c~3c59x-fix-duplex-configuration
> drivers/net/3c59x.c
> --- a/drivers/net/3c59x.c~3c59x-fix-duplex-configuration
> +++ a/drivers/net/3c59x.c
> @@ -1559,6 +1559,7 @@ vortex_up(struct net_device *
On Sun, 19 Aug 2007 18:15:47 -0700 (PDT)
Kevin E <[EMAIL PROTECTED]> wrote:
> Someone wrote me with a solution to try and so far
> it's working. They suggested I try the driver up on
> Marvell's website but to make sure I powered off the
> machine completely and when it rebooted to not have
> any
On Mon, 20 Aug 2007 13:45:36 +0530
Varun Chandramohan <[EMAIL PROTECTED]> wrote:
> A new function for converting timeval to time_t is added in time.h. Its a
> common function used in different
> places.
>
> Signed-off-by: Varun Chandramohan <[EMAIL PROTECTED]>
> ---
> include/linux/time.h | 1
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> Actually if dmesg will show that there is something in fragments, it
> should use pskb_may_pull(). The same bug exist in bridge and vlan, btw,
> so it might be a solution to remove bug_on from skb_pull_rcsum() and
> instead call may_pull?
That would
Herbert Xu wrote:
On Mon, Aug 20, 2007 at 09:15:11AM -0400, Chris Snook wrote:
Linus Torvalds wrote:
So the only reason to add back "volatile" to the atomic_read() sequence is
not to fix bugs, but to _hide_ the bugs better. They're still there, they
are just a lot harder to trigger, and tend t
Christoph Lameter wrote:
On Fri, 17 Aug 2007, Paul E. McKenney wrote:
On Sat, Aug 18, 2007 at 08:09:13AM +0800, Herbert Xu wrote:
On Fri, Aug 17, 2007 at 04:59:12PM -0700, Paul E. McKenney wrote:
gcc bugzilla bug #33102, for whatever that ends up being worth. ;-)
I had totally forgotten tha
On Mon, Aug 20, 2007 at 09:15:11AM -0400, Chris Snook wrote:
> Linus Torvalds wrote:
> >So the only reason to add back "volatile" to the atomic_read() sequence is
> >not to fix bugs, but to _hide_ the bugs better. They're still there, they
> >are just a lot harder to trigger, and tend to be a lot
Stefan Richter wrote:
Nick Piggin wrote:
Stefan Richter wrote:
Nick Piggin wrote:
I don't know why people would assume volatile of atomics. AFAIK, most
of the documentation is pretty clear that all the atomic stuff can be
reordered etc. except for those that modify and return a value.
Which
This patch solves a problem that the spidernet driver sometimes fails
to handle IRQ.
The problem happens because,
- In Cell architecture, interrupts may arrive at an interrupt
controller, even if they are masked by the setting on registers of
devices. It happens when interrupt packets are sent
From: =?ISO-8859-1?q?Ilpo_J=E4rvinen?= <[EMAIL PROTECTED]>
Only thing that tiny function does is rearming the RTO (if
necessary), name it accordingly.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
net/ipv4/tcp_input.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --
From: =?ISO-8859-1?q?Ilpo_J=E4rvinen?= <[EMAIL PROTECTED]>
In DSACK case, some events are not extraordinary, such as packet
duplication generated DSACK. They can arrive easily below
snd_una when undo_marker is not set (TCP being in CA_Open),
counting such DSACKs amoung SACK discards will likely ju
Linus Torvalds wrote:
So the only reason to add back "volatile" to the atomic_read() sequence is
not to fix bugs, but to _hide_ the bugs better. They're still there, they
are just a lot harder to trigger, and tend to be a lot subtler.
What about barrier removal? With consistent semantics we c
From: =?ISO-8859-1?q?Ilpo_J=E4rvinen?= <[EMAIL PROTECTED]>
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
include/net/tcp.h | 12
net/ipv4/tcp_output.c | 12
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tc
From: =?ISO-8859-1?q?Ilpo_J=E4rvinen?= <[EMAIL PROTECTED]>
Makes caller side more obvious, there's no need to have
a wrapper for this oneliner!
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
include/net/tcp.h |6 --
net/ipv4/tcp_input.c |2 +-
net/ipv4/tcp_output.c |2
Hi Dave,
Here are couple of patches to net-2.6.24. The first three are trivial
cleanups. The idea to the last two comes from tcp-2.6 but the validator
has been heavily modified (and hopefully improved in the process :-)).
I'm not sure though if checking for the undo_marker boundary crossing
case i
From: =?ISO-8859-1?q?Ilpo_J=E4rvinen?= <[EMAIL PROTECTED]>
SACK processing code has been a sort of russian roulette as no
validation of SACK blocks is previously attempted. Besides, it
is not very clear what all kinds of broken SACK blocks really
mean (e.g., one that has start and end sequence num
Hi,
David Miller wrote:
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Fri, 17 Aug 2007 15:40:22 -0700
Compile tested only!!!
Obviously. The first loopback transmit is guarenteed to crash.
[...]
And this also breaks loopback again, which uses a static struct netdev
in the kernel image,
"Felix Marti" <[EMAIL PROTECTED]> writes:
> > avoidance gains of TSO and LRO are still a very worthwhile savings.
> So, i.e. with TSO, your saving about 16 headers (let us say 14 + 20 +
> 20), 864B, when moving ~64KB of payload - looks like very much in the
> noise to me.
TSO is beneficial for the
On Sun, Aug 19, 2007 at 05:47:59PM -0700, Felix Marti ([EMAIL PROTECTED]) wrote:
> [Felix Marti] David and Herbert, so you agree that the user<>kernel
> space memory copy overhead is a significant overhead and we want to
> enable zero-copy in both the receive and transmit path? - Yes, copy
It depe
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.
2007/8/16, Francois Romieu <[EMAIL PROTECTED]>:
> (please do not remove the netdev Cc:)
>
> Francois Romieu <[EMAIL
On 8/19/07, Bruce Cole <[EMAIL PROTECTED]> wrote:
> So it seems that when the driver tries to queue a packet while the
> controller is busy processing the queue, the newly queued packet does
> not get noticed by the controller (until further packet activity occurs).
> Perhaps there is a problem wit
The age field of the ipv6 route structures are initilized with the current
timeval at the time of route
creation. When the route dump is called the route age value stored in the
structure is subtracted from the
present timeval and the difference is passed on as the route age.
Signed-off-by: Varu
A new function for converting timeval to time_t is added in time.h. Its a
common function used in different
places.
Signed-off-by: Varun Chandramohan <[EMAIL PROTECTED]>
---
include/linux/time.h | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/include/linux/ti
The age field is filled with the current time at the time of creation of the
route. When the routes are dumped
then the age value stored in the route structure is subtracted from the current
time value and the difference is the age expressed in secs.
Signed-off-by: Varun Chandramohan <[EMAIL PRO
A new attribute RTA_AGE is added for the age value to be exported to userlevel
using netlink
Signed-off-by: Varun Chandramohan <[EMAIL PROTECTED]>
---
include/linux/rtnetlink.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/rtnetlink.h b/include/linux/rtne
Hi Dave,
This is rev2 of the patch set i sent out sometime ago. I have made it
against net-2.6.24 tree. Can you please review and let me know? There have been
a few minor changes since rev1.
Original Message:
According to the RFC 4292 (IP Forwarding Table MIB) there is a need for an age
77 matches
Mail list logo
