* Re: (2nd attempt) Please pull 'upstream-davem' branch of wireless-2.6
From: David Miller @ 2007-12-25 4:57 UTC (permalink / raw)
To: linville; +Cc: netdev, linux-wireless
In-Reply-To: <20071221140527.GA19874@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Fri, 21 Dec 2007 09:05:27 -0500
> These are destined for 2.6.25. The patches fall mostly into two
> categories: a new rate control algorithm for mac80211, and some
> cfg80211 enhancements (including mac80211 patches to use them).
>
> Also there are some small hits in the iwlwifi drivers related to
> rate control. I'll CC Jeff since his tree has a lot of iwlwifi symbol
> renames and those patches will conflict (or break the build, or both)
> when your tree and his finally come together.
>
> Let me know if there are any problems!
Pulled, thanks a lot!
^ permalink raw reply
* Re: [SOCK] Avoid divides in sk_stream_pages() and __sk_stream_mem_reclaim()
From: David Miller @ 2007-12-25 4:58 UTC (permalink / raw)
To: dada1; +Cc: netdev
In-Reply-To: <20071221154508.97aef5d9.dada1@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Fri, 21 Dec 2007 15:45:08 +0100
> [SOCK] Avoid divides in sk_stream_pages() and __sk_stream_mem_reclaim()
>
> sk_forward_alloc being signed, we should take care of divides by
> SK_STREAM_MEM_QUANTUM we do in sk_stream_pages() and
> __sk_stream_mem_reclaim()
>
> This patchs introduces SK_STREAM_MEM_QUANTUM_SHIFT, defined
> as ilog2(SK_STREAM_MEM_QUANTUM), to be able to use right
> shifts instead of plain divides.
>
> This should help compiler to choose right shifts instead of
> expensive divides (as seen with CONFIG_CC_OPTIMIZE_FOR_SIZE=y on x86)
>
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [WEXT 3/12]: Extract standard call iw_point handling into seperate function.
From: David Miller @ 2007-12-25 5:18 UTC (permalink / raw)
To: joe-6d6DIl74uiNBDgjK7y7TUQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1198308172.4895.11.camel@localhost>
From: Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
Date: Fri, 21 Dec 2007 23:22:52 -0800
> On Fri, 2007-12-21 at 20:54 -0800, David Miller wrote:
> > [WEXT]: Extract standard call iw_point handling into seperate function.
>
> This potentially does copy_from_user twice,
> first to the stack, second to a kmalloc'ed area.
> Perhaps it's better to kmalloc first and copy once?
I'm preserving existing behavior in these changes,
feel free to make these kinds of improvements as
a follow-on changeset.
^ permalink raw reply
* Re: [ETH]: Combine format_addr() with print_mac().
From: David Miller @ 2007-12-25 5:28 UTC (permalink / raw)
To: mchan; +Cc: joe, netdev, anilgv, michaelc, david.somayajulu
In-Reply-To: <1198455635.5491.4.camel@dell>
From: "Michael Chan" <mchan@broadcom.com>
Date: Sun, 23 Dec 2007 16:20:35 -0800
> Here's the revised patch:
>
> [ETH]: Combine format_addr() with print_mac().
>
> print_mac() used many most net drivers and format_addr() used by
> net-sysfs.c are very similar and they can be intergrated.
>
> format_addr() is also identically redefined in the qla4xxx iscsi
> driver.
>
> Export a new function sysfs_format_mac() to be used by net-sysfs,
> qla4xxx and others in the future. Both print_mac() and
> sysfs_format_mac() call _format_mac_addr() to do the formatting.
>
> Changed print_mac() to use unsigned char * to be consistent with
> net_device struct's dev_addr. Added buffer length overrun checking
> as suggested by Joe Perches.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied to net-2.6.25, thanks Michael.
^ permalink raw reply
* Re: [PATCH] TUNTAP: Fix wrong debug message
From: David Miller @ 2007-12-25 5:30 UTC (permalink / raw)
To: tabe; +Cc: joe, netdev, maxk
In-Reply-To: <20071225.122756.-713540829.tabe@miraclelinux.com>
From: Toyo Abe <tabe@miraclelinux.com>
Date: Tue, 25 Dec 2007 12:27:56 +0900 (JST)
> --- Original Messsage ---
> From: Joe Perches <joe@perches.com>
> Subject: Re: [PATCH] TUNTAP: Fix wrong debug message
> Date: Mon, 24 Dec 2007 18:48:48 -0800
> Message-ID: <1198550928.19504.1.camel@localhost>
>
> > More readable to reverse the strings
> >
> > tun->dev->name, arg ? "enabled" : "disabled");
> >
>
> Hello Joe,
> Thanks for your advice.
>
> This is the more readable version.
Applied, thanks Toyo.
Joe, please don't provide patch feedback in private emails as it
appears you did here. When you do this, it cheapens the value
of the feedback because other people reading the list cannot
benefit nor comment on it.
You've done this to me in the past too, and I told you back then
to please stop doing it.
Thanks.
^ permalink raw reply
* Re: [PATCH] [TCP]: Force TSO splits to MSS boundaries
From: David Miller @ 2007-12-25 5:35 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: herbert, netdev
In-Reply-To: <Pine.LNX.4.64.0712211953580.7301@kivilampi-30.cs.helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Fri, 21 Dec 2007 20:55:28 +0200 (EET)
> [PATCH] [TCP]: Force TSO splits to MSS boundaries
>
> If snd_wnd - snd_nxt wasn't multiple of MSS, skb was split on
> odd boundary by the callers of tcp_window_allows.
>
> We try really hard to avoid unnecessary modulos. Therefore the
> old caller side check "if (skb->len < limit)" was too wide as
> well because limit is not bound in any way to skb->len and can
> cause spurious testing for trimming in the middle of the queue
> while we only wanted that to happen at the tail of the queue.
> A simple additional caller side check for tcp_write_queue_tail
> would likely have resulted 2 x modulos because the limit would
> have to be first calculated from window, however, doing that
> unnecessary modulo is not mandatory. After a minor change to
> the algorithm, simply determine first if the modulo is needed
> at all and at that point immediately decide also from which
> value it should be calculated from.
>
> This approach also kills some duplicated code.
>
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Looks good, patch applied, thanks.
With respect to code duplicateion, tcp_push_one() is essentially
the inner loop of tcp_write_xmit() :-)
^ permalink raw reply
* Re: [PATCH] [TCP]: Remove seq_rtt ptr from clean_rtx_queue args
From: David Miller @ 2007-12-25 5:56 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: netdev
In-Reply-To: <Pine.LNX.4.64.0712211617020.7301@kivilampi-30.cs.helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Fri, 21 Dec 2007 16:19:19 +0200 (EET)
> While checking Gavin's patch I noticed that the returned seq_rtt
> is not used by the caller.
>
> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Good catch, applied to net-2.6.25
The history of this is that way back when, Vegas used to
use it for RTT calculations, bit it handles that now via
the ->pkts_acked() cong-control method.
^ permalink raw reply
* Re: [PATCH] net: santize headers for iproute2
From: David Miller @ 2007-12-25 6:05 UTC (permalink / raw)
To: stephen.hemminger; +Cc: vgusev, netdev
In-Reply-To: <20071221094336.63600b8c@deepthought>
From: Stephen Hemminger <stephen.hemminger@vyatta.com>
Date: Fri, 21 Dec 2007 09:43:36 -0800
> iproute2 source uses headers that result from "make headers_install".
> The header files net/tcp_states.h and net/veth.h are both being used
> but are not processed.
>
> Signed-off-by: Stephen Hemminger <stephen.hemminger@vyatta.com>
The convention is to place user visible interfaces in header
files under include/linux/ and purely kernel internal bits
in header files under include/net/
Therefore exporting net/*.h headers is not right.
net/veth.h only defines user visible interfaces, so it
belongs under include/linux and added to include/linux/Kbuild,
and I would happily take a patch implementing that.
net/tcp_states.h is not movable to include/linux/ and thus to
userspace, it defines things that are present already in existing
userland header files. If you look, <netinet/tcp.h> defines these
state values, as an enumeration. If you need the TCPF_* flag bit
versions, sorry... you'll need to find some other way to get those
into userspace.
^ permalink raw reply
* Re: Please pull 'fixes-davem' branch of wireless-2.6
From: David Miller @ 2007-12-25 6:07 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20071220155227.GE3139-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Thu, 20 Dec 2007 10:52:27 -0500
> A few more stragglers for 2.6.24...let me know if there are any
> problems!
...
> The following changes since commit 82d29bf6dc7317aeb0a3a13c2348ca8591965875:
> Linus Torvalds (1):
> Linux 2.6.24-rc5
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git fixes-davem
>
> Johannes Berg (2):
> mac80211: round station cleanup timer
> mac80211: warn when receiving frames with unaligned data
Pulled and pushed back out to net-2.6, thanks John.
^ permalink raw reply
* [patch] skbuff: spelling and formatting fixes
From: Matti Linnanvuori @ 2007-12-25 6:59 UTC (permalink / raw)
To: netdev, trivial
--- a/include/linux/skbuff.h 2007-12-25
08:24:51.032348500 +0200
+++ b/include/linux/skbuff.h 2007-12-25
08:38:31.067753500 +0200
@@ -127,7 +127,7 @@ struct sk_buff_head {
struct sk_buff;
/* To allow 64K frame to be packed as single skb
without frag_list */
-#define MAX_SKB_FRAGS (65536/PAGE_SIZE + 2)
+#define MAX_SKB_FRAGS ((65536 / PAGE_SIZE) + 2)
typedef struct skb_frag_struct skb_frag_t;
@@ -394,7 +394,7 @@ static inline void
skb_truesize_check(st
extern int skb_append_datato_frags(struct sock *sk,
struct sk_buff *skb,
int getfrag(void *from, char *to, int offset,
- int len,int odd, struct sk_buff *skb),
+ int len, int odd, struct sk_buff *skb),
void *from, int length);
struct skb_seq_state
@@ -1346,7 +1346,7 @@ static inline struct sk_buff
*netdev_all
* @len: length up to which to write
*
* Returns true if modifying the header part of the
cloned buffer
- * does not requires the data to be copied.
+ * does not require the data to be copied.
*/
static inline int skb_clone_writable(struct sk_buff
*skb, unsigned int len)
{
__________________________________ Ihr erstes Fernweh? Wo gibt es den schönsten Strand? www.yahoo.de/clever
^ permalink raw reply
* Re: Simple question about network stack
From: Badalian Vyacheslav @ 2007-12-25 8:52 UTC (permalink / raw)
To: Marek Kierdelewicz, netdev
In-Reply-To: <20071224205358.5c192f8d@catlap>
Marek Kierdelewicz:
> Hi,
>
>
>> Have 2 Ethernet adapters e1000. Have 8 CPU (4 real).
>> Computer work as Shaper. Use only TC rules to shape and IPTABLES to
>> drop.
>> question:
>> 1. I may balance load to other cpu? I understand that i can't balance
>> polling place, but find in TC and IPTABLES hash may do different cpu?
>>
>
> You need as many nics as cpus to effectivelu use all your processing
> power. You can pair-up nics and cpus by configuring appropriate irq
> smp affinity. Read in [1] from line 350 on.
>
Interesting. Sorry if my questions will be stupid. "smp affinity" its
was i need, but it not work for me, and never work if i remember =(
Maybe Guru of Network ask me where i have simple stupid mistake?
In theory
#cat ffffffff > /proc/irq/ID/smp_affinity
set mask that all cpus must get interrupts RR
but i see in cat /proc/interrupts that all interrupts get only CPU0
On CPU1 0 interrupts
i do
#cat 2 > /proc/irq/16/smp_affinity
#cat 2 > /proc/irq/17/smp_affinity
#echo /proc/irq/1[67]/smp_affinity
00000002
00000002
Great. Interrupts go to CPU1
#cat 1 > /proc/irq/16/smp_affinity
#cat 1 > /proc/irq/17/smp_affinity
#echo /proc/irq/1[67]/smp_affinity
00000001
00000001
Great. Interrupts go to CPU0
#cat 3 > /proc/irq/16/smp_affinity
#cat 3 > /proc/irq/17/smp_affinity
#echo /proc/irq/1[67]/smp_affinity
00000003
00000003
Strange. Interrupts go to CPU0 only.
Where i have mistake? Why i not have RR? Or i mistake in SMP Affinity idea?
Thanks for answers!
Slavon
> Another option is to use recent e1000 nics with multiqueue capability.
> Read in [2]. Google for more information. I'm not sure but you'll
> probably need non-kerel recent e1000 drivers from sourceforge.
>
> [1]http://www.mjmwired.net/kernel/Documentation/filesystems/proc.txt
> [2]http://www.mjmwired.net/kernel/Documentation/networking/multiqueue.txt
>
> cheers,
> Marek Kierdelewicz
>
>
^ permalink raw reply
* Re: Strange Panic (Deadlock)
From: Badalian Vyacheslav @ 2007-12-25 9:11 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: netdev
In-Reply-To: <47701542.9010806@gmail.com>
Jarek Poplawski пишет:
> slavon@bigtelecom.ru wrote, On 12/24/2007 07:18 PM:
>
>
>> Hello again.
>> Its bug depend to
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4aae07025265151e3f7041dfbf0f529e122de1d8
>> ?
>>
>
ok. i will add it to bugtracker, but bug process in gentoo and in
vanilla kernel.
I send to netdev mail list becouse i think that bug depend to TC or
IPTABLES functional.
I have 4 machine. All platforms different. All machine do 1 time in
hour rebuild TC and IPTABLES rules.
After it do
echo START >> log.txt
iptables-restore < xxx.txt
tc qdisc del dev eth0 root
tc qdisc del dev eth1 root
tc -b new_rules.txt
echo END >> log.txt
and its all that its doing.
Bug always be between START and END
All machines have above 300mbs traffic.
I try turn off rebuilding rules on 1 PC and it work 3 week without reboot!
I think that situation ask that problem depends to network. If its
mistake - sorry please.
Slavon
> Hello Vyacheslav!
>
> I wonder why do you think there is such a dependency, and why do you report
> timer.c bug to netdev after all? I added some CCs here, but IMHO you would
> better open a new bug at bugzilla.kernel.org, adding some more details like
> .config, and reply back to this thread with the bug's number. BTW, if it's
> patched by Gentoo or otherwise, you should try and report on 'vanilla' one
> only.
>
> Regards,
> Jarek P.
>
>
>> Its very critical bug to us. This PC must be HA. Server place so far
>> for me to go and reboot server. I go to it 1-3 times in week =(
>> Please help to fix it =)
>>
>>
>>> Hello all. Some time machine freeze. No information on monitor. No
>>> rebooting on sysctl "kernel.panic".
>>> Any idea?
>>>
>>> Catched by netconsole:
>>> [91922.085864] ------------[ cut here ]------------
>>> [91922.085975] kernel BUG at kernel/timer.c:606!
>>> [91922.086058] invalid opcode: 0000 [#1]
>>> [91922.086127] SMP
>>> [91922.086201] Modules linked in: netconsole cls_u32 sch_sfq sch_htb
>>> xt_tcpudp iptable_filter ip_tables x_tables i2c_i801 i2c_core
>>> [91922.086386] CPU: 1
>>> [91922.086387] EIP: 0060:[<c0127387>] Not tainted VLI
>>> [91922.086389] EFLAGS: 00010087 (2.6.23-gentoo-r4-fw #4)
>>> [91922.086600] EIP is at cascade+0x34/0x4f
>>> [91922.086669] eax: c0452200 ebx: f450408c ecx: 00000022 edx: f3c6e08c
>>> [91922.086740] esi: 00000022 edi: c21ce000 ebp: 00000001 esp: c21c3ef8
>>> [91922.086815] ds: 007b es: 007b fs: 00d8 gs: 0000 ss: 0068
>>> [91922.086885] Process swapper (pid: 0, ti=c21c2000 task=c21af000
>>> task.ti=c21c2000)
>>> [91922.086954] Stack: f3c6e08c c21bfb74 00000000 c21ce000 0000000a
>>> c012767a c21af000 00000001
>>> [91922.087119] c21c3f18 c0106963 c21c3f68 00000001 00000021
>>> c03c0b08 0000000a c0124556
>>> [91922.087285] 00000046 00000000 c21c2008 00000000 c01245ec
>>> c2015120 c0114a11 00000046
>>> [91922.087451] Call Trace:
>>> [91922.087586] [<c012767a>] run_timer_softirq+0x51/0x154
>>> [91922.087669] [<c0106963>] profile_pc+0x21/0x46
>>> [91922.087752] [<c0124556>] __do_softirq+0x5d/0xc1
>>> [91922.087833] [<c01245ec>] do_softirq+0x32/0x36
>>> [91922.087915] [<c0114a11>] smp_apic_timer_interrupt+0x74/0x80
>>> [91922.087997] [<c010484c>] apic_timer_interrupt+0x28/0x30
>>> [91922.088076] [<c0102255>] mwait_idle_with_hints+0x3b/0x3f
>>> [91922.088162] [<c0102259>] mwait_idle+0x0/0xa
>>> [91922.088237] [<c0102398>] cpu_idle+0x91/0xaa
>>> [91922.088319] =======================
>>> [91922.088390] Code: 08 8d 04 ca 8b 10 89 62 04 89 14 24 8b 50 04 89 22
>>> 89 00 89 54 24 04 8b 14 24 89 40 04 8b 1a eb 19 8b 42 14 83 e0 fe 39 f8
>>> 74 04 <0f> 0b eb fe 89 f8 e8 d8 fe ff ff 89 da 8b 1b 39 e2 75 e3 59 89
>>> [91922.088864] EIP: [<c0127387>] cascade+0x34/0x4f SS:ESP 0068:c21c3ef8
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>>
>>>
>>
>> ----------------------------------------------------------------
>> This message was sent using IMP, the Internet Messaging Program.
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>
>
>
>
^ permalink raw reply
* [PATCH][XFRM] Documentaion: Fix error example at XFRMOUTSTATEMODEERROR. (Re: [XFRM]: Fix outbound statistics.)
From: Masahide NAKAMURA @ 2007-12-25 11:43 UTC (permalink / raw)
To: davem, herbert; +Cc: netdev, usagi-core, Masahide NAKAMURA
# This is resent email since the Subject is blank at the first time;
Hello,
On Fri, 21 Dec 2007 23:11:11 +0800
Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Fri, Dec 21, 2007 at 11:25:00PM +0900, Masahide NAKAMURA wrote:
> >
> > do {
> > err = xfrm_state_check_space(x, skb);
> > - if (err)
> > + if (err) {
> > + XFRM_INC_STATS(LINUX_MIB_XFRMOUTERROR);
> > goto error_nolock;
> > + }
> >
> > err = x->outer_mode->output(x, skb);
> > - if (err)
> > + if (err) {
> > + XFRM_INC_STATS(LINUX_MIB_XFRMOUTSTATEMODEERROR);
>
> BTW, none of our existing mode output functions actually return
> an error. I noticed that the description for this field is actually
> "Transformation mode specific error, e.g. Outer header space is not
> enough". This is slightly misleading as output header space is
> checked by xfrm_state_check_space so if there's an error that's
> where it'll show up.
Thanks for comment, Herbert.
I fix the documentation to remove "e.g. Outer header space is not enough"
from XFRMSTATEMODEERROR.
About error code from xfrm_state_check_space(), I still map it XFRMOUTERROR
(other errors) this time because I think the error here is not a length
error by protocol (e.g MTU related things) but an internal buffer management.
Any comments for the statistics are still welcomed.
David, please apply the following patch, too.
[XFRM] Documentaion: Fix error example at XFRMOUTSTATEMODEERROR.
Signed-off-by: Masahide NAKAMURA <nakam@linux-ipv6.org>
---
Documentation/networking/xfrm_proc.txt | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/Documentation/networking/xfrm_proc.txt b/Documentation/networking/xfrm_proc.txt
index ec9045b..53c1a58 100644
--- a/Documentation/networking/xfrm_proc.txt
+++ b/Documentation/networking/xfrm_proc.txt
@@ -60,7 +60,6 @@ XfrmOutStateProtoError:
Transformation protocol specific error
XfrmOutStateModeError:
Transformation mode specific error
- e.g. Outer header space is not enough
XfrmOutStateExpired:
State is expired
XfrmOutPolBlock:
--
1.4.4.2
^ permalink raw reply related
* Re: Strange Panic (Deadlock)
From: Jarek Poplawski @ 2007-12-25 14:49 UTC (permalink / raw)
To: Badalian Vyacheslav; +Cc: netdev
In-Reply-To: <4770C956.5040409@bigtelecom.ru>
On Tue, Dec 25, 2007 at 12:11:50PM +0300, Badalian Vyacheslav wrote:
...
> ok. i will add it to bugtracker, but bug process in gentoo and in
> vanilla kernel.
> I send to netdev mail list becouse i think that bug depend to TC or
> IPTABLES functional.
> I have 4 machine. All platforms different. All machine do 1 time in
> hour rebuild TC and IPTABLES rules.
> After it do
> echo START >> log.txt
> iptables-restore < xxx.txt
> tc qdisc del dev eth0 root
> tc qdisc del dev eth1 root
> tc -b new_rules.txt
> echo END >> log.txt
>
> and its all that its doing.
> Bug always be between START and END
> All machines have above 300mbs traffic.
> I try turn off rebuilding rules on 1 PC and it work 3 week without reboot!
>
> I think that situation ask that problem depends to network. If its
> mistake - sorry please.
>
Yes, this description seems to point at network, but since the bug
triggers in timer.c ...we could try to share this work with somebody
(or even blame them 100% if they are not clever enough...)?!
I think there were similar things reported especially around HTB, but
it seems there were problems with later debugging. I'll try to think
about it, but if there are some more logs or details, it should be
helpful.
BTW: you've written there is a need to go and reboot this each time:
did you try something like drivers/char/watchdog/softdog.c?
Regards,
Jarek P.
^ permalink raw reply
* [PATCH] qla3xxx: convert byte order of constant instead of variable
From: Marcin Slusarz @ 2007-12-25 14:48 UTC (permalink / raw)
To: netdev; +Cc: linux-driver, LKML
convert byte order of constant instead of variable
it will be done at compile time (vs run time)
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
---
drivers/net/qla3xxx.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c
index a579111..c9f8ba4 100644
--- a/drivers/net/qla3xxx.c
+++ b/drivers/net/qla3xxx.c
@@ -2497,8 +2497,7 @@ static int ql_send_map(struct ql3_adapter *qdev,
if (seg_cnt == 1) {
/* Terminate the last segment. */
- oal_entry->len =
- cpu_to_le32(le32_to_cpu(oal_entry->len) | OAL_LAST_ENTRY);
+ oal_entry->len |= cpu_to_le32(OAL_LAST_ENTRY);
} else {
oal = tx_cb->oal;
for (completed_segs=0; completed_segs<frag_cnt; completed_segs++,seg++) {
@@ -2555,8 +2554,7 @@ static int ql_send_map(struct ql3_adapter *qdev,
frag->size);
}
/* Terminate the last segment. */
- oal_entry->len =
- cpu_to_le32(le32_to_cpu(oal_entry->len) | OAL_LAST_ENTRY);
+ oal_entry->len |= cpu_to_le32(OAL_LAST_ENTRY);
}
return NETDEV_TX_OK;
--
1.5.3.4
^ permalink raw reply related
* Re: Strange Panic (Deadlock)
From: Denys Fedoryshchenko @ 2007-12-25 15:38 UTC (permalink / raw)
To: Jarek Poplawski, Badalian Vyacheslav; +Cc: netdev
In-Reply-To: <20071225144940.GA2998@ami.dom.local>
Probably also there is TCO watchdog, if it is Intel motherboard. I am using
also on unreliable machines nmi_watchdog. And also if it is servers, probably
there is IPMI.
Plus it is IMHO important to know lspci -vvv, cat /proc/interrupts, and kernel
config.
Vyacheslav, on my experience i am tried also latest rc kernels on production
machines, it helps sometimes for me, and also it helps alot to kernel
developers. Gentoo kernels not heavily patched in critical parts, but IMHO it
will make debugging difficult, if patch exist in "failed" part.
I am not kernel developer, but can help with watchdogs and etc, and probably
extended debugging. Contact me via ICQ 17962627 or MSN nuclearcat AT
nuclearcat.com, probably i can help somehow to make your setup more reliable.
On Tue, 25 Dec 2007 15:49:40 +0100, Jarek Poplawski wrote
> On Tue, Dec 25, 2007 at 12:11:50PM +0300, Badalian Vyacheslav wrote:
> ....
> > ok. i will add it to bugtracker, but bug process in gentoo and in
> > vanilla kernel.
> > I send to netdev mail list becouse i think that bug depend to TC or
> > IPTABLES functional.
> > I have 4 machine. All platforms different. All machine do 1 time in
> > hour rebuild TC and IPTABLES rules.
> > After it do
> > echo START >> log.txt
> > iptables-restore < xxx.txt
> > tc qdisc del dev eth0 root
> > tc qdisc del dev eth1 root
> > tc -b new_rules.txt
> > echo END >> log.txt
> >
> > and its all that its doing.
> > Bug always be between START and END
> > All machines have above 300mbs traffic.
> > I try turn off rebuilding rules on 1 PC and it work 3 week without reboot!
> >
> > I think that situation ask that problem depends to network. If its
> > mistake - sorry please.
> >
>
> Yes, this description seems to point at network, but since the bug
> triggers in timer.c ...we could try to share this work with somebody
> (or even blame them 100% if they are not clever enough...)?!
>
> I think there were similar things reported especially around HTB, but
> it seems there were problems with later debugging. I'll try to think
> about it, but if there are some more logs or details, it should be
> helpful.
>
> BTW: you've written there is a need to go and reboot this each time:
> did you try something like drivers/char/watchdog/softdog.c?
>
> Regards,
> Jarek P.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.
^ permalink raw reply
* Re: Simple question about network stack
From: Denys Fedoryshchenko @ 2007-12-25 15:41 UTC (permalink / raw)
To: Badalian Vyacheslav, Marek Kierdelewicz, netdev
In-Reply-To: <4770C4E0.1040708@bigtelecom.ru>
Probably you have enabled in kernel "Enable kernel irq balancing" or
CONFIG_IRQBALANCE
It is wrong. It has to be disabled.
On Tue, 25 Dec 2007 11:52:48 +0300, Badalian Vyacheslav wrote
> Marek Kierdelewicz:
> > Hi,
> >
> >
> >> Have 2 Ethernet adapters e1000. Have 8 CPU (4 real).
> >> Computer work as Shaper. Use only TC rules to shape and IPTABLES to
> >> drop.
> >> question:
> >> 1. I may balance load to other cpu? I understand that i can't balance
> >> polling place, but find in TC and IPTABLES hash may do different cpu?
> >>
> >
> > You need as many nics as cpus to effectivelu use all your processing
> > power. You can pair-up nics and cpus by configuring appropriate irq
> > smp affinity. Read in [1] from line 350 on.
> >
> Interesting. Sorry if my questions will be stupid. "smp affinity" its
> was i need, but it not work for me, and never work if i remember =(
> Maybe Guru of Network ask me where i have simple stupid mistake?
>
> In theory
> #cat ffffffff > /proc/irq/ID/smp_affinity
> set mask that all cpus must get interrupts RR
>
> but i see in cat /proc/interrupts that all interrupts get only CPU0
> On CPU1 0 interrupts
>
> i do
> #cat 2 > /proc/irq/16/smp_affinity
> #cat 2 > /proc/irq/17/smp_affinity
> #echo /proc/irq/1[67]/smp_affinity
> 00000002
> 00000002
>
> Great. Interrupts go to CPU1
>
> #cat 1 > /proc/irq/16/smp_affinity
> #cat 1 > /proc/irq/17/smp_affinity
> #echo /proc/irq/1[67]/smp_affinity
> 00000001
> 00000001
>
> Great. Interrupts go to CPU0
>
> #cat 3 > /proc/irq/16/smp_affinity
> #cat 3 > /proc/irq/17/smp_affinity
> #echo /proc/irq/1[67]/smp_affinity
> 00000003
> 00000003
>
> Strange. Interrupts go to CPU0 only.
>
> Where i have mistake? Why i not have RR? Or i mistake in SMP
> Affinity idea? Thanks for answers!
>
> Slavon
>
> > Another option is to use recent e1000 nics with multiqueue capability.
> > Read in [2]. Google for more information. I'm not sure but you'll
> > probably need non-kerel recent e1000 drivers from sourceforge.
> >
> > [1]http://www.mjmwired.net/kernel/Documentation/filesystems/proc.txt
> > [2]http://www.mjmwired.net/kernel/Documentation/networking/multiqueue.txt
> >
> > cheers,
> > Marek Kierdelewicz
> >
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.
^ permalink raw reply
* Re: [PATCH] [IPROUTE2] IPT action compatibility with iptables 1.4.0
From: Denys Fedoryshchenko @ 2007-12-25 15:50 UTC (permalink / raw)
To: hadi, Stephen Hemminger; +Cc: netdev, Pablo Neira Ayuso
In-Reply-To: <1198519052.4427.22.camel@localhost>
I will try to be more careful on patches formatting. I am newbie to this.
And thanks for all responding on christmas :-) Usually all people N/A at this
time.
It seems 2.6.24-rc6 + iptables 1.4.0 + iproute2-git working fine now.
On Mon, 24 Dec 2007 12:57:32 -0500, jamal wrote
> On Mon, 2007-24-12 at 09:48 -0800, Stephen Hemminger wrote:
> > On Mon, 24 Dec 2007 11:55:05 -0500
>
> > Is this backwards compatible with older kernels?
>
> Yes.
> Denys change adds forward compat (although iptables in 1.4 is not fully
> backward compatible).
>
> cheers,
> jamal
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.
^ permalink raw reply
* Re: [PATCH] net: santize headers for iproute2
From: Stephen Hemminger @ 2007-12-25 20:43 UTC (permalink / raw)
To: David Miller; +Cc: vgusev, netdev
In-Reply-To: <20071224.220527.254578945.davem@davemloft.net>
> net/tcp_states.h is not movable to include/linux/ and thus to
> userspace, it defines things that are present already in existing
> userland header files. If you look, <netinet/tcp.h> defines these
> state values, as an enumeration. If you need the TCPF_* flag bit
> versions, sorry... you'll need to find some other way to get those
> into userspace.
The problem is that iproute ss.c needs linux/tcp.h to get the tcp_info
structure definition but linux/tcp.h has incompatible definitions with netinet/tcp.h.
I propose that the enum be moved from net/tcp_states.h to linux/tcp.h.
--
Stephen Hemminger <stephen.hemminger@vyatta.com>
^ permalink raw reply
* [PATCH] veth: move veth.h to include/linux
From: Stephen Hemminger @ 2007-12-25 20:46 UTC (permalink / raw)
To: David Miller, vgusev; +Cc: netdev
In-Reply-To: <20071224.220527.254578945.davem@davemloft.net>
Move veth.h from net/ to linux/ since it is a user api, and
add it to user header processing Kbuild.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
--- a/drivers/net/veth.c 2007-12-25 12:30:56.000000000 -0800
+++ b/drivers/net/veth.c 2007-12-25 12:31:38.000000000 -0800
@@ -15,7 +15,7 @@
#include <net/dst.h>
#include <net/xfrm.h>
-#include <net/veth.h>
+#include <linux/veth.h>
#define DRV_NAME "veth"
#define DRV_VERSION "1.0"
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ b/include/linux/veth.h 2007-10-16 16:48:20.000000000 -0700
@@ -0,0 +1,12 @@
+#ifndef __NET_VETH_H_
+#define __NET_VETH_H_
+
+enum {
+ VETH_INFO_UNSPEC,
+ VETH_INFO_PEER,
+
+ __VETH_INFO_MAX
+#define VETH_INFO_MAX (__VETH_INFO_MAX - 1)
+};
+
+#endif
--- a/include/net/veth.h 2007-12-25 12:33:49.000000000 -0800
+++ /dev/null 1970-01-01 00:00:00.000000000 +0000
@@ -1,12 +0,0 @@
-#ifndef __NET_VETH_H_
-#define __NET_VETH_H_
-
-enum {
- VETH_INFO_UNSPEC,
- VETH_INFO_PEER,
-
- __VETH_INFO_MAX
-#define VETH_INFO_MAX (__VETH_INFO_MAX - 1)
-};
-
-#endif
--- a/include/linux/Kbuild 2007-12-25 12:44:59.000000000 -0800
+++ b/include/linux/Kbuild 2007-12-25 12:45:31.000000000 -0800
@@ -342,6 +342,7 @@ unifdef-y += unistd.h
unifdef-y += usbdevice_fs.h
unifdef-y += user.h
unifdef-y += utsname.h
+unifdef-y += veth.h
unifdef-y += videodev2.h
unifdef-y += videodev.h
unifdef-y += virtio_config.h
^ permalink raw reply
* Re: ipv4_devconf.arp_accept mystery
From: Benny Amorsen @ 2007-12-25 22:08 UTC (permalink / raw)
To: netdev
In-Reply-To: <E1J6mmW-0006dP-00@gondolin.me.apana.org.au>
Herbert Xu <herbert@gondor.apana.org.au> writes:
> As the name suggests you should use
>
> /proc/sys/net/ipv4/conf/all/arp_accept
The documentation says that if arp_accept is 0, unsolicited arp
replies are dropped. Doesn't that interfere with failover services
such as vrrp, keepalived, ucarp etc? I thought they did unsolicited
arp when failing over.
/Benny
^ permalink raw reply
* Re: [PATCH] veth: move veth.h to include/linux
From: Sam Ravnborg @ 2007-12-25 22:23 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, vgusev, netdev
In-Reply-To: <20071225124656.723c2db6@deepthought>
On Tue, Dec 25, 2007 at 12:46:56PM -0800, Stephen Hemminger wrote:
> Move veth.h from net/ to linux/ since it is a user api, and
> add it to user header processing Kbuild.
>
> Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
>
> --- a/drivers/net/veth.c 2007-12-25 12:30:56.000000000 -0800
> +++ b/drivers/net/veth.c 2007-12-25 12:31:38.000000000 -0800
> @@ -15,7 +15,7 @@
>
> #include <net/dst.h>
> #include <net/xfrm.h>
> -#include <net/veth.h>
> +#include <linux/veth.h>
>
> #define DRV_NAME "veth"
> #define DRV_VERSION "1.0"
> --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> +++ b/include/linux/veth.h 2007-10-16 16:48:20.000000000 -0700
> @@ -0,0 +1,12 @@
> +#ifndef __NET_VETH_H_
> +#define __NET_VETH_H_
> +
> +enum {
> + VETH_INFO_UNSPEC,
> + VETH_INFO_PEER,
> +
> + __VETH_INFO_MAX
> +#define VETH_INFO_MAX (__VETH_INFO_MAX - 1)
> +};
> +
> +#endif
> --- a/include/net/veth.h 2007-12-25 12:33:49.000000000 -0800
> +++ /dev/null 1970-01-01 00:00:00.000000000 +0000
> @@ -1,12 +0,0 @@
> -#ifndef __NET_VETH_H_
> -#define __NET_VETH_H_
> -
> -enum {
> - VETH_INFO_UNSPEC,
> - VETH_INFO_PEER,
> -
> - __VETH_INFO_MAX
> -#define VETH_INFO_MAX (__VETH_INFO_MAX - 1)
> -};
> -
> -#endif
> --- a/include/linux/Kbuild 2007-12-25 12:44:59.000000000 -0800
> +++ b/include/linux/Kbuild 2007-12-25 12:45:31.000000000 -0800
> @@ -342,6 +342,7 @@ unifdef-y += unistd.h
> unifdef-y += usbdevice_fs.h
> unifdef-y += user.h
> unifdef-y += utsname.h
> +unifdef-y += veth.h
> unifdef-y += videodev2.h
> unifdef-y += videodev.h
> unifdef-y += virtio_config.h
Someone will argue that you should use header-y +=
because the file has no conditionals removed by unifdef.
My personal opinion is that we should kill header-y and
I had patches to greatly improve all this but they got
lost by accident and I have not yet redone them.
Sam
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] via-velocity big-endian support
From: Francois Romieu @ 2007-12-25 22:43 UTC (permalink / raw)
To: Al Viro; +Cc: netdev, jgarzik
In-Reply-To: <20071224050659.GS8181@ftp.linux.org.uk>
Al Viro <viro@ftp.linux.org.uk> :
[...]
> diff --git a/drivers/net/via-velocity.h b/drivers/net/via-velocity.h
> index aa91796..e0ec5d4 100644
> --- a/drivers/net/via-velocity.h
> +++ b/drivers/net/via-velocity.h
> @@ -196,26 +196,29 @@
> * Receive descriptor
> */
>
> +#define DESC_OWNER cpu_to_le16(0x8000)
> +
DESC_OWNER does not seem to be used.
[...]
> +enum {
> + RX_INTEN = __constant_cpu_to_le16(0x8000)
> +};
Can we avoid using cpu_to_leXY here for consistency sake within the driver
(and among different drivers as well) ?
--
Ueimor
^ permalink raw reply
* Re: [PATCH] via-velocity big-endian support
From: Al Viro @ 2007-12-25 22:56 UTC (permalink / raw)
To: Francois Romieu; +Cc: Al Viro, netdev, jgarzik
In-Reply-To: <20071225224333.GA21585@electric-eye.fr.zoreil.com>
On Tue, Dec 25, 2007 at 11:43:33PM +0100, Francois Romieu wrote:
> > +#define DESC_OWNER cpu_to_le16(0x8000)
> > +
>
> DESC_OWNER does not seem to be used.
*nod*
That should be removed.
> [...]
> > +enum {
> > + RX_INTEN = __constant_cpu_to_le16(0x8000)
> > +};
>
> Can we avoid using cpu_to_leXY here for consistency sake within the driver
> (and among different drivers as well) ?
???
What is the problem with having such constants? If you mean "could we
use cpu_to_le16() instead of __constant_cpu_to_le16()", the answer's
no - that's one of the very few places where __constant_.... form is
needed (other are case <...>: and initializers for non-auto variables).
^ permalink raw reply
* Re: [PATCH] net: santize headers for iproute2
From: David Miller @ 2007-12-25 23:02 UTC (permalink / raw)
To: shemminger; +Cc: vgusev, netdev
In-Reply-To: <20071225124323.70e0c772@deepthought>
From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Tue, 25 Dec 2007 12:43:23 -0800
> The problem is that iproute ss.c needs linux/tcp.h to get the
> tcp_info structure definition but linux/tcp.h has incompatible
> definitions with netinet/tcp.h. I propose that the enum be moved
> from net/tcp_states.h to linux/tcp.h.
This would be fragile, at best.
We need to solve this in a way such that both linux/tcp.h and
netinet/tcp.h can both be included at the same time by userland.
If we export linux/tcp.h to userspace, we have to make it play nice
with the existing header file namespace.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox