On Thu, 06 Sep 2007 00:25:51 -0700
Divy Le Ray [EMAIL PROTECTED] wrote:
Hi Dave,
I get this error compiling net-2.6.24 with XFRM off:
[EMAIL PROTECTED] net-2.6.24]# make O=/opt/build/net-2.6.24
fatal: corrupted pack file
On Thu, Sep 06, 2007 at 10:32:33AM +0530, Satyam Sharma wrote:
Probably tangential, but Herbert, is the call to synchronize_rcu() in
dev_deactivate() really correct?
Yes it's still correct as of today's tree. Of course patches
such as preemptible RCU may change things but they'll need to
On Thu, Sep 06, 2007 at 10:32:33AM +0530, Satyam Sharma wrote:
[ 382.529041] [c02c8abc] dev_close+0x24/0x67
[ 382.529052] [e01f402b] ieee80211_master_stop+0x4a/0x6d [mac80211]
This is where the bug is. You cannot call dev_close from an
atomic context as i33380211_master_stop does it
On Thu, 6 Sep 2007, Herbert Xu wrote:
On Thu, Sep 06, 2007 at 10:32:33AM +0530, Satyam Sharma wrote:
[ 382.529041] [c02c8abc] dev_close+0x24/0x67
[ 382.529052] [e01f402b] ieee80211_master_stop+0x4a/0x6d [mac80211]
This is where the bug is. You cannot call dev_close from an
On Thu, Sep 06, 2007 at 02:11:46PM +0530, Satyam Sharma wrote:
On Thu, 6 Sep 2007, Herbert Xu wrote:
On Thu, Sep 06, 2007 at 10:32:33AM +0530, Satyam Sharma wrote:
[ 382.529041] [c02c8abc] dev_close+0x24/0x67
[ 382.529052] [e01f402b] ieee80211_master_stop+0x4a/0x6d
On Tue, 4 Sep 2007, Mark Hindley wrote:
On Tue, Sep 04, 2007 at 02:09:47PM +0530, Satyam Sharma wrote:
Hi Steffen,
On Tue, 4 Sep 2007, Steffen Klassert wrote:
On Tue, Sep 04, 2007 at 03:45:55AM +0530, Satyam Sharma wrote:
drivers/net/3c59x.c: In function 'vortex_up':
From: Eric Dumazet [EMAIL PROTECTED]
Date: Thu, 6 Sep 2007 10:13:26 +0200
I believe this problem is known.
Please check http://marc.info/?l=linux-netdevm=118881627028135w=2
I'll toss that fix into the tree, thanks.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the
Hi,
Thu, 6 Sep 2007 10:13:26 +0200
[Subject: Re: net-26.24 broken with XFRM off]
Eric Dumazet [EMAIL PROTECTED] wrote...
Hi Divy
I believe this problem is known.
Please check http://marc.info/?l=linux-netdevm=118881627028135w=2
I'm sorry not to check more precisely.
As Eric
- Added support to poll entire set of device errors and alarams.
- A note on how device errors and alarms are handled:
- The adapter will automatically recover from uncorrectable ECC errors.
Packets containing corrupted data will be dropped (not transmitted) or tagged
as invalid before being
- Removed the unused variable, intr_type, in device private structure.
Signed-off-by: Sivakumar Subramani [EMAIL PROTECTED]
Signed-off-by: Santosh Rastapur [EMAIL PROTECTED]
Signed-off-by: Ramkrishna Vepa [EMAIL PROTECTED]
---
diff -urpN patch_2/drivers/net/s2io.c patch_3/drivers/net/s2io.c
---
- Added check to return from the traffic handling function, if the card status
is DOWN.
- Implemented Jeff's comments on incorrect return value in s2io_poll function.
Signed-off-by: Sivakumar Subramani [EMAIL PROTECTED]
Signed-off-by: Santosh Rastapur [EMAIL PROTECTED]
Signed-off-by: Ramkrishna
Upstream got a backport of my netdev-priv fixes for the
cxgb3 driver, creating a bunch of conflicts with the napi_struct
changes, so I took the opportunity to refresh the tree and
combine some bug fixes into the changes that introduced those
bugs :-) (bug fix attributions were added to the
From: Michael Chan [EMAIL PROTECTED]
Date: Wed, 05 Sep 2007 13:07:08 -0700
[TG3]: Workaround MSI bug on 5714/5780.
A hardware bug was revealed after a recent PCI MSI patch was made to
always disable legacy INTX when enabling MSI. The 5714/5780 chips
will not generate MSI when INTX is
Thanks Chuck and Brian for your comments.
Here is some correction for the ip_map caching code part.
I have updated the code to use Brian's ipv6_addr_v4mapped function, and
corrected some mistake you pointed out.
I have checked this patch with the checkpatch.pl script and i do not understand
On Thu, 2007-09-06 at 16:23 +0800, Herbert Xu wrote:
On Thu, Sep 06, 2007 at 10:32:33AM +0530, Satyam Sharma wrote:
[ 382.529041] [c02c8abc] dev_close+0x24/0x67
[ 382.529052] [e01f402b] ieee80211_master_stop+0x4a/0x6d [mac80211]
This is where the bug is. You cannot call
Johannes Berg [EMAIL PROTECTED] wrote:
Hah, I suspected as much but didn't have a chance to look yet. I had
plans to replace that sub_if_list with an RCU list and not require the
lock there, but that's far off. Any ideas how to fix this? We can't
reject the master stop so we have to walk the
On Thu, 2007-09-06 at 20:36 +0800, Herbert Xu wrote:
Johannes Berg [EMAIL PROTECTED] wrote:
Hah, I suspected as much but didn't have a chance to look yet. I had
plans to replace that sub_if_list with an RCU list and not require the
lock there, but that's far off. Any ideas how to fix
On Thu, 2007-09-06 at 18:22 +0530, Satyam Sharma wrote:
Unless I missed something obvious (let me know if that's the case! :-)
an RCU-protected list would suffer the same fate. list_for_each_xxx_rcu()
must be under rcu_read_lock() which == preempt_disable() ...
Right. But I'm thinking that
The dgrs driver is crap and assumes direct access to PCI iomem.
CHECK drivers/net/dgrs.c
drivers/net/dgrs.c:314:20: warning: cast removes address space of expression
drivers/net/dgrs.c:330:12: warning: incorrect type in argument 1 (different
address spaces)
drivers/net/dgrs.c:330:12:
On Thu, Sep 06, 2007 at 01:55:47PM +0100, Stephen Hemminger wrote:
The dgrs driver is crap and assumes direct access to PCI iomem.
dgrs wants to be removed, it has no users.
(no bug report in bugzilla nor in debian nor in google)
the firmware is not distrutable.
i'll resend my removal patch
On Thu, 2007-09-06 at 20:36 +0800, Herbert Xu wrote:
Yeah I think they're all under RTNL too. So you don't need to
take the lock here at all since you should already have the RTNL.
Ok, this patch gets rid of the lock. I'd appreciate if you could give it
a quick look for obvious RCU abuse as I
Hello.
Thank you very much for your time, Paul.
Yes, you understood what I wanted to do.
TOMOYO Linux's approach:
(1) It uses userspace intervention to allow/reject
connections and/or packets based on the application's domain.
Since existent hooks can't be used for this purpose,
I
From: Andy Gospodarek [EMAIL PROTECTED]
Date: Thu, 6 Sep 2007 09:45:16 -0400
Is is really necessary to get rid of the HT1000 patch?
Yes, absolutely and without a single doubt.
commit e3008dedff4bdc96a5f67224cd3d8d12237082a0
Author: Andy Gospodarek [EMAIL PROTECTED]
Date: Thu May 10
On Thu, 6 Sep 2007 15:16:00 +0100
James Chapman [EMAIL PROTECTED] wrote:
This RFC suggests some possible improvements to NAPI in the area of
minimizing interrupt rates. A possible scheme to reduce interrupt rate for
the low packet rate / fast CPU case is described.
First, do we need to
On 9/6/07, David Miller [EMAIL PROTECTED] wrote:
From: Andy Gospodarek [EMAIL PROTECTED]
Date: Thu, 6 Sep 2007 09:45:16 -0400
Is is really necessary to get rid of the HT1000 patch?
Yes, absolutely and without a single doubt.
commit e3008dedff4bdc96a5f67224cd3d8d12237082a0
Author: Andy
Bug: http://bugzilla.kernel.org/show_bug.cgi?id=8876
Not all ips are shown by ip addr show command when IPs number assigned to an
interface is more than 60-80 (in fact it depends on broadcast/label etc
presence on each address).
Steps to reproduce:
It's terribly simple to reproduce:
# for i in
Andy Gospodarek wrote:
This patch was designed to address tg3 and bnx2 messages printed on
systems with HT1000 chips IIRC. Are we going back to those
messages on
bnx2 or is there a workaround in that driver needed too?
Andy, I've checked all the Broadcom chips including bnx2 chips, only
On Thu, 2007-09-06 at 16:23 +0800, Herbert Xu wrote:
On Thu, Sep 06, 2007 at 10:32:33AM +0530, Satyam Sharma wrote:
[ 382.529041] [c02c8abc] dev_close+0x24/0x67
[ 382.529052] [e01f402b] ieee80211_master_stop+0x4a/0x6d [mac80211]
This is where the bug is. You cannot call
On Thursday, September 6 2007 9:04:01 am Tetsuo Handa wrote:
(1) It uses userspace intervention to allow/reject
connections and/or packets based on the application's domain.
Since existent hooks can't be used for this purpose,
I inserted a new hook post_recv_datagram() at
Stephen Hemminger wrote:
What about the latency that NAPI imposes? Right now there are certain
applications that
don't like NAPI because it add several more microseconds, and this may make it
worse.
Latency is something that I think this approach will actually improve,
at the expense of
On Thu, Sep 06, 2007 at 07:34:23AM -0700, David Miller wrote:
From: Andy Gospodarek [EMAIL PROTECTED]
Date: Thu, 6 Sep 2007 09:45:16 -0400
Is is really necessary to get rid of the HT1000 patch?
Yes, absolutely and without a single doubt.
commit e3008dedff4bdc96a5f67224cd3d8d12237082a0
Stephen Hemminger wrote:
On Thu, 06 Sep 2007 16:30:30 +0100
James Chapman [EMAIL PROTECTED] wrote:
Stephen Hemminger wrote:
What about the latency that NAPI imposes? Right now there are certain
applications that
don't like NAPI because it add several more microseconds, and this may make it
Hi,
This patch addresses a couple of issues related to interfamily ipsec
modes. The problem is that the structure of the routing info changes
with the family during the __xfrmX_bundle_create, which hasn't been
taken properly into account. Seems that by coincidence it hasn't
caused problems on
* Stephen Hemminger [EMAIL PROTECTED] 2007-09-06 16:10
Bug: http://bugzilla.kernel.org/show_bug.cgi?id=8876
Not all ips are shown by ip addr show command when IPs number assigned to an
interface is more than 60-80 (in fact it depends on broadcast/label etc
presence on each address).
The
Hi Aurelien,
More comments.
Aurélien Charbon wrote:
This is a small part of missing pieces of IPv6 support for the server.
It deals with the ip_map caching code part.
/* Insert client into hashtable. */
- for (i = 0; i ncp-cl_naddr; i++)
-
Stephen Hemminger wrote:
Bug: http://bugzilla.kernel.org/show_bug.cgi?id=8876
Not all ips are shown by ip addr show command when IPs number assigned to an
interface is more than 60-80 (in fact it depends on broadcast/label etc
presence on each address).
Steps to reproduce:
It's terribly simple
On Thu, Sep 06, 2007 at 12:05:30PM -0700, Michael Chan wrote:
On Thu, 2007-09-06 at 11:41 -0400, Andy Gospodarek wrote:
On Thu, Sep 06, 2007 at 07:34:23AM -0700, David Miller wrote:
From: Andy Gospodarek [EMAIL PROTECTED]
Date: Thu, 6 Sep 2007 09:45:16 -0400
Is is really necessary
On Thu, 2007-09-06 at 11:41 -0400, Andy Gospodarek wrote:
On Thu, Sep 06, 2007 at 07:34:23AM -0700, David Miller wrote:
From: Andy Gospodarek [EMAIL PROTECTED]
Date: Thu, 6 Sep 2007 09:45:16 -0400
Is is really necessary to get rid of the HT1000 patch?
Yes, absolutely and without a
Auke Kok wrote:
This patch adds support for the Intel 82598 PCI-Express 10GbE
chipset. Devices will be available on the market soon.
Also available through git:// and http:// here:
http://foo-projects.org/~sofar/ixgbe-20070905-submission.patch
From: Stephen Hemminger [EMAIL PROTECTED]
Since E100 timer is 2HZ, use rounding to make timer occur on the
correct boundary.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e100.c |3 ++-
1 files changed, 2 insertions(+), 1
Removed sparse warnings from tg3 driver. The new logic seems fine (I
don't immediately see where we are running over values for any of the
variables that need to be saved).
This patch compiles fine and I'm currently using a tg3 with the patched
driver to post this patch as a basic proof of
Already reported in an answer to the 2.6.23-rc4-mm1 announcement on
linux-kernel [1].
cu
Adrian
[1] http://lkml.org/lkml/2007/9/1/18
--
Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
Only a promise,
From: Kok, Auke [EMAIL PROTECTED]
Date: Thu, 06 Sep 2007 11:31:47 -0700
Also available through git:// and http:// here:
http://foo-projects.org/~sofar/ixgbe-20070905-submission.patch
http://foo-projects.org/~sofar/ixgbe-20070905-submission.patch.bz2
(git-am formatted!)
From: Michael Chan [EMAIL PROTECTED]
Date: Thu, 06 Sep 2007 12:05:30 -0700
The HT1000 bridge may very well have an MSI issue. I'm checking with
ServerWorks and I will do some testing to confirm. If confirmed, we can
disable MSI behind the HT1000 bridge instead of globally. The 5714
issue
From: [EMAIL PROTECTED]
Date: Wed, 05 Sep 2007 19:07:29 +0200
Fixes for 3 typos in Kconfig files
While these fixes are appreciated, I do not think they fall
under the networking umbrella.
Please resubmit them to linux-kernel or similar.
Thanks.
-
To unsubscribe from this list: send the line
On Thu, Sep 06, 2007 at 12:50:19PM -0700, David Miller wrote:
From: Michael Chan [EMAIL PROTECTED]
Date: Thu, 06 Sep 2007 12:05:30 -0700
The HT1000 bridge may very well have an MSI issue. I'm checking with
ServerWorks and I will do some testing to confirm. If confirmed, we can
disable
From: Ilpo_Järvinen [EMAIL PROTECTED]
Date: Wed, 5 Sep 2007 22:04:11 +0300 (EEST)
Main obstacle to FRTO use is its deployment as it has to be on the
sender side where as wireless link is often the receiver's access
link but if one can tune tcp_min_rto (or equal) on the sender side,
one could
[PATCH] Fix config requirements of IPv6
net/ipv6/inet6_connection_sock.c in function __inet6_csk_dst_store() requires
flow_cache_genid which is defined in net/core/flow.c which is compiled when
CONFIG_XFRM is set.
This patch expresses that dependency.
Signed-off-by: Bernhard Walle [EMAIL
From: Bernhard Walle [EMAIL PROTECTED]
Date: Thu, 6 Sep 2007 22:01:52 +0200
[PATCH] Fix config requirements of IPv6
net/ipv6/inet6_connection_sock.c in function __inet6_csk_dst_store() requires
flow_cache_genid which is defined in net/core/flow.c which is compiled when
CONFIG_XFRM is set.
On Thu, Sep 06, 2007 at 12:47:11PM +0200, Thomas Graf wrote:
* Milan Kocian [EMAIL PROTECTED] 2007-08-29 23:51
Because RTM_NEWLINK is used to notify about device status change
(as I see in net/core/rtnetlink.c) and RTM_DELLINK to inform about
NETDEV_UNREGISTER. Why should it be else in ipv6
Stephen Hemminger wrote:
On Tue, 4 Sep 2007 13:20:47 -0700 (PDT)
Rick Jones [EMAIL PROTECTED] wrote:
Build upon David Miller's initial patches to set the per-route rto_min
so users can specify the rto_min in the same units (milliseconds) in
which they are displayed. This is desirable because
On Thu, Sep 06, 2007 at 03:25:55PM +0530, Satyam Sharma wrote:
This is a GCC bug (regression, actually, as you've found out) -- no two
ways about it. Although different from the kind Jeff mentioned couple days
back -- that was about wising GCC up to false positives and /not/ emitting
On Thu, 6 Sep 2007 17:34:10 +0200 Matteo Croce [EMAIL PROTECTED] wrote:
Driver for the cpmac 100M ethernet driver.
It works fine disabling napi support, enabling it gives a kernel panic
when the first IPv6 packet has to be forwarded.
Other than that works fine.
I'm not too sure why I got
On Thu, 2007-06-09 at 15:16 +0100, James Chapman wrote:
First, do we need to encourage consistency in NAPI poll drivers? A
survey of current NAPI drivers shows different strategies being used
in their poll(). Some such as r8169 do the napi_complete() if poll()
does less work than their
On Thu, 06 Sep 2007 12:44:22 -0700 (PDT) David Miller [EMAIL PROTECTED]
wrote:
From: Kok, Auke [EMAIL PROTECTED]
Date: Thu, 06 Sep 2007 11:31:47 -0700
Also available through git:// and http:// here:
http://foo-projects.org/~sofar/ixgbe-20070905-submission.patch
Il Friday 07 September 2007 00:30:25 Andrew Morton ha scritto:
On Thu, 6 Sep 2007 17:34:10 +0200 Matteo Croce [EMAIL PROTECTED] wrote:
Driver for the cpmac 100M ethernet driver.
It works fine disabling napi support, enabling it gives a kernel panic
when the first IPv6 packet has to be
On Thu, 6 Sep 2007 15:30:25 -0700 Andrew Morton wrote:
On Thu, 6 Sep 2007 17:34:10 +0200 Matteo Croce [EMAIL PROTECTED] wrote:
Driver for the cpmac 100M ethernet driver.
It works fine disabling napi support, enabling it gives a kernel panic
when the first IPv6 packet has to be forwarded.
On Fri, 7 Sep 2007 01:21:41 +0200 Matteo Croce [EMAIL PROTECTED] wrote:
The patch introduces vast number of volatile structure fields. Please see
Documentation/volatile-considered-harmful.txt.
Removing them and the kernel hangs at module load
They can't just be removed. Please see the
Joseph Southwell wrote:
scenario
Machine A
eth0 is plugged into network.
192.168.1.201
eth0:1
192.168.1.2
Machine B
eth1 is plugged into network.
192.168.1.101
eth0 is not plugged into network. so I can test locally before
switching the wire.
192.168.1.201
eth0:1
192.168.1.2
arp request
scenario
Machine A
eth0 is plugged into network.
192.168.1.201
eth0:1
192.168.1.2
Machine B
eth1 is plugged into network.
192.168.1.101
eth0 is not plugged into network. so I can test locally before
switching the wire.
192.168.1.201
eth0:1
192.168.1.2
arp request for 192.168.1.2 is
Hi Dave,
Last week i sent out the rev-3 of the age patch set,
and i got no comments . So i assume the people who reviewed it earlier
are ok with it. Can you please go through it and push it upstream?
Regards,
Varun
-
To unsubscribe from this list: send the line unsubscribe
Hi James,
I like the idea of staying in poll longer.
My comments are similar to what Jamal and Stephen have already said.
A tunable (via sysfs) would be nice.
A timer might be preferred to jiffy polling. Jiffy polling will not increase
latency the way a timer would. However, jiffy polling
Andrew Morton wrote:
On Thu, 06 Sep 2007 12:44:22 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote:
From: Kok, Auke [EMAIL PROTECTED]
Date: Thu, 06 Sep 2007 11:31:47 -0700
Also available through git:// and http:// here:
http://foo-projects.org/~sofar/ixgbe-20070905-submission.patch
63 matches
Mail list logo
