Hi Jeff,
Now that Greg pushed my fix to expose pcie_get_readrq() prototype in
linux/pci.h, I am resending my rework of Peter Oruba's patch to use
pcie_get/set_readrq() in myri10ge. Please apply for 2.6.23.
1. use pcie_get/set_readrq
2. update driver version to 1.3.2-1.269
Also, we noticed
Based on a patch from Peter Oruba, convert myri10ge to use pcie_get_readrq()
and pcie_set_readrq() instead of our own PCI calls and arithmetics.
These driver changes incorporate the proposed PCI-X / PCI-Express read byte
count interface. Reading and setting those values doesn't take place
Update myri10ge driver version to 1.3.2-1.269.
Signed-off-by: Brice Goglin [EMAIL PROTECTED]
---
drivers/net/myri10ge/myri10ge.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.git/drivers/net/myri10ge/myri10ge.c
On Fri, Aug 24, 2007 at 01:08:25AM +0100, TJ wrote:
An RFC 793 standard TCP handshake requires three packets:
client SYN server LISTENING
client SYN ACK server SYN_RECEIVED
client ACK server ESTABLISHED
client PSH ACK + data server
TCP_DEFER_ACCEPT is designed to increase
On Aug 23, 2007, at 6:59 PM, Jesper Juhl wrote:
kmalloc() returns a void ptr, so there's no need to cast its return
value in drivers/net/gianfar.c .
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
Acked-by: Kumar Gala [EMAIL PROTECTED]
- k
-
To unsubscribe from this list: send the line
Stephen Hemminger wrote:
Forget earlier patch, it is wrong...
The stp change code generates sleeping function called from invalid context
because rtnl_lock() called with BH disabled. This fixes it by not acquiring then
dropping the bridge lock.
Signed-off-by: Stephen Hemminger [EMAIL
Hello!
At present with TCP_DEFER_ACCEPT the kernel treats the RFC 793 handshake
as invalid; dropping the ACK from the client without replying so the
client doesn't know the server has in fact set it's internal ACKed flag.
If the client doesn't send a packet containing data before the
Hi, all:
I encountered a problem of using sk_buff.
I used 2.4.20 kernel, when burst traffic come, the kernel will complain
a bug report at skbuff.c:316 later:
311 void __kfree_skb(struct sk_buff *skb)
312 {
313 if (skb-list) {
314 printk(KERN_WARNING Warning: kfree_skb passed an skb still
315
On Fri, 2007-08-24 at 12:40 +0400, Alexey Kuznetsov wrote:
There is no protocol violation here, ACK from client is considered as lost,
it is quite normal and happens all the time. Handshake is not complete,
server remains in SYN-RECV state and continues to retransmit SYN-ACK.
If client tried
This is minor fix about sizeof argument using with kmemdup().
Signed-off-by: Masahide NAKAMURA [EMAIL PROTECTED]
---
net/xfrm/xfrm_user.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index 0b8491f..46076f5 100644
---
When XFRM policy and state are ready after TCP connection is started,
the traffic should be transformed immediately, however it does not
on IPv6 TCP.
It depends on a dst cache replacement policy with connected socket.
It seems that the replacement is always done for IPv4, however, on
IPv6 case it
IPv6 IPsec tunnel gateway incorrectly sends redirect to
router or sender when network device the IPsec tunnelled packet
is arrived is the same as the one the decapsulated packet
is sent.
With this patch, it omits to send the redirect when the forwarding
skbuff carries secpath, since such skbuff
IPv4 IPsec tunnel gateway incorrectly sends redirect to
sender if it is onlink host when network device the IPsec tunnelled
packet is arrived is the same as the one the decapsulated packet
is sent.
With this patch, it omits to send the redirect when the forwarding
skbuff carries secpath, since
On 22-08-2007 20:08, Stephen Hemminger wrote:
There have been a lot of changes for 2.6.23, so here is a test release
of iproute2 that should capture all the submitted patches
http://developer.osdl.org/shemminger/iproute2/download/iproute2-2.6.23-rc3.tar.gz
But... isn't it forged, btw?!
In article [EMAIL PROTECTED] (at Thu, 23 Aug 2007 14:14:35 -0400), Brian
Haley [EMAIL PROTECTED] says:
YOSHIFUJI Hideaki / wrote:
Please put this just after ipv6_addr_any(), not after
ipv6_addr_diff().
Ok, updated patch attached.
-Brian
Add v4mapped address inline to avoid
* Masahide NAKAMURA [EMAIL PROTECTED] 2007-08-24 19:05
This is minor fix about sizeof argument using with kmemdup().
Thanks for catching this!
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Thursday 16 August 2007 01:39, Satyam Sharma wrote:
static inline void wait_for_init_deassert(atomic_t *deassert)
{
- while (!atomic_read(deassert));
+ while (!atomic_read(deassert))
+ cpu_relax();
return;
}
For less-than-briliant people like me, it's
On Thu, 2007-23-08 at 23:18 -0400, Bill Fink wrote:
[..]
Here you can see there is a major difference in the TX CPU utilization
(99 % with TSO disabled versus only 39 % with TSO enabled), although
the TSO disabled case was able to squeeze out a little extra performance
from its extra CPU
On Saturday 18 August 2007 05:13, Linus Torvalds wrote:
On Sat, 18 Aug 2007, Satyam Sharma wrote:
No code does (or would do, or should do):
x.counter++;
on an atomic_t x; anyway.
That's just an example of a general problem.
No, you don't use x.counter++. But you *do* use
On Thursday 16 August 2007 01:39, Satyam Sharma wrote:
static inline void wait_for_init_deassert(atomic_t *deassert)
{
- while (!atomic_read(deassert));
+ while (!atomic_read(deassert))
+ cpu_relax();
return;
}
For less-than-briliant people like me, it's
On Friday 24 August 2007 13:59:32 Denys Vlasenko wrote:
On Thursday 16 August 2007 01:39, Satyam Sharma wrote:
static inline void wait_for_init_deassert(atomic_t *deassert)
{
- while (!atomic_read(deassert));
+ while (!atomic_read(deassert))
+ cpu_relax();
On Thu, 2007-23-08 at 20:34 -0700, Stephen Hemminger wrote:
A current hot topic of research is reducing the number of ACK's to make TCP
work better over asymmetric links like 3G.
One other good reason to reduce ACKs to battery powered (3G) terminals
is it reduces the power consumption i.e you
On Thursday 16 August 2007 00:22, Paul Mackerras wrote:
Satyam Sharma writes:
In the kernel we use atomic variables in precisely those situations
where a variable is potentially accessed concurrently by multiple
CPUs, and where each CPU needs to see updates done by other CPUs in a
timely
Hi Denys,
On Fri, 24 Aug 2007, Denys Vlasenko wrote:
On Thursday 16 August 2007 01:39, Satyam Sharma wrote:
static inline void wait_for_init_deassert(atomic_t *deassert)
{
- while (!atomic_read(deassert));
+ while (!atomic_read(deassert))
+ cpu_relax();
On Friday 24 August 2007 13:12, Kenn Humborg wrote:
On Thursday 16 August 2007 01:39, Satyam Sharma wrote:
static inline void wait_for_init_deassert(atomic_t *deassert)
{
- while (!atomic_read(deassert));
+ while (!atomic_read(deassert))
+ cpu_relax();
return;
}
Hi,
when I tried to get the eHEA driver working with the new interface,
the following issues came up.
1) The current implementation of netif_rx_schedule, netif_rx_complete
and the net_rx_action have the following problem: netif_rx_schedule
sets the NAPI_STATE_SCHED flag and adds the NAPI
Hi,
On Friday 24 August 2007 17:37, [EMAIL PROTECTED] wrote:
On Fri, Aug 24, 2007 at 03:59:16PM +0200, Jan-Bernd Themann wrote:
...
3) On modern systems the incoming packets are processed very fast.
Especially
on SMP systems when we use multiple queues we process only a few
On Fri, 24 Aug 2007 17:47:15 +0200
Jan-Bernd Themann [EMAIL PROTECTED] wrote:
Hi,
On Friday 24 August 2007 17:37, [EMAIL PROTECTED] wrote:
On Fri, Aug 24, 2007 at 03:59:16PM +0200, Jan-Bernd Themann wrote:
...
3) On modern systems the incoming packets are processed very fast.
On Fri, 2007-08-24 at 02:03 +0200, Jesper Juhl wrote:
kmalloc() and friends return void*, no need to cast it.
Applied to libertas-2.6 'for-linville' branch, thanks.
Dan
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
drivers/net/wireless/libertas/debugfs.c |2 +-
[EMAIL PROTECTED] wrote:
From: Daniel Lezcano [EMAIL PROTECTED]
Doing this makes loopback.c a better example of how to do a
simple network device, and it removes the special case
single static allocation of a struct net_device, hopefully
making maintenance easier.
Applies against
On Fri, Aug 24, 2007 at 03:59:16PM +0200, Jan-Bernd Themann wrote:
...
3) On modern systems the incoming packets are processed very fast. Especially
on SMP systems when we use multiple queues we process only a few packets
per napi poll cycle. So NAPI does not work very well here and
From: Daniel Lezcano [EMAIL PROTECTED]
Doing this makes loopback.c a better example of how to do a
simple network device, and it removes the special case
single static allocation of a struct net_device, hopefully
making maintenance easier.
Applies against net-2.6.24
Tested on i386, x86_64
TJ wrote:
Right now Juniper are claiming the issue that brought this to the
surface (the bug linked to in my original post) is a problem with the
implementation of TCP_DEFER_ACCEPT.
My position so far is that the Juniper DX OS is not following the HTTP
standard because it doesn't send a request
static inline void wait_for_init_deassert(atomic_t *deassert)
{
-while (!atomic_read(deassert));
+while (!atomic_read(deassert))
+cpu_relax();
return;
}
For less-than-briliant people like me, it's totally non-obvious that
cpu_relax() is needed for correctness
On Fri, Aug 24, 2007 at 03:59:16PM +0200, Jan-Bernd Themann wrote:
3) On modern systems the incoming packets are processed very fast. Especially
on SMP systems when we use multiple queues we process only a few packets
per napi poll cycle. So NAPI does not work very well here and the
Denis V. Lunev wrote:
[EMAIL PROTECTED] wrote:
From: Daniel Lezcano [EMAIL PROTECTED]
Doing this makes loopback.c a better example of how to do a
simple network device, and it removes the special case
single static allocation of a struct net_device, hopefully
making maintenance easier.
Stephen Hemminger [EMAIL PROTECTED] wrote on 08/24/2007
08:52:03 AM:
You need hardware support for deferred interrupts. Most devices have it
(e1000, sky2, tg3)
and it interacts well with NAPI. It is not a generic thing you want done
by the stack,
you want the hardware to hold off
On Fri, Aug 24, 2007 at 08:52:03AM -0700, Stephen Hemminger wrote:
You need hardware support for deferred interrupts. Most devices have it
(e1000, sky2, tg3)
and it interacts well with NAPI. It is not a generic thing you want done by
the stack,
you want the hardware to hold off interrupts
A current hot topic of research is reducing the number of ACK's to make TCP
work better over asymmetric links like 3G.
Oy. People running Solaris and HP-UX have been researching ACK reductions
since 1997 if not earlier.
rick jones
-
To unsubscribe from this list: send the line unsubscribe
On Fri, 24 Aug 2007, Satyam Sharma wrote:
But if people do seem to have a mixed / confused notion of atomicity
and barriers, and if there's consensus, then as I'd said earlier, I
have no issues in going with the consensus (eg. having API variants).
Linus would be more difficult to convince,
Stephen Hemminger wrote:
On Fri, 24 Aug 2007 17:47:15 +0200
Jan-Bernd Themann [EMAIL PROTECTED] wrote:
Hi,
On Friday 24 August 2007 17:37, [EMAIL PROTECTED] wrote:
On Fri, Aug 24, 2007 at 03:59:16PM +0200, Jan-Bernd Themann wrote:
...
3) On modern systems the incoming packets are
On Fri, 24 Aug 2007, Denys Vlasenko wrote:
No, you don't use x.counter++. But you *do* use
if (atomic_read(x) = 1)
and loading into a register is stupid and pointless, when you could just
do it as a regular memory-operand to the cmp instruction.
It doesn't mean that (volatile
Just to be clear, in the previous email I posted on this thread, I
described a worst-case network ping-pong test case (send a packet, wait
for reply), and found out that a deffered interrupt scheme just damaged
the performance of the test case. Since the folks who came up with the
test case were
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
O
Subject : New wake ups from sky2
References : http://lkml.org/lkml/2007/7/20/386
Last known good : ?
Submitter : Thomas Meyer [EMAIL PROTECTED]
Caused-By : Stephen Hemminger [EMAIL PROTECTED]
commit eb35cf60e462491249166182e3e755d3d5d91a28
Just to be clear, in the previous email I posted on this thread, I
described a worst-case network ping-pong test case (send a packet, wait
for reply), and found out that a deffered interrupt scheme just damaged
the performance of the test case.
When splitting rx and tx handler, I found some
On Fri, 24 Aug 2007 19:55:47 +0400
Denis V. Lunev [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
From: Daniel Lezcano [EMAIL PROTECTED]
Doing this makes loopback.c a better example of how to do a
simple network device, and it removes the special case
single static allocation of a
On Fri, 24 Aug 2007, Denys Vlasenko wrote:
So you are ok with compiler propagating n1 to n2 here:
n1 += atomic_read(x);
other_variable++;
n2 += atomic_read(x);
without accessing x second time. What's the point? Any sane coder
will say that explicitly anyway:
No.
This is a common
The following driver API is broken on any architecture with 64 bit addresses.
because of cast that loses high bits.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- a/drivers/isdn/capi/capidrv.c 2007-06-25 09:03:12.0 -0700
+++ b/drivers/isdn/capi/capidrv.c 2007-08-24
On Fri, 24 Aug 2007, jamal wrote:
On Thu, 2007-23-08 at 23:18 -0400, Bill Fink wrote:
[..]
Here you can see there is a major difference in the TX CPU utilization
(99 % with TSO disabled versus only 39 % with TSO enabled), although
the TSO disabled case was able to squeeze out a little
James Chapman schrieb:
Stephen Hemminger wrote:
On Fri, 24 Aug 2007 17:47:15 +0200
Jan-Bernd Themann [EMAIL PROTECTED] wrote:
Hi,
On Friday 24 August 2007 17:37, [EMAIL PROTECTED] wrote:
On Fri, Aug 24, 2007 at 03:59:16PM +0200, Jan-Bernd Themann wrote:
...
3) On modern systems the
Bill Fink wrote:
On Thu, 23 Aug 2007, Rick Jones wrote:
jamal wrote:
[TSO already passed - iirc, it has been
demostranted to really not add much to throughput (cant improve much
over closeness to wire speed) but improve CPU utilization].
In the one gig space sure, but in the 10 Gig space,
Linas Vepstas [EMAIL PROTECTED] wrote:
On Fri, Aug 24, 2007 at 03:59:16PM +0200, Jan-Bernd Themann wrote:
3) On modern systems the incoming packets are processed very fast. Especially
on SMP systems when we use multiple queues we process only a few packets
per napi poll cycle. So NAPI does
On Fri, Aug 24, 2007 at 02:05:31PM +1000, Stephen Rothwell wrote:
On Thu, 23 Aug 2007 13:13:10 -0500 Olof Johansson [EMAIL PROTECTED] wrote:
out:
- pci_dev_put(mac-iob_pdev);
-out_put_dma_pdev:
- pci_dev_put(mac-dma_pdev);
-out_free_netdev:
+ if (mac-iob_pdev)
+
On Fri, 24 Aug 2007 12:10:44 +0200
Jarek Poplawski [EMAIL PROTECTED] wrote:
On 22-08-2007 20:08, Stephen Hemminger wrote:
There have been a lot of changes for 2.6.23, so here is a test release
of iproute2 that should capture all the submitted patches
On Friday 24 August 2007 18:15, Christoph Lameter wrote:
On Fri, 24 Aug 2007, Denys Vlasenko wrote:
On Thursday 16 August 2007 00:22, Paul Mackerras wrote:
Satyam Sharma writes:
In the kernel we use atomic variables in precisely those situations
where a variable is potentially accessed
On Friday 24 August 2007 18:06, Christoph Lameter wrote:
On Fri, 24 Aug 2007, Satyam Sharma wrote:
But if people do seem to have a mixed / confused notion of atomicity
and barriers, and if there's consensus, then as I'd said earlier, I
have no issues in going with the consensus (eg. having
Denys Vlasenko wrote:
On Friday 24 August 2007 18:06, Christoph Lameter wrote:
On Fri, 24 Aug 2007, Satyam Sharma wrote:
But if people do seem to have a mixed / confused notion of atomicity
and barriers, and if there's consensus, then as I'd said earlier, I
have no issues in going with the
On Fri, Aug 24, 2007 at 09:04:56PM +0200, Bodo Eggert wrote:
Linas Vepstas [EMAIL PROTECTED] wrote:
On Fri, Aug 24, 2007 at 03:59:16PM +0200, Jan-Bernd Themann wrote:
3) On modern systems the incoming packets are processed very fast.
Especially
on SMP systems when we use multiple queues
The follow patches series starts the process of moving function
pointers out of network device structure. This saves space and
separates code from data.
The first step is moving the functions dealing with hardware
headers.
Patches are against current net-2.6.24 tree. Basic functional
testing on
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-08-23 21:25:57.0 -0700
+++ b/include/linux/netdevice.h 2007-08-23 22:25:35.0 -0700
@@ -639,7 +639,7 @@
Add inline for common usage of hardware header creation, and
fix bug in IPV6 mcast where the assumption about negative return value
was wrong.
Negative return from hard_header means not enough space was available,
(ie -N bytes).
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
The via-velocity is using a non-standard VLAN interface configured
via module parameters (yuck).
Replace with the standard acceleration interface.
It solves a number of problems with being able to handle multiple
vlans, and dynamically reconfigure.
This is compile tested only, don't have this
Linas Vepstas schrieb:
On Fri, Aug 24, 2007 at 09:04:56PM +0200, Bodo Eggert wrote:
Linas Vepstas [EMAIL PROTECTED] wrote:
On Fri, Aug 24, 2007 at 03:59:16PM +0200, Jan-Bernd Themann wrote:
3) On modern systems the incoming packets are processed very fast. Especially
on SMP
On Fri, Aug 24, 2007 at 01:56:49PM -0700, Stephen Hemminger wrote:
static void velocity_init_cam_filter(struct velocity_info *vptr)
{
struct mac_regs __iomem * regs = vptr-mac_regs;
+ unsigned short vid;
- mac_set_cam(regs, 0, (u8 *) (vptr-options.vid),
no, and this is important. Loopback is initialized in fs_initcall which
is called sufficiently before module_init.
I have checked the code and do not see initialization order mistakes
right now. But, from now on, maintainer should pay attention for this
unfortunate consequence :(
Regards,
From: jamal [EMAIL PROTECTED]
Date: Fri, 24 Aug 2007 08:14:16 -0400
Seems the receive side of the sender is also consuming a lot more cpu
i suspect because receiver is generating a lot more ACKs with TSO.
I've seen this behavior before on a low cpu powered receiver and the
issue is that
From: Jan-Bernd Themann [EMAIL PROTECTED]
Date: Fri, 24 Aug 2007 15:59:16 +0200
It would be nice if it is possible to schedule queues to other CPU's, or
at least to use interrupts to put the queue to another cpu (not nice for
as you never know which one you will hit).
I'm not
On Fri, Aug 24, 2007 at 11:11:56PM +0200, Jan-Bernd Themann wrote:
(when they are available for
POWER in our case).
hrtimer worked fine on the powerpc cell arch last summer.
I assume they work on p5 and p6 too, no ??
I tried to implement something with normal timers, but the result
was
From: Jan-Bernd Themann [EMAIL PROTECTED]
Date: Fri, 24 Aug 2007 15:59:16 +0200
1) The current implementation of netif_rx_schedule, netif_rx_complete
and the net_rx_action have the following problem: netif_rx_schedule
sets the NAPI_STATE_SCHED flag and adds the NAPI instance to the
Per Al's suggestion, get rid of the stupid stuff:
Remove cam_type switch,
And deinline things that aren't important for speed.
And make big macro and inline.
And remove some dead/unused code.
And use const char * for chip name.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
From: [EMAIL PROTECTED] (Linas Vepstas)
Date: Fri, 24 Aug 2007 11:45:41 -0500
In the end, I just let it be, and let the system work as a
busy-beaver, with the high interrupt rate. Is this a wise thing to
do?
The tradeoff is always going to be latency vs. throughput.
A sane default should
From: David Stevens [EMAIL PROTECTED]
Date: Fri, 24 Aug 2007 09:50:58 -0700
Problem is if it increases rapidly, you may drop packets
before you notice that the ring is full in the current estimated
interval.
This is one of many reasons why hardware interrupt mitigation
is really
From: James Chapman [EMAIL PROTECTED]
Date: Fri, 24 Aug 2007 18:16:45 +0100
Does hardware interrupt mitigation really interact well with NAPI?
It interacts quite excellently.
There was a long saga about this with tg3 and huge SGI numa
systems with large costs for interrupt processing, and the
On Fri, Aug 24, 2007 at 02:44:36PM -0700, David Miller wrote:
From: David Stevens [EMAIL PROTECTED]
Date: Fri, 24 Aug 2007 09:50:58 -0700
Problem is if it increases rapidly, you may drop packets
before you notice that the ring is full in the current estimated
interval.
This is
On Fri, Aug 24, 2007 at 02:47:11PM -0700, David Miller wrote:
Someone should reference that thread _now_ before this discussion goes
too far and we repeat a lot of information ..
Here's part of the thread:
http://marc.info/?t=11159530601r=1w=2
Also, Jamal's paper may be of
On Fri, Aug 24, 2007 at 02:25:03PM -0700, David Miller wrote:
My hunch is that even if in the non-TSO case the TX packets were all
back to back in the cards TX ring, TSO still spits them out faster on
the wire.
If this is the case then we should see an improvement by
disabling TSO and
On Fri, Aug 24, 2007 at 02:40:45PM -0700, Stephen Hemminger wrote:
+static void mac_set_vlan_cam(struct mac_regs __iomem * regs, int idx,
+ const u8 *addr)
ITYM const u16 *, if not an outright u16. These casts (one below and
ones in callers) really should die.
+
On Fri, 24 Aug 2007 13:11:04 -0500 Olof Johansson [EMAIL PROTECTED] wrote:
On Fri, Aug 24, 2007 at 02:05:31PM +1000, Stephen Rothwell wrote:
It is not documented as such (as far as I can see), but pci_dev_put is
safe to call with NULL. And there are other places in the kernel that
Divy Le Ray wrote:
From: Divy Le Ray [EMAIL PROTECTED]
cxgb3 used netdev_priv() and dev-priv for different purposes.
In 2.6.23, netdev_priv() == dev-priv, cxgb3 needs a fix.
This patch is a partial backport of Dave Miller's changes in the
net-2.6.24 git branch.
Without this fix, cxgb3
Laurent Pinchart wrote:
This patch splits the receive status in 8bit wide fields and convert the
packet length from little endian to CPU byte order.
Signed-off-by: Laurent Pinchart [EMAIL PROTECTED]
---
drivers/net/dm9000.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
Jan-Bernd Themann wrote:
Introduces a module parameter to decide whether the physical
port link state is propagated to the network stack or not.
It makes sense not to take the physical port state into account
on machines with more logical partitions that communicate
with each other. This is
Kumar Gala wrote:
The ucc_geth_mii code is based on the gianfar_mii code that use to include
ocp.h. ucc never need this and it causes issues when we want to kill
arch/ppc includes from arch/powerpc.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
Jeff, if you issue with this for 2.6.23, I'd
Florian Westphal wrote:
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
Ralf Baechle wrote:
IP32 doesn't even have a ZONE_DMA so no point in using GFP_DMA in any
IP32-specific device driver.
Signed-off-by: Ralf Baechle [EMAIL PROTECTED]
applied
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More
Jan-Bernd Themann wrote:
Userspace DLPAR tool expects decimal numbers to be written to
and read from sysfs entries.
Signed-off-by: Jan-Bernd Themann [EMAIL PROTECTED]
applied 1-3
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
Brice Goglin wrote:
Based on a patch from Peter Oruba, convert myri10ge to use pcie_get_readrq()
and pcie_set_readrq() instead of our own PCI calls and arithmetics.
These driver changes incorporate the proposed PCI-X / PCI-Express read byte
count interface. Reading and setting those values
From: Flavio Leitner [EMAIL PROTECTED]
Date: Tue, 31 Jul 2007 15:29:40 -0300
On Tue, Jul 31, 2007 at 12:00:41AM -0300, Arnaldo Carvalho de Melo wrote:
On 7/30/07, David Miller [EMAIL PROTECTED] wrote:
Allowing non-datagram sockets to end up with a non-NULL inet-mc_list
in the first place
From: vignesh babu [EMAIL PROTECTED]
Date: Mon, 13 Aug 2007 18:33:47 +0530
Replacing n (n - 1) for power of 2 check by is_power_of_2(n)
Signed-off-by: vignesh babu [EMAIL PROTECTED]
Patch applied, thanks.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Fri, 17 Aug 2007 16:29:50 -0700
The ethernet header management only needs to handle a fixed
size address (6 bytes). If the memcpy/memset are changed to
be passed a constant length, then compiler can optimize for
this case (and if it is smart
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Fri, 17 Aug 2007 18:31:31 -0700
Get rid of using DPRINTK macro in ATM and use pr_debug (in kernel.h).
Using the standard macro is cleaner and forces code to check for bad arguments
and formatting.
Signed-off-by: Stephen Hemminger [EMAIL
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Fri, 17 Aug 2007 18:53:11 -0700
Run the 802 related protocols through Lindent (and hand cleanup)
to fix indentation and whitespace style issues.
Applied to net-2.6.24, thanks.
-
To unsubscribe from this list: send the line unsubscribe netdev in
From: David Miller [EMAIL PROTECTED]
Date: Fri, 24 Aug 2007 22:39:40 -0700 (PDT)
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Fri, 17 Aug 2007 18:53:11 -0700
Run the 802 related protocols through Lindent (and hand cleanup)
to fix indentation and whitespace style issues.
Applied to
From: Ilpo_Järvinen [EMAIL PROTECTED]
Date: Mon, 20 Aug 2007 16:16:29 +0300
Makes caller side more obvious, there's no need to have
a wrapper for this oneliner!
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
Applied, thanks.
-
To unsubscribe from this list: send the line unsubscribe netdev
From: Ilpo_Järvinen [EMAIL PROTECTED]
Date: Mon, 20 Aug 2007 16:16:30 +0300
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
Applied.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
From: Ilpo_Järvinen [EMAIL PROTECTED]
Date: Mon, 20 Aug 2007 16:16:31 +0300
Only thing that tiny function does is rearming the RTO (if
necessary), name it accordingly.
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
Applied, thanks.
-
To unsubscribe from this list: send the line unsubscribe
From: Ilpo_Järvinen [EMAIL PROTECTED]
Date: Mon, 20 Aug 2007 16:16:32 +0300
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
From: Ilpo_Järvinen [EMAIL PROTECTED]
Date: Mon, 20 Aug 2007 16:16:33 +0300
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
From: Andrew Morton [EMAIL PROTECTED]
Date: Tue, 21 Aug 2007 01:30:57 -0700
ERROR: slhc_init [drivers/net/ppp_generic.ko] undefined!
ERROR: slhc_free [drivers/net/ppp_generic.ko] undefined!
ERROR: slhc_uncompress [drivers/net/ppp_generic.ko] undefined!
ERROR: slhc_compress
100 matches
Mail list logo
