* Re: [Patch] iwlwifi: remove obsoleted module alias and parameters
From: Cong Wang @ 2011-04-07 7:17 UTC (permalink / raw)
To: Guy, Wey-Yi
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
Intel Linux Wireless, Berg, Johannes, John W. Linville,
Stanislaw Gruszka, Venkataraman, Meenakshi, Larry Finger
In-Reply-To: <1302098755.14995.112.camel@wwguy-huron>
于 2011年04月06日 22:05, Guy, Wey-Yi 写道:
> On Wed, 2011-04-06 at 02:49 -0700, Amerigo Wang wrote:
>> As scheduled in Documentation/feature-removal-schedule.txt,
>> remove "*50", "disable_hw_scan" module parameters and MODULE_ALIAS("iwl4965").
>>
>> Cc: Intel Linux Wireless<ilw@linux.intel.com>
>> Cc: Johannes Berg<johannes.berg@intel.com>
>> Cc: "John W. Linville"<linville@tuxdriver.com>
>> Cc: Wey-Yi Guy<wey-yi.w.guy@intel.com>
>> Cc: Stanislaw Gruszka<sgruszka@redhat.com>
>> Cc: Meenakshi Venkataraman<meenakshi.venkataraman@intel.com>
>> Cc: Larry Finger<Larry.Finger@lwfinger.net>
>> Signed-off-by: WANG Cong<amwang@redhat.com>
>>
>> ---
> what tree you are base on?
> please check commit#7eaa6a5e964f1ab02d849bda36950c0d30be8ce2 in
> wireless-next-2.6
The latest Linus tree, sorry that I didn't know wireless has its own tree,
I just checked wireless-next-2.6 but don't find any commit matched
that commit ID, but I assume you meant you already sent a same patch?
If yes, feel free to discard mine.
Thanks.
^ permalink raw reply
* Re: [Patch] isdn: remove deprecated ISDN_CAPI_CAPIFS
From: Cong Wang @ 2011-04-07 7:06 UTC (permalink / raw)
To: David Miller; +Cc: netdev, isdn, jan.kiszka
In-Reply-To: <20110406.131216.15250040.davem@davemloft.net>
于 2011年04月07日 04:12, David Miller 写道:
> From: Amerigo Wang<amwang@redhat.com>
> Date: Wed, 6 Apr 2011 17:05:39 +0800
>
>> Cc: Jan Kiszka<jan.kiszka@web.de>
>> Cc: Karsten Keil<isdn@linux-pingi.de>
>> Signed-off-by: WANG Cong<amwang@redhat.com>
>
> capi.c still includes capifs.h, which you are deleting here.
>
> How did you build test this?
Oops! I definitely used a wrong .config.. :-/
Thanks for fixing it, Jan!
^ permalink raw reply
* Re: [PATCH] xen: drop anti-dependency on X86_VISWS
From: Ian Campbell @ 2011-04-07 6:58 UTC (permalink / raw)
To: David Miller
Cc: eric.dumazet@gmail.com, mirq-linux@rere.qmqm.pl,
netdev@vger.kernel.org, Jeremy Fitzhardinge,
konrad.wilk@oracle.com, xen-devel@lists.xensource.com,
virtualization@lists.linux-foundation.org,
randy.dunlap@oracle.com, pazke@donpac.ru,
linux-visws-devel@lists.sf.net, tglx@linutronix.de,
mingo@redhat.com, hpa@zytor.com
In-Reply-To: <20110406.144515.235693855.davem@davemloft.net>
On Wed, 2011-04-06 at 22:45 +0100, David Miller wrote:
> From: Ian Campbell <Ian.Campbell@eu.citrix.com>
> Date: Mon, 4 Apr 2011 10:55:55 +0100
>
> > You mean the "!X86_VISWS" I presume? It doesn't make sense to me either.
>
> No, I think 32-bit x86 allmodconfig elides XEN because of it's X86_TSC dependency.
TSC is a real dependency of the Xen interfaces.
> And, well, you could type "make allmodconfig" on your tree and see for
> yourself instead of asking me :-)
True.
X86_TSC not being enabled appears to due to CONFIG_ELAN being enabled
which causes the processor selection option (which defaults to M686,
which is a sane choice and enables TSC etc) to be gated at the top level
in arch/x86/Kconfig.cpu. Disabling the ELAN option then leaves X86_TSC
gated on !CONFIG_NUMAQ but removing that results in a generally useful
looking config.
It's a shame that these sorts of minority options cause allmodconfig to
omit support for more interesting configurations, such as modern
processors. Other than negating the semantics of such options I'm not
really sure what can be done about it though. On the other hand
compiling all the unusual stuff in an allmodconfig is probably a
positive thing.
I'm not sure why ELAN belongs in the EXTENDED_PLATFORM option space
rather than in the CPU choice option, since its only impact seems to be
on -march, MODULE_PROC_FAMILY and some cpufreq drivers which doesn't
sound like an extended platform to me but does it appear to be
deliberate (see 9e111f3e167a "x86: move ELAN to the
NON_STANDARD_PLATFORM section", that was the old name for
EXTENDED_PLATFORM).
Hrm, what about the following? (doesn't actually make a difference to
Xen since allmodconfig chooses HIGHMEM4G instead of HIGHMEM64G in the !
NUMAQ case but I stopped worrying about that several paragraphs ago)
8<--------
x86: invert X86_EXTENDED_PLATFORM to X86_STANDARD_PLATFORM
Having the =y choice be the more "standard" configuration causes
all*config to provide greater coverage of usual configurations.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index cc6c53a..6d8a404 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -299,15 +299,15 @@ config X86_BIGSMP
This option is needed for the systems that have more than 8 CPUs
if X86_32
-config X86_EXTENDED_PLATFORM
- bool "Support for extended (non-PC) x86 platforms"
+config X86_STANDARD_PLATFORM
+ bool "Restrict support to standard (PC) x86 platforms"
default y
---help---
- If you disable this option then the kernel will only support
+ If you enable this option then the kernel will only support
standard PC platforms. (which covers the vast majority of
systems out there.)
- If you enable this option then you'll be able to select support
+ If you disable this option then you'll be able to select support
for the following (non-PC) 32 bit x86 platforms:
AMD Elan
NUMAQ (IBM/Sequent)
@@ -318,25 +318,25 @@ config X86_EXTENDED_PLATFORM
Moorestown MID devices
If you have one of these systems, or if you want to build a
- generic distribution kernel, say Y here - otherwise say N.
+ generic distribution kernel, say N here - otherwise say Y.
endif
if X86_64
-config X86_EXTENDED_PLATFORM
- bool "Support for extended (non-PC) x86 platforms"
+config X86_STANDARD_PLATFORM
+ bool "Restrict support to standard (PC) x86 platforms"
default y
---help---
- If you disable this option then the kernel will only support
+ If you enable this option then the kernel will only support
standard PC platforms. (which covers the vast majority of
systems out there.)
- If you enable this option then you'll be able to select support
+ If you disable this option then you'll be able to select support
for the following (non-PC) 64 bit x86 platforms:
ScaleMP vSMP
SGI Ultraviolet
If you have one of these systems, or if you want to build a
- generic distribution kernel, say Y here - otherwise say N.
+ generic distribution kernel, say N here - otherwise say Y.
endif
# This is an alphabetically sorted list of 64 bit extended platforms
# Please maintain the alphabetic order if and when there are additions
@@ -346,7 +346,7 @@ config X86_VSMP
select PARAVIRT_GUEST
select PARAVIRT
depends on X86_64 && PCI
- depends on X86_EXTENDED_PLATFORM
+ depends on !X86_STANDARD_PLATFORM
---help---
Support for ScaleMP vSMP systems. Say 'Y' here if this kernel is
supposed to run on these EM64T-based machines. Only choose this option
@@ -355,7 +355,7 @@ config X86_VSMP
config X86_UV
bool "SGI Ultraviolet"
depends on X86_64
- depends on X86_EXTENDED_PLATFORM
+ depends on !X86_STANDARD_PLATFORM
depends on NUMA
depends on X86_X2APIC
---help---
@@ -368,7 +368,7 @@ config X86_UV
config X86_ELAN
bool "AMD Elan"
depends on X86_32
- depends on X86_EXTENDED_PLATFORM
+ depends on !X86_STANDARD_PLATFORM
---help---
Select this for an AMD Elan processor.
@@ -381,7 +381,7 @@ config X86_INTEL_CE
depends on PCI
depends on PCI_GODIRECT
depends on X86_32
- depends on X86_EXTENDED_PLATFORM
+ depends on !X86_STANDARD_PLATFORM
select X86_REBOOTFIXUPS
select OF
select OF_EARLY_FLATTREE
@@ -395,7 +395,7 @@ config X86_MRST
depends on PCI
depends on PCI_GOANY
depends on X86_32
- depends on X86_EXTENDED_PLATFORM
+ depends on !X86_STANDARD_PLATFORM
depends on X86_IO_APIC
select APB_TIMER
select I2C
@@ -413,7 +413,7 @@ config X86_MRST
config X86_RDC321X
bool "RDC R-321x SoC"
depends on X86_32
- depends on X86_EXTENDED_PLATFORM
+ depends on !X86_STANDARD_PLATFORM
select M486
select X86_REBOOTFIXUPS
---help---
@@ -424,7 +424,7 @@ config X86_RDC321X
config X86_32_NON_STANDARD
bool "Support non-standard 32-bit SMP architectures"
depends on X86_32 && SMP
- depends on X86_EXTENDED_PLATFORM
+ depends on !X86_STANDARD_PLATFORM
---help---
This option compiles in the NUMAQ, Summit, bigsmp, ES7000, default
subarchitectures. It is intended for a generic binary kernel.
^ permalink raw reply related
* Re: nfs client doesn't work [was: mmotm 2011-03-31-14-48 uploaded]
From: Jiri Slaby @ 2011-04-07 6:42 UTC (permalink / raw)
To: Myklebust, Trond
Cc: Jiri Slaby, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
mm-commits-u79uwXL29TY76Z2rM5mHXA, ML netdev,
linux-nfs-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1302122693.16786.0.camel-SyLVLa/KEI9HwK5hSS5vWB2eb7JE58TQ@public.gmane.org>
On 04/06/2011 10:44 PM, Myklebust, Trond wrote:
> On Sat, 2011-04-02 at 10:56 +0200, Jiri Slaby wrote:
>> On 03/31/2011 11:48 PM, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org wrote:
>> > The mm-of-the-moment snapshot 2011-03-31-14-48 has been uploaded to
>>
>> Hi, nfs client is defunct in this kernel. Tcpdump says:
>> 10:51:55.489717 IP 10.20.11.33.759945860 > 10.20.3.2.2049: 132 getattr
>> fh 0,0/24
>> 10:51:55.515927 IP 10.20.3.2.2049 > 10.20.11.33.759945860: reply ok 44
>> getattr ERROR: Operation not permitted
>> 10:51:55.515949 IP 10.20.11.33.921 > 10.20.3.2.2049: Flags [.], ack
>> 3569361440, win 115, options [nop,nop,TS val 599750 ecr 255058541],
> length 0
>> 10:52:04.130310 IP 10.20.11.33.793500292 > 10.20.3.2.2049: 76 getattr fh
>> 0,0/24
>> 10:52:04.152178 IP 10.20.3.2.2049 > 10.20.11.33.793500292: reply ok 44
>> getattr ERROR: Operation not permitted
>>
>> If I run the same mount command (mount -oro,intr host:dir mountpoint)
>> from within a virtual machine with 2.6.38.2 there, everything mounts OK.
>
> Does the attached patch help?
No, still the operation not permitted in the tcpdump output and no mount.
thanks,
--
js
suse labs
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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: Question on "net: allocate skbs on local node"
From: Eric Dumazet @ 2011-04-07 6:16 UTC (permalink / raw)
To: Wei Gu; +Cc: netdev, Alexander Duyck, Jeff Kirsher
In-Reply-To: <1302153412.2701.64.camel@edumazet-laptop>
Le jeudi 07 avril 2011 à 07:16 +0200, Eric Dumazet a écrit :
> Le jeudi 07 avril 2011 à 06:58 +0200, Eric Dumazet a écrit :
> > Le jeudi 07 avril 2011 à 10:16 +0800, Wei Gu a écrit :
> > > Hi Eric,
> > > Testing with ixgbe Linux 2.6.38 driver:
> > > We have a little better thruput figure with this driver, but it looks
> > > not scalling at all, I always stressed one CPU core/24.
> > > And when look the perf report for ksoftirqd/24, the most cost function
> > > is still "_raw_spin_unlock_irqstore" and the IRQ/s is huge, it's
> > > somehow conflicts with desgin of NAPI. On linux 2.6.32 while the CPU
> > > was stressed the IRQ will descreased while the NAPI will running much
> > > on the polling mode. I don't know why on 2.6.38 the IRQ was keep
> > > increasing.
> >
> >
> > CC netdev and Intel guys, since they said it should not happen (TM)
> >
> > IF you dont use DCA (make sure ioatdma module is not loaded), how comes
> > alloc_iova() is called at all ?
> >
> > IF you use DCA, how comes its called, since the same CPU serves a given
> > interrupt ?
> >
> >
>
> But then, maybe you forgot to cpu affine IRQS ?
>
> High performance routing setup is tricky, since you probably want to
> disable many features that are ON by default : Most machines act as a
> end host.
>
>
Please dont send me anymore private mails, I do think the issue you have
is on a setup, not a particular optimization done in network stack.
Copy of your private mail :
> On 2.6.38, I got a lot of "rx_missed_errors" on NIC, which means the
> rx loop was really busy to get packet from the receiving ring. Usually
> in this case it shouldn't exit the softirqs and keep polling in order
> to decrease the initrs.
>
> On 2.6.32, I can Rx and Tx 2.3Mpps with no packet lost(error on NIC),
> but on 2.6.38 I can only reach 50kpps with a lot of
> "rx_missed_errors", and all the binding cpu core was 100% in SI. I
> don't think there was any optimizations on it.
I hope you understand there is something wrong with your setup ?
50.000 pps on a 64 cpu machine is a bad joke.
We can reach +10.000.000 on a 16 cpus one.
^ permalink raw reply
* Re: [PATCH net-next] net: fix skb_add_data_nocache() to calc csum correctly
From: David Miller @ 2011-04-07 6:05 UTC (permalink / raw)
To: therbert; +Cc: yjwei, netdev
In-Reply-To: <BANLkTikspQHnjagFme0S3GdPUo-zw48zBw@mail.gmail.com>
From: Tom Herbert <therbert@google.com>
Date: Wed, 6 Apr 2011 21:50:55 -0700
> Nice catch.
>
> Acked-by: Tom Herbert <therbert@google.com>
>
> On Wed, Apr 6, 2011 at 9:40 PM, Wei Yongjun <yjwei@cn.fujitsu.com> wrote:
>> commit c6e1a0d12ca7b4f22c58e55a16beacfb7d3d8462 broken the calc
>> (net: Allow no-cache copy from user on transmit)
>> of checksum, which may cause some tcp packets be dropped because
>> incorrect checksum. ssh does not work under today's net-next-2.6
>> tree.
>>
>> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Applied, thanks everyone.
^ permalink raw reply
* RE: [PATCHv3 NEXT 1/1] net: ethtool support to configure number of channels
From: Amit Salecha @ 2011-04-07 6:03 UTC (permalink / raw)
To: David Miller, bhutchings@solarflare.com
Cc: netdev@vger.kernel.org, Ameen Rahman, Anirban Chakraborty
In-Reply-To: <20110406.133019.212692386.davem@davemloft.net>
>
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Wed, 06 Apr 2011 21:20:47 +0100
>
> > Amit, I told you already that you must not use my Signed-off-by line
> > since you are changing the patch significantly.
>
> Amit, this is a very serious infraction.
>
> You must not ever add someone else's signed-off-by when you make
> changes to a patch, unless you have their very clear and explicit
> permission to do so.
As this patch is based on Ben patch, so I thought its my duty to add his Signed-off.
Then I misinterpreted Ben comment and thought he want me to explain his contribution.
Sorry Ben.
-Amit
This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
^ permalink raw reply
* Re: problem of "ipv4: revert Set rt->rt_iif more sanely on output routes."
From: David Miller @ 2011-04-07 5:42 UTC (permalink / raw)
To: hirofumi; +Cc: netdev
In-Reply-To: <20110406.223400.71127145.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 06 Apr 2011 22:34:00 -0700 (PDT)
> From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
> Date: Thu, 07 Apr 2011 13:31:06 +0900
>
>> I'm not pretty sure though, output message is
>>
>> ip_finish_output2: No header cache and no neighbour!
>>
>> I'm not debugging this though,
>>
>> static inline bool rt_is_output_route(struct rtable *rt)
>> {
>> return rt->rt_iif == 0;
>> }
>>
>> from review I guess the above is one of cause.
>
> arp_bind_neighbour() is only called if rt_is_output_route() is true
> or route is unicast.
>
> If packet is sent using a route for which arp_bind_neighbour() has not
> been called, you will see that warning message.
Ok, the problem is that, for output routes in original code:
1) user's flow device index is stored in rt->rt_iif
2) arp_bind_neighbour() tests meanwhile used rt->fl.iif
So we do need, for now, to add a new member. But I think for
correct semantics it needs to have inverse meaning to the one
you added in your RFC patch.
So fix is something like:
1) Add "int rt_route_iif;" to struct rtable
2) For input routes, always set rt_route_iif to same value as rt_iif
3) For output routes, always set rt_route_iif to zero. Set rt_iif
as it is done currently.
4) Change rt_is_{output,input}_route() to test rt_route_iif
This should fix the bug and not introduce new regressions.
Can you write and test such a patch with your test case?
Thank you!
^ permalink raw reply
* Re: problem of "ipv4: revert Set rt->rt_iif more sanely on output routes."
From: David Miller @ 2011-04-07 5:34 UTC (permalink / raw)
To: hirofumi; +Cc: netdev
In-Reply-To: <87ipuqsmwl.fsf@devron.myhome.or.jp>
From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Date: Thu, 07 Apr 2011 13:31:06 +0900
> I'm not pretty sure though, output message is
>
> ip_finish_output2: No header cache and no neighbour!
>
> I'm not debugging this though,
>
> static inline bool rt_is_output_route(struct rtable *rt)
> {
> return rt->rt_iif == 0;
> }
>
> from review I guess the above is one of cause.
arp_bind_neighbour() is only called if rt_is_output_route() is true
or route is unicast.
If packet is sent using a route for which arp_bind_neighbour() has not
been called, you will see that warning message.
^ permalink raw reply
* RE: Question on "net: allocate skbs on local node"
From: Eric Dumazet @ 2011-04-07 5:16 UTC (permalink / raw)
To: Wei Gu; +Cc: netdev, Alexander Duyck, Jeff Kirsher
In-Reply-To: <1302152327.2701.50.camel@edumazet-laptop>
Le jeudi 07 avril 2011 à 06:58 +0200, Eric Dumazet a écrit :
> Le jeudi 07 avril 2011 à 10:16 +0800, Wei Gu a écrit :
> > Hi Eric,
> > Testing with ixgbe Linux 2.6.38 driver:
> > We have a little better thruput figure with this driver, but it looks
> > not scalling at all, I always stressed one CPU core/24.
> > And when look the perf report for ksoftirqd/24, the most cost function
> > is still "_raw_spin_unlock_irqstore" and the IRQ/s is huge, it's
> > somehow conflicts with desgin of NAPI. On linux 2.6.32 while the CPU
> > was stressed the IRQ will descreased while the NAPI will running much
> > on the polling mode. I don't know why on 2.6.38 the IRQ was keep
> > increasing.
>
>
> CC netdev and Intel guys, since they said it should not happen (TM)
>
> IF you dont use DCA (make sure ioatdma module is not loaded), how comes
> alloc_iova() is called at all ?
>
> IF you use DCA, how comes its called, since the same CPU serves a given
> interrupt ?
>
>
But then, maybe you forgot to cpu affine IRQS ?
High performance routing setup is tricky, since you probably want to
disable many features that are ON by default : Most machines act as a
end host.
^ permalink raw reply
* Re: [PATCH net-next 1/5] be2net: add rxhash support
From: Eric Dumazet @ 2011-04-07 5:05 UTC (permalink / raw)
To: Ajit Khaparde; +Cc: netdev
In-Reply-To: <20110407040743.GA4183@akhaparde-VBox>
Le mercredi 06 avril 2011 à 23:07 -0500, Ajit Khaparde a écrit :
> Add rxhash support,
> Based on initial work by Eric Dumazet.
>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
> ---
> drivers/net/benet/be.h | 5 +++++
> drivers/net/benet/be_ethtool.c | 13 +++++++++++++
> drivers/net/benet/be_main.c | 17 ++++++++++++-----
> 3 files changed, 30 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/benet/be.h b/drivers/net/benet/be.h
> index 0899d91..8941b98 100644
> --- a/drivers/net/benet/be.h
> +++ b/drivers/net/benet/be.h
> @@ -485,6 +485,11 @@ static inline void be_vf_eth_addr_generate(struct be_adapter *adapter, u8 *mac)
> memcpy(mac, adapter->netdev->dev_addr, 3);
> }
>
> +static inline bool be_multi_rxq(struct be_adapter *adapter)
static inline bool be_multi_rxq(const struct be_adapter *adapter)
> +{
> + return (adapter->num_rx_qs > 1);
return adapter->num_rx_qs > 1;
> +}
> +
Other parts seems fine, thanks !
^ permalink raw reply
* RE: Question on "net: allocate skbs on local node"
From: Eric Dumazet @ 2011-04-07 4:58 UTC (permalink / raw)
To: Wei Gu; +Cc: netdev, Alexander Duyck, Jeff Kirsher
In-Reply-To: <D12839161ADD3A4B8DA63D1A134D084026E48B9BEB@ESGSCCMS0001.eapac.ericsson.se>
Le jeudi 07 avril 2011 à 10:16 +0800, Wei Gu a écrit :
> Hi Eric,
> Testing with ixgbe Linux 2.6.38 driver:
> We have a little better thruput figure with this driver, but it looks
> not scalling at all, I always stressed one CPU core/24.
> And when look the perf report for ksoftirqd/24, the most cost function
> is still "_raw_spin_unlock_irqstore" and the IRQ/s is huge, it's
> somehow conflicts with desgin of NAPI. On linux 2.6.32 while the CPU
> was stressed the IRQ will descreased while the NAPI will running much
> on the polling mode. I don't know why on 2.6.38 the IRQ was keep
> increasing.
CC netdev and Intel guys, since they said it should not happen (TM)
IF you dont use DCA (make sure ioatdma module is not loaded), how comes
alloc_iova() is called at all ?
IF you use DCA, how comes its called, since the same CPU serves a given
interrupt ?
>
> CONFIG_TICK_ONESHOT=y
> CONFIG_NO_HZ=y
>
> PerfTop: 512417 irqs/sec kernel:91.3% exact: 0.0% [1000Hz cpu-clock-msecs], (all, 64 CPUs)
> ------------------------------------------------------------------------------------------------------------------------------------------------------
> - 0.82% ksoftirqd/24 [kernel.kallsyms] [k] _raw_spin_unlock_irqrestore
> \u2592 - _raw_spin_unlock_irqrestore
> \u2592 - 44.27% alloc_iova
> \u2592 intel_alloc_iova
> \u2592 __intel_map_single
> \u2592 intel_map_page
> \u2592 - ixgbe_init_interrupt_scheme
> \u2592 - 59.97% ixgbe_alloc_rx_buffers
> \u2592 ixgbe_clean_rx_irq
> \u2592 0xffffffffa033a5
> \u2592 net_rx_action
> u2592 __do_softirq
> \u2592 + call_softirq
> \u2592 - 40.03% ixgbe_change_mtu
> \u2592 ixgbe_change_mtu
> \u2592 dev_hard_start_xmit
> \u2592 sch_direct_xmit
> \u2592 dev_queue_xmit
> \u2592 vlan_dev_hard_start_xmit
> \u2592 hook_func
> \u2592 nf_iterate
> \u2592 nf_hook_slow
> \u2592 NF_HOOK.clone.1
> \u2592 ip_rcv
> \u2592 __netif_receive_skb
> \u2592 __netif_receive_skb
> \u2592 netif_receive_skb
> \u2592 napi_skb_finish
> \u2592 napi_gro_receive
> \u2592 ixgbe_clean_rx_irq
> \u2592 0xffffffffa033a5
> \u2592 net_rx_action
> \u2592 __do_softirq
> \u2592 + call_softirq
> \u2592 + 35.85% find_iova
> \u2592 + 19.44% add_unmap
>
>
> Thanks
> WeiGu
>
^ permalink raw reply
* Re: [PATCH net-next] net: fix skb_add_data_nocache() to calc csum correctly
From: Tom Herbert @ 2011-04-07 4:50 UTC (permalink / raw)
To: Wei Yongjun; +Cc: David Miller, netdev@vger.kernel.org
In-Reply-To: <4D9D402C.60107@cn.fujitsu.com>
Nice catch.
Acked-by: Tom Herbert <therbert@google.com>
On Wed, Apr 6, 2011 at 9:40 PM, Wei Yongjun <yjwei@cn.fujitsu.com> wrote:
> commit c6e1a0d12ca7b4f22c58e55a16beacfb7d3d8462 broken the calc
> (net: Allow no-cache copy from user on transmit)
> of checksum, which may cause some tcp packets be dropped because
> incorrect checksum. ssh does not work under today's net-next-2.6
> tree.
>
> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
> ---
> include/net/sock.h | 15 ++++++++-------
> 1 files changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/include/net/sock.h b/include/net/sock.h
> index 43bd515..9cbf23c 100644
> --- a/include/net/sock.h
> +++ b/include/net/sock.h
> @@ -1392,14 +1392,14 @@ static inline void sk_nocaps_add(struct sock *sk, int flags)
>
> static inline int skb_do_copy_data_nocache(struct sock *sk, struct sk_buff *skb,
> char __user *from, char *to,
> - int copy)
> + int copy, int offset)
> {
> if (skb->ip_summed == CHECKSUM_NONE) {
> int err = 0;
> __wsum csum = csum_and_copy_from_user(from, to, copy, 0, &err);
> if (err)
> return err;
> - skb->csum = csum_block_add(skb->csum, csum, skb->len);
> + skb->csum = csum_block_add(skb->csum, csum, offset);
> } else if (sk->sk_route_caps & NETIF_F_NOCACHE_COPY) {
> if (!access_ok(VERIFY_READ, from, copy) ||
> __copy_from_user_nocache(to, from, copy))
> @@ -1413,11 +1413,12 @@ static inline int skb_do_copy_data_nocache(struct sock *sk, struct sk_buff *skb,
> static inline int skb_add_data_nocache(struct sock *sk, struct sk_buff *skb,
> char __user *from, int copy)
> {
> - int err;
> + int err, offset = skb->len;
>
> - err = skb_do_copy_data_nocache(sk, skb, from, skb_put(skb, copy), copy);
> + err = skb_do_copy_data_nocache(sk, skb, from, skb_put(skb, copy),
> + copy, offset);
> if (err)
> - __skb_trim(skb, skb->len);
> + __skb_trim(skb, offset);
>
> return err;
> }
> @@ -1429,8 +1430,8 @@ static inline int skb_copy_to_page_nocache(struct sock *sk, char __user *from,
> {
> int err;
>
> - err = skb_do_copy_data_nocache(sk, skb, from,
> - page_address(page) + off, copy);
> + err = skb_do_copy_data_nocache(sk, skb, from, page_address(page) + off,
> + copy, skb->len);
> if (err)
> return err;
>
> --
> 1.6.5.2
>
>
>
^ permalink raw reply
* [PATCH net-next] net: fix skb_add_data_nocache() to calc csum correctly
From: Wei Yongjun @ 2011-04-07 4:40 UTC (permalink / raw)
To: David Miller, Tom Herbert, netdev@vger.kernel.org
commit c6e1a0d12ca7b4f22c58e55a16beacfb7d3d8462 broken the calc
(net: Allow no-cache copy from user on transmit)
of checksum, which may cause some tcp packets be dropped because
incorrect checksum. ssh does not work under today's net-next-2.6
tree.
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
---
include/net/sock.h | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index 43bd515..9cbf23c 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1392,14 +1392,14 @@ static inline void sk_nocaps_add(struct sock *sk, int flags)
static inline int skb_do_copy_data_nocache(struct sock *sk, struct sk_buff *skb,
char __user *from, char *to,
- int copy)
+ int copy, int offset)
{
if (skb->ip_summed == CHECKSUM_NONE) {
int err = 0;
__wsum csum = csum_and_copy_from_user(from, to, copy, 0, &err);
if (err)
return err;
- skb->csum = csum_block_add(skb->csum, csum, skb->len);
+ skb->csum = csum_block_add(skb->csum, csum, offset);
} else if (sk->sk_route_caps & NETIF_F_NOCACHE_COPY) {
if (!access_ok(VERIFY_READ, from, copy) ||
__copy_from_user_nocache(to, from, copy))
@@ -1413,11 +1413,12 @@ static inline int skb_do_copy_data_nocache(struct sock *sk, struct sk_buff *skb,
static inline int skb_add_data_nocache(struct sock *sk, struct sk_buff *skb,
char __user *from, int copy)
{
- int err;
+ int err, offset = skb->len;
- err = skb_do_copy_data_nocache(sk, skb, from, skb_put(skb, copy), copy);
+ err = skb_do_copy_data_nocache(sk, skb, from, skb_put(skb, copy),
+ copy, offset);
if (err)
- __skb_trim(skb, skb->len);
+ __skb_trim(skb, offset);
return err;
}
@@ -1429,8 +1430,8 @@ static inline int skb_copy_to_page_nocache(struct sock *sk, char __user *from,
{
int err;
- err = skb_do_copy_data_nocache(sk, skb, from,
- page_address(page) + off, copy);
+ err = skb_do_copy_data_nocache(sk, skb, from, page_address(page) + off,
+ copy, skb->len);
if (err)
return err;
--
1.6.5.2
^ permalink raw reply related
* Re: problem of "ipv4: revert Set rt->rt_iif more sanely on output routes."
From: OGAWA Hirofumi @ 2011-04-07 4:31 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110406.132829.116375350.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
> Date: Tue, 05 Apr 2011 22:05:10 +0900
>
>> ipv4: Set rt->rt_iif more sanely on output routes.
>> (1018b5c01636c7c6bda31a719bda34fc631db29a)
>>
>> The above patch seems to be caused of avahi breakage.
>>
>> I'm not debugging fully though, avahi is using IP_PKTINFO and checking
>> in_pktinfo->ipi_ifindex > 0.
>>
>> And if I reverted above patch, it seems to fix avahi's IP_PKTINFO problem.
>
> in_pktinfo is given to the application only during recvmsg() calls, the
> call chain is (for example):
>
> udp_recvmsg()
> --> ip_cmsg_recv()
> --> ip_cmsg_recv_pktinfo()
>
> Therefore we will only be working with receive packets, whose routes are
> computed using ip_route_input*() which will fill in the rt_iif field
> appropriately.
>
> The only exception to this would be packets which are looped back, in
> which case the cached output route attached to the packet will be used.
I see.
> Your RFC patch should work, but we're trying to make "struct rtable"
> smaller rather than larger.
I felt it from git hisotry.
> In what way does routing break if you simply restore the original
> rt_iif assignment in output route creation? That's the most preferred
> fix for this.
I'm not pretty sure though, output message is
ip_finish_output2: No header cache and no neighbour!
I'm not debugging this though,
static inline bool rt_is_output_route(struct rtable *rt)
{
return rt->rt_iif == 0;
}
from review I guess the above is one of cause.
Thanks.
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
^ permalink raw reply
* [PATCH net-next 5/5] be2net: call FLR after setup wol in be_shutdown
From: Ajit Khaparde @ 2011-04-07 4:08 UTC (permalink / raw)
To: netdev
Calling setup_wol after a reset is inconsequential.
The WOL setting should be programmed before FLR.
And yes, FLR does not erase wol information.
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
---
drivers/net/benet/be_main.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index 6a43b26..a7a2dec 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -3188,11 +3188,11 @@ static void be_shutdown(struct pci_dev *pdev)
netif_device_detach(netdev);
- be_cmd_reset_function(adapter);
-
if (adapter->wol)
be_setup_wol(adapter, true);
+ be_cmd_reset_function(adapter);
+
pci_disable_device(pdev);
}
--
1.7.1
^ permalink raw reply related
* [PATCH net-next 4/5] be2net: dynamically allocate adapter->vf_cfg
From: Ajit Khaparde @ 2011-04-07 4:08 UTC (permalink / raw)
To: netdev
Instead of a fixed sized array for vf_cfg, allocate the size dynamically
depending on number of VFs the device supports.
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
---
drivers/net/benet/be.h | 4 +---
drivers/net/benet/be_main.c | 14 ++++++++++++--
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/net/benet/be.h b/drivers/net/benet/be.h
index eba405b..1d976b8 100644
--- a/drivers/net/benet/be.h
+++ b/drivers/net/benet/be.h
@@ -92,8 +92,6 @@ static inline char *nic_name(struct pci_dev *pdev)
#define FW_VER_LEN 32
-#define BE_MAX_VF 32
-
struct be_dma_mem {
void *va;
dma_addr_t dma;
@@ -336,7 +334,7 @@ struct be_adapter {
bool be3_native;
bool sriov_enabled;
- struct be_vf_cfg vf_cfg[BE_MAX_VF];
+ struct be_vf_cfg *vf_cfg;
u8 is_virtfn;
u32 sli_family;
u8 hba_port_num;
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index 9d6982a..6a43b26 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -2837,6 +2837,7 @@ static void __devexit be_remove(struct pci_dev *pdev)
be_ctrl_cleanup(adapter);
+ kfree(adapter->vf_cfg);
be_sriov_disable(adapter);
be_msix_disable(adapter);
@@ -3021,16 +3022,23 @@ static int __devinit be_probe(struct pci_dev *pdev,
}
be_sriov_enable(adapter);
+ if (adapter->sriov_enabled) {
+ adapter->vf_cfg = kcalloc(num_vfs,
+ sizeof(struct be_vf_cfg), GFP_KERNEL);
+
+ if (!adapter->vf_cfg)
+ goto free_netdev;
+ }
status = be_ctrl_init(adapter);
if (status)
- goto free_netdev;
+ goto free_vf_cfg;
if (lancer_chip(adapter)) {
status = lancer_test_and_set_rdy_state(adapter);
if (status) {
dev_err(&pdev->dev, "Adapter in non recoverable error\n");
- goto free_netdev;
+ goto ctrl_clean;
}
}
@@ -3092,6 +3100,8 @@ stats_clean:
be_stats_cleanup(adapter);
ctrl_clean:
be_ctrl_cleanup(adapter);
+free_vf_cfg:
+ kfree(adapter->vf_cfg);
free_netdev:
be_sriov_disable(adapter);
free_netdev(netdev);
--
1.7.1
^ permalink raw reply related
* [PATCH net-next 3/5] be2net: fix to get max VFs supported from adapter
From: Ajit Khaparde @ 2011-04-07 4:08 UTC (permalink / raw)
To: netdev
The user supplied num_vfs value need not be compared
against a static BE_MAX_VF, but can be checked against
the actual VFs that the device can support.
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
---
drivers/net/benet/be_main.c | 22 ++++++++++++++--------
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index 4910055..9d6982a 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -1947,7 +1947,20 @@ static void be_sriov_enable(struct be_adapter *adapter)
be_check_sriov_fn_type(adapter);
#ifdef CONFIG_PCI_IOV
if (be_physfn(adapter) && num_vfs) {
- int status;
+ int status, pos;
+ u16 nvfs;
+
+ pos = pci_find_ext_capability(adapter->pdev,
+ PCI_EXT_CAP_ID_SRIOV);
+ pci_read_config_word(adapter->pdev,
+ pos + PCI_SRIOV_TOTAL_VF, &nvfs);
+
+ if (num_vfs > nvfs) {
+ dev_info(&adapter->pdev->dev,
+ "Device supports %d VFs and not %d\n",
+ nvfs, num_vfs);
+ num_vfs = nvfs;
+ }
status = pci_enable_sriov(adapter->pdev, num_vfs);
adapter->sriov_enabled = status ? false : true;
@@ -3281,13 +3294,6 @@ static int __init be_init_module(void)
rx_frag_size = 2048;
}
- if (num_vfs > 32) {
- printk(KERN_WARNING DRV_NAME
- " : Module param num_vfs must not be greater than 32."
- "Using 32\n");
- num_vfs = 32;
- }
-
return pci_register_driver(&be_driver);
}
module_init(be_init_module);
--
1.7.1
^ permalink raw reply related
* [PATCH net-next 1/5] be2net: add rxhash support
From: Ajit Khaparde @ 2011-04-07 4:07 UTC (permalink / raw)
To: netdev; +Cc: Eric Dumazet
Add rxhash support,
Based on initial work by Eric Dumazet.
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
---
drivers/net/benet/be.h | 5 +++++
drivers/net/benet/be_ethtool.c | 13 +++++++++++++
drivers/net/benet/be_main.c | 17 ++++++++++++-----
3 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/drivers/net/benet/be.h b/drivers/net/benet/be.h
index 0899d91..8941b98 100644
--- a/drivers/net/benet/be.h
+++ b/drivers/net/benet/be.h
@@ -485,6 +485,11 @@ static inline void be_vf_eth_addr_generate(struct be_adapter *adapter, u8 *mac)
memcpy(mac, adapter->netdev->dev_addr, 3);
}
+static inline bool be_multi_rxq(struct be_adapter *adapter)
+{
+ return (adapter->num_rx_qs > 1);
+}
+
extern void be_cq_notify(struct be_adapter *adapter, u16 qid, bool arm,
u16 num_popped);
extern void be_link_status_update(struct be_adapter *adapter, bool link_up);
diff --git a/drivers/net/benet/be_ethtool.c b/drivers/net/benet/be_ethtool.c
index a665697..1565c81 100644
--- a/drivers/net/benet/be_ethtool.c
+++ b/drivers/net/benet/be_ethtool.c
@@ -735,6 +735,18 @@ be_read_eeprom(struct net_device *netdev, struct ethtool_eeprom *eeprom,
return status;
}
+static int be_set_flags(struct net_device *netdev, u32 data)
+{
+ struct be_adapter *adapter = netdev_priv(netdev);
+ int rc = -1;
+
+ if (be_multi_rxq(adapter))
+ rc = ethtool_op_set_flags(netdev, data, ETH_FLAG_RXHASH |
+ ETH_FLAG_TXVLAN | ETH_FLAG_RXVLAN);
+
+ return rc;
+}
+
const struct ethtool_ops be_ethtool_ops = {
.get_settings = be_get_settings,
.get_drvinfo = be_get_drvinfo,
@@ -764,4 +776,5 @@ const struct ethtool_ops be_ethtool_ops = {
.get_regs = be_get_regs,
.flash_device = be_do_flash,
.self_test = be_self_test,
+ .set_flags = be_set_flags,
};
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index a24fb45..4910055 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -116,11 +116,6 @@ static char *ue_status_hi_desc[] = {
"Unknown"
};
-static inline bool be_multi_rxq(struct be_adapter *adapter)
-{
- return (adapter->num_rx_qs > 1);
-}
-
static void be_queue_free(struct be_adapter *adapter, struct be_queue_info *q)
{
struct be_dma_mem *mem = &q->dma_mem;
@@ -1012,6 +1007,9 @@ static void be_rx_compl_process(struct be_adapter *adapter,
skb->truesize = skb->len + sizeof(struct sk_buff);
skb->protocol = eth_type_trans(skb, adapter->netdev);
+ if (adapter->netdev->features & NETIF_F_RXHASH)
+ skb->rxhash = rxcp->rss_hash;
+
if (unlikely(rxcp->vlanf)) {
if (!adapter->vlan_grp || adapter->vlans_added == 0) {
@@ -1072,6 +1070,8 @@ static void be_rx_compl_process_gro(struct be_adapter *adapter,
skb->data_len = rxcp->pkt_size;
skb->truesize += rxcp->pkt_size;
skb->ip_summed = CHECKSUM_UNNECESSARY;
+ if (adapter->netdev->features & NETIF_F_RXHASH)
+ skb->rxhash = rxcp->rss_hash;
if (likely(!rxcp->vlanf))
napi_gro_frags(&eq_obj->napi);
@@ -1101,6 +1101,8 @@ static void be_parse_rx_compl_v1(struct be_adapter *adapter,
AMAP_GET_BITS(struct amap_eth_rx_compl_v1, numfrags, compl);
rxcp->pkt_type =
AMAP_GET_BITS(struct amap_eth_rx_compl_v1, cast_enc, compl);
+ rxcp->rss_hash =
+ AMAP_GET_BITS(struct amap_eth_rx_compl_v1, rsshash, rxcp);
if (rxcp->vlanf) {
rxcp->vtm = AMAP_GET_BITS(struct amap_eth_rx_compl_v1, vtm,
compl);
@@ -1131,6 +1133,8 @@ static void be_parse_rx_compl_v0(struct be_adapter *adapter,
AMAP_GET_BITS(struct amap_eth_rx_compl_v0, numfrags, compl);
rxcp->pkt_type =
AMAP_GET_BITS(struct amap_eth_rx_compl_v0, cast_enc, compl);
+ rxcp->rss_hash =
+ AMAP_GET_BITS(struct amap_eth_rx_compl_v0, rsshash, rxcp);
if (rxcp->vlanf) {
rxcp->vtm = AMAP_GET_BITS(struct amap_eth_rx_compl_v0, vtm,
compl);
@@ -2614,6 +2618,9 @@ static void be_netdev_init(struct net_device *netdev)
NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
NETIF_F_GRO | NETIF_F_TSO6;
+ if (be_multi_rxq(adapter))
+ netdev->features |= NETIF_F_RXHASH;
+
netdev->vlan_features |= NETIF_F_SG | NETIF_F_TSO |
NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM;
--
1.7.1
^ permalink raw reply related
* [PATCH net-next 2/5] be2net: use common method to check for sriov function type
From: Ajit Khaparde @ 2011-04-07 4:08 UTC (permalink / raw)
To: netdev
Lancer and BE can both use SLI_INTF_REG to check a VF or a PF.
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
---
drivers/net/benet/be.h | 12 ++----------
1 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/net/benet/be.h b/drivers/net/benet/be.h
index 8941b98..eba405b 100644
--- a/drivers/net/benet/be.h
+++ b/drivers/net/benet/be.h
@@ -458,18 +458,10 @@ static inline u8 is_udp_pkt(struct sk_buff *skb)
static inline void be_check_sriov_fn_type(struct be_adapter *adapter)
{
- u8 data;
u32 sli_intf;
- if (lancer_chip(adapter)) {
- pci_read_config_dword(adapter->pdev, SLI_INTF_REG_OFFSET,
- &sli_intf);
- adapter->is_virtfn = (sli_intf & SLI_INTF_FT_MASK) ? 1 : 0;
- } else {
- pci_write_config_byte(adapter->pdev, 0xFE, 0xAA);
- pci_read_config_byte(adapter->pdev, 0xFE, &data);
- adapter->is_virtfn = (data != 0xAA);
- }
+ pci_read_config_dword(adapter->pdev, SLI_INTF_REG_OFFSET, &sli_intf);
+ adapter->is_virtfn = (sli_intf & SLI_INTF_FT_MASK) ? 1 : 0;
}
static inline void be_vf_eth_addr_generate(struct be_adapter *adapter, u8 *mac)
--
1.7.1
^ permalink raw reply related
* [PATCH net-next 0/5] be2net: Patch series
From: Ajit Khaparde @ 2011-04-07 4:07 UTC (permalink / raw)
To: netdev
Series of 5 patches. Please apply.
Thanks
-Ajit
[1/5] add rxhash support
[2/5] use common method to check for sriov function type
[3/5] fix to get max VFs supported from adapter
[4/5] dynamically allocate adapter->vf_cfg
[5/5] call FLR after setup wol in be_shutdown
^ permalink raw reply
* (unknown),
From: Wang Lei @ 2011-04-07 3:22 UTC (permalink / raw)
I'm Wang Lei, I have a deal worth 25 Million USD if interested, please contact me via my personal email: wlei2344@gala.net
^ permalink raw reply
* linux-next: manual merge of the net tree with the net-current tree
From: Stephen Rothwell @ 2011-04-07 1:39 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Sathya Perla, Ajit Khaparde
Hi all,
Today's linux-next merge of the net tree got a conflict in
drivers/net/benet/be_main.c between commit 2d5d41546504 ("be2net: Fix a
potential crash during shutdown.") from the net-current tree and commit
0f4a68288217 ("be2net: cancel be_worker in be_shutdown() even when i/f is
down") from the net tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/net/benet/be_main.c
index 88d4c80,a24fb45..0000000
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@@ -3142,14 -3152,11 +3153,13 @@@ static int be_resume(struct pci_dev *pd
static void be_shutdown(struct pci_dev *pdev)
{
struct be_adapter *adapter = pci_get_drvdata(pdev);
- struct net_device *netdev = adapter->netdev;
+
+ if (!adapter)
+ return;
- if (netif_running(adapter->netdev))
- cancel_delayed_work_sync(&adapter->work);
+ cancel_delayed_work_sync(&adapter->work);
- netif_device_detach(netdev);
+ netif_device_detach(adapter->netdev);
be_cmd_reset_function(adapter);
^ permalink raw reply
* Re: ipv6: Add support for RTA_PREFSRC
From: David Miller @ 2011-04-07 1:37 UTC (permalink / raw)
To: dwalter; +Cc: netdev
In-Reply-To: <1301903804.31789.234.camel@localhost>
From: Daniel Walter <dwalter@barracuda.com>
Date: Mon, 4 Apr 2011 09:56:44 +0200
> On Fri, 2011-04-01 at 20:46 -0700, David Miller wrote:
>> You can't change the layout of "struct in6_rtmsg", as that structure
>> is explicitly exported to user space and changing it will break every
>> application out there.
>
> Hi,
>
> I've kicked support for setting the preferred source via ioctl,
> to keep "struct in6_rtmsg" untouched.
> This reduces the RTA_PREFSRC support to netlink only, unless
> we break the struct.
>
> Do you see any other way around this problem?
This is fine, adding new feature support to deprecated things like
the ioctl routing calls is undesirable anyways.
Since you do the prefsrc extraction in at least two places, make a
helper function that does the whole "if prefsrc.plen use prefsrc, else
use ipv6_dev_get_saddr()"
This would be akin to ipv4's FIB_RES_PREFSRC
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: don't hold RTNL during ethtool phys_id
From: Ben Hutchings @ 2011-04-07 0:35 UTC (permalink / raw)
To: Casey Leedom
Cc: Stephen Hemminger, Dimitris Michailidis, David Miller, netdev
In-Reply-To: <201104061720.30219.leedom@chelsio.com>
On Wed, 2011-04-06 at 17:20 -0700, Casey Leedom wrote:
> | From: Stephen Hemminger <shemminger@linux-foundation.org>
> | Date: Wednesday, April 06, 2011 05:09 pm
> |
> | The Chelsio cxgb4 drivers implement blinking in a unique way by
> | waiting on the mailbox. This patch cleans it up slightly by no longer
> | holding the system wide network configuration lock during the process.
> |
> | The patch also uses correct semantics for the time argument
> | which is supposed to be in seconds; and zero is supposed
> | to signify infinite blinking.
> |
> | This is still a bad firmware interface design for this
> | since it means the board is basically hung while doing the blink.
> | But fixing it correctly would require hardware and firmware
> | documentation. With that information the device could be converted
> | to the new set_phys_id.
> |
> | Compile tested only.
> |
> | Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> Are you assuming that the firmware won't respond with a command completion
> until the LED blinking is complete? If so, that's a bad assumption. The
> firmware runs as an asynchronous real-time OS. The LED blinking simply becomes
> a thread of activity within the OS and the command completes immediately.
[...]
Stephen was assuming (as I did) that you actually implemented this
operation correctly. You're supposed to blink the LED for the specified
time but let the user interrupt early. If you just start the LED
blinking and then return, then it appears the user has no way to
interrupt it.
Is there a defined firmware command to stop blinking the LED?
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
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