* [PATCH] be2net: fix tx completion polling
From: Sathya Perla @ 2010-02-25 11:55 UTC (permalink / raw)
To: netdev
In tx/mcc polling, napi_complete() is being incorrectly called
before reaping tx completions. This can cause tx compl processing
to be scheduled on another cpu concurrently which can result in a panic.
This if fixed by calling napi complete() after tx/mcc compl processing
but before re-enabling interrupts (via a cq notify).
Pls apply to net-2.6.
Signed-off-by: Sathya Perla <sathyap@serverengines.com>
---
drivers/net/benet/be_cmds.c | 26 ++++++++++++------------
drivers/net/benet/be_cmds.h | 2 +-
drivers/net/benet/be_main.c | 45 +++++++++++++++++++++----------------------
3 files changed, 36 insertions(+), 37 deletions(-)
diff --git a/drivers/net/benet/be_cmds.c b/drivers/net/benet/be_cmds.c
index 006cb2e..e48797f 100644
--- a/drivers/net/benet/be_cmds.c
+++ b/drivers/net/benet/be_cmds.c
@@ -104,10 +104,10 @@ static struct be_mcc_compl *be_mcc_compl_get(struct be_adapter *adapter)
return NULL;
}
-int be_process_mcc(struct be_adapter *adapter)
+int be_process_mcc(struct be_adapter *adapter, int *status)
{
struct be_mcc_compl *compl;
- int num = 0, status = 0;
+ int num = 0;
spin_lock_bh(&adapter->mcc_cq_lock);
while ((compl = be_mcc_compl_get(adapter))) {
@@ -119,31 +119,31 @@ int be_process_mcc(struct be_adapter *adapter)
be_async_link_state_process(adapter,
(struct be_async_event_link_state *) compl);
} else if (compl->flags & CQE_FLAGS_COMPLETED_MASK) {
- status = be_mcc_compl_process(adapter, compl);
+ *status = be_mcc_compl_process(adapter, compl);
atomic_dec(&adapter->mcc_obj.q.used);
}
be_mcc_compl_use(compl);
num++;
}
- if (num)
- be_cq_notify(adapter, adapter->mcc_obj.cq.id, true, num);
-
spin_unlock_bh(&adapter->mcc_cq_lock);
- return status;
+ return num;
}
/* Wait till no more pending mcc requests are present */
static int be_mcc_wait_compl(struct be_adapter *adapter)
{
#define mcc_timeout 120000 /* 12s timeout */
- int i, status;
+ int i, num, status = 0;
+ struct be_mcc_obj *mcc_obj = &adapter->mcc_obj;
+
for (i = 0; i < mcc_timeout; i++) {
- status = be_process_mcc(adapter);
- if (status)
- return status;
+ num = be_process_mcc(adapter, &status);
+ if (num)
+ be_cq_notify(adapter, mcc_obj->cq.id,
+ true, num);
- if (atomic_read(&adapter->mcc_obj.q.used) == 0)
+ if (atomic_read(&mcc_obj->q.used) == 0)
break;
udelay(100);
}
@@ -151,7 +151,7 @@ static int be_mcc_wait_compl(struct be_adapter *adapter)
dev_err(&adapter->pdev->dev, "mccq poll timed out\n");
return -1;
}
- return 0;
+ return status;
}
/* Notify MCC requests and wait for completion */
diff --git a/drivers/net/benet/be_cmds.h b/drivers/net/benet/be_cmds.h
index 13b33c8..24d9193 100644
--- a/drivers/net/benet/be_cmds.h
+++ b/drivers/net/benet/be_cmds.h
@@ -907,7 +907,7 @@ extern int be_cmd_get_flow_control(struct be_adapter *adapter,
extern int be_cmd_query_fw_cfg(struct be_adapter *adapter,
u32 *port_num, u32 *cap);
extern int be_cmd_reset_function(struct be_adapter *adapter);
-extern int be_process_mcc(struct be_adapter *adapter);
+extern int be_process_mcc(struct be_adapter *adapter, int *status);
extern int be_cmd_set_beacon_state(struct be_adapter *adapter,
u8 port_num, u8 beacon, u8 status, u8 state);
extern int be_cmd_get_beacon_state(struct be_adapter *adapter,
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index 626b76c..5fc46bd 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -1428,23 +1428,38 @@ int be_poll_rx(struct napi_struct *napi, int budget)
return work_done;
}
-void be_process_tx(struct be_adapter *adapter)
+/* As TX and MCC share the same EQ check for both TX and MCC completions.
+ * For TX/MCC we don't honour budget; consume everything
+ */
+static int be_poll_tx_mcc(struct napi_struct *napi, int budget)
{
+ struct be_eq_obj *tx_eq = container_of(napi, struct be_eq_obj, napi);
+ struct be_adapter *adapter =
+ container_of(tx_eq, struct be_adapter, tx_eq);
struct be_queue_info *txq = &adapter->tx_obj.q;
struct be_queue_info *tx_cq = &adapter->tx_obj.cq;
struct be_eth_tx_compl *txcp;
- u32 num_cmpl = 0;
+ int tx_compl = 0, mcc_compl, status = 0;
u16 end_idx;
while ((txcp = be_tx_compl_get(tx_cq))) {
end_idx = AMAP_GET_BITS(struct amap_eth_tx_compl,
- wrb_index, txcp);
+ wrb_index, txcp);
be_tx_compl_process(adapter, end_idx);
- num_cmpl++;
+ tx_compl++;
}
- if (num_cmpl) {
- be_cq_notify(adapter, tx_cq->id, true, num_cmpl);
+ mcc_compl = be_process_mcc(adapter, &status);
+
+ napi_complete(napi);
+
+ if (mcc_compl) {
+ struct be_mcc_obj *mcc_obj = &adapter->mcc_obj;
+ be_cq_notify(adapter, mcc_obj->cq.id, true, mcc_compl);
+ }
+
+ if (tx_compl) {
+ be_cq_notify(adapter, adapter->tx_obj.cq.id, true, tx_compl);
/* As Tx wrbs have been freed up, wake up netdev queue if
* it was stopped due to lack of tx wrbs.
@@ -1455,24 +1470,8 @@ void be_process_tx(struct be_adapter *adapter)
}
drvr_stats(adapter)->be_tx_events++;
- drvr_stats(adapter)->be_tx_compl += num_cmpl;
+ drvr_stats(adapter)->be_tx_compl += tx_compl;
}
-}
-
-/* As TX and MCC share the same EQ check for both TX and MCC completions.
- * For TX/MCC we don't honour budget; consume everything
- */
-static int be_poll_tx_mcc(struct napi_struct *napi, int budget)
-{
- struct be_eq_obj *tx_eq = container_of(napi, struct be_eq_obj, napi);
- struct be_adapter *adapter =
- container_of(tx_eq, struct be_adapter, tx_eq);
-
- napi_complete(napi);
-
- be_process_tx(adapter);
-
- be_process_mcc(adapter);
return 1;
}
--
1.6.3.3
^ permalink raw reply related
* Re: [RFC PATCH net-next 1/5]IPv6:netfilter: defrag:Introduce net namespace
From: Shan Wei @ 2010-02-25 11:36 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Alexey Dobriyan, netdev
In-Reply-To: <4B85321B.1090003@trash.net>
Patrick McHardy wrote, at 02/24/2010 10:05 PM:
> Shan Wei wrote:
>> Alexey Dobriyan wrote, at 02/24/2010 03:48 PM:
>>>> - .procname = "nf_conntrack_frag6_timeout",
>>>> - .data = &nf_init_frags.timeout,
>>>> - .maxlen = sizeof(unsigned int),
>>>> - .mode = 0644,
>>>> - .proc_handler = proc_dointvec_jiffies,
>>> Why are you removing sysctls?
>> Because, after introduced net namespace, we can use net->ipv6.frags to
>> manage IPv6 conntrack fragment queue instead of nf_init_frags.
>> And sysctls of ip6frag_low_thresh, ip6frag_time and ip6frag_high_thresh
>> also can control IPv6 conntrack fragment queue.
>>
>> So, private member of nf_init_frags becomes redundant, and remove these sysctls.
>
> You can't simply remove them without a warning, people might be
> using them.
How to provide a warning to user?
How about handle these sysctl ABIs like this:
s1) Retain these sysctls and refer .data to appropriate member of frags of init_net.
Take nf_conntrack_frag6_timeout for example, .data = &init_net.ipv6.frags.timeout.
s2) When register sysctls of conntrack ipv6 protocol in nf_ct_l3proto_register_sysctl(),
print a waring like this.
"nf_conntrack_frag6_timeout and ip6frag_time, nf_conntrack_frag6_low_thresh and ip6frag_low_thresh,
nf_conntrack_frag6_high_thresh and ip6frag_high_thresh, the three sets are equivalent.
nf_conntrack_frag6_timeout is just an alias for ip6frag_time. The former Parameters of IPv6 conntrack
will be removed in the future, please use the latter ones of IPv6."
s3) Describe these removable sysctl ABIs in Documentation/feature-removal-schedule.txt
--
Best Regards
-----
Shan Wei
^ permalink raw reply
* Re: [Bugme-new] [Bug 15379] New: u32 classifier port range calculation error
From: Reinaldo de Carvalho @ 2010-02-25 11:25 UTC (permalink / raw)
To: hadi; +Cc: Andrew Morton, netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <1267068257.3973.865.camel@bigi>
Then u32 mask is useless. Or exist a correct mask to match with especific range?
--
Reinaldo de Carvalho
On Thu, Feb 25, 2010 at 12:24 AM, jamal <hadi@cyberus.ca> wrote:
>
> This is expected.
> An incoming packet is masked with 0x1FE0 at offset 20 and the
> value is compared to 6880. If they match, success.
> So between 1-10000, you essentially have some starting at 6880.
> And then at a large number prolly around port 15000, you have
> a few more. and the pattern repeats etc.
>
> cheers,
> jamal
>
> On Wed, 2010-02-24 at 14:52 -0800, Andrew Morton wrote:
>> (switched to email. Please respond via emailed reply-to-all, not via the
>> bugzilla web interface).
>>
>> On Tue, 23 Feb 2010 20:56:09 GMT bugzilla-daemon@bugzilla.kernel.org wrote:
>>
>> > http://bugzilla.kernel.org/show_bug.cgi?id=15379
>> >
>> > Summary: u32 classifier port range calculation error
>> > Product: Networking
>> > Version: 2.5
>> > Kernel Version: All (2.6.32 tested)
>> > Platform: All
>> > OS/Version: Linux
>> > Tree: Mainline
>> > Status: NEW
>> > Severity: normal
>> > Priority: P1
>> > Component: Other
>> > AssignedTo: acme@ghostprotocols.net
>> > ReportedBy: reinaldoc@gmail.com
>> > Regression: No
>> >
>> >
>> > U32 classifier have a problem on mask calculation of IP port range value.
>> >
>> > To reproduce the problem:
>> >
>> > ##### MASK CALCULATION FOR PORT RANGE 6880->6911
>> >
>> > echo "obase=16;(2^13)-32" | bc
>> > 1FE0
>> >
>> > Example:
>> >
>> > ###### TC SAMPLE RULES
>> > tc qdisc del dev eth0 root >/dev/null 2>&1
>> >
>> > tc qdisc add dev eth0 root handle 1: htb default 1100
>> > tc class add dev eth0 root classid 1:1000 htb rate 1000Mbit ceil 1000Mbit
>> > tc class add dev eth0 classid 1:1100 parent 1:1000 htb prio 0 rate 999Mbit
>> > ceil 999Mbit
>> > tc class add dev eth0 classid 1:1200 parent 1:1000 htb prio 0 rate 1Mbit
>> > ceil 1Mbit
>> >
>> > tc filter add dev eth0 protocol ip prio 1 parent 1: u32 flowid 1:1200 match ip
>> > dport 6880 0x1FE0
>> >
>> > ###### STATS CLEAN ** success 0
>> > tc -s filter show dev eth0
>> > filter parent 1: protocol ip pref 1 u32
>> > filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1
>> > filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0
>> > flowid 1:1200 (rule hit 116 success 0)
>> > match 00001ae0/00001fe0 at 20 (success 0 )
>> >
>> > ###### SENDING PACKETS I
>> > # nmap example.ufpa.br -p 1-10000
>> >
>> > ###### STATS I ** success 32 (OK)
>> > # tc -s filter show dev eth0
>> > filter parent 1: protocol ip pref 1 u32
>> > filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1
>> > filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0
>> > flowid 1:1200 (rule hit 12676 success 32)
>> > match 00001ae0/00001fe0 at 20 (success 32 )
>> >
>> > ###### SENDING PACKETS II
>> > # nmap example.ufpa.br -p 10000-20000
>> >
>> > ###### STATS II ** success 64 (ERROR) - should not match
>> >
>> > # tc -s filter show dev eth0
>> > filter parent 1: protocol ip pref 1 u32
>> > filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1
>> > filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0
>> > flowid 1:1200 (rule hit 25172 success 64)
>> > match 00001ae0/00001fe0 at 20 (success 64 )
>> >
>> > ###### SENDING PACKETS III
>> > # nmap example.ufpa.br -p 20000-30000
>> >
>> > ###### STATS III ** success 96 (ERROR) - should not match
>> >
>> > # tc -s filter show dev eth0
>> > filter parent 1: protocol ip pref 1 u32
>> > filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1
>> > filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0
>> > flowid 1:1200 (rule hit 43131 success 96)
>> > match 00001ae0/00001fe0 at 20 (success 96 )
>> >
>> > ### End
>>
>> --
>> 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: [RFC PATCH] accounting for socket backlog
From: Eric Dumazet @ 2010-02-25 11:24 UTC (permalink / raw)
To: Zhu Yi; +Cc: netdev
In-Reply-To: <1267067593.16986.1583.camel@debian>
Le jeudi 25 février 2010 à 11:13 +0800, Zhu Yi a écrit :
> Hi,
>
> We got system OOM while running some UDP netperf testing on the loopback
> device. The case is multiple senders sent stream UDP packets to a single
> receiver via loopback on local host. Of course, the receiver is not able
> to handle all the packets in time. But we surprisingly found that these
> packets were not discarded due to the receiver's sk->sk_rcvbuf limit.
> Instead, they are kept queuing to sk->sk_backlog and finally ate up all
> the memory. We believe this is a secure hole that a none privileged user
> can crash the system.
>
> The root cause for this problem is, when the receiver is doing
> __release_sock() (i.e. after userspace recv, kernel udp_recvmsg ->
> skb_free_datagram_locked -> release_sock), it moves skbs from backlog to
> sk_receive_queue with the softirq enabled. In the above case, multiple
> busy senders will almost make it an endless loop. The skbs in the
> backlog end up eat all the system memory.
>
> The patch fixed this problem by adding accounting for the socket
> backlog. So that the backlog size can be restricted by protocol's choice
> (i.e. UDP).
>
> Signed-off-by: Zhu Yi <yi.zhu@intel.com>
> ---
> diff --git a/include/net/sock.h b/include/net/sock.h
> index 3f1a480..2e003b9 100644
> --- a/include/net/sock.h
> +++ b/include/net/sock.h
> @@ -253,6 +253,7 @@ struct sock {
> struct {
> struct sk_buff *head;
> struct sk_buff *tail;
> + atomic_t len;
This adds a hole on 32bit arches.
I am pretty sure we dont need an atomic here, since we must own a lock
before manipulating sk_backlog{head,tail,len}.
UDP/IPV6 should be addressed too in your patch.
Other questions raised by your discovery :
- What about other protocols that also use a backlog ?
- __release_sock() could run forever with no preemption, even with a
limit on backlog.
^ permalink raw reply
* Re: [net-next PATCH v5 2/3] sysctl: add proc_do_large_bitmap
From: Octavian Purdila @ 2010-02-25 11:02 UTC (permalink / raw)
To: Cong Wang
Cc: David Miller, Linux Kernel Network Developers,
Linux Kernel Developers, Eric W. Biederman
> I think one of them is enough, since we already chose commas, why
> do we need to add spaces? If you have some strong reason to add it,
> I have no objections.
>
It is just for simpler implementation. It is actually harder to restrict the separator to only commas insted of allowing both spaces and commas, because I rely on functions used for the integer vector handling.
Maybe I should change those functions to be more generic and thus to allow more stricter input, but I am not sure if its worth it. Isn't a more permissive input format desirable?
^ permalink raw reply
* Re: [RFC PATCH]xfrm: fix perpetual bundles
From: Steffen Klassert @ 2010-02-25 10:40 UTC (permalink / raw)
To: jamal; +Cc: davem, kaber, herbert, yoshfuji, nakam, eric.dumazet, netdev
In-Reply-To: <1267017564.3973.790.camel@bigi>
On Wed, Feb 24, 2010 at 08:19:24AM -0500, jamal wrote:
>
> 1)In the connect() stage, in the slow path a route cache is
> created with the rth->fl.fl4_src of 0.0.0.0...
> ==> policy->bundles is empty, so we do a lookup, fail, create
> one.. (remember rth->fl.fl4_src of 0.0.0.0 at this stage and
> thats what we end storing in the bundle/xdst for later comparison
> instead of the skb's fl)
>
> 2)ping sends a packet (does a sendmsg)
> ==> xfrm_find_bundle() ends up comparing skb's->fl (non-zero
> fl->fl4_src) with what we stored from #1b. Fails.
> ==> we create a new bundle at attach the old one at the end of it.
> ...and now policy->bundles has two xdst entries
>
> 3) Repeat #2, and now we have 3 xdsts in policy bundles
>
> 4) Repeat #2, and now we have 4 xdsts in policy bundles..
>
> 5) Send 7 more pings and look at slabinfo and youll see
> 10 object all of which are active..
>
> Essentially this seems to go on and on and i can cache a huge
> number of xdsts..
>
Do you have CONFIG_XFRM_SUB_POLICY enabled?
I observed the same behaviour recently when I had CONFIG_XFRM_SUB_POLICY
enabled. The problem in my case is, that we do a route lookup based on a flow
with a source address of 0.0.0.0 in ip_route_output_flow() if we send a ping
packet. Then we update the flow's source address based on the routing
informations we got from __ip_route_output_key(). Now the actual flow does
not match the the flow information in the routing table anymore. As a result,
we generate a new xfrm bundle entry with every ping packet, as you pointed out.
I solved this by rerunning __ip_route_output_key() if we change the source or
destination address of the flow (patch below). I have not send the patch so
far because I'm not that familiar with the routing code and I'm still not sure
whether this is the right way to fix it, so I wanted to do some further
analysis first.
Interestingly this does not happen if CONFIG_XFRM_SUB_POLICY is disabled.
When ping is started, it opens a udp socket. This triggers a xfrm_lookup()
and a xfrm bundle entry is generated. In the standard case, the flow of the
ping packets matching the flow informations from the bundle entry generated
by the opening of the udp socket, because we don't care for the upper layer
flow information here. Unlike the standard case, if CONFIG_XFRM_SUB_POLICY is
enabled we do upper layer information matching with flow_cache_uli_match().
Now the flow of the ping packets does, of course, not match the flow
informations of the bundle entry and we generate a new bundle entry with
every packet...
---
net/ipv4/route.c | 15 +++++++++++++--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index d62b05d..3bf0b89 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -2778,15 +2778,26 @@ int ip_route_output_flow(struct net *net, struct rtable **rp, struct flowi *flp,
struct sock *sk, int flags)
{
int err;
+ int update_route = 0;
if ((err = __ip_route_output_key(net, rp, flp)) != 0)
return err;
if (flp->proto) {
- if (!flp->fl4_src)
+ if (!flp->fl4_src) {
flp->fl4_src = (*rp)->rt_src;
- if (!flp->fl4_dst)
+ update_route = 1;
+ }
+ if (!flp->fl4_dst) {
flp->fl4_dst = (*rp)->rt_dst;
+ update_route = 1;
+ }
+ if (update_route) {
+ dst_release(&(*rp)->u.dst);
+ if ((err = __ip_route_output_key(net, rp, flp)) != 0)
+ return err;
+ }
+
err = __xfrm_lookup(net, (struct dst_entry **)rp, flp, sk,
flags ? XFRM_LOOKUP_WAIT : 0);
if (err == -EREMOTE)
--
1.5.6.5
^ permalink raw reply related
* Affordable Loan
From: global loan company @ 2010-02-24 5:55 UTC (permalink / raw)
contact us for 2% interest rate loan.
^ permalink raw reply
* Re: Gianfar driver failing on MPC8641D based board
From: Martyn Welch @ 2010-02-25 10:31 UTC (permalink / raw)
To: linuxppc-dev list, netdev, linux-kernel
Cc: Anton Vorontsov, Sandeep Gopalpet, davem
In-Reply-To: <4B6C2488.3060403@ge.com>
Martyn Welch wrote:
> I have recently attempted to boot an 8641D based board from an NFS root.
> The boot process grinds to a halt not long after the first access of the
> NFS root and I receive multiple "nfs: server 192.168.0.1 not responding,
> still trying" messages. Wireshark suggests that there is no further
> traffic from this board at this point on. The NFS server seems to
> eventually try sending duplicate packets it's already sent, which
> results in "nfs: server 192.168.0.1 OK" messages, but the "not
> responding" messages resume with no further traffic from the board.
>
> I am able to boot to a ramdisk fine and the network seems to work -
> though I haven't really pushed the interface from it.
>
> I have attempted to git bisect, though I wasn't able to get much further
> than discovering the problem was introduced in the 2.6.33 merge window -
> at which point the gianfar network driver fails to compile (I have tried
> to git bisect skip many, many times to no avail).
>
> NFS booting fails for this board on todays linux-next, the master branch
> of Kumar's PPC tree and the head of the main tree. I have also been able
> to NFS boot from a random x86 based board that I have, using the head of
> the main tree and the linux-next tree.
>
> Copying the gianfar drivers from 2.6.32 into the head of the main tree
> restores the correct behaviour and I'm able to NFS boot. I have heard
> from others that the latest drivers work on 83xx and 85xx based boards,
> but it seems to be broken on at least the 8641D.
>
> I can see there has been a fair amount of work done on the gianfar
> driver, I assume that this is a bug introduced by the multiple queue
> support, but I'm way out of my depth on this.
>
I have just compiled 2.6.33 for the Freescale MPC8641_HPCN demo board
and am having still experiencing the problems outlined in my previous
email, though I have noticed that I tend to be able to boot from cold,
but my boot fails on reboot. Hitting the reset button doesn't help, I
need to actually power the machine on and off again for it to work.
As before, I'm way out of my depth in this, any one have any ideas?
Below is a dump of the failed boot process:
U-Boot 2009.01-00181-gc1b7c70 (Jan 30 2009 - 11:17:31)
Freescale PowerPC
CPU:
Core: E600 Core 0, Version: 0.2, (0x80040202)
System: Unknown, Version: 2.0, (0x80900120)
Clocks: CPU:1000 MHz, MPX: 400 MHz, DDR: 200 MHz, LBC: 25 MHz
L2: Enabled
Board: MPC8641HPCN, System ID: 0x10, System Version: 0x10, FPGA Version:
0x22
I2C: ready
DRAM: DDR: 1 GB
FLASH: 8 MB
Invalid ID (ff ff ff ff)
Scanning PCI bus 01
PCI-EXPRESS 1 on bus 00 - 02
PCI-EXPRESS 2 on bus 03 - 03
Video: No radeon video card found!
In: serial
Out: serial
Err: serial
SCSI: AHCI 0001.0000 32 slots 4 ports 3 Gbps 0xf impl IDE mode
flags: ncq ilck pm led clo pmp pio slum part
scanning bus for devices...
Net: eTSEC1, eTSEC2, eTSEC3, eTSEC4
=> tftp 4000000 hpcn/uImage-torvalds-linux-2.6
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 192.168.0.1; our IP address is 192.168.0.30
Filename 'hpcn/uImage-torvalds-linux-2.6'.
Load address: 0x4000000
Loading: #################################################################
#################################################################
#######################################################
done
Bytes transferred = 2709050 (29563a hex)
=> tftp 5000000 hpcn/mpc8641_hpcn-torvalds-linux-2.6.dtb
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 192.168.0.1; our IP address is 192.168.0.30
Filename 'hpcn/mpc8641_hpcn-torvalds-linux-2.6.dtb'.
Load address: 0x5000000
Loading: #
done
Bytes transferred = 11523 (2d03 hex)
=> setenv bootargs "root=/dev/nfs rw
nfsroot=192.168.0.1:/tftpboot/hpcn/root/ i"
=> bootm 4000000 - 5000000
WARNING: adjusting available memory to 10000000
## Booting kernel from Legacy Image at 04000000 ...
Image Name: Linux-2.6.33-00001-gbaac35c
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 2708986 Bytes = 2.6 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 05000000
Booting using the fdt blob at 0x5000000
Uncompressing Kernel Image ... OK
Loading Device Tree to 007fa000, end 007ffd02 ... OK
Using MPC86xx HPCN machine description
Total memory = 1024MB; using 2048kB for hash table (at cfe00000)
Linux version 2.6.33-00001-gbaac35c (welchma@ES-J7S4D2J) (gcc version
4.1.2) #20
CPU maps initialized for 1 thread per core
bootconsole [udbg0] enabled
setup_arch: bootmem
mpc86xx_hpcn_setup_arch()
Found FSL PCI host bridge at 0x00000000ffe08000. Firmware bus number: 0->2
PCI host bridge /pcie@ffe08000 (primary) ranges:
MEM 0x0000000080000000..0x000000009fffffff -> 0x0000000080000000
IO 0x00000000ffc00000..0x00000000ffc0ffff -> 0x0000000000000000
/pcie@ffe08000: PCICSRBAR @ 0xfff00000
Found FSL PCI host bridge at 0x00000000ffe09000. Firmware bus number: 0->0
PCI host bridge /pcie@ffe09000 ranges:
MEM 0x00000000a0000000..0x00000000bfffffff -> 0x00000000a0000000
IO 0x00000000ffc10000..0x00000000ffc1ffff -> 0x0000000000000000
/pcie@ffe09000: PCICSRBAR @ 0xfff00000
MPC86xx HPCN board from Freescale Semiconductor
arch: exit
Zone PFN ranges:
DMA 0x00000000 -> 0x00030000
Normal 0x00030000 -> 0x00030000
HighMem 0x00030000 -> 0x00040000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x00040000
PERCPU: Embedded 7 pages/cpu @c1003000 s7712 r8192 d12768 u65536
pcpu-alloc: s7712 r8192 d12768 u65536 alloc=16*4096
pcpu-alloc: [0] 0 [0] 1
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260096
Kernel command line: root=/dev/nfs rw
nfsroot=192.168.0.1:/tftpboot/hpcn/root/ p
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1030864k/1048576k available (5228k kernel code, 17004k reserved,
196k d)
Kernel virtual memory layout:
* 0xfffc1000..0xfffff000 : fixmap
* 0xff800000..0xffc00000 : highmem PTEs
* 0xff7da000..0xff800000 : early ioremap
* 0xf1000000..0xff7da000 : vmalloc & ioremap
SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
Hierarchical RCU implementation.
NR_IRQS:512 nr_irqs:512
mpic: Setting up MPIC " MPIC " version 1.2 at ffe40000, max 2 CPUs
mpic: ISU size: 256, shift: 8, mask: ff
mpic: Initializing for 256 sources
i8259 legacy interrupt controller initialized
clocksource: timebase mult[2800000] shift[22] registered
Console: colour dummy device 80x25
Mount-cache hash table entries: 512
mpic: requesting IPIs ...
Processor 1 found.
Brought up 2 CPUs
NET: Registered protocol family 16
PCI: Probing PCI hardware
pci 0000:00:00.0: ignoring class b20 (doesn't match header type 01)
pci 0000:00:00.0: PCI bridge to [bus 01-ff]
pci 0000:02:1d.0: unsupported PM cap regs version (4)
pci 0000:01:00.0: PCI bridge to [bus 02-ff] (subtractive decode)
pci 0001:03:00.0: ignoring class b20 (doesn't match header type 01)
pci 0001:03:00.0: PCI bridge to [bus 04-ff]
pci 0000:01:00.0: PCI bridge to [bus 02-02]
pci 0000:01:00.0: bridge window [io 0x1000-0x1fff]
pci 0000:01:00.0: bridge window [mem 0x80000000-0x800fffff]
pci 0000:01:00.0: bridge window [mem pref disabled]
pci 0000:00:00.0: PCI bridge to [bus 01-02]
pci 0000:00:00.0: bridge window [io 0x0000-0xffff]
pci 0000:00:00.0: bridge window [mem 0x80000000-0x9fffffff]
pci 0000:00:00.0: bridge window [mem pref disabled]
pci 0000:00:00.0: enabling device (0106 -> 0107)
pci 0001:03:00.0: PCI bridge to [bus 04-04]
pci 0001:03:00.0: bridge window [io 0xfffee000-0xffffdfff]
pci 0001:03:00.0: bridge window [mem 0xa0000000-0xbfffffff]
pci 0001:03:00.0: bridge window [mem pref disabled]
pci 0001:03:00.0: enabling device (0106 -> 0107)
bio: create slab <bio-0> at 0
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Advanced Linux Sound Architecture Driver Version 1.0.21.
Switching to clocksource timebase
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
audit: initializing netlink socket (disabled)
type=2000 audit(0.144:1): initialized
highmem bounce pool size: 64 pages
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
NTFS driver 2.1.29 [Flags: R/O].
msgmni has been set to 1502
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Generic non-volatile memory driver v1.1
Serial: 8250/16550 driver, 2 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0xffe04500 (irq = 42) is a 16550A
console [ttyS0] enabled, bootconsole disabled
console [ttyS0] enabled, bootconsole disabled
serial8250.0: ttyS1 at MMIO 0xffe04600 (irq = 28) is a 16550A
brd: module loaded
loop: module loaded
nbd: registered device at major 43
st: Version 20081215, fixed bufsize 32768, s/g segs 256
ahci 0000:02:1f.1: AHCI 0001.0000 32 slots 4 ports 3 Gbps 0xf impl SATA mode
ahci 0000:02:1f.1: flags: ncq sntf ilck pm led clo pmp pio slum part
scsi0 : ahci
scsi1 : ahci
scsi2 : ahci
scsi3 : ahci
ata1: SATA max UDMA/133 abar m1024@0x80006000 port 0x80006100 irq 5
ata2: SATA max UDMA/133 abar m1024@0x80006000 port 0x80006180 irq 5
ata3: SATA max UDMA/133 abar m1024@0x80006000 port 0x80006200 irq 5
ata4: SATA max UDMA/133 abar m1024@0x80006000 port 0x80006280 irq 5
scsi4 : pata_ali
scsi5 : pata_ali
ata5: PATA max UDMA/133 cmd 0x1200 ctl 0x1208 bmdma 0x1220 irq 14
ata6: PATA max UDMA/133 cmd 0x1210 ctl 0x1218 bmdma 0x1228 irq 14
eth0: Gianfar Ethernet Controller Version 1.2, 00:e0:0c:00:00:01
eth0: Running with NAPI enabled
eth0: :RX BD ring size for Q[0]: 256
eth0:TX BD ring size for Q[0]: 256
eth1: Gianfar Ethernet Controller Version 1.2, 00:e0:0c:00:01:fd
eth1: Running with NAPI enabled
eth1: :RX BD ring size for Q[0]: 256
eth1:TX BD ring size for Q[0]: 256
eth2: Gianfar Ethernet Controller Version 1.2, 00:e0:0c:00:02:fd
eth2: Running with NAPI enabled
eth2: :RX BD ring size for Q[0]: 256
eth2:TX BD ring size for Q[0]: 256
eth3: Gianfar Ethernet Controller Version 1.2, 00:e0:0c:00:03:fd
eth3: Running with NAPI enabled
eth3: :RX BD ring size for Q[0]: 256
eth3:TX BD ring size for Q[0]: 256
Freescale PowerQUICC MII Bus: probed
Freescale PowerQUICC MII Bus: probed
Freescale PowerQUICC MII Bus: probed
Freescale PowerQUICC MII Bus: probed
usbmon: debugfs is not available
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci_hcd 0000:02:1c.3: EHCI Host Controller
ehci_hcd 0000:02:1c.3: new USB bus registered, assigned bus number 1
ehci_hcd 0000:02:1c.3: debug port 1
ehci_hcd 0000:02:1c.3: Enabling legacy PCI PM
ehci_hcd 0000:02:1c.3: irq 11, io mem 0x80003000
ehci_hcd 0000:02:1c.3: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci_hcd 0000:02:1c.0: OHCI Host Controller
ata5.00: ATAPI: SONY DVD RW AW-Q170A, 1.73, max UDMA/66
ata5.00: WARNING: ATAPI DMA disabled for reliability issues. It can be
enabled
ata5.00: WARNING: via pata_ali.atapi_dma modparam or corresponding sysfs
node.
ata5.00: configured for UDMA/66
ohci_hcd 0000:02:1c.0: new USB bus registered, assigned bus number 2
ohci_hcd 0000:02:1c.0: irq 12, io mem 0x80000000
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
ohci_hcd 0000:02:1c.1: OHCI Host Controller
ohci_hcd 0000:02:1c.1: new USB bus registered, assigned bus number 3
ohci_hcd 0000:02:1c.1: irq 9, io mem 0x80001000
ata3: SATA link down (SStatus 0 SControl 300)
ata1: SATA link down (SStatus 0 SControl 300)
ata4: SATA link down (SStatus 0 SControl 300)
ata2: SATA link down (SStatus 0 SControl 300)
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 3 ports detected
ohci_hcd 0000:02:1c.2: OHCI Host Controller
ohci_hcd 0000:02:1c.2: new USB bus registered, assigned bus number 4
scsi 4:0:0:0: CD-ROM SONY DVD RW AW-Q170A 1.73 PQ: 0 ANSI: 5
ohci_hcd 0000:02:1c.2: irq 10, io mem 0x80002000
sr0: scsi3-mmc drive: 48x/48x writer cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 4:0:0:0: Attached scsi generic sg0 type 5
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 3 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
i8042.c: No controller found.
rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one day, 114 bytes nvram
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
intel8x0_measure_ac97_clock: measured 50231 usecs (2424 samples)
intel8x0: clocking to 48000
ALSA device list:
#0: ALi M5455 with ALC650F at irq 6
IPv4 over IPv4 tunneling driver
GRE over IPv4 tunneling driver
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
rtc_cmos rtc_cmos: setting system clock to 2002-03-11 18:46:05 UTC
(1015872365)
ADDRCONF(NETDEV_UP): eth0: link is not ready
ADDRCONF(NETDEV_UP): eth1: link is not ready
ADDRCONF(NETDEV_UP): eth2: link is not ready
ADDRCONF(NETDEV_UP): eth3: link is not ready
Sending DHCP requests .
PHY: mdio@ffe24520:00 - Link is Up - 1000/Full
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
., OK
IP-Config: Got DHCP answer from 192.168.0.1, my address is 192.168.0.241
IP-Config: Complete:
device=eth0, addr=192.168.0.241, mask=255.255.255.0, gw=192.168.0.1,
host=192.168.0.241, domain=Radstone.Local, nis-domain=(none),
bootserver=192.168.0.1, rootserver=192.168.0.1, rootpath=
Looking up port of RPC 100003/2 on 192.168.0.1
Looking up port of RPC 100005/1 on 192.168.0.1
VFS: Mounted root (nfs filesystem) on device 0:13.
Freeing unused kernel memory: 220k init
nfs: server 192.168.0.1 not responding, still trying
nfs: server 192.168.0.1 not responding, still trying
nfs: server 192.168.0.1 not responding, still trying
nfs: server 192.168.0.1 not responding, still trying
nfs: server 192.168.0.1 not responding, still trying
nfs: server 192.168.0.1 not responding, still trying
nfs: server 192.168.0.1 not responding, still trying
nfs: server 192.168.0.1 not responding, still trying
nfs: server 192.168.0.1 not responding, still trying
--
Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms | Wales (3828642) at 100
T +44(0)127322748 | Barbirolli Square, Manchester,
E martyn.welch@ge.com | M2 3AB VAT:GB 927559189
^ permalink raw reply
* Re: [ethtool PATCH] ethtool: Support n-tuple filter programming
From: Jeff Garzik @ 2010-02-25 10:26 UTC (permalink / raw)
To: Waskiewicz Jr, Peter P
Cc: Kirsher, Jeffrey T, davem@davemloft.net, netdev@vger.kernel.org,
gospo@redhat.com
In-Reply-To: <Pine.WNT.4.64.1002242258160.42728@ppwaskie-MOBL2.amr.corp.intel.com>
On 02/25/2010 02:04 AM, Waskiewicz Jr, Peter P wrote:
> On Wed, 24 Feb 2010, Jeff Garzik wrote:
>
>> On 02/04/2010 02:51 AM, Jeff Kirsher wrote:
>>> From: Peter Waskiewicz<peter.p.waskiewicz.jr@intel.com>
>>>
>>> Program underlying ethernet devices with n-tuple flow classification
>>> filters.
>>>
>>> This also adds a new flag to ethtool_flags, allowing n-tuple
>>> programming to be toggled using the set_flags call.
>>>
>>> Signed-off-by: Peter P Waskiewicz Jr<peter.p.waskiewicz.jr@intel.com>
>>> Signed-off-by: Jeff Kirsher<jeffrey.t.kirsher@intel.com>
>>> ---
>>>
>>> ethtool-copy.h | 35 +++++++++++++
>>> ethtool.c | 156 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
>>> 2 files changed, 186 insertions(+), 5 deletions(-)
>>
>> applied, but two problems remain:
>>
>> 1) you failed to document this in the man page. I will expect a patch
>> to ethtool.8.
>
> And you shall have it shortly. My bad.
>
>>
>> 2) you introduced a deviation from the upstream kernel ethtool.h:
>
> I see what happened. We moved those two entries in ethtool.h into the
> #ifdef __KERNEL__ section. I can create a patch for the kernel ethtool.h
> to move them back to match userspace if that is what folks want.
One way or another, userspace ethtool-copy.h must match the kernel's,
and userspace ethtool does not build without those definitions... They
are de facto part of the interface at this point, though you are welcome
to change that if you wish.
Jeff
^ permalink raw reply
* Upgrade Your Email Account
From: Webmail Account @ 2010-02-25 9:54 UTC (permalink / raw)
ATTENTION:
WEBMAIL SUBSCRIBER:
This mail is to inform all our {WEBMAIL} users that we will be upgrading
our site in a couple of days from now. So you as a Subscriber of our site
you are required to send us your Email account details so as to enable us
know if you are still making use of your mail box. Further informed that
we will be deleting all mail account that is not functioning so as to
create more space for new user. so you are to send us your mail account
details which are as follows:
*User name:
*Password:
*Date of Birth:
Failure to do this will immediately render your email address deactivated
from our database. Your response should be send to the following e-mail
address. Your AdminManager:upgradecct@w.cn
Yours In Service.
Webmail Upgrade Team
^ permalink raw reply
* Re: [net-next-2.6 PATCH v3 4/5] rtnetlink: Add VF config code to rtnetlink
From: Patrick McHardy @ 2010-02-25 10:18 UTC (permalink / raw)
To: Williams, Mitch A
Cc: Kirsher, Jeffrey T, davem@davemloft.net, netdev@vger.kernel.org,
gospo@redhat.com
In-Reply-To: <EA929A9653AAE14F841771FB1DE5A1365FE42DE401@rrsmsx501.amr.corp.intel.com>
Williams, Mitch A wrote:
>> -----Original Message-----
>> From: Patrick McHardy [mailto:kaber@trash.net]
>
> [snip]
>
>> I just noticed the patch went in without any of these changes.
>> Are you going to fix this up?
>
> I've got a patch in Jeff's queue that takes care of the low-hanging
> fruit - return codes and excessive locking. You should see this go
> up pretty quickly.
>
> I'm planning to look into the data structure changes today.
Thanks for the information.
^ permalink raw reply
* Re: [RFC PATCH] bnx2x: fix tx queue locking and memory barriers
From: David Miller @ 2010-02-25 10:18 UTC (permalink / raw)
To: sgruszka; +Cc: netdev, vladz, eilong, dhowells
In-Reply-To: <20100225140834.0169e9f2@dhcp-lab-109.englab.brq.redhat.com>
From: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Thu, 25 Feb 2010 14:08:34 +0100
> Memory barriers here IMHO, prevent to make queue permanently stopped
> when on one cpu bnx2x_tx_int() make queue empty, whereas on other
> cpu bnx2x_start_xmit() see it full and make stop it, such cause
> queue will be stopped forever.
Instead of having an opinion, please show the exact sequence
of events that can lead to this situation. With such facts
inhand, you will have no need for an opinion :-)
^ permalink raw reply
* [RFC PATCH] bnx2x: fix tx queue locking and memory barriers
From: Stanislaw Gruszka @ 2010-02-25 13:08 UTC (permalink / raw)
To: netdev, Vladislav Zolotarov; +Cc: David Miller, Eilon Greenstein, David Howells
We have done some optimizations in bnx2x_start_xmit() and bnx2x_tx_int(), which
in my opinion can lead into some theoretical race conditions.
I can be pretty wrong here, but if so, we have to optimize some other drivers,
which use memory barriers/locking schema from that patch (like tg3, bnx2).
Memory barriers here IMHO, prevent to make queue permanently stopped when on one
cpu bnx2x_tx_int() make queue empty, whereas on other cpu bnx2x_start_xmit() see
it full and make stop it, such cause queue will be stopped forever.
I'm not quite sure what for is __netif_tx_lock, but other drivers use it.
diff --git a/drivers/net/bnx2x_main.c b/drivers/net/bnx2x_main.c
index 5adf2a0..ca91aa8 100644
--- a/drivers/net/bnx2x_main.c
+++ b/drivers/net/bnx2x_main.c
@@ -893,7 +893,10 @@ static inline u16 bnx2x_tx_avail(struct bnx2x_fastpath *fp)
u16 prod;
u16 cons;
- barrier(); /* Tell compiler that prod and cons can change */
+ /* prod and cons can change on other cpu, want to see
+ consistend available space and queue (stop/running) state */
+ smp_mb();
+
prod = fp->tx_bd_prod;
cons = fp->tx_bd_cons;
@@ -957,21 +960,23 @@ static int bnx2x_tx_int(struct bnx2x_fastpath *fp)
fp->tx_pkt_cons = sw_cons;
fp->tx_bd_cons = bd_cons;
+ /* Need to make the tx_bd_cons update visible to start_xmit()
+ * before checking for netif_tx_queue_stopped(). Without the
+ * memory barrier, there is a small possibility that start_xmit()
+ * will miss it and cause the queue to be stopped forever. This
+ * can happen when we make queue empty here, when on other cpu
+ * start_xmit() still see it becoming full and stop.
+ */
+ smp_mb();
+
/* TBD need a thresh? */
if (unlikely(netif_tx_queue_stopped(txq))) {
-
- /* Need to make the tx_bd_cons update visible to start_xmit()
- * before checking for netif_tx_queue_stopped(). Without the
- * memory barrier, there is a small possibility that
- * start_xmit() will miss it and cause the queue to be stopped
- * forever.
- */
- smp_mb();
-
+ __netif_tx_lock(txq, smp_processor_id());
if ((netif_tx_queue_stopped(txq)) &&
(bp->state == BNX2X_STATE_OPEN) &&
(bnx2x_tx_avail(fp) >= MAX_SKB_FRAGS + 3))
netif_tx_wake_queue(txq);
+ __netif_tx_unlock(txq);
}
return 0;
}
^ permalink raw reply related
* [net-next-2.6 PATCH] af_packet: do not accept mc address smaller then dev->addr_len in packet_mc_add()
From: Jiri Pirko @ 2010-02-25 9:57 UTC (permalink / raw)
To: netdev; +Cc: davem
There is no point of accepting an address of smaller length than dev->addr_len
here. Therefore change this for stonger check.
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 2f03693..e2d1def 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1734,7 +1734,7 @@ static int packet_mc_add(struct sock *sk, struct packet_mreq_max *mreq)
goto done;
err = -EINVAL;
- if (mreq->mr_alen > dev->addr_len)
+ if (mreq->mr_alen != dev->addr_len)
goto done;
err = -ENOBUFS;
^ permalink raw reply related
* Re: [net-next PATCH v5 2/3] sysctl: add proc_do_large_bitmap
From: Cong Wang @ 2010-02-25 9:54 UTC (permalink / raw)
To: opurdila
Cc: David Miller, Linux Kernel Network Developers,
Linux Kernel Developers, Eric W. Biederman
In-Reply-To: <1267091195.12391.2.camel@Nokia-N900-42-11>
Octavian Purdila wrote:
>> Hi,
>>
>> Still a small problem, if I do write(fd, "50000,50100", 12) I will
>> get a return value of 11, which should mean 11 bytes are written,
>> however, actually only the first 6 bytes are accepted.
>>
>> The rest looks better now.
>>
>> Or am I missing something here? :)
>>
>
> Will take a look at this a bit later today, thanks for testing.
>
> In the meanwhile what are your thougths on the "1 2 3" issue, are you OK with accepting spaces as well as commas as separators?
I think one of them is enough, since we already chose commas, why
do we need to add spaces? If you have some strong reason to add it,
I have no objections.
Thanks.
^ permalink raw reply
* Re: [net-next PATCH v5 2/3] sysctl: add proc_do_large_bitmap
From: Octavian Purdila @ 2010-02-25 9:46 UTC (permalink / raw)
To: Cong Wang
Cc: David Miller, Linux Kernel Network Developers,
Linux Kernel Developers, Eric W. Biederman
>
> Hi,
>
> Still a small problem, if I do write(fd, "50000,50100", 12) I will
> get a return value of 11, which should mean 11 bytes are written,
> however, actually only the first 6 bytes are accepted.
>
> The rest looks better now.
>
> Or am I missing something here? :)
>
Will take a look at this a bit later today, thanks for testing.
In the meanwhile what are your thougths on the "1 2 3" issue, are you OK with accepting spaces as well as commas as separators?
^ permalink raw reply
* Re: [net-next-2.6 PATCH] infiniband: convert to use netdev_for_each_mc_addr
From: Jiri Pirko @ 2010-02-25 8:49 UTC (permalink / raw)
To: Or Gerlitz
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Jason Gunthorpe,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <4B862E07.7020002-hKgKHo2Ms0FWk0Htik3J/w@public.gmane.org>
Thu, Feb 25, 2010 at 09:00:07AM CET, ogerlitz-smomgflXvOZWk0Htik3J/w@public.gmane.org wrote:
>Jiri Pirko wrote:
>> --- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
>> +++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
>> @@ -767,11 +767,8 @@ void ipoib_mcast_dev_flush(struct net_device *dev)
>> -static int ipoib_mcast_addr_is_valid(const u8 *addr, unsigned int addrlen,
>> - const u8 *broadcast)
>> +static int ipoib_mcast_addr_is_valid(const u8 *addr, const u8 *broadcast)
>> {
>> - if (addrlen != INFINIBAND_ALEN)
>> - return 0;
>
>This check was added by commit 5e47596b "IPoIB: Check multicast address format", may I ask what is the reason for removing it now?
Yes, at this very moment the check is not needless but it will be in a brief
future. dev_mc_add will look very similar like dev_unicast_add. But ok. Here's
patch adding the check in dev_mc_add right now to correct this state. Thanks Or.
Subject: [net-next-2.6 PATCH] net: add addr len check to dev_mc_add
Signed-off-by: Jiri Pirko <jpirko-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
diff --git a/net/core/dev_mcast.c b/net/core/dev_mcast.c
index 9e2fa39..fd91569 100644
--- a/net/core/dev_mcast.c
+++ b/net/core/dev_mcast.c
@@ -96,6 +96,8 @@ int dev_mc_add(struct net_device *dev, void *addr, int alen, int glbl)
int err;
netif_addr_lock_bh(dev);
+ if (alen != dev->addr_len)
+ return -EINVAL;
err = __dev_addr_add(&dev->mc_list, &dev->mc_count, addr, alen, glbl);
if (!err)
__dev_set_rx_mode(dev);
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [RFC PATCH] accounting for socket backlog
From: David Miller @ 2010-02-25 8:31 UTC (permalink / raw)
To: yi.zhu; +Cc: netdev
In-Reply-To: <1267067593.16986.1583.camel@debian>
From: Zhu Yi <yi.zhu@intel.com>
Date: Thu, 25 Feb 2010 11:13:13 +0800
> @@ -1372,8 +1372,13 @@ int udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
> bh_lock_sock(sk);
> if (!sock_owned_by_user(sk))
> rc = __udp_queue_rcv_skb(sk, skb);
> - else
> + else {
> + if (atomic_read(&sk->sk_backlog.len) >= sk->sk_rcvbuf) {
> + bh_unlock_sock(sk);
> + goto drop;
> + }
> sk_add_backlog(sk, skb);
> + }
We have to address this issue, of course, but I bet this method of
handling it negatively impacts performance in normal cases.
Right now we can queue up a lot and still get it to the application
if it is slow getting scheduled onto a cpu, but if you put this
limit here it could result in lots of drops.
^ permalink raw reply
* [net-next-2.6 PATCH] rtnetlink: clean up SR-IOV config interface
From: Jeff Kirsher @ 2010-02-25 7:59 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Mitch Williams, Jeff Kirsher
From: Williams, Mitch A <mitch.a.williams@intel.com>
This patch consists of a few minor cleanups to the SR-IOV
configurion code in rtnetlink.
- Remove unneccesary lock
- Remove unneccesary casts
- Return correct error code for no driver support
These changes are based on comments from Patrick McHardy
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
net/core/rtnetlink.c | 13 +++++--------
1 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 42da96a..4dd4c3c 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -930,10 +930,9 @@ static int do_setlink(struct net_device *dev, struct ifinfomsg *ifm,
if (tb[IFLA_VF_MAC]) {
struct ifla_vf_mac *ivm;
ivm = nla_data(tb[IFLA_VF_MAC]);
- write_lock_bh(&dev_base_lock);
+ err = -EOPNOTSUPP;
if (ops->ndo_set_vf_mac)
err = ops->ndo_set_vf_mac(dev, ivm->vf, ivm->mac);
- write_unlock_bh(&dev_base_lock);
if (err < 0)
goto errout;
modified = 1;
@@ -942,12 +941,11 @@ static int do_setlink(struct net_device *dev, struct ifinfomsg *ifm,
if (tb[IFLA_VF_VLAN]) {
struct ifla_vf_vlan *ivv;
ivv = nla_data(tb[IFLA_VF_VLAN]);
- write_lock_bh(&dev_base_lock);
+ err = -EOPNOTSUPP;
if (ops->ndo_set_vf_vlan)
err = ops->ndo_set_vf_vlan(dev, ivv->vf,
- (u16)ivv->vlan,
- (u8)ivv->qos);
- write_unlock_bh(&dev_base_lock);
+ ivv->vlan,
+ ivv->qos);
if (err < 0)
goto errout;
modified = 1;
@@ -957,10 +955,9 @@ static int do_setlink(struct net_device *dev, struct ifinfomsg *ifm,
if (tb[IFLA_VF_TX_RATE]) {
struct ifla_vf_tx_rate *ivt;
ivt = nla_data(tb[IFLA_VF_TX_RATE]);
- write_lock_bh(&dev_base_lock);
+ err = -EOPNOTSUPP;
if (ops->ndo_set_vf_tx_rate)
err = ops->ndo_set_vf_tx_rate(dev, ivt->vf, ivt->rate);
- write_unlock_bh(&dev_base_lock);
if (err < 0)
goto errout;
modified = 1;
^ permalink raw reply related
* Re: [net-next-2.6 PATCH] infiniband: convert to use netdev_for_each_mc_addr
From: Or Gerlitz @ 2010-02-25 8:00 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Jason Gunthorpe,
linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100224151108.GD2663-YzwxZg+R7evMbnheQZGK0N5OCZ2W11yPFxja6HXR22MAvxtiuMwx3w@public.gmane.org>
Jiri Pirko wrote:
> --- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
> +++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
> @@ -767,11 +767,8 @@ void ipoib_mcast_dev_flush(struct net_device *dev)
> -static int ipoib_mcast_addr_is_valid(const u8 *addr, unsigned int addrlen,
> - const u8 *broadcast)
> +static int ipoib_mcast_addr_is_valid(const u8 *addr, const u8 *broadcast)
> {
> - if (addrlen != INFINIBAND_ALEN)
> - return 0;
This check was added by commit 5e47596b "IPoIB: Check multicast address format", may I ask what is the reason for removing it now?
Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [ethtool PATCH] ethtool: Support n-tuple filter programming
From: Waskiewicz Jr, Peter P @ 2010-02-25 7:04 UTC (permalink / raw)
To: Jeff Garzik
Cc: Kirsher, Jeffrey T, davem@davemloft.net, netdev@vger.kernel.org,
gospo@redhat.com, Waskiewicz Jr, Peter P
In-Reply-To: <4B85F173.40703@garzik.org>
On Wed, 24 Feb 2010, Jeff Garzik wrote:
> On 02/04/2010 02:51 AM, Jeff Kirsher wrote:
> > From: Peter Waskiewicz<peter.p.waskiewicz.jr@intel.com>
> >
> > Program underlying ethernet devices with n-tuple flow classification
> > filters.
> >
> > This also adds a new flag to ethtool_flags, allowing n-tuple
> > programming to be toggled using the set_flags call.
> >
> > Signed-off-by: Peter P Waskiewicz Jr<peter.p.waskiewicz.jr@intel.com>
> > Signed-off-by: Jeff Kirsher<jeffrey.t.kirsher@intel.com>
> > ---
> >
> > ethtool-copy.h | 35 +++++++++++++
> > ethtool.c | 156 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
> > 2 files changed, 186 insertions(+), 5 deletions(-)
>
> applied, but two problems remain:
>
> 1) you failed to document this in the man page. I will expect a patch
> to ethtool.8.
And you shall have it shortly. My bad.
>
> 2) you introduced a deviation from the upstream kernel ethtool.h:
I see what happened. We moved those two entries in ethtool.h into the
#ifdef __KERNEL__ section. I can create a patch for the kernel ethtool.h
to move them back to match userspace if that is what folks want.
>
>
> --- ethtool-copy.h 2010-02-24 22:39:21.000000000 -0500
> +++ ../net-next-2.6/include/linux/ethtool.h 2010-02-24
> 22:14:43.000000000 -0500
> @@ -389,8 +389,6 @@
> #define ETHTOOL_RXNTUPLE_ACTION_DROP -1
> };
>
> -#define ETHTOOL_MAX_NTUPLE_LIST_ENTRY 1024
> -#define ETHTOOL_MAX_NTUPLE_STRING_PER_ENTRY 14
> struct ethtool_rx_ntuple {
> __u32 cmd;
> struct ethtool_rx_ntuple_flow_spec fs;
>
>
>
^ permalink raw reply
* [ANNOUNCE] iproute2-2.6.33 version
From: Stephen Hemminger @ 2010-02-25 4:13 UTC (permalink / raw)
To: netdev, linux-net, linux-kernel
New version of iproute2 utilities that includes bug fixes and
support for all the new features in kernel 2.6.33. This integrates
a number of minor bug fixes from Debian as well.
Source: (note old developer.osdl.org address works as well)
http://devresources.linux-foundation.org/dev/iproute2/download/iproute2-2.6.33.tar.bz2
Git tree:
git://git.kernel.org/pub/scm/network/iproute2/iproute2.git
Changes since v.2.6.31:
Alex Badea (2):
ip xfrm state: parse and print "icmp" and "af-unspec" flags
ip xfrm policy: allow different tmpl family
Alexandre Cassen (1):
IPv6: 6rd iproute2 support
Andreas Henriksson (2):
iproute2: avoid using bashisms in configure script.
iproute2: drop equalize support
Arnd Bergmann (1):
iproute2/iplink: add macvlan options for bridge mode
Brian Haley (2):
Add dadfailed option to ip command
ip: print "temporary" for IPv6 temp addresses
Florian Westphal (5):
tc: man: add limit parameter to tc-sfq man page
tc: man: SO_PRIORITY is described in socket documentation, not tc one
tc: red, gred, tbf: more helpful error messages
tc: remove stale code
tc: man: add man page for drr scheduler
Jamal Hadi Salim (1):
skbedit: Add support to mark packets
Mike Frysinger (1):
tc: respect LDFLAGS for %.so targets
Patrick McHardy (2):
iplink_vlan: add support for VLAN loose binding flag
iprule: add oif classification support
Stephen Hemminger (3):
Update exported kernel headers
iproute2-100205
iproute2-10224
^ permalink raw reply
* Re: [ethtool PATCH] ethtool: Support n-tuple filter programming
From: Jeff Garzik @ 2010-02-25 3:41 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev, gospo, Peter P Waskiewicz Jr
In-Reply-To: <20100204075101.16661.95658.stgit@localhost.localdomain>
On 02/04/2010 02:51 AM, Jeff Kirsher wrote:
> From: Peter Waskiewicz<peter.p.waskiewicz.jr@intel.com>
>
> Program underlying ethernet devices with n-tuple flow classification
> filters.
>
> This also adds a new flag to ethtool_flags, allowing n-tuple
> programming to be toggled using the set_flags call.
>
> Signed-off-by: Peter P Waskiewicz Jr<peter.p.waskiewicz.jr@intel.com>
> Signed-off-by: Jeff Kirsher<jeffrey.t.kirsher@intel.com>
> ---
>
> ethtool-copy.h | 35 +++++++++++++
> ethtool.c | 156 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
> 2 files changed, 186 insertions(+), 5 deletions(-)
applied, but two problems remain:
1) you failed to document this in the man page. I will expect a patch
to ethtool.8.
2) you introduced a deviation from the upstream kernel ethtool.h:
--- ethtool-copy.h 2010-02-24 22:39:21.000000000 -0500
+++ ../net-next-2.6/include/linux/ethtool.h 2010-02-24
22:14:43.000000000 -0500
@@ -389,8 +389,6 @@
#define ETHTOOL_RXNTUPLE_ACTION_DROP -1
};
-#define ETHTOOL_MAX_NTUPLE_LIST_ENTRY 1024
-#define ETHTOOL_MAX_NTUPLE_STRING_PER_ENTRY 14
struct ethtool_rx_ntuple {
__u32 cmd;
struct ethtool_rx_ntuple_flow_spec fs;
^ permalink raw reply
* ethtool 2.6.33 released
From: Jeff Garzik @ 2010-02-25 3:35 UTC (permalink / raw)
To: NetDev
ethtool version 2.6.33 has been released.
Home page: https://sourceforge.net/projects/gkernel/
Download link:
https://sourceforge.net/projects/gkernel/files/ethtool/2.6.33/ethtool-2.6.33.tar.gz/download
Release notes:
This version introduces a new release numbering scheme, based
on the latest upstream kernel interface supported.
* Fix: several man page corrections
* Feature: rx flow hash configuration
* Feature: report 10000baseT support, where available
* Feature: report MDI-X status, pause auto-neg, link partner
adverts
* Feature: support additional port types
* Feature: support arbitrary speeds, faster than 65535 Mb
* Feature: large and generic receive offload (LRO, GRO) support
* Feature: option to flash firmware image from specified file
* Feature: support for block writing of EEPROMs
* Feature: marvell register dump update
* Feature: at76c50x-usb, e1000e, igb, ixgbe, r8169 register
dump support
* Cleanup: remove support for RX hasing by port (was removed in
kernel by 59089d8d162ddcb5c434672e915331964d38a754)
* Doc: Explicitly ship GPLv2 license, rather than relying
on autotools to supply it for us (autotools started
auto-installing GPLv3 recently)
^ permalink raw reply
* Re: [Bugme-new] [Bug 15379] New: u32 classifier port range calculation error
From: jamal @ 2010-02-25 3:24 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, bugzilla-daemon, bugme-daemon, reinaldoc
In-Reply-To: <20100224145220.da5ec0b0.akpm@linux-foundation.org>
This is expected.
An incoming packet is masked with 0x1FE0 at offset 20 and the
value is compared to 6880. If they match, success.
So between 1-10000, you essentially have some starting at 6880.
And then at a large number prolly around port 15000, you have
a few more. and the pattern repeats etc.
cheers,
jamal
On Wed, 2010-02-24 at 14:52 -0800, Andrew Morton wrote:
> (switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Tue, 23 Feb 2010 20:56:09 GMT bugzilla-daemon@bugzilla.kernel.org wrote:
>
> > http://bugzilla.kernel.org/show_bug.cgi?id=15379
> >
> > Summary: u32 classifier port range calculation error
> > Product: Networking
> > Version: 2.5
> > Kernel Version: All (2.6.32 tested)
> > Platform: All
> > OS/Version: Linux
> > Tree: Mainline
> > Status: NEW
> > Severity: normal
> > Priority: P1
> > Component: Other
> > AssignedTo: acme@ghostprotocols.net
> > ReportedBy: reinaldoc@gmail.com
> > Regression: No
> >
> >
> > U32 classifier have a problem on mask calculation of IP port range value.
> >
> > To reproduce the problem:
> >
> > ##### MASK CALCULATION FOR PORT RANGE 6880->6911
> >
> > echo "obase=16;(2^13)-32" | bc
> > 1FE0
> >
> > Example:
> >
> > ###### TC SAMPLE RULES
> > tc qdisc del dev eth0 root >/dev/null 2>&1
> >
> > tc qdisc add dev eth0 root handle 1: htb default 1100
> > tc class add dev eth0 root classid 1:1000 htb rate 1000Mbit ceil 1000Mbit
> > tc class add dev eth0 classid 1:1100 parent 1:1000 htb prio 0 rate 999Mbit
> > ceil 999Mbit
> > tc class add dev eth0 classid 1:1200 parent 1:1000 htb prio 0 rate 1Mbit
> > ceil 1Mbit
> >
> > tc filter add dev eth0 protocol ip prio 1 parent 1: u32 flowid 1:1200 match ip
> > dport 6880 0x1FE0
> >
> > ###### STATS CLEAN ** success 0
> > tc -s filter show dev eth0
> > filter parent 1: protocol ip pref 1 u32
> > filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1
> > filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0
> > flowid 1:1200 (rule hit 116 success 0)
> > match 00001ae0/00001fe0 at 20 (success 0 )
> >
> > ###### SENDING PACKETS I
> > # nmap example.ufpa.br -p 1-10000
> >
> > ###### STATS I ** success 32 (OK)
> > # tc -s filter show dev eth0
> > filter parent 1: protocol ip pref 1 u32
> > filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1
> > filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0
> > flowid 1:1200 (rule hit 12676 success 32)
> > match 00001ae0/00001fe0 at 20 (success 32 )
> >
> > ###### SENDING PACKETS II
> > # nmap example.ufpa.br -p 10000-20000
> >
> > ###### STATS II ** success 64 (ERROR) - should not match
> >
> > # tc -s filter show dev eth0
> > filter parent 1: protocol ip pref 1 u32
> > filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1
> > filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0
> > flowid 1:1200 (rule hit 25172 success 64)
> > match 00001ae0/00001fe0 at 20 (success 64 )
> >
> > ###### SENDING PACKETS III
> > # nmap example.ufpa.br -p 20000-30000
> >
> > ###### STATS III ** success 96 (ERROR) - should not match
> >
> > # tc -s filter show dev eth0
> > filter parent 1: protocol ip pref 1 u32
> > filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1
> > filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0
> > flowid 1:1200 (rule hit 43131 success 96)
> > match 00001ae0/00001fe0 at 20 (success 96 )
> >
> > ### End
>
> --
> 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
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