Hi,
this are the changes to the smc911x driver, which were necessary
to get it running on the Magic Panel R2 (smsc9115).
It is a SH3-DSP based board. The other patches are available on
the linuxsh-dev mailinglist.
http://marc.info/?l=linuxsh-devr=1b=200708w=2
It was necessary to set the irq
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
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
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
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
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:
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 with the
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 Sun, Aug 19, 2007 at 05:47:59PM -0700, Felix Marti ([EMAIL PROTECTED]) wrote:
[Felix Marti] David and Herbert, so you agree that the userkernel
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 depends.
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
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,
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
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
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/tcp.h
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 +-
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
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
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 --git
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
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.
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
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
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 to
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 be
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 | 12
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 of
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 *dev)
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
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
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
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
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
--- 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
2.6.21.1
and it came
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
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
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 +---
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
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
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. :-)
I'll check
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 ethernet
--- 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 with a more recent kernel?
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) { ). Comment out
-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]; [EMAIL
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:
On Thu, 16 Aug
-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: Re:
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's
--- 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:
--- Stephen
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 cwnd
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
-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
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
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,
* 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 there
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]
-
To
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
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
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
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
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]
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() function
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 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 can't
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 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
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 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 for instance can't
[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
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 PROTECTED]
---
-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 PROTECTED]
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.
Why
73 matches
Mail list logo
