* Re: [PATCH RESEND] uts: Set default hostname to "localhost", rather than "(none)"
From: Valdis.Kletnieks @ 2011-04-12 2:47 UTC (permalink / raw)
To: Josh Triplett
Cc: David Miller, netdev, Serge E. Hallyn, Andrew Morton,
Linus Torvalds, linux-kernel
In-Reply-To: <20110411050155.GA2507@feather>
[-- Attachment #1: Type: text/plain, Size: 630 bytes --]
On Sun, 10 Apr 2011 22:01:59 PDT, Josh Triplett said:
> Change the default hostname to "localhost". This removes the need for
> the standard fallback, provides a useful default for systems that never
> call sethostname, and makes minimal systems that much more useful with
> less configuration.
Seems sane enough to me. Only possible objection I can think of is "if you're running
with 'init=/bin/sh' or similar config too crippled to run /bin/hostname, maybe your
network config *should* be intentionally toasted so you can't get further surprises".
I personally don't agree - just saying somebody might hold that position.
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* RE: [PATCH v2] net: r8169: convert to hw_features
From: hayeswang @ 2011-04-12 2:10 UTC (permalink / raw)
To: 'François Romieu',
'Michał Mirosław'
Cc: netdev, 'David Dillow'
In-Reply-To: <20110411184739.GA17331@electric-eye.fr.zoreil.com>
> From: François Romieu [mailto:romieu@fr.zoreil.com]
> Sent: Tuesday, April 12, 2011 2:48 AM
> To: Michał Mirosław
> Cc: netdev@vger.kernel.org; David Dillow; Hayeswang
> Subject: Re: [PATCH v2] net: r8169: convert to hw_features
>
>
> Hayes, I have a 8168c manual at hand. Do all 8168 have the
> same Tx descriptors layout ?
>
Yes, all 8168 have the same Tx descriptors layout except for 8168B series.
Best Regards,
Hayes
^ permalink raw reply
* Re: [Bugme-new] [Bug 32872] New: LLC PDU is dropped if skb is not linear
From: David Miller @ 2011-04-12 1:56 UTC (permalink / raw)
To: akpm; +Cc: vitalyb, bugzilla-daemon, bugme-daemon, netdev
In-Reply-To: <20110411164812.8f84f995.akpm@linux-foundation.org>
From: Andrew Morton <akpm@linux-foundation.org>
Date: Mon, 11 Apr 2011 16:48:12 -0700
> --- linux-2.6.32.36/net/llc/llc_input.c.orig 2009-12-03 05:51:21.000000000 +0200
> +++ linux-2.6.32.36/net/llc/llc_input.c 2011-04-08 08:57:29.000000000 +0300
> @@ -105,6 +105,11 @@
> if (unlikely(!pskb_may_pull(skb, sizeof(*pdu))))
> return 0;
>
> + if (skb->data_len != 0){
> + if (unlikely(skb_linearize(skb)))
> + return 0;
> + }
> +
> pdu = (struct llc_pdu_un *)skb->data;
> if ((pdu->ctrl_1 & LLC_PDU_TYPE_MASK) == LLC_PDU_TYPE_U)
> llc_len = 1;
>
>
> 2.6.32 is a pretty old kernel - we'll need to verify if current kernels
> have the same problem.
>
> Please don't send patches via bugzilla - it causes lots of problems
> with our usual patch management and review processes. It's preferred
> that patches be sent via email as per Documentation/SubmittingPatches,
> and that they include a Signed-off-by:, as described in that file.
The skb_tail_pointer() check in llc_fixup_skb() is beyond wonky and
honestly the source of the problems here.
I'd suggest instead:
diff --git a/net/llc/llc_input.c b/net/llc/llc_input.c
index 058f1e9..9032421 100644
--- a/net/llc/llc_input.c
+++ b/net/llc/llc_input.c
@@ -121,8 +121,7 @@ static inline int llc_fixup_skb(struct sk_buff *skb)
s32 data_size = ntohs(pdulen) - llc_len;
if (data_size < 0 ||
- ((skb_tail_pointer(skb) -
- (u8 *)pdu) - llc_len) < data_size)
+ !pskb_may_pull(skb, data_size))
return 0;
if (unlikely(pskb_trim_rcsum(skb, data_size)))
return 0;
^ permalink raw reply related
* Re: Kernel panic when using bridge
From: Stephen Hemminger @ 2011-04-12 1:31 UTC (permalink / raw)
To: Scot Doyle; +Cc: Hiroaki SHIMODA, netdev, Sebastian Nickel, Pallai Roland
In-Reply-To: <4DA39330.2030102@scotdoyle.com>
On Mon, 11 Apr 2011 18:48:00 -0500
Scot Doyle <lkml@scotdoyle.com> wrote:
> On 04/09/2011 02:19 AM, Hiroaki SHIMODA wrote:
> >
> > It seems that the bug trap is occurred in ip_options_compile() due to
> > rt is NULL.
> >
> > 8b 96 cc 00 00 00 mov 0xcc(%rsi),%edx
> > rsi is rt, and 0xcc means rt->rt_spec_dst. So I think below code hit
> > the bug trap.
> >
> > 332 if (skb) {
> > 333 memcpy(&optptr[optptr[2]-1],&rt->rt_spec_dst, 4);<- here
> > 334 opt->is_changed = 1;
> > 335 }
> >
> > And call trace seems as follows.
> > __netif_receive_skb()
> > -> br_handle_frame()
> > -> NF_HOOK()
> > -> br_nf_pre_routing()
> > -> br_parse_ip_options()
> > -> ip_options_compile()
> >
> > br_parse_ip_options() was introduced at 462fb2a (bridge : Sanitize
> > skb before it enters the IP stack) but ip_options_compile() or
> > ip_options_rcv_srr() seems to be called with no rt info.
>
> Thanks to a tip from Sebastian, I can now reproduce this panic by
> running "IP Stack Integrity Checker v0.07" from another machine on the
> same subnet with command "icmpsic -s x.y.z.a -d x.y.z.b" where "x.y.z.a"
> is IP address of the other machine and "x.y.z.b" is the IP address of
> the target. When I enable iptables logging on the target machine, no
> panic occurs. When I disable iptables logging (but otherwise leave the
> same iptables rules) a panic occurs within a few seconds.
>
> Thanks Hiroaki for the analysis of the kernel panic output. I've
> confirmed that you are correct by placing a printk just before those two
> lines. In every panic, the printk was triggered on line 333 of
> net/ipv4/ip_options.c
>
> The kernel panic does not occur after applying the following patch.
>
> # diff net/ipv4/ip_options.c.original net/ipv4/ip_options.c.fix
> 332c332
> < if (skb) {
> ---
> > if (skb && rt) {
> 374c374
> < if (skb) {
> ---
> > if (skb && rt) {
>
> What do you all think? Will it cause other problems?
It would help if you gave a little more context (like diff -up)
next time.
I think the correct fix is for the skb handed to ip_compile_options
to match the layout expected by ip_compile_options.
This patch is compile tested only, please validate.
Subject: [PATCH] bridge: set pseudo-route table before calling ip_comple_options
For some ip options, ip_compile_options assumes it can find the associated
route table. The bridge to iptables code doesn't supply the necessary
reference causing NULL dereference.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
Patch against net-next-2.6, but if validated should go to net-2.6
and stable.
--- a/net/bridge/br_netfilter.c 2011-04-11 18:18:22.534837859 -0700
+++ b/net/bridge/br_netfilter.c 2011-04-11 18:25:15.427244826 -0700
@@ -221,6 +221,7 @@ static int br_parse_ip_options(struct sk
struct ip_options *opt;
struct iphdr *iph;
struct net_device *dev = skb->dev;
+ struct rtable *rt;
u32 len;
iph = ip_hdr(skb);
@@ -255,6 +256,14 @@ static int br_parse_ip_options(struct sk
return 0;
}
+ /* Associate bogus bridge route table */
+ rt = bridge_parent_rtable(dev);
+ if (!rt) {
+ kfree_skb(skb);
+ return 0;
+ }
+ skb_dst_set(skb, &rt->dst);
+
opt->optlen = iph->ihl*4 - sizeof(struct iphdr);
if (ip_options_compile(dev_net(dev), opt, skb))
goto inhdr_error;
^ permalink raw reply
* RE: Low performance Intel 10GE NIC (3.2.10) on 2.6.38 Kernel
From: Wei Gu @ 2011-04-12 1:22 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Alexander Duyck, netdev, Kirsher, Jeffrey T
In-Reply-To: <1302536577.4605.1.camel@edumazet-laptop>
I was not stress the NIC/CPU, since I only send 290Kpps 400byte packets towards eth10. the CPU load almost 100%IDEL.
BTW, there are some problem with perf tool on 2.6.35.2, I will try to get you the top offenders if possible.
Thanks
WeiGu
-----Original Message-----
From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
Sent: Monday, April 11, 2011 11:43 PM
To: Wei Gu
Cc: Alexander Duyck; netdev; Kirsher, Jeffrey T
Subject: RE: Low performance Intel 10GE NIC (3.2.10) on 2.6.38 Kernel
Le lundi 11 avril 2011 à 23:14 +0800, Wei Gu a écrit :
> I tried the ixgbe-3.3.8 (insmod ixgbe.ko RSS=8,8,8,8,8,8,8,8 FdirMode=0,0,0,0,0,0,0,0 Node=0,0,1,1,2,2,3,3) from e1000.sf.net both on 2.6.35.1 and 2.6.35.2, same observation as 3.2.10 ixgbe driver, On 2.6.35.2 it have high rx errors:
> Ethtool -S eth10 |grep error
> rx_errors: 0
> tx_errors: 0
> rx_over_errors: 0
> rx_crc_errors: 0
> rx_frame_errors: 0
> rx_fifo_errors: 0
> rx_missed_errors: 2263088
> tx_aborted_errors: 0
> tx_carrier_errors: 0
> tx_fifo_errors: 0
> tx_heartbeat_errors: 0
> rx_long_length_errors: 0
> rx_short_length_errors: 0
> rx_csum_offload_errors: 0
> fcoe_last_errors: 0
>
It would be nice you post perf record / perf report results
During your stress , do
perf record -a -g sleep 10
perf report
And post "top offenders"
Thanks
^ permalink raw reply
* RE: [net-next-2.6 RFC PATCH] ethtool: allow custom interval for physical identification
From: Allan, Bruce W @ 2011-04-12 1:07 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Stephen Hemminger, netdev@vger.kernel.org
In-Reply-To: <1302566453.5282.585.camel@localhost>
>-----Original Message-----
>From: Ben Hutchings [mailto:bhutchings@solarflare.com]
>Sent: Monday, April 11, 2011 5:01 PM
>To: Allan, Bruce W
>Cc: Stephen Hemminger; netdev@vger.kernel.org
>Subject: RE: [net-next-2.6 RFC PATCH] ethtool: allow custom interval for
>physical identification
>
>I noticed that some drivers did this. Do you know if these OEMs expect
>this of all hardware, or do they actually want different vendors'
>hardware to blink in different ways? If it's a common requirement to
>blink at 2 Hz then let's use that frequency for all the drivers that
>want to be called periodically.
>
>Ben.
Sorry, I don't know. I'll ask around, but doubt I will get a definitive
answer.
FWIW, without digging too deep into how other drivers identify their
respective ports through software, it appears it was split:
* bnx2*, cxgb3, niu, s2io, sfc, sky2, tg3 - once per second
* e100*, igb, ixgb*, pcnet32, ewrk3, cxgb4 - approx. twice per second
AFAIK for parts that can set the physical identification through hardware,
the Intel drivers set the on/off intervals to approximately twice/second;
I don't know what other drivers do in that situation.
So, I would guess it is not a common requirement to blink at a specific Hz.
I have no problem with changing the hard-coded blink frequency to what our
OEMs expect, but that might be an issue for those other vendors; I was just
trying to make it flexible.
Thanks,
Bruce.
^ permalink raw reply
* Re: Race condition when creating multiple namespaces?
From: Eric W. Biederman @ 2011-04-12 0:27 UTC (permalink / raw)
To: Hans Schillstrom; +Cc: netdev, Daniel Lezcano
In-Reply-To: <201104112301.46776.hans@schillstrom.com>
Hans Schillstrom <hans@schillstrom.com> writes:
> Hello
> I'v been strugling with this for some time now
>
> When creating multiple namespaces using lxc-start, un-initialized network namespace parts will be called by the new process in the namespace.
> ex. when using conntrack or ipvsadm to quickly, (a sleep 2 "solves" the problem).
> (From what I can see syscall clone() is used in lx-start i.e. do_fork will be called later on.)
> Actually I was debugging ip_vs when closing multiple ns when I fell into this one.
>
> I have a loop that create 33 containers whith lxc-start ... -- test.sh
> the first thing the new conatiner does in test.sh is
> #!/bin/bash
> iptables -t mangle -A PREROUTING -m conntrack --ctstate RELATED,ESTABLISHED -j CONNMARK --restore-mark
> nc -l -p1234
>
> This results in NULL ptr in ip_conntrack_net_init(struct *net)
Ouch!
> and in anoither test test.sh looks like this
> #!/bin/bash
> ipvsadm --start-daemon=master --mcast-interface=lo
> nc -l -p1234
>
> And this results in an uniitialized spinlock in ip_vs_sync
>
> I put a printk in nsproxy: copy_namespaces() and could see a dozens of them
> before anything appears from ipvs or conntrack.
>
> My feeling is that when you start up user processes in a new name space,
> all kernel related init should have been done (you should not need to add a sleep to get it working)
>
> All test made by using todays net-next-2.6 (2.6.39-rc1)
>
> Note:
> That neither conntrack or ip_vs modules where loaded,
> if modules where loaded before creating new namespaces it all works...
>
> Finally the question,
> Should it really work to load modules within a namespace ,
> that is a part of netns ?
>From an implementation point of view kernel modules are not in a
namespace, so there should be no difference between being in a namespace
and loading a kernel networking module and not being in a namespace and
loading in a kernel module.
It does sound like you have hit a module loading race, and perhaps
a race that is confined to network namespaces.
My head is in another problem so I won't be able to look at this for
a bit. But if you are getting into ip_conntrack_net_init with
a NULL network namespace something spectacularly bad is happening.
In particular it looks like you must be hitting a bug in for_each_net.
Which would pretty much have to be a race in adding or removing from
net_namespace_list.
I took a quick skim through the code and whenever we modify the
net_namespace we hold but the net_mutex and inside it the rtnl_lock so I
don't immediate see how you could be getting a NULL net into
ip_conntrack_net_init.
Is there a codepath besides register_pernet_subsys that is calling
ip_conntrack_net_init?
Do you have any local modifications that could be messing up register_pernet_subsys?
Eric
^ permalink raw reply
* Re: [Bugme-new] [Bug 33102] New: File's copied from client->linux server only copy 1st 64K data; rest is lost
From: Steve French @ 2011-04-12 0:06 UTC (permalink / raw)
To: Linda Walsh
Cc: Andrew Morton, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-cifs-u79uwXL29TY76Z2rM5mHXA,
bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r,
bugme-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r
In-Reply-To: <4DA3839B.1050102-gT3AUAsYRbTYtjvyW6yDsg@public.gmane.org>
On Mon, Apr 11, 2011 at 5:41 PM, Linda Walsh <lkml-gT3AUAsYRbTYtjvyW6yDsg@public.gmane.org> wrote:
>
> Andrew Morton wrote:
>>
>> (switched to email. Please respond via emailed reply-to-all, not via the
>> bugzilla web interface).
>>
>> On Mon, 11 Apr 2011 22:12:41 GMT
>> bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r@public.gmane.org wrote:
>>>
>>> https://bugzilla.kernel.org/show_bug.cgi?id=33102
>>>
>>> Summary: File's copied from client->linux server only copy 1st
>>> 64K data;rest is lost
>>> Product: Networking
>>> Version: 2.5
>>> Kernel Version: 2.6.38.2
>>> Platform: All
>>> OS/Version: Linux
>>> Tree: Mainline
>>> Status: NEW
>>> Severity: blocking
>>> Priority: P1
>>> Component: IPV4
>>> AssignedTo: shemminger-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org
>>> ReportedBy: lkml-gT3AUAsYRbTYtjvyW6yDsg@public.gmane.org
>>> Regression: Yes
>>>
>>
>> Seems to be a 2.6.37->2.6.38 regression.
>>
>> ----------
>
> Not exactly -- Please note -- I tried both 2.6.38(.0) and 2.6.38.1.
>
> They both work.
Any chance that we could get a wireshark trace of the failure?
https://wiki.samba.org/index.php/Capture_Packets
gives instructions. There may also be useful information on
network stack failures returned in the samba log
(often named smbd.log).
--
Thanks,
Steve
^ permalink raw reply
* RE: [net-next-2.6 RFC PATCH] ethtool: allow custom interval for physical identification
From: Ben Hutchings @ 2011-04-12 0:00 UTC (permalink / raw)
To: Allan, Bruce W; +Cc: Stephen Hemminger, netdev@vger.kernel.org
In-Reply-To: <8DD2590731AB5D4C9DBF71A877482A90018A2A30A9@orsmsx509.amr.corp.intel.com>
On Mon, 2011-04-11 at 16:30 -0700, Allan, Bruce W wrote:
> >-----Original Message-----
> >From: Stephen Hemminger [mailto:shemminger@vyatta.com]
> >Sent: Monday, April 11, 2011 4:26 PM
> >To: Allan, Bruce W
> >Cc: netdev@vger.kernel.org
> >Subject: Re: [net-next-2.6 RFC PATCH] ethtool: allow custom interval for
> >physical identification
> >
> >On Mon, 11 Apr 2011 16:16:35 -0700
> >Bruce Allan <bruce.w.allan@intel.com> wrote:
> >
> >> When physical identification of an adapter is done by toggling the
> >> mechanism on and off through software utilizing the .set_phys_id operation,
> >> it is done with a fixed duration for both on and off states. Some drivers
> >> may want to set a custom duration for the on/off intervals. This patch
> >> changes the API so the return code from the driver's entry point can
> >> specify the interval duration as a positive number; -EINVAL is still
> >> allowed in order to use the default single on/off interval per second.
> >>
> >> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> >
> >IMHO this is -EOVERKILL.
>
> I realize it does seem like that, but we have OEMs that expect the LEDs to
> blink a certain way during a physical identification (twice a second vs.
> once a second per the original .set_phys_id patchset). There may be other
> drivers from different hardware vendors that have similar but different
> requirements.
I noticed that some drivers did this. Do you know if these OEMs expect
this of all hardware, or do they actually want different vendors'
hardware to blink in different ways? If it's a common requirement to
blink at 2 Hz then let's use that frequency for all the drivers that
want to be called periodically.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] ethtool: time to blink provided in seconds not jiffies
From: Ben Hutchings @ 2011-04-11 23:57 UTC (permalink / raw)
To: Bruce Allan; +Cc: netdev
In-Reply-To: <20110411230159.6727.91380.stgit@gitlad.jf.intel.com>
On Mon, 2011-04-11 at 16:01 -0700, Bruce Allan wrote:
> When blinking for a duration set by the user, the value specified is in
> seconds but it is used as the number of jiffies in the timeout after which
> the Physical ID indicator is deactivated. Fix by converting the timeout
> to seconds.
D'oh.
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Acked-by: Ben Hutchings <bhutchings@solarflare.com>
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [Bugme-new] [Bug 32872] New: LLC PDU is dropped if skb is not linear
From: Andrew Morton @ 2011-04-11 23:48 UTC (permalink / raw)
To: vitalyb; +Cc: bugzilla-daemon, bugme-daemon, netdev
In-Reply-To: <bug-32872-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Fri, 8 Apr 2011 09:52:34 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=32872
>
> Summary: LLC PDU is dropped if skb is not linear
> Product: Networking
> Version: 2.5
> Kernel Version: 2.6.32
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Other
> AssignedTo: acme@ghostprotocols.net
> ReportedBy: vitalyb@telenet.dn.ua
> Regression: No
>
>
> If skb consists of several fragments this check fails
> net/llc/llc_input.c:
> =============================================
> llc_fixup_skb()
> ...
> pdu = (struct llc_pdu_un *)skb->data;
> ...
> __be16 pdulen = eth_hdr(skb)->h_proto;
> s32 data_size = ntohs(pdulen) - llc_len;
>
> if (data_size < 0 ||
> ((skb_tail_pointer(skb) -
> (u8 *)pdu) - llc_len) < data_size)
> return 0;
> =============================================
>
> and packet is silently dropped.
>
> This breaks GVRP protocol if received packet is large ( > 512 bytes on my
> system) and contains a Leave All message. Since Leave All is missed,
> corresponding JoinIns are not sent and switch unregisters VLANs from port.
>
> Attached patch seems to resolve this issue, but I don't know if it's a correct
> solution.
--- linux-2.6.32.36/net/llc/llc_input.c.orig 2009-12-03 05:51:21.000000000 +0200
+++ linux-2.6.32.36/net/llc/llc_input.c 2011-04-08 08:57:29.000000000 +0300
@@ -105,6 +105,11 @@
if (unlikely(!pskb_may_pull(skb, sizeof(*pdu))))
return 0;
+ if (skb->data_len != 0){
+ if (unlikely(skb_linearize(skb)))
+ return 0;
+ }
+
pdu = (struct llc_pdu_un *)skb->data;
if ((pdu->ctrl_1 & LLC_PDU_TYPE_MASK) == LLC_PDU_TYPE_U)
llc_len = 1;
2.6.32 is a pretty old kernel - we'll need to verify if current kernels
have the same problem.
Please don't send patches via bugzilla - it causes lots of problems
with our usual patch management and review processes. It's preferred
that patches be sent via email as per Documentation/SubmittingPatches,
and that they include a Signed-off-by:, as described in that file.
Thanks.
^ permalink raw reply
* Re: Kernel panic when using bridge
From: Scot Doyle @ 2011-04-11 23:48 UTC (permalink / raw)
To: Hiroaki SHIMODA, Stephen Hemminger
Cc: netdev, Sebastian Nickel, Pallai Roland
In-Reply-To: <20110409161908.a2aca120.shimoda.hiroaki@gmail.com>
On 04/09/2011 02:19 AM, Hiroaki SHIMODA wrote:
>
> It seems that the bug trap is occurred in ip_options_compile() due to
> rt is NULL.
>
> 8b 96 cc 00 00 00 mov 0xcc(%rsi),%edx
> rsi is rt, and 0xcc means rt->rt_spec_dst. So I think below code hit
> the bug trap.
>
> 332 if (skb) {
> 333 memcpy(&optptr[optptr[2]-1],&rt->rt_spec_dst, 4);<- here
> 334 opt->is_changed = 1;
> 335 }
>
> And call trace seems as follows.
> __netif_receive_skb()
> -> br_handle_frame()
> -> NF_HOOK()
> -> br_nf_pre_routing()
> -> br_parse_ip_options()
> -> ip_options_compile()
>
> br_parse_ip_options() was introduced at 462fb2a (bridge : Sanitize
> skb before it enters the IP stack) but ip_options_compile() or
> ip_options_rcv_srr() seems to be called with no rt info.
Thanks to a tip from Sebastian, I can now reproduce this panic by
running "IP Stack Integrity Checker v0.07" from another machine on the
same subnet with command "icmpsic -s x.y.z.a -d x.y.z.b" where "x.y.z.a"
is IP address of the other machine and "x.y.z.b" is the IP address of
the target. When I enable iptables logging on the target machine, no
panic occurs. When I disable iptables logging (but otherwise leave the
same iptables rules) a panic occurs within a few seconds.
Thanks Hiroaki for the analysis of the kernel panic output. I've
confirmed that you are correct by placing a printk just before those two
lines. In every panic, the printk was triggered on line 333 of
net/ipv4/ip_options.c
The kernel panic does not occur after applying the following patch.
# diff net/ipv4/ip_options.c.original net/ipv4/ip_options.c.fix
332c332
< if (skb) {
---
> if (skb && rt) {
374c374
< if (skb) {
---
> if (skb && rt) {
What do you all think? Will it cause other problems?
^ permalink raw reply
* RE: [net-next-2.6 RFC PATCH] ethtool: allow custom interval for physical identification
From: Allan, Bruce W @ 2011-04-11 23:30 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev@vger.kernel.org
In-Reply-To: <20110411162601.6686f169@nehalam>
>-----Original Message-----
>From: Stephen Hemminger [mailto:shemminger@vyatta.com]
>Sent: Monday, April 11, 2011 4:26 PM
>To: Allan, Bruce W
>Cc: netdev@vger.kernel.org
>Subject: Re: [net-next-2.6 RFC PATCH] ethtool: allow custom interval for
>physical identification
>
>On Mon, 11 Apr 2011 16:16:35 -0700
>Bruce Allan <bruce.w.allan@intel.com> wrote:
>
>> When physical identification of an adapter is done by toggling the
>> mechanism on and off through software utilizing the .set_phys_id operation,
>> it is done with a fixed duration for both on and off states. Some drivers
>> may want to set a custom duration for the on/off intervals. This patch
>> changes the API so the return code from the driver's entry point can
>> specify the interval duration as a positive number; -EINVAL is still
>> allowed in order to use the default single on/off interval per second.
>>
>> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
>
>IMHO this is -EOVERKILL.
I realize it does seem like that, but we have OEMs that expect the LEDs to
blink a certain way during a physical identification (twice a second vs.
once a second per the original .set_phys_id patchset). There may be other
drivers from different hardware vendors that have similar but different
requirements.
^ permalink raw reply
* Re: [net-next-2.6 RFC PATCH] ethtool: allow custom interval for physical identification
From: Stephen Hemminger @ 2011-04-11 23:26 UTC (permalink / raw)
To: Bruce Allan; +Cc: netdev
In-Reply-To: <20110411231635.9339.36369.stgit@gitlad.jf.intel.com>
On Mon, 11 Apr 2011 16:16:35 -0700
Bruce Allan <bruce.w.allan@intel.com> wrote:
> When physical identification of an adapter is done by toggling the
> mechanism on and off through software utilizing the .set_phys_id operation,
> it is done with a fixed duration for both on and off states. Some drivers
> may want to set a custom duration for the on/off intervals. This patch
> changes the API so the return code from the driver's entry point can
> specify the interval duration as a positive number; -EINVAL is still
> allowed in order to use the default single on/off interval per second.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
IMHO this is -EOVERKILL.
--
^ permalink raw reply
* [net-next-2.6 RFC PATCH] ethtool: allow custom interval for physical identification
From: Bruce Allan @ 2011-04-11 23:16 UTC (permalink / raw)
To: netdev
When physical identification of an adapter is done by toggling the
mechanism on and off through software utilizing the .set_phys_id operation,
it is done with a fixed duration for both on and off states. Some drivers
may want to set a custom duration for the on/off intervals. This patch
changes the API so the return code from the driver's entry point can
specify the interval duration as a positive number; -EINVAL is still
allowed in order to use the default single on/off interval per second.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
---
net/core/ethtool.c | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 43ef09f..02db945 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -1640,7 +1640,7 @@ static int ethtool_phys_id(struct net_device *dev, void __user *useraddr)
return dev->ethtool_ops->phys_id(dev, id.data);
rc = dev->ethtool_ops->set_phys_id(dev, ETHTOOL_ID_ACTIVE);
- if (rc && rc != -EINVAL)
+ if (rc < 0 && rc != -EINVAL)
return rc;
/* Drop the RTNL lock while waiting, but prevent reentry or
@@ -1656,22 +1656,25 @@ static int ethtool_phys_id(struct net_device *dev, void __user *useraddr)
id.data ? (id.data * HZ) : MAX_SCHEDULE_TIMEOUT);
} else {
/* Driver expects to be called periodically */
+ int i = 0, interval = ((rc > 0) ? rc : (HZ / 2));
+
do {
rtnl_lock();
rc = dev->ethtool_ops->set_phys_id(dev, ETHTOOL_ID_ON);
rtnl_unlock();
if (rc)
break;
- schedule_timeout_interruptible(HZ / 2);
+ schedule_timeout_interruptible(interval);
rtnl_lock();
rc = dev->ethtool_ops->set_phys_id(dev, ETHTOOL_ID_OFF);
rtnl_unlock();
if (rc)
break;
- schedule_timeout_interruptible(HZ / 2);
+ schedule_timeout_interruptible(interval);
} while (!signal_pending(current) &&
- (id.data == 0 || --id.data != 0));
+ (id.data == 0 ||
+ (++i * 2 * interval) < (id.data * HZ)));
}
rtnl_lock();
^ permalink raw reply related
* Re: [PATCHv2 NEXT 2/8] qlcnic: fix eswitch stats
From: Stephen Hemminger @ 2011-04-11 23:09 UTC (permalink / raw)
To: Amit Kumar Salecha; +Cc: davem, netdev, ameen.rahman, anirban.chakraborty
In-Reply-To: <1286205297-23214-2-git-send-email-amit.salecha@qlogic.com>
On Mon, 4 Oct 2010 08:14:51 -0700
Amit Kumar Salecha <amit.salecha@qlogic.com> wrote:
> +
> +#define QLCNIC_ADD_ESW_STATS(VAL1, VAL2)\
> +do { \
> + if (((VAL1) == QLCNIC_ESW_STATS_NOT_AVAIL) && \
> + ((VAL2) != QLCNIC_ESW_STATS_NOT_AVAIL)) \
> + (VAL1) = (VAL2); \
> + else if (((VAL1) != QLCNIC_ESW_STATS_NOT_AVAIL) && \
> + ((VAL2) != QLCNIC_ESW_STATS_NOT_AVAIL)) \
> + (VAL1) += (VAL2); \
> +} while (0)
Fugly macro. Make it an inline function?
^ permalink raw reply
* [net-next-2.6 PATCH] ethtool: time to blink provided in seconds not jiffies
From: Bruce Allan @ 2011-04-11 23:01 UTC (permalink / raw)
To: netdev
When blinking for a duration set by the user, the value specified is in
seconds but it is used as the number of jiffies in the timeout after which
the Physical ID indicator is deactivated. Fix by converting the timeout
to seconds.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
---
net/core/ethtool.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 704e176..43ef09f 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -1653,7 +1653,7 @@ static int ethtool_phys_id(struct net_device *dev, void __user *useraddr)
if (rc == 0) {
/* Driver will handle this itself */
schedule_timeout_interruptible(
- id.data ? id.data : MAX_SCHEDULE_TIMEOUT);
+ id.data ? (id.data * HZ) : MAX_SCHEDULE_TIMEOUT);
} else {
/* Driver expects to be called periodically */
do {
^ permalink raw reply related
* [PATCH] s2io: Fix warnings due to -Wunused-but-set-variable.
From: David Miller @ 2011-04-11 23:01 UTC (permalink / raw)
To: netdev
Most of these are cases where we are trying to read back a register
after a write to ensure completion.
Simply pre-fixing the readl() or readq() with "(void)" is sufficient
because these are volatile operations and the compiler cannot eliminate
them just because no real assignment takes place.
The case of free_rxd_blk()'s assignments to "struct buffAdd *ba" is a
real spurious assignment as this variable is completely otherwise
unused.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/s2io.c | 5 +----
drivers/net/s2io.h | 10 ++++------
2 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/net/s2io.c b/drivers/net/s2io.c
index ca8e75e..2d5cc61 100644
--- a/drivers/net/s2io.c
+++ b/drivers/net/s2io.c
@@ -2244,13 +2244,12 @@ static int verify_xena_quiescence(struct s2io_nic *sp)
static void fix_mac_address(struct s2io_nic *sp)
{
struct XENA_dev_config __iomem *bar0 = sp->bar0;
- u64 val64;
int i = 0;
while (fix_mac[i] != END_SIGN) {
writeq(fix_mac[i++], &bar0->gpio_control);
udelay(10);
- val64 = readq(&bar0->gpio_control);
+ (void) readq(&bar0->gpio_control);
}
}
@@ -2727,7 +2726,6 @@ static void free_rxd_blk(struct s2io_nic *sp, int ring_no, int blk)
int j;
struct sk_buff *skb;
struct RxD_t *rxdp;
- struct buffAdd *ba;
struct RxD1 *rxdp1;
struct RxD3 *rxdp3;
struct mac_info *mac_control = &sp->mac_control;
@@ -2751,7 +2749,6 @@ static void free_rxd_blk(struct s2io_nic *sp, int ring_no, int blk)
memset(rxdp, 0, sizeof(struct RxD1));
} else if (sp->rxd_mode == RXD_MODE_3B) {
rxdp3 = (struct RxD3 *)rxdp;
- ba = &mac_control->rings[ring_no].ba[blk][j];
pci_unmap_single(sp->pdev,
(dma_addr_t)rxdp3->Buffer0_ptr,
BUF0_LEN,
diff --git a/drivers/net/s2io.h b/drivers/net/s2io.h
index 628fd27..800b3a4 100644
--- a/drivers/net/s2io.h
+++ b/drivers/net/s2io.h
@@ -1002,18 +1002,16 @@ static inline void writeq(u64 val, void __iomem *addr)
#define LF 2
static inline void SPECIAL_REG_WRITE(u64 val, void __iomem *addr, int order)
{
- u32 ret;
-
if (order == LF) {
writel((u32) (val), addr);
- ret = readl(addr);
+ (void) readl(addr);
writel((u32) (val >> 32), (addr + 4));
- ret = readl(addr + 4);
+ (void) readl(addr + 4);
} else {
writel((u32) (val >> 32), (addr + 4));
- ret = readl(addr + 4);
+ (void) readl(addr + 4);
writel((u32) (val), addr);
- ret = readl(addr);
+ (void) readl(addr);
}
}
--
1.7.4.3
^ permalink raw reply related
* Re: [PATCHv2 NEXT 6/8] qlcnic: sparse warning fixes
From: Ben Hutchings @ 2011-04-11 23:00 UTC (permalink / raw)
To: Amit Kumar Salecha
Cc: davem, netdev, ameen.rahman, anirban.chakraborty,
Sucheta Chakraborty
In-Reply-To: <1286205297-23214-6-git-send-email-amit.salecha@qlogic.com>
On Mon, 2010-10-04 at 08:14 -0700, Amit Kumar Salecha wrote:
> From: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
>
> Signed-off-by: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
> ---
> drivers/net/qlcnic/qlcnic_ctx.c | 12 ++++++------
> drivers/net/qlcnic/qlcnic_main.c | 10 +++++-----
> 2 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/qlcnic/qlcnic_ctx.c b/drivers/net/qlcnic/qlcnic_ctx.c
> index a4c4d09..75e3b19 100644
> --- a/drivers/net/qlcnic/qlcnic_ctx.c
> +++ b/drivers/net/qlcnic/qlcnic_ctx.c
> @@ -742,15 +742,15 @@ int qlcnic_get_pci_info(struct qlcnic_adapter *adapter,
>
> if (err == QLCNIC_RCODE_SUCCESS) {
> for (i = 0; i < QLCNIC_MAX_PCI_FUNC; i++, npar++, pci_info++) {
> - pci_info->id = le32_to_cpu(npar->id);
> - pci_info->active = le32_to_cpu(npar->active);
> - pci_info->type = le32_to_cpu(npar->type);
> + pci_info->id = le16_to_cpu(npar->id);
> + pci_info->active = le16_to_cpu(npar->active);
> + pci_info->type = le16_to_cpu(npar->type);
> pci_info->default_port =
> - le32_to_cpu(npar->default_port);
> + le16_to_cpu(npar->default_port);
> pci_info->tx_min_bw =
> - le32_to_cpu(npar->tx_min_bw);
> + le16_to_cpu(npar->tx_min_bw);
> pci_info->tx_max_bw =
> - le32_to_cpu(npar->tx_max_bw);
> + le16_to_cpu(npar->tx_max_bw);
[...]
It looks like this function was broken on big-endian systems. The
commit message should say that you are fixing a bug, not just that some
unspecified 'sparse warning[s]' (that alerted you to the bug) were
fixed.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH NET-2.6 1/1] netxen: limit skb frags for non tso packet
From: David Miller @ 2011-04-11 22:57 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman, anirban.chakraborty, stable
In-Reply-To: <1302547974-7310-1-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Mon, 11 Apr 2011 11:52:54 -0700
> Machines are getting deadlock in four node cluster environment.
> All nodes are accessing (find /gfs2 -depth -print|cpio -ocv > /dev/null)
> 200 GB storage on a GFS2 filesystem.
> This result in memory fragmentation and driver receives 18 frags for
> 1448 byte packets.
> For non tso packet, fw drops the tx request, if it has >14 frags.
>
> Fixing it by pulling extra frags.
>
> Cc: stable@kernel.org
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
I applied this to net-2.6 earlier today, so:
1) Why are you sending it again?
2) On top of that, why are you sending two copies?
^ permalink raw reply
* Re: [PATCH NEXT 2/2] netxen: support for GbE port settings
From: Ben Hutchings @ 2011-04-11 22:56 UTC (permalink / raw)
To: Amit Kumar Salecha
Cc: davem, netdev, ameen.rahman, anirban.chakraborty, Sony Chacko
In-Reply-To: <1299840277-30591-3-git-send-email-amit.salecha@qlogic.com>
On Fri, 2011-03-11 at 02:44 -0800, Amit Kumar Salecha wrote:
> From: Sony Chacko <sony.chacko@qlogic.com>
>
> o Allow setting speed and auto negotiation parameters for GbE ports.
> o Log an error message to indicate duplex setting is not supported in
> the hardware currently.
[...]
> + ret = nx_fw_cmd_set_gbe_port(adapter, ecmd->speed, ecmd->duplex,
> + ecmd->autoneg);
> + if (ret == NX_RCODE_NOT_SUPPORTED && ecmd->duplex == DUPLEX_HALF) {
> + netdev_info(dev, "Speed and autoneg mode settings supported, "
> + "half duplex mode not supported\n");
> return -EOPNOTSUPP;
[...]
Should be -EINVAL.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCHv2 NEXT 2/8] qlcnic: fix eswitch stats
From: David Miller @ 2011-04-11 22:55 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman, anirban.chakraborty
In-Reply-To: <1286205297-23214-2-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Mon, 4 Oct 2010 08:14:51 -0700
> Some of the counters are not implemented in fw.
> Fw return NOT AVAILABLE VALUE as (0xffffffffffffffff).
> Adding these counters, result in invalid value.
>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Why are patches being posted from back in October 4, 2010?
^ permalink raw reply
* [PATCH NET-2.6 1/1] netxen: limit skb frags for non tso packet
From: Amit Kumar Salecha @ 2011-04-11 18:50 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, anirban.chakraborty, stable
Machines are getting deadlock in four node cluster environment.
All nodes are accessing (find /gfs2 -depth -print|cpio -ocv > /dev/null)
200 GB storage on a GFS2 filesystem.
This result in memory fragmentation and driver receives 18 frags for
1448 byte packets.
For non tso packet, fw drops the tx request, if it has >14 frags.
Fixing it by pulling extra frags.
Cc: stable@kernel.org
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/netxen/netxen_nic.h | 4 ++--
drivers/net/netxen/netxen_nic_main.c | 17 +++++++++++++++++
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
index d7299f1..679dc85 100644
--- a/drivers/net/netxen/netxen_nic.h
+++ b/drivers/net/netxen/netxen_nic.h
@@ -174,7 +174,7 @@
#define MAX_NUM_CARDS 4
-#define MAX_BUFFERS_PER_CMD 32
+#define NETXEN_MAX_FRAGS_PER_TX 14
#define MAX_TSO_HEADER_DESC 2
#define MGMT_CMD_DESC_RESV 4
#define TX_STOP_THRESH ((MAX_SKB_FRAGS >> 2) + MAX_TSO_HEADER_DESC \
@@ -558,7 +558,7 @@ struct netxen_recv_crb {
*/
struct netxen_cmd_buffer {
struct sk_buff *skb;
- struct netxen_skb_frag frag_array[MAX_BUFFERS_PER_CMD + 1];
+ struct netxen_skb_frag frag_array[MAX_SKB_FRAGS + 1];
u32 frag_count;
};
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index 83348dc..e8a4b66 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -1844,6 +1844,8 @@ netxen_nic_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
struct cmd_desc_type0 *hwdesc, *first_desc;
struct pci_dev *pdev;
int i, k;
+ int delta = 0;
+ struct skb_frag_struct *frag;
u32 producer;
int frag_count, no_of_desc;
@@ -1851,6 +1853,21 @@ netxen_nic_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
frag_count = skb_shinfo(skb)->nr_frags + 1;
+ /* 14 frags supported for normal packet and
+ * 32 frags supported for TSO packet
+ */
+ if (!skb_is_gso(skb) && frag_count > NETXEN_MAX_FRAGS_PER_TX) {
+
+ for (i = 0; i < (frag_count - NETXEN_MAX_FRAGS_PER_TX); i++) {
+ frag = &skb_shinfo(skb)->frags[i];
+ delta += frag->size;
+ }
+
+ if (!__pskb_pull_tail(skb, delta))
+ goto drop_packet;
+
+ frag_count = 1 + skb_shinfo(skb)->nr_frags;
+ }
/* 4 fragments per cmd des */
no_of_desc = (frag_count + 3) >> 2;
--
1.7.3.2
^ permalink raw reply related
* [PATCH NET-2.6 1/1] netxen: limit skb frags for non tso packet
From: Amit Kumar Salecha @ 2011-04-11 18:52 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, anirban.chakraborty, stable
Machines are getting deadlock in four node cluster environment.
All nodes are accessing (find /gfs2 -depth -print|cpio -ocv > /dev/null)
200 GB storage on a GFS2 filesystem.
This result in memory fragmentation and driver receives 18 frags for
1448 byte packets.
For non tso packet, fw drops the tx request, if it has >14 frags.
Fixing it by pulling extra frags.
Cc: stable@kernel.org
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/netxen/netxen_nic.h | 4 ++--
drivers/net/netxen/netxen_nic_main.c | 17 +++++++++++++++++
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
index d7299f1..679dc85 100644
--- a/drivers/net/netxen/netxen_nic.h
+++ b/drivers/net/netxen/netxen_nic.h
@@ -174,7 +174,7 @@
#define MAX_NUM_CARDS 4
-#define MAX_BUFFERS_PER_CMD 32
+#define NETXEN_MAX_FRAGS_PER_TX 14
#define MAX_TSO_HEADER_DESC 2
#define MGMT_CMD_DESC_RESV 4
#define TX_STOP_THRESH ((MAX_SKB_FRAGS >> 2) + MAX_TSO_HEADER_DESC \
@@ -558,7 +558,7 @@ struct netxen_recv_crb {
*/
struct netxen_cmd_buffer {
struct sk_buff *skb;
- struct netxen_skb_frag frag_array[MAX_BUFFERS_PER_CMD + 1];
+ struct netxen_skb_frag frag_array[MAX_SKB_FRAGS + 1];
u32 frag_count;
};
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index 83348dc..e8a4b66 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -1844,6 +1844,8 @@ netxen_nic_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
struct cmd_desc_type0 *hwdesc, *first_desc;
struct pci_dev *pdev;
int i, k;
+ int delta = 0;
+ struct skb_frag_struct *frag;
u32 producer;
int frag_count, no_of_desc;
@@ -1851,6 +1853,21 @@ netxen_nic_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
frag_count = skb_shinfo(skb)->nr_frags + 1;
+ /* 14 frags supported for normal packet and
+ * 32 frags supported for TSO packet
+ */
+ if (!skb_is_gso(skb) && frag_count > NETXEN_MAX_FRAGS_PER_TX) {
+
+ for (i = 0; i < (frag_count - NETXEN_MAX_FRAGS_PER_TX); i++) {
+ frag = &skb_shinfo(skb)->frags[i];
+ delta += frag->size;
+ }
+
+ if (!__pskb_pull_tail(skb, delta))
+ goto drop_packet;
+
+ frag_count = 1 + skb_shinfo(skb)->nr_frags;
+ }
/* 4 fragments per cmd des */
no_of_desc = (frag_count + 3) >> 2;
--
1.7.3.2
^ permalink raw reply related
* [PATCHv2 NEXT 7/8] qlcnic: cleanup port mode setting
From: Amit Kumar Salecha @ 2010-10-04 15:14 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, anirban.chakraborty, Sritej Velaga
In-Reply-To: <1286205297-23214-1-git-send-email-amit.salecha@qlogic.com>
From: Sritej Velaga <sritej.velaga@qlogic.com>
Port mode setting is not required for Qlogic CNA adapters.
Signed-off-by: Sritej Velaga <sritej.velaga@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/qlcnic/qlcnic_main.c | 40 --------------------------------------
1 files changed, 0 insertions(+), 40 deletions(-)
diff --git a/drivers/net/qlcnic/qlcnic_main.c b/drivers/net/qlcnic/qlcnic_main.c
index 59a2138..4757908 100644
--- a/drivers/net/qlcnic/qlcnic_main.c
+++ b/drivers/net/qlcnic/qlcnic_main.c
@@ -46,11 +46,6 @@ char qlcnic_driver_name[] = "qlcnic";
static const char qlcnic_driver_string[] = "QLogic 1/10 GbE "
"Converged/Intelligent Ethernet Driver v" QLCNIC_LINUX_VERSIONID;
-static int port_mode = QLCNIC_PORT_MODE_AUTO_NEG;
-
-/* Default to restricted 1G auto-neg mode */
-static int wol_port_mode = 5;
-
static int qlcnic_mac_learn;
module_param(qlcnic_mac_learn, int, 0644);
MODULE_PARM_DESC(qlcnic_mac_learn, "Mac Filter (0=disabled, 1=enabled)");
@@ -264,40 +259,6 @@ static void qlcnic_clear_stats(struct qlcnic_adapter *adapter)
memset(&adapter->stats, 0, sizeof(adapter->stats));
}
-static void qlcnic_set_port_mode(struct qlcnic_adapter *adapter)
-{
- u32 val, data;
-
- val = adapter->ahw.board_type;
- if ((val == QLCNIC_BRDTYPE_P3_HMEZ) ||
- (val == QLCNIC_BRDTYPE_P3_XG_LOM)) {
- if (port_mode == QLCNIC_PORT_MODE_802_3_AP) {
- data = QLCNIC_PORT_MODE_802_3_AP;
- QLCWR32(adapter, QLCNIC_PORT_MODE_ADDR, data);
- } else if (port_mode == QLCNIC_PORT_MODE_XG) {
- data = QLCNIC_PORT_MODE_XG;
- QLCWR32(adapter, QLCNIC_PORT_MODE_ADDR, data);
- } else if (port_mode == QLCNIC_PORT_MODE_AUTO_NEG_1G) {
- data = QLCNIC_PORT_MODE_AUTO_NEG_1G;
- QLCWR32(adapter, QLCNIC_PORT_MODE_ADDR, data);
- } else if (port_mode == QLCNIC_PORT_MODE_AUTO_NEG_XG) {
- data = QLCNIC_PORT_MODE_AUTO_NEG_XG;
- QLCWR32(adapter, QLCNIC_PORT_MODE_ADDR, data);
- } else {
- data = QLCNIC_PORT_MODE_AUTO_NEG;
- QLCWR32(adapter, QLCNIC_PORT_MODE_ADDR, data);
- }
-
- if ((wol_port_mode != QLCNIC_PORT_MODE_802_3_AP) &&
- (wol_port_mode != QLCNIC_PORT_MODE_XG) &&
- (wol_port_mode != QLCNIC_PORT_MODE_AUTO_NEG_1G) &&
- (wol_port_mode != QLCNIC_PORT_MODE_AUTO_NEG_XG)) {
- wol_port_mode = QLCNIC_PORT_MODE_AUTO_NEG;
- }
- QLCWR32(adapter, QLCNIC_WOL_PORT_MODE, wol_port_mode);
- }
-}
-
static void qlcnic_set_msix_bit(struct pci_dev *pdev, int enable)
{
u32 control;
@@ -1032,7 +993,6 @@ qlcnic_start_firmware(struct qlcnic_adapter *adapter)
err = qlcnic_pinit_from_rom(adapter);
if (err)
goto err_out;
- qlcnic_set_port_mode(adapter);
err = qlcnic_load_firmware(adapter);
if (err)
--
1.6.3.3
^ permalink raw reply related
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