(apologies for the repost, I thought people may have missed this
question since it was not phrased as such)
I have a hw network device that can benefit from knowing what its
associated IP addresses (if any) are... Is there a correct way to
determine the IP address(es) from within the driver
On Thu, Apr 26, 2007 at 02:11:33PM -0700, Andrew Morton wrote:
I have this floating about in my tree. Is it of any interest?
From: Jarek Poplawski [EMAIL PROTECTED]
I know you've more interesting problems, but I'd like to
straighten something: this is not my patch!
Please, change this
On Tue, 17 Apr 2007 20:14:36 +0900
Mitsuru Chinen [EMAIL PROTECTED] wrote:
This displays the statistics specified in the updated IP-MIB RFC
(RFC4293) at /proc/net/snmp. As new statistics are placed as the
last elements, this change wouldn't affect netstat, net-snmp, etc.
I'm sorry. I found
On Thu, 26 Apr 2007 20:54:36 +0100, David Howells wrote:
Provide AF_RXRPC sockets that can be used to talk to AFS servers, or serve
answers to AFS clients. KerberosIV security is fully supported. The patches
and some example test programs can be found in:
This patch is to support network adapter on pxa3xx-based boards
Signed-off-by: dmitry pervushin [EMAIL PROTECTED]
KernelVersion: 2.6.21
Index: linux-2.6.21/drivers/net/smc91x.h
===
--- linux-2.6.21.orig/drivers/net/smc91x.h
+++
From: Chuck Ebbert [EMAIL PROTECTED]
Date: Thu, 26 Apr 2007 18:57:06 -0400
David Miller wrote:
+ case IPV6_SRCRT_TYPE_2:
+ if (accept_source_route = 0)
+ break;
+ kfree_skb(skb);
+ return -1;
+ case
On Fri, Apr 27, 2007 at 12:52:08PM +0400, dmitry pervushin wrote:
+#elif defined(CONFIG_PXA3xx)
+#define SMC_CAN_USE_8BIT 1
+#define SMC_CAN_USE_16BIT1
+#define SMC_CAN_USE_32BIT0
+#define SMC_IO_SHIFT 0
+#define SMC_NOWAIT 1
+#define SMC_USE_PXA_DMA
In article [EMAIL PROTECTED] (at Fri, 27 Apr 2007 02:08:05 -0700 (PDT)),
David Miller [EMAIL PROTECTED] says:
then the function proceeds to use the largest of
'accept_source_route' and 'idev-cnf.accept_source_route'
for further checks.
Smallest:
if (accept_source_route
From: YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED]
Date: Fri, 27 Apr 2007 18:36:35 +0900 (JST)
In article [EMAIL PROTECTED] (at Fri, 27 Apr 2007 02:08:05 -0700 (PDT)),
David Miller [EMAIL PROTECTED] says:
then the function proceeds to use the largest of
'accept_source_route' and
[TCP]: Update references in two old comments
This updates references to drafts in comments which must be about 10
years old. Internet draft draft-ietf-tcpimpl-prob-03.txt expired in 1998
and was replaced by RFC 2525 in March 1999.
Section 3.10 of the draft maps almost identically into section
Hello Jeff,
the patch below fixes compilation breakage of smc911x driver when
ENABLE_SMC_DEBUG_PKTS equals to 1.
smc911x.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Signed-off-by: Vitaly Wool [EMAIL PROTECTED]
Index: linux-2.6/drivers/net/smc911x.c
Hi Jeff,
currently (with 2.6.21) compilation of smc911x driver fails in the following
way:
CC drivers/net/smc911x.o
/sandbox/vital/opensource/linux-2.6/drivers/net/smc911x.c: In function
`smc911x_probe':
/sandbox/vital/opensource/linux-2.6/drivers/net/smc911x.c:2125: warning:
implicit
Hi Jon,
Jon Paul Maloy schrieb:
Ingo Oeser wrote:
static inlinevoid msg_set_bits(struct tipc_msg *m, u32 w,
u32 pos, __be32 mask, __be32 val)
Care to resubmit?
I don't mind at all, but I would first like to understand better
what this means.
If I
David Miller [EMAIL PROTECTED] wrote:
Ok, I applied it all and added a compiler warning fix for 64-bit
at the end.
What compiler and arch is that with?
Acked-By: David Howells [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to
Sparse annotations, including two minor bugfixes.
Signed-off-by: Krzysztof Halasa [EMAIL PROTECTED]
diff --git a/drivers/net/wan/hdlc_cisco.c b/drivers/net/wan/hdlc_cisco.c
index c9664fd..a7a12d6 100644
--- a/drivers/net/wan/hdlc_cisco.c
+++ b/drivers/net/wan/hdlc_cisco.c
@@ -37,16 +37,16 @@
David Miller [EMAIL PROTECTED] wrote:
I'm fixing this as follows, if you want this debugging code
back do it properly, thanks.
Fine by me.
Acked-By: David Howells [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
David Miller [EMAIL PROTECTED] wrote:
net/rxrpc/ar-input.c:171: warning: passing argument 2 of
$,1rx(B__test_and_set_bit$,1ry(B from incompatible pointer type
net/rxrpc/ar-input.c:180: warning: passing argument 2 of
$,1rx(B__clear_bit$,1ry(B from incompatible pointer type
Here's the SPD version against net-2.6.
cheers,
jamal
[XFRM] Export SPD info
With this patch you can use iproute2 in user space to efficiently
see how many policies exist in different directions.
Signed-off-by: Jamal Hadi Salim [EMAIL PROTECTED]
---
commit
jamal wrote:
+static int build_spdinfo(struct sk_buff *skb, u32 pid, u32 seq, u32 flags)
+{
+ struct xfrm_spdinfo si;
+ struct nlmsghdr *nlh;
+ u32 *f;
+
+ nlh = nlmsg_put(skb, pid, seq, XFRM_MSG_NEWSPDINFO, sizeof(u32), 0);
+ if (nlh == NULL) /* shouldnt really happen
On Thu, 2007-26-04 at 14:18 -0700, David Miller wrote:
I wouldn't mind if it actually helped anything.
The SMP cache line transactions are more expensive than the
execution of the code blocks they are protecting. rwlock's
rarely help, and when they do (the execution path is more
expensive
David Miller [EMAIL PROTECTED] wrote:
Here is how I'm fixing this for now to get the tree into
a buildable state.
Okay, that looks mostly reasonable, but it needs to go a little bit further.
If you have a better fix, please send it to me relative
to what's in net-2.6, thanks.
I'm about to
On Fri, 2007-27-04 at 15:55 +0200, Patrick McHardy wrote:
It it really worth the extra code for dumping them conditionally?
The attributes are neither large nor will they be sent very often.
That thought did cross my mind when i was coding this;- I hate the way
netlink filters are done in
Fix miscellaneous networking compilation errors.
(*) Export ktime_add_ns() for modules.
(*) wext_proc_init() should have an ANSI declaration.
Signed-Off-By: David Howells [EMAIL PROTECTED]
---
include/net/wext.h |2 +-
kernel/hrtimer.c |2 ++
2 files changed, 3 insertions(+), 1
On Thu, 2007-26-04 at 17:57 +0200, Patrick McHardy wrote:
The reason for suggesting to add a TC option was that these patches
move (parts of) the scheduling policy into the driver since it can
start and stop individual subqueues, which in turn cause single
bands of prio not to be dequeued
On Fri, 27 Apr 2007, Bill Fink wrote:
On Thu, 26 Apr 2007, Ilpo Järvinen wrote:
On Thu, 26 Apr 2007, Chuck Ebbert wrote:
Ilpo Järvinen wrote:
...I'm unsure how to continue the investigation from this point onward
and asking for ideas/suggestions or how to rule out more
On Thu, 2007-26-04 at 09:30 -0700, Waskiewicz Jr, Peter P wrote:
jamal wrote:
On Wed, 2007-25-04 at 10:45 -0700, Waskiewicz Jr, Peter P wrote:
We have plans to write a new qdisc that has no priority given to any
skb's being sent to the driver. The reasoning for providing a
multiqueue
jamal wrote:
Heres the way i see it from a user perspective:
If a NIC has 3 hardware queues; if that NIC supports strict
priority
(i.e the prio qdisc) which we already support, there should
be no need
for the user to really explicitly enable that support.
It should be transparent
YOSHIFUJI Hideaki / [EMAIL PROTECTED] wrote:
Hello.
I heard that there is a plan to remove eepro100 driver from kernel,
but from the IPv6 point of view, there are still some issues with
e100 driver, which does not exist in eepro100.
We are using some e100/eepro100 devices, and we have found
Roland Dreier wrote:
Update required firmware revision to 4.0.0.
Hmm... should we fold this into the earlier patch, which actually
needs this new FW? Or at least merge this patch first?
Also, is it cool with everyone to require a new FW, even for users who
might not be using (or even
Please pull from 'e1000-fixes' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git e1000-fixes
to receive the following updates:
drivers/net/e1000/e1000_main.c | 104 ++--
1 files changed, 58 insertions(+), 46 deletions(-)
Auke Kok
On Fri, 27 Apr 2007 11:33:18 +0200
Csillag Kristof [EMAIL PROTECTED] wrote:
Hi all!
I have encountered a strange error, and I believe that
the culprit might be the sky2 driver, so I hope you can help.
The symptom is that sometimes the connection between my server box
(which is based on a
That patch I sent was against 2.6.21, but both 2.6.20 and 2.6.21 have
the problem. Here is a version for 2.6.20.
=
When network device's are renamed, the IPV6 snmp6 code
gets confused. It doesn't track name changes so it will OOPS
when network device's
The subsystem rwsem is not used by the driver core at all, so the use of
it in the phy code doesn't make any sense. They might possibly
want to use a local lock, but I am unsure about that.
Cc: netdev netdev@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
---
On Thu, Apr 26, 2007 at 09:19:34AM -0700, H. Peter Anvin wrote:
Why wouldn't that be permitted? It, in fact, happens all the time (the
host bridge withdraws the GNT# line and raises STOP#, which does a
Termination With Data of the bus transfer.) This is a normal event and
if you can't handle
On Thu, Apr 26, 2007 at 10:53:04AM -0400, Ayaz Abdulla wrote:
Ok. In that case, the patch needs to be improved.
The following needs to be done when NAPI is enabled:
- remove the tx handling within the ISRs
- mask off the tx interrupts within the ISRs that handle tx processing
- re-enable tx
On Fri, 27 Apr 2007 11:25:46 +0200 VE \(HOME\) [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
On Thu, 26 Apr 2007 20:58:32 +0200 Vincent ETIENNE [EMAIL PROTECTED]
wrote:
This was due to locking bustage in the net tree. It should be fixed
in 2.6.21-rc7-mm2.
I have tried this
CONFIG_NETPOLL_TRAP causes the TX queue controls to be completely bypassed in
the netpoll's trapped mode which easily causes overflows in the drivers with
short TX queues (most notably, in 8139too with its 4-deep queue).
Make this option more sensible by only bypassing TX softirq wakeup and remove
Bryan Lawver wrote:
Your right about the ipoib module not combining packets (I believed you
without checking) but I did never the less. The ipoib_start_xmit
routine is definitely handed a double packet which means that the IP
NIC driver or the kernel is combining two packets into a single
On Fri, Apr 27, 2007 at 11:44:00PM +0400, Sergei Shtylyov wrote:
CONFIG_NETPOLL_TRAP causes the TX queue controls to be completely bypassed in
the netpoll's trapped mode which easily causes overflows in the drivers with
short TX queues (most notably, in 8139too with its 4-deep queue).
Make
From: Milind Arun Choudhary [EMAIL PROTECTED]
E1000_ROUNDUP macro cleanup, use ALIGN
Signed-off-by: Milind Arun Choudhary [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000.h |3 ---
drivers/net/e1000/e1000_ethtool.c |6 +++---
From: Milind Arun Choudhary [EMAIL PROTECTED]
IXGB_ROUNDUP macro cleanup ,use ALIGN
Signed-off-by: Milind Arun Choudhary [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/ixgb/ixgb.h |3 ---
drivers/net/ixgb/ixgb_ethtool.c |4 ++--
See:
http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.21-rc7/
Please Cc: netdev on success/failure.
Applied suggested patchset to vanilla 2.6.21.
Compiled using .config from linux-image-2.6.21-rc7 pulled down from
http://kernel-archive.buildserver.net/debian-kernel
Compiles, boots.
Bonding
On Apr 27, 2007, at 13:53, Greg Kroah-Hartman wrote:
The subsystem rwsem is not used by the driver core at all, so the
use of
it in the phy code doesn't make any sense. They might possibly
want to use a local lock, but I am unsure about that.
Cc: netdev netdev@vger.kernel.org
Tim Durack [EMAIL PROTECTED] wrote:
[...]
Bond comes up, cannot ping unless I manually force promisc on both member
links:
ip link set dev eth1 promisc on
ip link set dev eth2 promisc off
From looking at the source code for r8169, but it appears that
the r8169 driver only reads the
ip link set dev eth1 promisc on
ip link set dev eth2 promisc off
typo, ip link set dev eth2 promisc on of course
From looking at the source code for r8169, but it appears that
the r8169 driver only reads the device MAC address at probe time, and
doesn't propogate changes to the MAC
Tim Durack [EMAIL PROTECTED] :
[...]
Link failover does not work reliably. Carrier-detect appears to be
working, so I don't think that is an issue.
A disturbing problem is mac corruption after modprobe -r r8169; modprobe
r8169
ip link sh:
2: eth5: BROADCAST,MULTICAST mtu 1500 qdisc
From: David Howells [EMAIL PROTECTED]
Date: Fri, 27 Apr 2007 15:31:35 +0100
Fix the wakeup transitions after a VLocation record update completes one way
or another. This builds on Dave Miller's partial fix.
Also move wakeups outside the spinlocked sections.
Applied, thanks David, although
From: David Howells [EMAIL PROTECTED]
Date: Fri, 27 Apr 2007 15:31:40 +0100
Fixes for various arch compilation problems:
(*) Missing module exports.
(*) Variable name collision when rxkad and af_rxrpc both built in
(rxrpc_debug).
(*) Large constant representation problem
From: David Howells [EMAIL PROTECTED]
Date: Fri, 27 Apr 2007 15:31:45 +0100
Fix miscellaneous networking compilation errors.
(*) Export ktime_add_ns() for modules.
(*) wext_proc_init() should have an ANSI declaration.
Signed-Off-By: David Howells [EMAIL PROTECTED]
Also applied,
Bryan Lawver wrote:
I hit the IP NIC over the head with a hammer and turned off all offload
features and I no longer get the super jumbo packet and I have symmetric
performance. This NIC supported ethtool -K ethx tso/tx/rx/sg on/off
and I am not sure at this time which one I needed to whack
On Fri, 27 Apr 2007 22:05:28 +0200
Vincent ETIENNE [EMAIL PROTECTED] wrote:
Le Friday 27 April 2007 21:20:39, vous avez __crit__:
On Fri, 27 Apr 2007 11:25:46 +0200 VE \(HOME\) [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
On Thu, 26 Apr 2007 20:58:32 +0200 Vincent ETIENNE [EMAIL
I hit the IP NIC over the head with a hammer and turned off all offload
features and I no longer get the super jumbo packet and I have symmetric
performance. This NIC supported ethtool -K ethx tso/tx/rx/sg on/off and
I am not sure at this time which one I needed to whack but all off solved
I had so much debugging turned on that it was not the slowing of the
traffic but the non-coelescencing that was the remedy. The NIC is a
MyriCom NIC and these are easy options to set.
At 03:32 PM 4/27/2007, Rick Jones wrote:
Bryan Lawver wrote:
I hit the IP NIC over the head with a hammer
Francois Romieu [EMAIL PROTECTED] :
[...]
A tcpdump trace 1) before promiscuous mode 2) after promiscuous mode 3)
after link failure (i.e. failover does not work) would be welcome.
A 'lspci -vx' will be needed too. There are different kinds of 8169.
--
Ueimor
Anybody got a battery for my
,On Fri, 27 Apr 2007 16:01:04 -0700
[EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=8382
Summary: 2.6.20 cannot route packets outside tunnel
Kernel Version: 2.6.20.9
Status: NEW
Severity: high
Owner: [EMAIL PROTECTED]
Toralf Förster [EMAIL PROTECTED] wrote:
net/rxrpc/rxkad.o:(.bss+0x0): multiple definition of `rxrpc_debug'
net/rxrpc/af-rxrpc.o:(.bss+0x10): first defined here
I've submitted a patch that fixes that already.
Subject: [PATCH 2/3] AF_RXRPC/AFS: Arch-specific fixes
Though DaveM isn't
Bryan Lawver wrote:
I had so much debugging turned on that it was not the slowing of the
traffic but the non-coelescencing that was the remedy. The NIC is a
MyriCom NIC and these are easy options to set.
As chance would have it, I've played with some Myricom myri10ge NICs recently,
and even
From: Rick Jones [EMAIL PROTECTED]
Date: Fri, 27 Apr 2007 16:37:49 -0700
Large Receive Offload (LRO) is enabled by default. This will
interfere with forwarding TCP traffic. If you plan to forward TCP
traffic (using the host with the Myri10GE NIC as a router or bridge),
you must disable LRO.
David Miller wrote:
From: Rick Jones [EMAIL PROTECTED]
Date: Fri, 27 Apr 2007 16:37:49 -0700
Large Receive Offload (LRO) is enabled by default. This will
interfere with forwarding TCP traffic. If you plan to forward TCP
traffic (using the host with the Myri10GE NIC as a router or bridge),
From: Rick Jones [EMAIL PROTECTED]
Date: Fri, 27 Apr 2007 16:48:00 -0700
No problem - just to play whatif/devil's advocate for a bit
though... is there any way to tie that in with the setting of
net.ipv4.ip_forward (and/or its IPv6 counterpart)?
Even ignoring that, consider the potential
[EMAIL PROTECTED] wrote:
From: Ingo Molnar [EMAIL PROTECTED]
Another forcedeth.c thing: i noticed that its NAPI handler does not do
tx-ring processing. The patch below implements this - tested on DESC_VER_2
hardware, with CONFIG_FORCEDETH_NAPI=y.
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Mithlesh Thukral wrote:
NetXen: Make driver use multiple PCI functions.
This patch will make NetXen driver work with multiple PCI functions. This will
make the usage of memory resources as well as interrupts more independent
among different functions which results in better throughput. This
[EMAIL PROTECTED] wrote:
From: Robert P. J. Day [EMAIL PROTECTED]
Remove the apparently redundant include of linux/pm_legacy.h.
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/3c509.c |1 -
1 file changed, 1 deletion(-)
Thomas Klein wrote:
Create symbolic link from each logical port to ehea driver
Signed-off-by: Thomas Klein [EMAIL PROTECTED]
---
This patch applies on top of the netdev upstream branch for 2.6.22
applied 1-2
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of
Neil Horman wrote:
On Tue, Apr 24, 2007 at 12:43:20PM -0400, Jeff Garzik wrote:
Neil Horman wrote:
Hey there-
The sis900 driver appears to have a bug in which the receive routine
passes the skbuff holding the received frame to the network stack before
refilling the buffer in the rx
Dan Williams wrote:
Simplify pegasus carrier detection; rely only on the periodic MII
polling. Reverts pieces of c43c49bd61fdb9bb085ddafcaadb17d06f95ec43.
Signed-off-by: Dan Williams [EMAIL PROTECTED]
--- a/drivers/usb/net/pegasus.h 2007-04-25 21:21:00.0 -0400
+++
On Fri, 27 Apr 2007 20:10:54 -0400
Jeff Garzik [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
From: Ingo Molnar [EMAIL PROTECTED]
Another forcedeth.c thing: i noticed that its NAPI handler does not do
tx-ring processing. The patch below implements this - tested on DESC_VER_2
[EMAIL PROTECTED] wrote:
From: Mark Mason [EMAIL PROTECTED]
Patch to add NAPI support to sb1250-mac.c (rev 2). This patch differs from
the last in that the NAPI support isn't marked as experimental, nor is it
configurable (ie. once applied - NAPI is enabled all the time). This was
based on
Krzysztof Halasa wrote:
Sparse annotations, including two minor bugfixes.
Signed-off-by: Krzysztof Halasa [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
Auke Kok wrote:
From: Milind Arun Choudhary [EMAIL PROTECTED]
E1000_ROUNDUP macro cleanup, use ALIGN
Signed-off-by: Milind Arun Choudhary [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000.h |3 ---
drivers/net/e1000/e1000_ethtool.c |6
As mentioned previously, the big batch queued for 2.6.22 is coming
after the dust settles.
[EMAIL PROTECTED] folks: the sis900 patch should be in 2.6.21.x
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to
It looks like Fabric7 has gone out of business, and the maintainer works
elsewhere, so I'm no longer inclined to merge it into the upstream kernel.
Yell now, if there is a contigent of Fabric7 users that still want this.
Jeff
-
To unsubscribe from this list: send the line unsubscribe
Hi,
In these days I met a strange situation, tcp handshake rate is
slow after 2.6.18.8.
The case is, server accepts connections, and records number of successful
tcp handshakes during last 10 seconds. Client tries to connect to server's
listen port as fast as possible and as many as possible,
Hi,
The five following patches contain a number of fixes and improvements
of the pasemi_mac driver:
1/5: A couple of minor bugfixes.
2/5: Move the IRQ mapping from the PCI layer under our platform, to
the driver.
3/5: A rather large patch with various NAPI/performance-related fixes
and
Ethernet bugfixes:
* Move the was_full/wake_queue logic from tx_intr to clean_tx
* Fix polarity in checks in pasemi_mac_close
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
Index: linux-2.6/drivers/net/pasemi_mac.c
===
---
NAPI fixes and cleanups for pasemi_mac:
* Timer changes/fixes
* Abstract out the rx intr restart to a separate function
* Similar function for tx intr to reset to a known clear state even if
firmware used the same interface
* Add a copy-break and recycle the SKB in the driver for small
PHY support for pasemi_mac. Also add msg_enable flags for future
disablement of the link messages.
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
Index: powerpc/drivers/net/pasemi_mac.c
===
---
Use local-mac-address in the device tree instead. Fall back to mac-address
for older firmware.
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
Index: powerpc/drivers/net/pasemi_mac.c
===
--- powerpc.orig/drivers/net/pasemi_mac.c
On Sat, Apr 28, 2007 at 03:46:01PM +1000, Rusty Russell wrote:
OK, I did a quick check, and the only one I could find was br_if.c which
calls register_netdevice() and doesn't set get_stats. I don't think
that zeroes in this case matters.
Thanks for following up on this Rusty!
Actually I
79 matches
Mail list logo
