Greg KH [EMAIL PROTECTED] writes:
We need our own namespace for these devices, and we have it today
already. Look if you enable CONFIG_SYSFS_DEPRECATED, or on a pre-2.6.19
machine at what shows up in the pci device directories:
-r--r--r-- 1 root root 4096 2007-02-18 13:06 vendor
Forgot the patch..
Angelo P. Castellani ha scritto:
From: Angelo P. Castellani [EMAIL PROTECTED]
RFC3742: limited slow start
See http://www.ietf.org/rfc/rfc3742.txt
Signed-off-by: Angelo P. Castellani [EMAIL PROTECTED]
---
To allow code reutilization I've added the limited slow start
From: Angelo P. Castellani [EMAIL PROTECTED]
YeAH-TCP is a sender-side high-speed enabled TCP congestion control
algorithm, which uses a mixed loss/delay approach to compute the
congestion window. It's design goals target high efficiency, internal,
RTT and Reno fairness, resilience to link
From: Angelo P. Castellani [EMAIL PROTECTED]
YeAH-TCP is a sender-side high-speed enabled TCP congestion control
algorithm, which uses a mixed loss/delay approach to compute the
congestion window. It's design goals target high efficiency, internal,
RTT and Reno fairness, resilience to link loss
The patch.
Angelo P. Castellani ha scritto:
From: Angelo P. Castellani [EMAIL PROTECTED]
YeAH-TCP is a sender-side high-speed enabled TCP congestion control
algorithm, which uses a mixed loss/delay approach to compute the
congestion window. It's design goals target high efficiency, internal,
Eric Dumazet [EMAIL PROTECTED] writes:
So are you speaking of one memory cache miss per lookup ?
Actually two: if the trie'ing allows RCUing you would save
the spinlock cache line too. This would increase the
break-even budget for the trie.
If not, you loose.
It all depends on if the
Michael K. Edwards [EMAIL PROTECTED] writes:
A better data structure for RCU, even with a fixed key space, is
probably a splay tree. Much less vulnerable to cache eviction DDoS
than a hash, because the hot connections get rotated up into non-leaf
layers and get traversed enough to keep them
FRTO spurious RTO detection algorithm (RFC4138) does not include response
to a detected spurious RTO but can use different response algorithms.
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
net/ipv4/tcp_input.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff
Hi,
Here is a set of patches that fix most of the flaws the current FRTO
implementation (specified in RFC4138) has, besides that, the last two
patches add SACK-enhanced FRTO (not enabled unless frto sysctl is set
to 2, which allows using of the basic version also with SACK). There
are some
FRTO was slightly too brave... Should only clear
TCPCB_SACKED_RETRANS bit.
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
net/ipv4/tcp_input.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 1a14191..b21e232 100644
Moved comments out from the body of process_frto() to the head
(preferred way; see Documentation/CodingStyle). Bonus: it's much
easier to read in this compacted form.
FRTO algorithm and implementation is described in greater detail.
For interested reader, more information is available in RFC4138.
In case a latency spike causes more than one RTO, the later should not
cause the already reduced ssthresh to propagate into the prior_ssthresh
since FRTO declares all such RTOs spurious at once or none of them. In
treating of ssthresh, we mimic what tcp_enter_loss() does.
The previous state (in
Retransmission counter assumptions are to be changed. Forcing
reason to do this exist: Using sysctl in check would be racy
as soon as FRTO starts to ignore some ACKs (doing that in the
following patches). Userspace may disable it at any moment
giving nice oops if timing is right. frto_counter
Handles RFC4138 shortcoming (in step 2); it should also have case
c) which ignores ACKs that are not duplicates nor advance window
(opposite dir data, winupdate).
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
net/ipv4/tcp_input.c | 13 ++---
1 files changed, 10 insertions(+), 3
FRTO controls cwnd when it still processes the ACK input or it
has just reverted back to conventional RTO recovery; the normal
rules apply when FRTO has reverted to standard congestion
control.
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
net/ipv4/tcp_input.c | 18 +++---
1
This interpretation comes from RFC4138:
If the sender implements some loss recovery algorithm other
than Reno or NewReno [FHG04], the F-RTO algorithm SHOULD
NOT be entered when earlier fast recovery is underway.
I think the RFC means to say (especially in the light of
Appendix B)
In addition, removed inline.
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
include/net/tcp.h| 14 +-
net/ipv4/tcp_input.c | 13 +
2 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 5c472f2..572a77b
The FRTO detection did not care how ACK pattern affects to cwnd
calculation of the conventional recovery. This caused incorrect
setting of cwnd when the fallback becames necessary. The
knowledge tcp_process_frto() has about the incoming ACK is now
passed on to tcp_enter_frto_loss() in
To be honest, I'm not too sure how the reord stuff works in the
first place but this seems necessary.
When FRTO has been active, the one and only retransmission could
be unnecessary but the state and sending order might not be what
the sacktag code expects it to be (to work correctly).
Implements the SACK-enhanced FRTO given in RFC4138 using the
variant given in Appendix B.
RFC4138, Appendix B:
This means that in order to declare timeout spurious, the TCP
sender must receive an acknowledgment for non-retransmitted
segment between SND.UNA and RecoveryPoint in algorithm
The description is overly verbose to avoid ambiguity between
SACK enabled and SACK enhanced FRTO
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
Documentation/networking/ip-sysctl.txt |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git
Previously RETRANS bits were cleared on the entry to FRTO. We
postpone that into tcp_enter_frto_loss, which is really the
place were the clearing should be done anyway. This allows
simplification of the logic from a clearing loop to the head skb
clearing only.
Besides, the other changes made in
TCP without FRTO would be in Loss state with small cwnd. FRTO,
however, leaves cwnd (typically) to a larger value which causes
ssthresh to become too large in case RTO is triggered again
compared to what conventional recovery would do. Because
consecutive RTOs result in only a single ssthresh
Because TCP is not in Loss state during FRTO recovery, fast
recovery could be triggered by accident. Non-SACK FRTO is more
robust than not yet included SACK-enhanced version (that can
receiver high number of duplicate ACKs with SACK blocks during
FRTO), at least with unidirectional transfers, but
Since purpose is to reduce CWND, we prevent immediate growth. This
is not a major issue nor is the correct way specified anywhere.
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
net/ipv4/tcp_input.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/tcp_input.c
On Sun, Feb 18, 2007 at 09:21:30PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
Evgeniy Polyakov a e'crit :
On Sun, Feb 18, 2007 at 07:46:22PM +0100, Eric Dumazet
([EMAIL PROTECTED]) wrote:
Why anyone do not want to use trie - for socket-like loads it has
exactly constant
On Fri, Feb 16, 2007 at 09:20:34PM +0100, Francois Romieu wrote:
Jarek Poplawski [EMAIL PROTECTED] :
...
@@ -1603,18 +1605,21 @@ static void rtl8139_thread (struct work_struct
*work)
struct net_device *dev = tp-mii.dev;
unsigned long thr_delay = next_tick;
+ rtnl_lock();
Andi Kleen writes:
If not, you loose.
It all depends on if the higher levels on the trie are small
enough to be kept in cache. Even with two cache misses it might
still break even, but have better scalability.
Yes the trick to keep root large to allow a very flat tree and few
On Monday 19 February 2007 12:41, Evgeniy Polyakov wrote:
1 microsecond ? Are you kidding ? We want no more than 50 ns.
Theory again.
Theory is nice, but I personally prefer oprofile :)
I base my comments on real facts.
We *want* 50 ns tcp lookups (2 cache line misses, one with reader
On Mon, Feb 19, 2007 at 02:38:13PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
On Monday 19 February 2007 12:41, Evgeniy Polyakov wrote:
1 microsecond ? Are you kidding ? We want no more than 50 ns.
Theory again.
Theory is nice, but I personally prefer oprofile :)
I base my
Actually for socket code any other binary tree will work perfectly ok -
socket code does not have wildcards (except listening sockets), so it is
possible to combine all values into one search key used in flat
one-dimensional tree - it scales as hell and allows still very high
lookup time.
As of
On Monday 19 February 2007 14:56, Evgeniy Polyakov wrote:
On Mon, Feb 19, 2007 at 02:38:13PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
On Monday 19 February 2007 12:41, Evgeniy Polyakov wrote:
1 microsecond ? Are you kidding ? We want no more than 50 ns.
Theory again.
Theory
On 17-02-2007 17:25, Evgeniy Polyakov wrote:
On Fri, Feb 16, 2007 at 09:34:27PM +0300, Evgeniy Polyakov ([EMAIL
PROTECTED]) wrote:
Otherwise we can extend select output mask to include hungup too
(getting into account that hungup is actually output event).
This is another possible way to
On Mon, Feb 19, 2007 at 03:14:02PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
Forget about cache misses and cache lines - we have a hash table, only
part of which is used (part for time-wait sockets, part for established
ones).
No you didnt not read my mail. Current ehash is not as
On Monday 19 February 2007 15:25, Evgeniy Polyakov wrote:
On Mon, Feb 19, 2007 at 03:14:02PM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
Forget about cache misses and cache lines - we have a hash table, only
part of which is used (part for time-wait sockets, part for established
On Fri, 2007-02-16 at 09:42 -0800, Joe Perches wrote:
Signed-off-by: Joe Perches [EMAIL PROTECTED]
Acked-By: Thomas Sailer [EMAIL PROTECTED]
Thanks a lot!
Tom
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info
On Monday 19 February 2007 16:14, Eric Dumazet wrote:
Because O(1) is different of O(log(N)) ?
if N = 2^20, it certainly makes a difference.
Yes, 1% of chains might have a length 10, but yet 99% of the lookups are
touching less than 4 cache lines.
With a binary tree, log(2^20) is 20. or
On Mon, Feb 19, 2007 at 07:13:07PM +0100, Eric Dumazet wrote:
So even with a lazy hash function, 89 % of lookups are satisfied with less
than 6 compares.
Which sucks, as those are typically going to be cache misses (costing many
hundreds of cpu cycles). Hash chains fair very poorly under DoS
On Mon, Feb 19, 2007 at 01:26:42PM -0500, Benjamin LaHaise wrote:
On Mon, Feb 19, 2007 at 07:13:07PM +0100, Eric Dumazet wrote:
So even with a lazy hash function, 89 % of lookups are satisfied with less
than 6 compares.
Which sucks, as those are typically going to be cache misses (costing
On 19 Feb 2007 13:04:12 +0100, Andi Kleen [EMAIL PROTECTED] wrote:
LRU tends to be hell for caches in MP systems, because it writes to
the cache lines too and makes them exclusive and more expensive.
That's why you let the hardware worry about LRU. You don't write to
the upper layers of the
On Fri, Feb 16, 2007 at 04:01:57PM -0500, Lennart Sorensen wrote:
eth1: netif_receive_skb(skb)
eth1: netif_receive_skb(skb)
eth1: pcnet32_poll: pcnet32_rx() got 16 packets
eth1: base: 0x05215812 status: 0310 next-status: 0310
eth1: netif_receive_skb(skb)
eth1: netif_receive_skb(skb)
eth1:
I'd prefer to make it apply automatically across all congestion controls
that do slow-start, and also make the max_ssthresh parameter
controllable via sysctl. This patch (attached) should implement this.
Note the default value for sysctl_tcp_max_ssthresh = 0, which disables
limited
On Thursday 08 February 2007 1:01 am, Zhu Yi wrote:
A generic requirement for dynamic power management is the hardware
resource should not be touched when you put it in a low power state.
That is in no way a generic requirement. It might apply specifically
to one ipw2100 low power state ...
Cc: list trimmed.
Jarek Poplawski [EMAIL PROTECTED] :
On Fri, Feb 16, 2007 at 09:20:34PM +0100, Francois Romieu wrote:
[...]
Btw, the thread runs every 3*HZ at most.
You are right (mostly)! But I think rtnl_lock is special
and should be spared (even this 3*HZ) and here it's used
for some
Evgeniy Polyakov [EMAIL PROTECTED] writes:
My experiment shows almost 400 nsecs without _any_ locks - they are
removed completely - it is pure hash selection/list traverse time.
Are you sure you're not measuring TLB misses too? In user space
you likely use 4K pages. The kernel would use 2MB
On Thu, Feb 15, 2007 at 03:45:23PM -0800, Jay Vosburgh wrote:
For the short term, yes, I don't have any disagreement with
switching the timer based stuff over to workqueues. Basically a one for
one replacement to get the functions in a process context and tweak the
locking.
I did
I go the following Oops with the latest wireless-dev git when starting
wpa_supplicant:
Feb 19 16:17:42 boss kernel: [ 377.359573] BUG: unable to handle kernel NULL
pointer dereference
at virtual address 0002
Feb 19 16:17:42 boss kernel: [ 377.359641] printing eip:
Feb 19 16:17:42 boss
On Mon, 2007-02-19 at 13:48 -0800, Alex Davis wrote:
I go the following Oops with the latest wireless-dev git when starting
wpa_supplicant:
Feb 19 16:17:42 boss kernel: [ 377.359573] BUG: unable to handle kernel NULL
pointer dereference
at virtual address 0002
Probably caused by my
On Mon, Feb 19, 2007 at 03:11:36PM -0500, Lennart Sorensen wrote:
I have been poking at things with firescope to see if the MAC is
actually writing to system memory or not.
The entry that it gets stuch on is _always_ entry 0 in the rx_ring.
There does not appear to be any exceptions to this.
On Mon, 2007-02-19 at 13:48 -0800, Alex Davis wrote:
I go the following Oops with the latest wireless-dev git when starting
wpa_supplicant:
Wireless topics moved from this list to [EMAIL PROTECTED]
Broadcom drivers are discussed in [EMAIL PROTECTED]
wireless-dev is horribly broken, and the
On Mon, Feb 19, 2007 at 05:18:45PM -0500, Lennart Sorensen wrote:
On Mon, Feb 19, 2007 at 03:11:36PM -0500, Lennart Sorensen wrote:
I have been poking at things with firescope to see if the MAC is
actually writing to system memory or not.
The entry that it gets stuch on is _always_ entry
On Mon, 2007-02-19 at 23:12 +0100, Johannes Berg wrote:
On Mon, 2007-02-19 at 13:48 -0800, Alex Davis wrote:
I go the following Oops with the latest wireless-dev git when starting
wpa_supplicant:
Feb 19 16:17:42 boss kernel: [ 377.359573] BUG: unable to handle kernel
NULL pointer
On Mon, 2007-02-19 at 17:30 -0500, Pavel Roskin wrote:
Johannes, would it be possible to commit patches faster, please? Now
that I told Michael about git-update-server-info, his changes are
downloadable as soon as he makes a commit. wireless-dev.git, on the
other hand, is a mess and has
Hi people,
I'm trying to save people the cost of buying extra servers by making
PowerDNS (GPL) ever faster, but I've hit a rather fundamental problem.
Linux 2.6.20-rc4 appears to take 4 microseconds on my P4 3GHz for a
non-blocking UDPv4 recvfrom() call, both on loopback and ethernet.
Linux
On Mon, Feb 19, 2007 at 05:29:20PM -0500, Lennart Sorensen wrote:
I just noticed, it seems almost all these problems occour right at the
start of transfers when the tcp window size is still being worked out
for the connection speed, and I am seeing the error count go up in
ifconfig for the
John Heffner ha scritto:
Note the patch is compile-tested only! I can do some real testing if
you'd like to apply this Dave.
The date you read on the patch is due to the fact I've splitted this
patchset into 2 diff files. This isn't compile-tested only, I've used
this piece of code for about
On Tue, 20 Feb 2007 00:14:47 +0100
bert hubert [EMAIL PROTECTED] wrote:
Hi people,
I'm trying to save people the cost of buying extra servers by making
PowerDNS (GPL) ever faster, but I've hit a rather fundamental problem.
Linux 2.6.20-rc4 appears to take 4 microseconds on my P4 3GHz for
On Mon, Feb 19, 2007 at 06:45:48PM -0500, Lennart Sorensen wrote:
It seems the problem actually occours when the receive descriptor ring
is full. This seems to generate one (or sometimes more) descriptors in
the ring which claim to be owned by the MAC, but at the head of the
receive ring as
On Mon, Feb 05, 2007 at 06:01:42PM -0800, David Miller wrote:
From: [EMAIL PROTECTED]
Date: Mon, 05 Feb 2007 16:30:53 -0800
From: Adrian Bunk [EMAIL PROTECTED]
Add proper prototypes for some functions in include/net/irda/irda.h
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
The napi poll routine was missing the call to the optimized rx process
routine. This patch adds the missing call for the optimized path.
Signed-Off-By: Ayaz Abdulla [EMAIL PROTECTED]
--- orig/drivers/net/forcedeth.c2007-02-19 09:13:10.0 -0500
+++ new/drivers/net/forcedeth.c
There seems to be an issue when both MSI-X is enabled and NAPI is
configured. This patch disables MSI-X until the issue is root caused.
Signed-Off-By: Ayaz Abdulla [EMAIL PROTECTED]
--- orig/drivers/net/forcedeth.c2007-02-19 09:17:02.0 -0500
+++ new/drivers/net/forcedeth.c
This patch removes checksum offload feature in mcp65 chipsets as they
are not supported in hw.
Signed-Off-By: Ayaz Abdulla [EMAIL PROTECTED]
--- orig/drivers/net/forcedeth.c2007-02-19 09:17:41.0 -0500
+++ new/drivers/net/forcedeth.c 2007-02-19 09:19:43.0 -0500
@@
Hey folks --
While digging through the atl1 source, I was troubled by the code using
irq_sem. I did some digging and found the same code in e1000 and ixgb. I'm
not entirely sure what it was originally intended to do, but it doesn't seem
to be doing anything useful now, except possibly
From: Chris Snook [EMAIL PROTECTED]
Remove unnecessary irq_sem code from atl1 driver. Tested with no problems.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
Signed-off-by: Jay Cliburn [EMAIL PROTECTED]
--
diff -urp linux-2.6.20-git14.orig/drivers/net/atl1/atl1.h
Chris Snook wrote:
Hey folks --
While digging through the atl1 source, I was troubled by the code using
irq_sem. I did some digging and found the same code in e1000 and ixgb. I'm
not entirely sure what it was originally intended to do, but it doesn't seem
to be doing anything useful now,
From: Chris Snook [EMAIL PROTECTED]
Remove unnecessary irq_sem accounting from e1000. Tested with no problems.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--
diff -urp linux-2.6.20-git14.orig/drivers/net/e1000/e1000.h
linux-2.6.20-git14/drivers/net/e1000/e1000.h
---
From: Chris Snook [EMAIL PROTECTED]
Remove irq_sem from ixgb. Currently untested, but similar to tested patches
on atl1 and e1000.
Signed-off-by: Chris Snook [EMAIL PROTECTED]
--
diff -urp linux-2.6.20-git14.orig/drivers/net/ixgb/ixgb.h
linux-2.6.20-git14/drivers/net/ixgb/ixgb.h
---
Hi,
More fix is needed for __xfrm6_bundle_create().
Signed-off-by: Noriaki TAKAMIYA [EMAIL PROTECTED]
Acked-by: Masahide NAKAMURA [EMAIL PROTECTED]
--
fixed to set fl_tunnel.fl6_src correctly in xfrm6_bundle_create().
---
Angelo P. Castellani wrote:
John Heffner ha scritto:
Note the patch is compile-tested only! I can do some real testing if
you'd like to apply this Dave.
The date you read on the patch is due to the fact I've splitted this
patchset into 2 diff files. This isn't compile-tested only, I've used
On Mon, 19 Feb 2007 15:55:19 -0800 [EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=8042
Summary: Cisco VPN Client cannot connect using TCP with Intel
82573L NIC
Kernel Version: 2.6.18.6
Status: NEW
Severity:
On Sun, Feb 11, 2007 at 04:57:55PM +0200, Matti Aarnio wrote:
With the skge driver there seems to be some sort of problem to work
in a system with memory above the 4 GB of PCI address space.
The chipset (apparently) doesn't deal with bus addresses over 4GB even
though the MAC does.
I guess
On Sat, Feb 17, 2007 at 11:11:13PM +0900, takada wrote:
is it mean what doesn't help with doesn't call set_cx86_reoder()?
this function disable to reorder at 0x4000: to 0x:.
does pcnet32 access at out of above range?
--- arch/i386/Kconfig.cpu~2007-02-05 03:44:54.0
Does anyone know if there is any way to flush a cache line of the cpu to
force rereading system memory for a given address or address range?
There is the clflush instruction, but not all x86 CPUs support it.
You need to check the CPUID flag to know for sure (/proc/cpuinfo will
show a clflush
On Mon, Feb 19, 2007 at 11:48:27AM -0800, Roland Dreier wrote:
Does anyone know if there is any way to flush a cache line of the cpu to
force rereading system memory for a given address or address range?
There is the clflush instruction, but not all x86 CPUs support it.
You need to check
These patches add support for the Aculab E1/T1 cPCI carrier card to the
natsemi driver. The first patch provides support for using the MII port
with no PHY and the second adds the quirks required to detect and
configure the card.
This revision should address the issues raised by Jeff over the
Aculab E1/T1 PMXc cPCI carrier card cards present a natsemi on the cPCI
bus with an oversized EEPROM using a direct MII-MII connection with no
PHY. This patch adds a new device table entry supporting these cards.
Signed-Off-By: Mark Brown [EMAIL PROTECTED]
---
This revision removes extra
This patch provides code paths which allow the natsemi driver to use the
external MII port on the chip but ignore any PHYs that may be attached to it.
The link state will be left as it was when the driver started and can be
configured via ethtool. Any PHYs that are present can be accessed via the
From: Roland Dreier [EMAIL PROTECTED]
Subject: Re: MediaGX/GeodeGX1 requires X86_OOSTORE.
Date: Mon, 19 Feb 2007 11:48:27 -0800
Does anyone know if there is any way to flush a cache line of the cpu to
force rereading system memory for a given address or address range?
There is the
On Tue, Nov 28, 2006 at 11:47:19PM -0800, Andrew Morton wrote:
On Wed, 29 Nov 2006 08:36:09 +0100
Adrian Bunk [EMAIL PROTECTED] wrote:
On Mon, Nov 27, 2006 at 10:24:55AM -0800, Stephen Hemminger wrote:
On Fri, 24 Nov 2006 01:17:31 +0100
Adrian Bunk [EMAIL PROTECTED] wrote:
On
On Tue, Feb 20, 2007 at 08:56:39AM +0900, takada wrote:
/proc/cpuinfo with MediaGXm :
processor : 0
vendor_id : CyrixInstead
cpu family: 5
model : 5
model name: Cyrix MediaGXtm MMXtm Enhanced
stepping : 2
cpu MHz : 199.750
cache size: 16 KB
This patch contains the following possible cleanups:
- make needlessly global functions static
- #if 0 the following unused global functions:
- zd_chip.c: zd_ioread16()
- zd_chip.c: zd_ioread32()
- zd_chip.c: zd_iowrite16()
- zd_chip.c: zd_ioread32v()
- zd_chip.c: zd_read_mac_addr()
-
On Thu, Feb 15, 2007 at 05:14:08AM -0800, Andrew Morton wrote:
...
Changes since 2.6.20-rc6-mm3:
...
+Fabric7-VIOC-driver.patch
...
netdev stuff
...
This patch contains the following possible cleanups:
- remove dead #ifdef EXPORT_SYMTAB code
- no inline functions in C files - gcc knows best
This patch moves the EXPORT_SYMBOL's from net/rxrpc/rxrpc_syms.c to the
files with the actual functions.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
This patch was already sent on:
- 26 Nov 2006
net/rxrpc/Makefile |1 -
net/rxrpc/call.c |5 +
net/rxrpc/connection.c
Ayaz Abdulla wrote:
For all those who are having issues, please try out the attached patch.
Ayaz
---
This email message is for the sole use of the intended recipient(s) and
may contain
confidential
Robert Hancock wrote:
Ayaz Abdulla wrote:
For all those who are having issues, please try out the attached patch.
Ayaz
---
This email message is for the sole use of the intended recipient(s)
and may
85 matches
Mail list logo
