* Re: [ath5k-devel] [PATCH] [ath5k][leds] Ability to disable leds support. If leds support enabled do not force mac802.11 leds layer selection.
From: Pavel Roskin @ 2010-05-12 15:48 UTC (permalink / raw)
To: Dmytro Milinevskyy
Cc: ath5k-devel-xDcbHBWguxEUs3QNXV6qNA, Kalle Valo,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, GeunSik Lim, Jiri Slaby,
Greg Kroah-Hartman, John W. Linville, Keng-Yu Lin,
netdev-u79uwXL29TY76Z2rM5mHXA, Jiri Kosina, Johannes Berg,
Shahar Or, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Luca Verdesca
In-Reply-To: <4bea1f81.09b6660a.746e.1c12-ATjtLOhZ0NVl57MIdRCFDg@public.gmane.org>
On Wed, 2010-04-07 at 21:58 +0300, Dmytro Milinevskyy wrote:
> Here is the patch to disable ath5k leds support on build stage.
> However if the leds support was enabled do not force selection of 802.11 leds layer.
The idea is good, but the implementation could be improved.
There are too many preprocessor conditionals in your patch.
> +#ifdef CONFIG_ATH5K_LEDS
> /*
> * These match net80211 definitions (not used in
> * mac80211).
> @@ -939,11 +940,7 @@ enum ath5k_power_mode {
> #define AR5K_LED_AUTH 2 /*IEEE80211_S_AUTH*/
> #define AR5K_LED_ASSOC 3 /*IEEE80211_S_ASSOC*/
> #define AR5K_LED_RUN 4 /*IEEE80211_S_RUN*/
It should be OK to leave the constants defined even if they are not
used.
> +#ifdef CONFIG_ATH5K_LEDS
> /* LED functions */
> extern int ath5k_init_leds(struct ath5k_softc *sc);
> extern void ath5k_led_enable(struct ath5k_softc *sc);
> extern void ath5k_led_off(struct ath5k_softc *sc);
> extern void ath5k_unregister_leds(struct ath5k_softc *sc);
> +#endif
You could add inline functions for the case when CONFIG_ATH5K_LEDS is
not defined. That would avoid may conditionals in the code.
> /* GPIO Functions */
> +#ifdef CONFIG_ATH5K_LEDS
> extern void ath5k_hw_set_ledstate(struct ath5k_hw *ah, unsigned int state);
> +#endif
The same comment applies.
Also, there is nothing wrong with having an external declaration that is
not used in some particular configuration.
> +#ifdef CONFIG_ATH5K_LEDS
> /* turn on HW LEDs */
> ath5k_hw_set_ledstate(ah, AR5K_LED_INIT);
> +#endif
This is avoidable by having an inline ath5k_hw_set_ledstate() that does
nothing.
> +#ifdef CONFIG_ATH5K_LEDS
> struct ieee80211_hw *hw = pci_get_drvdata(to_pci_dev(dev));
> struct ath5k_softc *sc = hw->priv;
>
> ath5k_led_off(sc);
> +#endif
Even this is avoidable if ath5k_led_off() does nothing. gcc should be
smart enough to optimize out unneeded function calls.
> +#ifdef CONFIG_ATH5K_LEDS
> /*
> * State for LED triggers
> */
> struct ath5k_led
> {
> +#ifdef CONFIG_LEDS_CLASS
I'm not sure this complexity is needed. Are you going to support LEDs
if CONFIG_LEDS_CLASS is disabled?
> +#ifdef CONFIG_ATH5K_LEDS
> unsigned int led_pin, /* GPIO pin for driving LED */
> led_on; /* pin setting for LED on */
> +#endif
>
> struct tasklet_struct restq; /* reset tasklet */
>
> @@ -164,7 +172,9 @@ struct ath5k_softc {
> spinlock_t rxbuflock;
> u32 *rxlink; /* link ptr in last RX desc */
> struct tasklet_struct rxtq; /* rx intr tasklet */
> +#ifdef CONFIG_ATH5K_LEDS
> struct ath5k_led rx_led; /* rx led */
> +#endif
You may want to group those fields together to make the code more
readable.
> --- a/drivers/net/wireless/ath/ath5k/led.c
> +++ b/drivers/net/wireless/ath/ath5k/led.c
I wonder if you could omit led.c completely in the Makefile. If there
are some parts of led.c that are needed without CONFIG_ATH5K_LEDS, maybe
they belong elsewhere?
--
Regards,
Pavel Roskin
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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: [RFC PATCH] bnx2: use netif_carrier_off to prevent tx timeout
From: Michael Chan @ 2010-05-12 14:09 UTC (permalink / raw)
To: 'Stanislaw Gruszka'
Cc: netdev@vger.kernel.org, Eric Dumazet, Eilon Greenstein,
Vladislav Zolotarov, Dmitry Kravkov, Breno Leitao,
Matthew Carlson
In-Reply-To: <20100512160036.1f69fd23@dhcp-lab-109.englab.brq.redhat.com>
Stanislaw Gruszka wrote:
> On Wed, 12 May 2010 06:31:52 -0700
> "Michael Chan" <mchan@broadcom.com> wrote:
>
> > > @@ -6346,6 +6338,8 @@ bnx2_vlan_rx_register(struct net_device
> > > *dev, struct vlan_group *vlgrp)
> > > if (bp->flags & BNX2_FLAG_CAN_KEEP_VLAN)
> > > bnx2_fw_sync(bp,
> > > BNX2_DRV_MSG_CODE_KEEP_VLAN_UPDATE, 0, 1);
> > >
> > > + if (bp->link_up)
> > > + netif_carrier_on(bp->dev);
> >
> > Thanks Stanislaw, I think it is better to turn carrier on in
> > bnx2_netif_start(). We can use the start_cnic parameter to
> > decide if we need to call carrier_on().
>
> IIRC in most cases we set carrier status in bnx2_init_nic()
> (based on what we get from PHY) called before bnx2_netif_start().
> One exception is bnx2_vlan_rx_register() function.
>
Yes, if we reset the chip and reset the PHY, we'll always get a
link up event and we'll set carrier. We need to take care of
the cases where the chip is not reset or the phy is not reset.
I think it is better if the caller of bnx2_netif_start() does
not have to worry about setting the carrier.
^ permalink raw reply
* Re: [BUG] crashes with kvm/nat networking and net-next
From: Bart De Schuymer @ 2010-05-12 14:03 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Eric Dumazet, Stephen Hemminger, netdev
In-Reply-To: <4BEA8E79.9000406@trash.net>
Patrick McHardy wrote:
> Eric Dumazet wrote:
>> Le mardi 11 mai 2010 à 20:25 -0700, Stephen Hemminger a écrit :
>>> This is a regression that is showing up now in net-next, not sure what
>>> changed recently in bridge netfilter that could be causing it?
>>>
>>> [ 4593.956206] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
>>> [ 4593.956219] IP: [<ffffffffa03357a4>] br_nf_forward_finish+0x154/0x170 [bridge]
>> Not sure, but br_nf_forward_ip() has following check :
>>
>> if (!skb->nf_bridge)
>> return NF_ACCEPT;
>>
>> while br_nf_forward_arp() missed this check ...
>>
>> So we can dereference null pointer later
>
> That looks correct to me, offset 0x18 would be nf_bridge_info->mask.
> Bart, please review, thanks.
>
>> diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
>> index 93f80fe..cd2e5f5 100644
>> --- a/net/bridge/br_netfilter.c
>> +++ b/net/bridge/br_netfilter.c
>> @@ -723,6 +723,9 @@ static unsigned int br_nf_forward_arp(unsigned int hook, struct sk_buff *skb,
>> return NF_ACCEPT;
>> #endif
>>
>> + if (!skb->nf_bridge)
>> + return NF_ACCEPT;
>> +
>> if (skb->protocol != htons(ETH_P_ARP)) {
>> if (!IS_VLAN_ARP(skb))
>> return NF_ACCEPT;
That won't fix it since nf_bridge isn't used in the ARP case. The
correct fix is below. Does anyone know why the null pointer
dereference (skb->nf_bridge->mask & BRNF_8021Q) in
nf_bridge_update_protocol() didn't cause my uml kernel to crash??
cheers,
Bart
Don't call nf_bridge_update_protocol() for ARP traffic as
skb->nf_bridge isn't used in the ARP case.
Signed-off-by: Bart De Schuymer <bdschuym@pandora.be>
Reported-by: Stephen Hemminger <shemminger@vyatta.com>
diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index 93f80fe..4442099 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -643,10 +643,10 @@ static int br_nf_forward_finish(struct sk_buff *skb)
skb->pkt_type = PACKET_OTHERHOST;
nf_bridge->mask ^= BRNF_PKT_TYPE;
}
+ nf_bridge_update_protocol(skb);
} else {
in = *((struct net_device **)(skb->cb));
}
- nf_bridge_update_protocol(skb);
nf_bridge_push_encap_header(skb);
NF_HOOK_THRESH(NFPROTO_BRIDGE, NF_BR_FORWARD, skb, in,
--
Bart De Schuymer
www.artinalgorithms.be
^ permalink raw reply related
* Re: [RFC PATCH] bnx2: use netif_carrier_off to prevent tx timeout
From: Stanislaw Gruszka @ 2010-05-12 14:00 UTC (permalink / raw)
To: Michael Chan
Cc: netdev@vger.kernel.org, Eric Dumazet, Eilon Greenstein,
Vladislav Zolotarov, Dmitry Kravkov, Breno Leitao,
Matthew Carlson
In-Reply-To: <C27F8246C663564A84BB7AB3439772421B6C41FC55@IRVEXCHCCR01.corp.ad.broadcom.com>
On Wed, 12 May 2010 06:31:52 -0700
"Michael Chan" <mchan@broadcom.com> wrote:
> > @@ -6346,6 +6338,8 @@ bnx2_vlan_rx_register(struct net_device
> > *dev, struct vlan_group *vlgrp)
> > if (bp->flags & BNX2_FLAG_CAN_KEEP_VLAN)
> > bnx2_fw_sync(bp,
> > BNX2_DRV_MSG_CODE_KEEP_VLAN_UPDATE, 0, 1);
> >
> > + if (bp->link_up)
> > + netif_carrier_on(bp->dev);
>
> Thanks Stanislaw, I think it is better to turn carrier on in
> bnx2_netif_start(). We can use the start_cnic parameter to
> decide if we need to call carrier_on().
IIRC in most cases we set carrier status in bnx2_init_nic()
(based on what we get from PHY) called before bnx2_netif_start().
One exception is bnx2_vlan_rx_register() function.
Thanks
Stanislaw
^ permalink raw reply
* [PATCH] arp_notify: generate broadcast ARP reply not request.
From: Ian Campbell @ 2010-05-12 13:40 UTC (permalink / raw)
To: netdev
Cc: Ian Campbell, Stephen Hemminger, Jeremy Fitzhardinge,
David S. Miller, stable
In-Reply-To: <1273671554.7572.11190.camel@zakaz.uk.xensource.com>
The arp_notify option causes us to send a broadcast ARP request
with the host IP address in both the source and destination IP address
fields. More usually a gratuitous ARP packet is a broadcast ARP reply
with a broadcast destination IP and the local IP as the source
The documentation of the arp_notify option in
Documentation/networking/ip-sysctl.txt suggests this was the original
intention therefore switch it over.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>
Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: stable@kernel.org
---
net/ipv4/devinet.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 90e3d63..e26f723 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1087,10 +1087,10 @@ static int inetdev_event(struct notifier_block *this, unsigned long event,
struct in_ifaddr *ifa = in_dev->ifa_list;
if (ifa)
- arp_send(ARPOP_REQUEST, ETH_P_ARP,
- ifa->ifa_address, dev,
- ifa->ifa_address, NULL,
- dev->dev_addr, NULL);
+ arp_send(ARPOP_REPLY, ETH_P_ARP,
+ INADDR_BROADCAST, dev,
+ ifa->ifa_address,
+ NULL, NULL, dev->dev_addr);
}
break;
case NETDEV_DOWN:
--
1.5.6.5
^ permalink raw reply related
* [PATCH] arp_notify: generate arp_notify event on NETDEV_CHANGE too
From: Ian Campbell @ 2010-05-12 13:40 UTC (permalink / raw)
To: netdev
Cc: Ian Campbell, Stephen Hemminger, Jeremy Fitzhardinge,
David S. Miller, stable
In-Reply-To: <1273671554.7572.11190.camel@zakaz.uk.xensource.com>
One of the use cases of the arp_notify functionality added in commit
eefef1 "net: add ARP notify option for devices" is to enable faster
network recovery after a virtual machine migration.
However a migration appears to the network subsystem as a temporary
loss of carrier rather than a down/up pair or an address change etc
therefore no gratuitous ARP is sent. Send one in the NETDEV_CHANGE
(generated by netif_carrier_{on,off}) case too. This catches carrier
down events too but that should be harmless.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>
Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: stable@kernel.org
---
net/ipv4/devinet.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index e26f723..5b04124 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1081,6 +1081,7 @@ static int inetdev_event(struct notifier_block *this, unsigned long event,
}
ip_mc_up(in_dev);
/* fall through */
+ case NETDEV_CHANGE:
case NETDEV_CHANGEADDR:
/* Send gratuitous ARP to notify of link change */
if (IN_DEV_ARP_NOTIFY(in_dev)) {
--
1.5.6.5
^ permalink raw reply related
* [PATCH 0/2] fixes to arp_notify for virtual machine migration use case
From: Ian Campbell @ 2010-05-12 13:39 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger, Jeremy Fitzhardinge, David S. Miller, stable
The following 2 patches fix two issues with arp_notify, one is a niggle
and the other makes the feature work with virtual machine migration.
The following changes since commit 94b849aaf6e22ab7bf54b0d0377a882d4892396d:
Linus Torvalds (1):
Merge branch 'fix/hda' of git://git.kernel.org/.../tiwai/sound-2.6
are available in the git repository at:
git://xenbits.xensource.com/people/ianc/linux-2.6.git for-netdev/fixes
Ian Campbell (2):
arp_notify: generate broadcast ARP reply not request.
arp_notify: generate arp_notify event on NETDEV_CHANGE too
net/ipv4/devinet.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
^ permalink raw reply
* comapt-wireless-2010-05-11,b43 can not be work.
From: SECO @ 2010-05-12 13:46 UTC (permalink / raw)
To: majordomo, netdev
Dear Sir,
UBUNTU 10.04 desktop
uname -a
Linux ubuntu 2.6.32-22-generic #33-Ubuntu SMP Wed Apr 28 13:27:30 UTC
2010 i686 GNU/Linux
What's the matter with it? TKS
seco@ubuntu:~/desktop/compat-wireless-2010-05-11$ sudo dmesg | grep b43
[ 1.097857] b43-pci-bridge 0000:30:00.0: PCI INT A -> GSI 18
(level, low) -> IRQ 18
[ 1.097867] b43-pci-bridge 0000:30:00.0: setting latency timer to 64
[ 22.341327] b43: disagrees about version of symbol
ieee80211_get_response_rate
[ 22.341334] b43: Unknown symbol ieee80211_get_response_rate
[ 22.342308] b43: disagrees about version of symbol ieee80211_free_hw
[ 22.342311] b43: Unknown symbol ieee80211_free_hw
[ 22.342577] b43: disagrees about version of symbol ieee80211_alloc_hw
[ 22.342579] b43: Unknown symbol ieee80211_alloc_hw
[ 22.342756] b43: disagrees about version of symbol ieee80211_register_hw
[ 22.342758] b43: Unknown symbol ieee80211_register_hw
[ 22.343024] b43: disagrees about version of symbol
__ieee80211_get_radio_led_name
[ 22.343026] b43: Unknown symbol __ieee80211_get_radio_led_name
[ 22.343128] b43: disagrees about version of symbol
ieee80211_generic_frame_duration
[ 22.343131] b43: Unknown symbol ieee80211_generic_frame_duration
[ 22.343232] b43: disagrees about version of symbol ieee80211_wake_queue
[ 22.343235] b43: Unknown symbol ieee80211_wake_queue
[ 22.343337] b43: disagrees about version of symbol ieee80211_get_tkip_key
[ 22.343339] b43: Unknown symbol ieee80211_get_tkip_key
[ 22.343644] b43: disagrees about version of symbol
__ieee80211_get_tx_led_name
[ 22.343647] b43: Unknown symbol __ieee80211_get_tx_led_name
[ 22.343757] b43: disagrees about version of symbol wiphy_rfkill_set_hw_state
[ 22.343760] b43: Unknown symbol wiphy_rfkill_set_hw_state
[ 22.344212] b43: disagrees about version of symbol
__ieee80211_get_rx_led_name
[ 22.344215] b43: Unknown symbol __ieee80211_get_rx_led_name
[ 22.344779] b43: disagrees about version of symbol
ieee80211_queue_delayed_work
[ 22.344782] b43: Unknown symbol ieee80211_queue_delayed_work
[ 22.344958] b43: disagrees about version of symbol ieee80211_ctstoself_get
[ 22.344961] b43: Unknown symbol ieee80211_ctstoself_get
[ 22.345130] b43: disagrees about version of symbol ieee80211_rx
[ 22.345133] b43: Unknown symbol ieee80211_rx
[ 22.345394] b43: disagrees about version of symbol ieee80211_wake_queues
[ 22.345397] b43: Unknown symbol ieee80211_wake_queues
[ 22.345635] b43: disagrees about version of symbol ieee80211_tx_status
[ 22.345637] b43: Unknown symbol ieee80211_tx_status
[ 22.345738] b43: disagrees about version of symbol ieee80211_stop_queue
[ 22.345740] b43: Unknown symbol ieee80211_stop_queue
[ 22.345992] b43: disagrees about version of symbol
__ieee80211_get_assoc_led_name
[ 22.345995] b43: Unknown symbol __ieee80211_get_assoc_led_name
[ 22.346100] b43: disagrees about version of symbol wiphy_rfkill_start_polling
[ 22.346103] b43: Unknown symbol wiphy_rfkill_start_polling
[ 22.346376] b43: disagrees about version of symbol ieee80211_unregister_hw
[ 22.346378] b43: Unknown symbol ieee80211_unregister_hw
[ 22.346985] b43: disagrees about version of symbol ieee80211_rts_get
[ 22.346988] b43: Unknown symbol ieee80211_rts_get
[ 22.347110] b43: Unknown symbol ieee80211_beacon_get
[ 22.347318] b43: disagrees about version of symbol ieee80211_queue_work
[ 22.347320] b43: Unknown symbol ieee80211_queue_work
[ 182.979820] b43: disagrees about version of symbol
ieee80211_get_response_rate
[ 182.979827] b43: Unknown symbol ieee80211_get_response_rate
[ 182.980856] b43: disagrees about version of symbol ieee80211_free_hw
[ 182.980859] b43: Unknown symbol ieee80211_free_hw
[ 182.981180] b43: disagrees about version of symbol ieee80211_alloc_hw
[ 182.981183] b43: Unknown symbol ieee80211_alloc_hw
[ 182.981369] b43: disagrees about version of symbol ieee80211_register_hw
[ 182.981372] b43: Unknown symbol ieee80211_register_hw
[ 182.982228] b43: disagrees about version of symbol
__ieee80211_get_radio_led_name
[ 182.982232] b43: Unknown symbol __ieee80211_get_radio_led_name
[ 182.982345] b43: disagrees about version of symbol
ieee80211_generic_frame_duration
[ 182.982348] b43: Unknown symbol ieee80211_generic_frame_duration
[ 182.982460] b43: disagrees about version of symbol ieee80211_wake_queue
[ 182.982463] b43: Unknown symbol ieee80211_wake_queue
[ 182.982573] b43: disagrees about version of symbol ieee80211_get_tkip_key
[ 182.982576] b43: Unknown symbol ieee80211_get_tkip_key
[ 182.982903] b43: disagrees about version of symbol
__ieee80211_get_tx_led_name
[ 182.982907] b43: Unknown symbol __ieee80211_get_tx_led_name
[ 182.983027] b43: disagrees about version of symbol wiphy_rfkill_set_hw_state
[ 182.983030] b43: Unknown symbol wiphy_rfkill_set_hw_state
[ 182.983457] b43: disagrees about version of symbol
__ieee80211_get_rx_led_name
[ 182.983460] b43: Unknown symbol __ieee80211_get_rx_led_name
[ 182.984058] b43: disagrees about version of symbol
ieee80211_queue_delayed_work
[ 182.984061] b43: Unknown symbol ieee80211_queue_delayed_work
[ 182.984247] b43: disagrees about version of symbol ieee80211_ctstoself_get
[ 182.984251] b43: Unknown symbol ieee80211_ctstoself_get
[ 182.984430] b43: disagrees about version of symbol ieee80211_rx
[ 182.984433] b43: Unknown symbol ieee80211_rx
[ 182.984714] b43: disagrees about version of symbol ieee80211_wake_queues
[ 182.984717] b43: Unknown symbol ieee80211_wake_queues
[ 182.984976] b43: disagrees about version of symbol ieee80211_tx_status
[ 182.984979] b43: Unknown symbol ieee80211_tx_status
[ 182.985111] b43: disagrees about version of symbol ieee80211_stop_queue
[ 182.985114] b43: Unknown symbol ieee80211_stop_queue
[ 182.985385] b43: disagrees about version of symbol
__ieee80211_get_assoc_led_name
[ 182.985389] b43: Unknown symbol __ieee80211_get_assoc_led_name
[ 182.985505] b43: disagrees about version of symbol wiphy_rfkill_start_polling
[ 182.985508] b43: Unknown symbol wiphy_rfkill_start_polling
[ 182.985800] b43: disagrees about version of symbol ieee80211_unregister_hw
[ 182.985803] b43: Unknown symbol ieee80211_unregister_hw
[ 182.987802] b43: disagrees about version of symbol ieee80211_rts_get
[ 182.987805] b43: Unknown symbol ieee80211_rts_get
[ 182.987936] b43: Unknown symbol ieee80211_beacon_get
[ 182.988166] b43: disagrees about version of symbol ieee80211_queue_work
[ 182.988170] b43: Unknown symbol ieee80211_queue_work
[ 715.137153] b43: disagrees about version of symbol
ieee80211_get_response_rate
[ 715.137175] b43: Unknown symbol ieee80211_get_response_rate
[ 715.139585] b43: disagrees about version of symbol ieee80211_free_hw
[ 715.139591] b43: Unknown symbol ieee80211_free_hw
[ 715.140289] b43: disagrees about version of symbol ieee80211_alloc_hw
[ 715.140295] b43: Unknown symbol ieee80211_alloc_hw
[ 715.140719] b43: disagrees about version of symbol ieee80211_register_hw
[ 715.140725] b43: Unknown symbol ieee80211_register_hw
[ 715.143098] b43: disagrees about version of symbol
__ieee80211_get_radio_led_name
[ 715.143107] b43: Unknown symbol __ieee80211_get_radio_led_name
[ 715.143362] b43: disagrees about version of symbol
ieee80211_generic_frame_duration
[ 715.143368] b43: Unknown symbol ieee80211_generic_frame_duration
[ 715.143623] b43: disagrees about version of symbol ieee80211_wake_queue
[ 715.143628] b43: Unknown symbol ieee80211_wake_queue
[ 715.143879] b43: disagrees about version of symbol ieee80211_get_tkip_key
[ 715.143884] b43: Unknown symbol ieee80211_get_tkip_key
[ 715.144734] b43: disagrees about version of symbol
__ieee80211_get_tx_led_name
[ 715.144740] b43: Unknown symbol __ieee80211_get_tx_led_name
[ 715.145026] b43: disagrees about version of symbol wiphy_rfkill_set_hw_state
[ 715.145032] b43: Unknown symbol wiphy_rfkill_set_hw_state
[ 715.146009] b43: disagrees about version of symbol
__ieee80211_get_rx_led_name
[ 715.146015] b43: Unknown symbol __ieee80211_get_rx_led_name
[ 715.147362] b43: disagrees about version of symbol
ieee80211_queue_delayed_work
[ 715.147368] b43: Unknown symbol ieee80211_queue_delayed_work
[ 715.147792] b43: disagrees about version of symbol ieee80211_ctstoself_get
[ 715.147798] b43: Unknown symbol ieee80211_ctstoself_get
[ 715.148231] b43: disagrees about version of symbol ieee80211_rx
[ 715.148237] b43: Unknown symbol ieee80211_rx
[ 715.148898] b43: disagrees about version of symbol ieee80211_wake_queues
[ 715.148910] b43: Unknown symbol ieee80211_wake_queues
[ 715.149522] b43: disagrees about version of symbol ieee80211_tx_status
[ 715.149529] b43: Unknown symbol ieee80211_tx_status
[ 715.149786] b43: disagrees about version of symbol ieee80211_stop_queue
[ 715.149792] b43: Unknown symbol ieee80211_stop_queue
[ 715.150435] b43: disagrees about version of symbol
__ieee80211_get_assoc_led_name
[ 715.150442] b43: Unknown symbol __ieee80211_get_assoc_led_name
[ 715.150716] b43: disagrees about version of symbol wiphy_rfkill_start_polling
[ 715.150722] b43: Unknown symbol wiphy_rfkill_start_polling
[ 715.151411] b43: disagrees about version of symbol ieee80211_unregister_hw
[ 715.151417] b43: Unknown symbol ieee80211_unregister_hw
[ 715.155035] b43: disagrees about version of symbol ieee80211_rts_get
[ 715.155043] b43: Unknown symbol ieee80211_rts_get
[ 715.155344] b43: Unknown symbol ieee80211_beacon_get
[ 715.155865] b43: disagrees about version of symbol ieee80211_queue_work
[ 715.155872] b43: Unknown symbol ieee80211_queue_work
seco@ubuntu:~/desktop/compat-wireless-2010-05-11$
--
Best Regards
--------------------
SECO
--------------------------------------------------------------------------------
This information in this e-mail is confidential and may well also be
legally privileged. It is intended solely for the addressee. If you
have received it in error, you are on notice of its status. Please
notify us immediately and then destroy this message. Please do not
copy it or use it for any purposes, or disclose its contents to any
other person: to do so could be a breach of confidence. Thank you for
your co-operation.
--------------------------------------------------------------------------------
^ permalink raw reply
* Re: [RFC PATCH] bnx2: use netif_carrier_off to prevent tx timeout
From: Michael Chan @ 2010-05-12 13:31 UTC (permalink / raw)
To: 'Stanislaw Gruszka', netdev@vger.kernel.org
Cc: Eric Dumazet, Eilon Greenstein, Vladislav Zolotarov,
Dmitry Kravkov, Breno Leitao, Matthew Carlson
In-Reply-To: <20100512130628.69bc3890@dhcp-lab-109.englab.brq.redhat.com>
Stanislaw Gruszka wrote:
> Touching ->trans_start make netdev watchdog timeouts only
> less probable.
> Use netif_carrier_off to prevent timeout, lately we take care
> of tuning
> carrier on.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> ---
> Patch was not tested!
>
> drivers/net/bnx2.c | 12 +++---------
> 1 files changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
> index 667f419..44fc392 100644
> --- a/drivers/net/bnx2.c
> +++ b/drivers/net/bnx2.c
> @@ -656,17 +656,9 @@ bnx2_netif_stop(struct bnx2 *bp, bool stop_cnic)
> if (stop_cnic)
> bnx2_cnic_stop(bp);
> if (netif_running(bp->dev)) {
> - int i;
> -
> bnx2_napi_disable(bp);
> netif_tx_disable(bp->dev);
> - /* prevent tx timeout */
> - for (i = 0; i < bp->dev->num_tx_queues; i++) {
> - struct netdev_queue *txq;
> -
> - txq = netdev_get_tx_queue(bp->dev, i);
> - txq->trans_start = jiffies;
> - }
> + netif_carrier_off(bp->dev);
> }
> bnx2_disable_int_sync(bp);
> }
> @@ -6346,6 +6338,8 @@ bnx2_vlan_rx_register(struct net_device
> *dev, struct vlan_group *vlgrp)
> if (bp->flags & BNX2_FLAG_CAN_KEEP_VLAN)
> bnx2_fw_sync(bp,
> BNX2_DRV_MSG_CODE_KEEP_VLAN_UPDATE, 0, 1);
>
> + if (bp->link_up)
> + netif_carrier_on(bp->dev);
Thanks Stanislaw, I think it is better to turn carrier on in
bnx2_netif_start(). We can use the start_cnic parameter to
decide if we need to call carrier_on(). I'll test this out.
Thanks.
> bnx2_netif_start(bp, false);
> }
> #endif
> --
> 1.5.5.6
>
>
>
>
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: avoid TX timeout when stopping device
From: Eric Dumazet @ 2010-05-12 12:37 UTC (permalink / raw)
To: eilong
Cc: Stanislaw Gruszka, netdev@vger.kernel.org, Vladislav Zolotarov,
Dmitry Kravkov, Michael Chan, Breno Leitao, Matthew Carlson
In-Reply-To: <1273663155.5948.7.camel@lb-tlvb-eilong.il.broadcom.com>
Le mercredi 12 mai 2010 à 14:19 +0300, Eilon Greenstein a écrit :
> Eric,
>
> I thought that your 1ae5dc342ac78d7a42965fd1f323815f6f5ef2c1 commit took
> care of trans_start, right? Well, actually the commit that made it
> possible to remove the trans_start manipulation.
Its only part of the (huge) job, started last year with 10GB and GB
nics.
My intent was to take care of not touching dev->trans_start in
start_xmit() method, then take care of other cases later.
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: avoid TX timeout when stopping device
From: Eilon Greenstein @ 2010-05-12 11:19 UTC (permalink / raw)
To: Stanislaw Gruszka, Eric Dumazet
Cc: netdev@vger.kernel.org, Vladislav Zolotarov, Dmitry Kravkov,
Michael Chan, Breno Leitao, Matthew Carlson
In-Reply-To: <20100512125815.0dad8ad0@dhcp-lab-109.englab.brq.redhat.com>
On Wed, 2010-05-12 at 03:58 -0700, Stanislaw Gruszka wrote:
> On Wed, 12 May 2010 11:27:38 +0200
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > Le mercredi 12 mai 2010 à 11:09 +0200, Stanislaw Gruszka a écrit :
> > > When stop device call netif_carrier_off() just after disabling TX queue to
> > > avoid possibility of netdev watchdog warning and ->ndo_tx_timeout() invocation.
> > >
> > > Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Stanislaw,
I like this patch - it does make a lot of sense. Thanks!
Acked-by: Eilon Greenstein <eilong@broadcom.com>
> > > ---
> >
> > This reminds me I saw some strange things in bnx2.c for a similar
> > symptom.
> >
> > Commit e6bf95ffa8d6f8f4b7ee33ea01490d95b0bbeb6e
> >
> > Would you take a look at this too ?
>
> I can send RFC patch for bnx2, and tg3 as I think it needs similar fix.
>
> > Or if this kind of trans_start refresh on all queues is really needed,
> > it should be a core network provided function, not implemented on every
> > driver...
>
> I think netif_carrier_off() should be used, since touching trans_start make
> timeout only less probable, but not prevent it.
Eric,
I thought that your 1ae5dc342ac78d7a42965fd1f323815f6f5ef2c1 commit took
care of trans_start, right? Well, actually the commit that made it
possible to remove the trans_start manipulation.
Eilon
^ permalink raw reply
* Re: [BUG] crashes with kvm/nat networking and net-next
From: Patrick McHardy @ 2010-05-12 11:18 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Stephen Hemminger, Bart De Schuymer, netdev
In-Reply-To: <1273649526.2621.3.camel@edumazet-laptop>
Eric Dumazet wrote:
> Le mardi 11 mai 2010 à 20:25 -0700, Stephen Hemminger a écrit :
>> This is a regression that is showing up now in net-next, not sure what
>> changed recently in bridge netfilter that could be causing it?
>>
>> [ 4593.956206] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
>> [ 4593.956219] IP: [<ffffffffa03357a4>] br_nf_forward_finish+0x154/0x170 [bridge]
>> [ 4593.956232] PGD 195ece067 PUD 1ba005067 PMD 0
>> [ 4593.956241] Oops: 0000 [#1] SMP
>> [ 4593.956248] last sysfs file: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:08/ATK0110:00/hwmon/hwmon0/temp2_label
>> [ 4593.956253] CPU 3
>> [ 4593.956256] Modules linked in: netconsole configfs hid_belkin tun ntfs vfat msdos fat autofs4 binfmt_misc ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc kvm_intel kvm radeon ttm drm_kms_helper drm i2c_algo_bit snd_hda_codec_analog ipv6 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device psmouse asus_atk0110 snd serio_raw soundcore snd_page_alloc usbhid mvsas libsas scsi_transport_sas floppy sky2 e1000e [last unloaded: netconsole]
>> [ 4593.956375]
>> [ 4593.956380] Pid: 29512, comm: kvm Not tainted 2.6.34-rc7-net #195 P6T DELUXE/System Product Name
>> [ 4593.956384] RIP: 0010:[<ffffffffa03357a4>] [<ffffffffa03357a4>] br_nf_forward_finish+0x154/0x170 [bridge]
>> [ 4593.956395] RSP: 0018:ffff880001e63b78 EFLAGS: 00010246
>> [ 4593.956399] RAX: 0000000000000608 RBX: ffff880057181700 RCX: ffff8801b813d000
>> [ 4593.956402] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff880057181700
>> [ 4593.956406] RBP: ffff880001e63ba8 R08: ffff8801b9d97000 R09: ffffffffa0335650
>> [ 4593.956410] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801b813d000
>> [ 4593.956413] R13: ffffffff81ab3940 R14: ffff880057181700 R15: 0000000000000002
>> [ 4593.956418] FS: 00007fc40d380710(0000) GS:ffff880001e60000(0000) knlGS:0000000000000000
>> [ 4593.956422] CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
>> [ 4593.956426] CR2: 0000000000000018 CR3: 00000001ba1d7000 CR4: 00000000000026e0
>> [ 4593.956429] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> [ 4593.956433] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> [ 4593.956437] Process kvm (pid: 29512, threadinfo ffff8801ba566000, task ffff8801b8003870)
>> [ 4593.956441] Stack:
>> [ 4593.956443] 0000000100000020 ffff880001e63ba0 ffff880001e63ba0 ffff880057181700
>> [ 4593.956451] <0> ffffffffa0335650 ffffffff81ab3940 ffff880001e63bd8 ffffffffa03350e6
>> [ 4593.956462] <0> ffff880001e63c40 000000000000024d ffff880057181700 0000000080000000
>> [ 4593.956474] Call Trace:
>> [ 4593.956478] <IRQ>
>> [ 4593.956488] [<ffffffffa0335650>] ? br_nf_forward_finish+0x0/0x170 [bridge]
>> [ 4593.956496] [<ffffffffa03350e6>] NF_HOOK_THRESH+0x56/0x60 [bridge]
>> [ 4593.956504] [<ffffffffa0335282>] br_nf_forward_arp+0x112/0x120 [bridge]
>> [ 4593.956511] [<ffffffff813f7184>] nf_iterate+0x64/0xa0
>> [ 4593.956519] [<ffffffffa032f920>] ? br_forward_finish+0x0/0x60 [bridge]
>> [ 4593.956524] [<ffffffff813f722c>] nf_hook_slow+0x6c/0x100
>> [ 4593.956531] [<ffffffffa032f920>] ? br_forward_finish+0x0/0x60 [bridge]
>> [ 4593.956538] [<ffffffffa032f800>] ? __br_forward+0x0/0xc0 [bridge]
>> [ 4593.956545] [<ffffffffa032f86d>] __br_forward+0x6d/0xc0 [bridge]
>> [ 4593.956550] [<ffffffff813c5d8e>] ? skb_clone+0x3e/0x70
>
> Not sure, but br_nf_forward_ip() has following check :
>
> if (!skb->nf_bridge)
> return NF_ACCEPT;
>
> while br_nf_forward_arp() missed this check ...
>
> So we can dereference null pointer later
That looks correct to me, offset 0x18 would be nf_bridge_info->mask.
Bart, please review, thanks.
>
> diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
> index 93f80fe..cd2e5f5 100644
> --- a/net/bridge/br_netfilter.c
> +++ b/net/bridge/br_netfilter.c
> @@ -723,6 +723,9 @@ static unsigned int br_nf_forward_arp(unsigned int hook, struct sk_buff *skb,
> return NF_ACCEPT;
> #endif
>
> + if (!skb->nf_bridge)
> + return NF_ACCEPT;
> +
> if (skb->protocol != htons(ETH_P_ARP)) {
> if (!IS_VLAN_ARP(skb))
> return NF_ACCEPT;
>
>
^ permalink raw reply
* [RFC PATCH] tg3: use netif_carrier_off to prevent tx timeout
From: Stanislaw Gruszka @ 2010-05-12 11:16 UTC (permalink / raw)
To: netdev
Cc: Eric Dumazet, Eilon Greenstein, Vladislav Zolotarov,
Dmitry Kravkov, Michael Chan, Breno Leitao, Matt Carlson
In-Reply-To: <20100512130628.69bc3890@dhcp-lab-109.englab.brq.redhat.com>
Touching ->trans_start make netdev watchdog timeouts only less probable.
Use netif_carrier_off to prevent timeout, lately we take care of turning
carrier on.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
Patch was not tested!
drivers/net/tg3.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 573054a..d745038 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -753,7 +753,7 @@ static void tg3_napi_enable(struct tg3 *tp)
static inline void tg3_netif_stop(struct tg3 *tp)
{
- tp->dev->trans_start = jiffies; /* prevent tx timeout */
+ netif_carrier_off(tp->dev); /* prevent tx timeout */
tg3_napi_disable(tp);
netif_tx_disable(tp->dev);
}
@@ -10964,12 +10964,14 @@ static int tg3_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
static void tg3_vlan_rx_register(struct net_device *dev, struct vlan_group *grp)
{
struct tg3 *tp = netdev_priv(dev);
+ int link_up;
if (!netif_running(dev)) {
tp->vlgrp = grp;
return;
}
+ link_up = netif_carrier_ok(dev);
tg3_netif_stop(tp);
tg3_full_lock(tp, 0);
@@ -10979,6 +10981,8 @@ static void tg3_vlan_rx_register(struct net_device *dev, struct vlan_group *grp)
/* Update RX_MODE_KEEP_VLAN_TAG bit in RX_MODE register. */
__tg3_set_rx_mode(dev);
+ if (link_up)
+ netif_carrier_on(dev);
tg3_netif_start(tp);
tg3_full_unlock(tp);
--
1.5.5.6
^ permalink raw reply related
* [RFC PATCH] bnx2: use netif_carrier_off to prevent tx timeout
From: Stanislaw Gruszka @ 2010-05-12 11:06 UTC (permalink / raw)
To: netdev
Cc: Eric Dumazet, Eilon Greenstein, Vladislav Zolotarov,
Dmitry Kravkov, Michael Chan, Breno Leitao, Matt Carlson
In-Reply-To: <20100512125815.0dad8ad0@dhcp-lab-109.englab.brq.redhat.com>
Touching ->trans_start make netdev watchdog timeouts only less probable.
Use netif_carrier_off to prevent timeout, lately we take care of tuning
carrier on.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
Patch was not tested!
drivers/net/bnx2.c | 12 +++---------
1 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 667f419..44fc392 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -656,17 +656,9 @@ bnx2_netif_stop(struct bnx2 *bp, bool stop_cnic)
if (stop_cnic)
bnx2_cnic_stop(bp);
if (netif_running(bp->dev)) {
- int i;
-
bnx2_napi_disable(bp);
netif_tx_disable(bp->dev);
- /* prevent tx timeout */
- for (i = 0; i < bp->dev->num_tx_queues; i++) {
- struct netdev_queue *txq;
-
- txq = netdev_get_tx_queue(bp->dev, i);
- txq->trans_start = jiffies;
- }
+ netif_carrier_off(bp->dev);
}
bnx2_disable_int_sync(bp);
}
@@ -6346,6 +6338,8 @@ bnx2_vlan_rx_register(struct net_device *dev, struct vlan_group *vlgrp)
if (bp->flags & BNX2_FLAG_CAN_KEEP_VLAN)
bnx2_fw_sync(bp, BNX2_DRV_MSG_CODE_KEEP_VLAN_UPDATE, 0, 1);
+ if (bp->link_up)
+ netif_carrier_on(bp->dev);
bnx2_netif_start(bp, false);
}
#endif
--
1.5.5.6
^ permalink raw reply related
* Re: [PATCH net-next] bnx2x: avoid TX timeout when stopping device
From: Stanislaw Gruszka @ 2010-05-12 10:58 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, Eilon Greenstein, Vladislav Zolotarov, Dmitry Kravkov,
Michael Chan, Breno Leitao, Matt Carlson
In-Reply-To: <1273656458.2621.22.camel@edumazet-laptop>
On Wed, 12 May 2010 11:27:38 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mercredi 12 mai 2010 à 11:09 +0200, Stanislaw Gruszka a écrit :
> > When stop device call netif_carrier_off() just after disabling TX queue to
> > avoid possibility of netdev watchdog warning and ->ndo_tx_timeout() invocation.
> >
> > Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> > ---
>
> This reminds me I saw some strange things in bnx2.c for a similar
> symptom.
>
> Commit e6bf95ffa8d6f8f4b7ee33ea01490d95b0bbeb6e
>
> Would you take a look at this too ?
I can send RFC patch for bnx2, and tg3 as I think it needs similar fix.
> Or if this kind of trans_start refresh on all queues is really needed,
> it should be a core network provided function, not implemented on every
> driver...
I think netif_carrier_off() should be used, since touching trans_start make
timeout only less probable, but not prevent it.
Stanislaw
^ permalink raw reply
* RE: does the broadcom bnx2x support RSS/multi queue
From: Eric Dumazet @ 2010-05-12 9:59 UTC (permalink / raw)
To: Jon Zhou; +Cc: eilong@broadcom.com, netdev@vger.kernel.org
In-Reply-To: <4A6A2125329CFD4D8CC40C9E8ABCAB9F2497D85DCD@MILEXCH2.ds.jdsu.net>
Le mercredi 12 mai 2010 à 02:34 -0700, Jon Zhou a écrit :
> hi eilon:
>
> do you think I need to update the kernel also?
>
> thanks!
> jon
I believe both of us (Eilong and me) stated your kernel version was too
old.
In order to play with multiqueue, you should use a very recent kernel,
or hit various bottlenecks and bugs.
^ permalink raw reply
* RE: does the broadcom bnx2x support RSS/multi queue
From: Eilon Greenstein @ 2010-05-12 9:58 UTC (permalink / raw)
To: Jon Zhou; +Cc: Eric Dumazet, netdev@vger.kernel.org
In-Reply-To: <4A6A2125329CFD4D8CC40C9E8ABCAB9F2497D85DCD@MILEXCH2.ds.jdsu.net>
On Wed, 2010-05-12 at 02:34 -0700, Jon Zhou wrote:
> hi eilon:
>
> do you think I need to update the kernel also?
Kernel 2.6.27 supports Tx multi queue (Rx multi-queue was added even
before that), so theoretically you can update only the bnx2x. However,
you cannot use the bnx2x from the current kernel due to other changes
between 2.6.27 and the current kernel. So you need to download the bnx2x
from the Broadcom site.
Enjoy,
Eilon
^ permalink raw reply
* [PATCH NEXT 2/4] netxen: remove unnecessary size checks
From: Amit Kumar Salecha @ 2010-05-12 9:53 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, Sucheta Chakraborty
In-Reply-To: <1273657985-13405-1-git-send-email-amit.salecha@qlogic.com>
From: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
NX3031 have 64bit on card memory. Fix the limit check to
64MB and remove unnecessary 128bit read/write check.
Signed-off-by: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/netxen/netxen_nic_hdr.h | 6 ----
drivers/net/netxen/netxen_nic_hw.c | 52 +++++-----------------------------
2 files changed, 8 insertions(+), 50 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_hdr.h b/drivers/net/netxen/netxen_nic_hdr.h
index d930068..d8bd73d 100644
--- a/drivers/net/netxen/netxen_nic_hdr.h
+++ b/drivers/net/netxen/netxen_nic_hdr.h
@@ -681,14 +681,8 @@ enum {
#define MIU_TEST_AGT_ADDR_HI (0x08)
#define MIU_TEST_AGT_WRDATA_LO (0x10)
#define MIU_TEST_AGT_WRDATA_HI (0x14)
-#define MIU_TEST_AGT_WRDATA_UPPER_LO (0x20)
-#define MIU_TEST_AGT_WRDATA_UPPER_HI (0x24)
-#define MIU_TEST_AGT_WRDATA(i) (0x10+(0x10*((i)>>1))+(4*((i)&1)))
#define MIU_TEST_AGT_RDDATA_LO (0x18)
#define MIU_TEST_AGT_RDDATA_HI (0x1c)
-#define MIU_TEST_AGT_RDDATA_UPPER_LO (0x28)
-#define MIU_TEST_AGT_RDDATA_UPPER_HI (0x2c)
-#define MIU_TEST_AGT_RDDATA(i) (0x18+(0x10*((i)>>1))+(4*((i)&1)))
#define MIU_TEST_AGT_ADDR_MASK 0xfffffff8
#define MIU_TEST_AGT_UPPER_ADDR(off) (0)
diff --git a/drivers/net/netxen/netxen_nic_hw.c b/drivers/net/netxen/netxen_nic_hw.c
index 5e5fe2f..87bc910 100644
--- a/drivers/net/netxen/netxen_nic_hw.c
+++ b/drivers/net/netxen/netxen_nic_hw.c
@@ -1621,9 +1621,8 @@ static int
netxen_nic_pci_mem_write_2M(struct netxen_adapter *adapter,
u64 off, u64 data)
{
- int i, j, ret;
+ int j, ret;
u32 temp, off8;
- u64 stride;
void __iomem *mem_crb;
/* Only 64-bit aligned access */
@@ -1650,44 +1649,17 @@ netxen_nic_pci_mem_write_2M(struct netxen_adapter *adapter,
return -EIO;
correct:
- stride = NX_IS_REVISION_P3P(adapter->ahw.revision_id) ? 16 : 8;
-
- off8 = off & ~(stride-1);
+ off8 = off & 0xfffffff8;
spin_lock(&adapter->ahw.mem_lock);
writel(off8, (mem_crb + MIU_TEST_AGT_ADDR_LO));
writel(0, (mem_crb + MIU_TEST_AGT_ADDR_HI));
- i = 0;
- if (stride == 16) {
- writel(TA_CTL_ENABLE, (mem_crb + TEST_AGT_CTRL));
- writel((TA_CTL_START | TA_CTL_ENABLE),
- (mem_crb + TEST_AGT_CTRL));
-
- for (j = 0; j < MAX_CTL_CHECK; j++) {
- temp = readl(mem_crb + TEST_AGT_CTRL);
- if ((temp & TA_CTL_BUSY) == 0)
- break;
- }
-
- if (j >= MAX_CTL_CHECK) {
- ret = -EIO;
- goto done;
- }
-
- i = (off & 0xf) ? 0 : 2;
- writel(readl(mem_crb + MIU_TEST_AGT_RDDATA(i)),
- mem_crb + MIU_TEST_AGT_WRDATA(i));
- writel(readl(mem_crb + MIU_TEST_AGT_RDDATA(i+1)),
- mem_crb + MIU_TEST_AGT_WRDATA(i+1));
- i = (off & 0xf) ? 2 : 0;
- }
-
writel(data & 0xffffffff,
- mem_crb + MIU_TEST_AGT_WRDATA(i));
+ mem_crb + MIU_TEST_AGT_WRDATA_LO);
writel((data >> 32) & 0xffffffff,
- mem_crb + MIU_TEST_AGT_WRDATA(i+1));
+ mem_crb + MIU_TEST_AGT_WRDATA_HI);
writel((TA_CTL_ENABLE | TA_CTL_WRITE), (mem_crb + TEST_AGT_CTRL));
writel((TA_CTL_START | TA_CTL_ENABLE | TA_CTL_WRITE),
@@ -1707,7 +1679,6 @@ correct:
} else
ret = 0;
-done:
spin_unlock(&adapter->ahw.mem_lock);
return ret;
@@ -1719,7 +1690,7 @@ netxen_nic_pci_mem_read_2M(struct netxen_adapter *adapter,
{
int j, ret;
u32 temp, off8;
- u64 val, stride;
+ u64 val;
void __iomem *mem_crb;
/* Only 64-bit aligned access */
@@ -1748,9 +1719,7 @@ netxen_nic_pci_mem_read_2M(struct netxen_adapter *adapter,
return -EIO;
correct:
- stride = NX_IS_REVISION_P3P(adapter->ahw.revision_id) ? 16 : 8;
-
- off8 = off & ~(stride-1);
+ off8 = off & 0xfffffff8;
spin_lock(&adapter->ahw.mem_lock);
@@ -1771,13 +1740,8 @@ correct:
"failed to read through agent\n");
ret = -EIO;
} else {
- off8 = MIU_TEST_AGT_RDDATA_LO;
- if ((stride == 16) && (off & 0xf))
- off8 = MIU_TEST_AGT_RDDATA_UPPER_LO;
-
- temp = readl(mem_crb + off8 + 4);
- val = (u64)temp << 32;
- val |= readl(mem_crb + off8);
+ val = (u64)(readl(mem_crb + MIU_TEST_AGT_RDDATA_HI)) << 32;
+ val |= readl(mem_crb + MIU_TEST_AGT_RDDATA_LO);
*data = val;
ret = 0;
}
--
1.6.0.2
^ permalink raw reply related
* [PATCH NEXT 0/4]netxen: bug fixes
From: Amit Kumar Salecha @ 2010-05-12 9:53 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman
Hi
Series of 4 patches to fix diagnostic tools access and register usage
for NX3031.
Please apply them on net-next branch.
-Amit
^ permalink raw reply
* [PATCH NEXT 4/4] netxen: handle queue manager access
From: Amit Kumar Salecha @ 2010-05-12 9:53 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman
In-Reply-To: <1273657985-13405-1-git-send-email-amit.salecha@qlogic.com>
Check the access by tools for hardware queue engine and handle it
separately than other block registers, otherwise incorrect data
is returned.
Support for only NX3031 based cards.
Acked-by: Dhananjay Phadke <dhananjay.phadke@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/netxen/netxen_nic.h | 5 ++++
drivers/net/netxen/netxen_nic_hw.c | 25 +++++++++++++++++--
drivers/net/netxen/netxen_nic_main.c | 44 +++++++++++++++++++++++++++------
3 files changed, 63 insertions(+), 11 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
index 174ac8e..ffa1b9c 100644
--- a/drivers/net/netxen/netxen_nic.h
+++ b/drivers/net/netxen/netxen_nic.h
@@ -95,6 +95,9 @@
#define ADDR_IN_WINDOW1(off) \
((off > NETXEN_CRB_PCIX_HOST2) && (off < NETXEN_CRB_MAX)) ? 1 : 0
+#define ADDR_IN_RANGE(addr, low, high) \
+ (((addr) < (high)) && ((addr) >= (low)))
+
/*
* normalize a 64MB crb address to 32MB PCI window
* To use NETXEN_CRB_NORMALIZE, window _must_ be set to 1
@@ -1352,6 +1355,8 @@ int netxen_config_rss(struct netxen_adapter *adapter, int enable);
int netxen_config_ipaddr(struct netxen_adapter *adapter, u32 ip, int cmd);
int netxen_linkevent_request(struct netxen_adapter *adapter, int enable);
void netxen_advert_link_change(struct netxen_adapter *adapter, int linkup);
+void netxen_pci_camqm_read_2M(struct netxen_adapter *, u64, u64 *);
+void netxen_pci_camqm_write_2M(struct netxen_adapter *, u64, u64);
int nx_fw_cmd_set_mtu(struct netxen_adapter *adapter, int mtu);
int netxen_nic_change_mtu(struct net_device *netdev, int new_mtu);
diff --git a/drivers/net/netxen/netxen_nic_hw.c b/drivers/net/netxen/netxen_nic_hw.c
index be63988..5c496f8 100644
--- a/drivers/net/netxen/netxen_nic_hw.c
+++ b/drivers/net/netxen/netxen_nic_hw.c
@@ -62,9 +62,6 @@ static inline void writeq(u64 val, void __iomem *addr)
}
#endif
-#define ADDR_IN_RANGE(addr, low, high) \
- (((addr) < (high)) && ((addr) >= (low)))
-
#define PCI_OFFSET_FIRST_RANGE(adapter, off) \
((adapter)->ahw.pci_base0 + (off))
#define PCI_OFFSET_SECOND_RANGE(adapter, off) \
@@ -1448,6 +1445,28 @@ unlock:
return ret;
}
+void
+netxen_pci_camqm_read_2M(struct netxen_adapter *adapter, u64 off, u64 *data)
+{
+ void __iomem *addr = adapter->ahw.pci_base0 +
+ NETXEN_PCI_CAMQM_2M_BASE + (off - NETXEN_PCI_CAMQM);
+
+ spin_lock(&adapter->ahw.mem_lock);
+ *data = readq(addr);
+ spin_unlock(&adapter->ahw.mem_lock);
+}
+
+void
+netxen_pci_camqm_write_2M(struct netxen_adapter *adapter, u64 off, u64 data)
+{
+ void __iomem *addr = adapter->ahw.pci_base0 +
+ NETXEN_PCI_CAMQM_2M_BASE + (off - NETXEN_PCI_CAMQM);
+
+ spin_lock(&adapter->ahw.mem_lock);
+ writeq(data, addr);
+ spin_unlock(&adapter->ahw.mem_lock);
+}
+
#define MAX_CTL_CHECK 1000
static int
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index b665b42..692e672 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -2537,14 +2537,24 @@ static int
netxen_sysfs_validate_crb(struct netxen_adapter *adapter,
loff_t offset, size_t size)
{
+ size_t crb_size = 4;
+
if (!(adapter->flags & NETXEN_NIC_DIAG_ENABLED))
return -EIO;
- if ((size != 4) || (offset & 0x3))
- return -EINVAL;
+ if (offset < NETXEN_PCI_CRBSPACE) {
+ if (NX_IS_REVISION_P2(adapter->ahw.revision_id))
+ return -EINVAL;
- if (offset < NETXEN_PCI_CRBSPACE)
- return -EINVAL;
+ if (ADDR_IN_RANGE(offset, NETXEN_PCI_CAMQM,
+ NETXEN_PCI_CAMQM_2M_END))
+ crb_size = 8;
+ else
+ return -EINVAL;
+ }
+
+ if ((size != crb_size) || (offset & (crb_size-1)))
+ return -EINVAL;
return 0;
}
@@ -2556,14 +2566,23 @@ netxen_sysfs_read_crb(struct kobject *kobj, struct bin_attribute *attr,
struct device *dev = container_of(kobj, struct device, kobj);
struct netxen_adapter *adapter = dev_get_drvdata(dev);
u32 data;
+ u64 qmdata;
int ret;
ret = netxen_sysfs_validate_crb(adapter, offset, size);
if (ret != 0)
return ret;
- data = NXRD32(adapter, offset);
- memcpy(buf, &data, size);
+ if (NX_IS_REVISION_P3(adapter->ahw.revision_id) &&
+ ADDR_IN_RANGE(offset, NETXEN_PCI_CAMQM,
+ NETXEN_PCI_CAMQM_2M_END)) {
+ netxen_pci_camqm_read_2M(adapter, offset, &qmdata);
+ memcpy(buf, &qmdata, size);
+ } else {
+ data = NXRD32(adapter, offset);
+ memcpy(buf, &data, size);
+ }
+
return size;
}
@@ -2574,14 +2593,23 @@ netxen_sysfs_write_crb(struct kobject *kobj, struct bin_attribute *attr,
struct device *dev = container_of(kobj, struct device, kobj);
struct netxen_adapter *adapter = dev_get_drvdata(dev);
u32 data;
+ u64 qmdata;
int ret;
ret = netxen_sysfs_validate_crb(adapter, offset, size);
if (ret != 0)
return ret;
- memcpy(&data, buf, size);
- NXWR32(adapter, offset, data);
+ if (NX_IS_REVISION_P3(adapter->ahw.revision_id) &&
+ ADDR_IN_RANGE(offset, NETXEN_PCI_CAMQM,
+ NETXEN_PCI_CAMQM_2M_END)) {
+ memcpy(&qmdata, buf, size);
+ netxen_pci_camqm_write_2M(adapter, offset, qmdata);
+ } else {
+ memcpy(&data, buf, size);
+ NXWR32(adapter, offset, data);
+ }
+
return size;
}
--
1.6.0.2
^ permalink raw reply related
* [PATCH NEXT 1/4] netxen: fix register usage
From: Amit Kumar Salecha @ 2010-05-12 9:53 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman
In-Reply-To: <1273657985-13405-1-git-send-email-amit.salecha@qlogic.com>
o For NX3031, MSI_MODE, CAPABILITIES_FW and SCRATCHPAD registers
are obsolete. These register addresses can be used for different
purpose.
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/netxen/netxen_nic_ethtool.c | 3 +++
drivers/net/netxen/netxen_nic_hdr.h | 2 --
drivers/net/netxen/netxen_nic_init.c | 4 +++-
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_ethtool.c b/drivers/net/netxen/netxen_nic_ethtool.c
index aecba78..20f7c58 100644
--- a/drivers/net/netxen/netxen_nic_ethtool.c
+++ b/drivers/net/netxen/netxen_nic_ethtool.c
@@ -632,6 +632,9 @@ static int netxen_nic_reg_test(struct net_device *dev)
if ((data_read & 0xffff) != adapter->pdev->vendor)
return 1;
+ if (NX_IS_REVISION_P3(adapter->ahw.revision_id))
+ return 0;
+
data_written = (u32)0xa5a5a5a5;
NXWR32(adapter, CRB_SCRATCHPAD_TEST, data_written);
diff --git a/drivers/net/netxen/netxen_nic_hdr.h b/drivers/net/netxen/netxen_nic_hdr.h
index 622e4c8..d930068 100644
--- a/drivers/net/netxen/netxen_nic_hdr.h
+++ b/drivers/net/netxen/netxen_nic_hdr.h
@@ -789,9 +789,7 @@ enum {
* for backward compability
*/
#define CRB_NIC_CAPABILITIES_HOST NETXEN_NIC_REG(0x1a8)
-#define CRB_NIC_CAPABILITIES_FW NETXEN_NIC_REG(0x1dc)
#define CRB_NIC_MSI_MODE_HOST NETXEN_NIC_REG(0x270)
-#define CRB_NIC_MSI_MODE_FW NETXEN_NIC_REG(0x274)
#define INTR_SCHEME_PERPORT 0x1
#define MSI_MODE_MULTIFUNC 0x1
diff --git a/drivers/net/netxen/netxen_nic_init.c b/drivers/net/netxen/netxen_nic_init.c
index 388feaf..4a2bbeb 100644
--- a/drivers/net/netxen/netxen_nic_init.c
+++ b/drivers/net/netxen/netxen_nic_init.c
@@ -1361,10 +1361,12 @@ int netxen_init_firmware(struct netxen_adapter *adapter)
return err;
NXWR32(adapter, CRB_NIC_CAPABILITIES_HOST, INTR_SCHEME_PERPORT);
- NXWR32(adapter, CRB_NIC_MSI_MODE_HOST, MSI_MODE_MULTIFUNC);
NXWR32(adapter, CRB_MPORT_MODE, MPORT_MULTI_FUNCTION_MODE);
NXWR32(adapter, CRB_CMDPEG_STATE, PHAN_INITIALIZE_ACK);
+ if (NX_IS_REVISION_P2(adapter->ahw.revision_id))
+ NXWR32(adapter, CRB_NIC_MSI_MODE_HOST, MSI_MODE_MULTIFUNC);
+
return err;
}
--
1.6.0.2
^ permalink raw reply related
* [PATCH NEXT 3/4] netxen: to fix onchip memory access.
From: Amit Kumar Salecha @ 2010-05-12 9:53 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, Sucheta Chakraborty
In-Reply-To: <1273657985-13405-1-git-send-email-amit.salecha@qlogic.com>
From: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
Remove unnecessary remap of the region in bar 0 to access onhip memory
for NX3031.
Signed-off-by: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/netxen/netxen_nic_hw.c | 42 ++++++++++++++---------------------
1 files changed, 17 insertions(+), 25 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_hw.c b/drivers/net/netxen/netxen_nic_hw.c
index 87bc910..be63988 100644
--- a/drivers/net/netxen/netxen_nic_hw.c
+++ b/drivers/net/netxen/netxen_nic_hw.c
@@ -32,7 +32,6 @@
#define MASK(n) ((1ULL<<(n))-1)
#define MN_WIN(addr) (((addr & 0x1fc0000) >> 1) | ((addr >> 25) & 0x3ff))
#define OCM_WIN(addr) (((addr & 0x1ff0000) >> 1) | ((addr >> 25) & 0x3ff))
-#define OCM_WIN_P3P(addr) (addr & 0xffc0000)
#define MS_WIN(addr) (addr & 0x0ffc0000)
#define GET_MEM_OFFS_2M(addr) (addr & MASK(18))
@@ -1391,18 +1390,8 @@ netxen_nic_pci_set_window_2M(struct netxen_adapter *adapter,
u64 addr, u32 *start)
{
u32 window;
- struct pci_dev *pdev = adapter->pdev;
- if ((addr & 0x00ff800) == 0xff800) {
- if (printk_ratelimit())
- dev_warn(&pdev->dev, "QM access not handled\n");
- return -EIO;
- }
-
- if (NX_IS_REVISION_P3P(adapter->ahw.revision_id))
- window = OCM_WIN_P3P(addr);
- else
- window = OCM_WIN(addr);
+ window = OCM_WIN(addr);
writel(window, adapter->ahw.ocm_win_crb);
/* read back to flush */
@@ -1419,7 +1408,7 @@ netxen_nic_pci_mem_access_direct(struct netxen_adapter *adapter, u64 off,
{
void __iomem *addr, *mem_ptr = NULL;
resource_size_t mem_base;
- int ret = -EIO;
+ int ret;
u32 start;
spin_lock(&adapter->ahw.mem_lock);
@@ -1428,20 +1417,23 @@ netxen_nic_pci_mem_access_direct(struct netxen_adapter *adapter, u64 off,
if (ret != 0)
goto unlock;
- addr = pci_base_offset(adapter, start);
- if (addr)
- goto noremap;
-
- mem_base = pci_resource_start(adapter->pdev, 0) + (start & PAGE_MASK);
+ if (NX_IS_REVISION_P3(adapter->ahw.revision_id)) {
+ addr = adapter->ahw.pci_base0 + start;
+ } else {
+ addr = pci_base_offset(adapter, start);
+ if (addr)
+ goto noremap;
+
+ mem_base = pci_resource_start(adapter->pdev, 0) +
+ (start & PAGE_MASK);
+ mem_ptr = ioremap(mem_base, PAGE_SIZE);
+ if (mem_ptr == NULL) {
+ ret = -EIO;
+ goto unlock;
+ }
- mem_ptr = ioremap(mem_base, PAGE_SIZE);
- if (mem_ptr == NULL) {
- ret = -EIO;
- goto unlock;
+ addr = mem_ptr + (start & (PAGE_SIZE-1));
}
-
- addr = mem_ptr + (start & (PAGE_SIZE - 1));
-
noremap:
if (op == 0) /* read */
*data = readq(addr);
--
1.6.0.2
^ permalink raw reply related
* RE: does the broadcom bnx2x support RSS/multi queue
From: Jon Zhou @ 2010-05-12 9:34 UTC (permalink / raw)
To: eilong@broadcom.com, Eric Dumazet; +Cc: netdev@vger.kernel.org
In-Reply-To: <1273655947.4491.5.camel@lb-tlvb-eilong.il.broadcom.com>
hi eilon:
do you think I need to update the kernel also?
thanks!
jon
-----Original Message-----
From: Eilon Greenstein [mailto:eilong@broadcom.com]
Sent: Wednesday, May 12, 2010 5:19 PM
To: Eric Dumazet
Cc: Jon Zhou; netdev@vger.kernel.org
Subject: Re: does the broadcom bnx2x support RSS/multi queue
On Wed, 2010-05-12 at 00:41 -0700, Eric Dumazet wrote:
> Le mercredi 12 mai 2010 à 00:31 -0700, Jon Zhou a écrit :
> > hi there
> >
> > I am not sure if my Broadcom 10G nic driver(bnx2x) support RSS/multi queue
> >
> > ibm-bc-53:/home/ruizhou/nprobe # uname -a
> > Linux ibm-bc-53 2.6.27.19-5-default #1 SMP 2009-02-28 04:40:21 +0100 x86_64 x86_64 x86_64 GNU/Linux
> >
> > ibm-bc-53:/home/ruizhou/nprobe # ethtool -S eth5
> > NIC statistics:
> > rx_bytes: 68100170
> > rx_error_bytes: 0
> > tx_bytes: 0
> > tx_error_bytes: 0
> > rx_ucast_packets: 201654
> > rx_mcast_packets: 0
> > rx_bcast_packets: 0
> > tx_packets: 0
> > tx_mac_errors: 0
> > tx_carrier_errors: 0
> > rx_crc_errors: 0
> > rx_align_errors: 0
> > tx_single_collisions: 0
> > tx_multi_collisions: 0
> > tx_deferred: 0
> > tx_excess_collisions: 0
> > tx_late_collisions: 0
> > tx_total_collisions: 0
> > rx_fragments: 0
> > rx_jabbers: 0
> > rx_undersize_packets: 0
> > rx_oversize_packets: 0
> > tx_64_byte_packets: 0
> > tx_65_to_127_byte_packets: 0
> > tx_128_to_255_byte_packets: 0
> > tx_256_to_511_byte_packets: 0
> > tx_512_to_1023_byte_packets: 0
> > tx_1024_to_1522_byte_packets: 0
> > tx_1523_to_9022_byte_packets: 0
> > rx_xon_frames: 0
> > rx_xoff_frames: 0
> > tx_xon_frames: 0
> > tx_xoff_frames: 0
> > rx_mac_ctrl_frames: 0
> > rx_filtered_packets: 0
> > rx_discards: 0
> > rx_fw_discards: 0
> > brb_discard: 0
> > brb_truncate: 0
> > rx_phy_ip_err_discards: 0
> > rx_skb_alloc_discard: 0
> > rx_csum_offload_errors: 6
> >
> > the driver ver is:
> > bnx2x_main.c
> > #define DRV_MODULE_VERSION "1.45.26"
> >
> > looks not support?
> >
> > thanks
> > jon
>
> Per queue stats were added last year only (Thu Feb 12 08:36:33 2009)
>
> You might check "grep eth5 /proc/interrupts"
>
> Or upgrade to 2.6.33.x kernel :)
>
The HW and current driver support multi-queue. However, you are using a version which is too old.
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: avoid TX timeout when stopping device
From: Eric Dumazet @ 2010-05-12 9:27 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: netdev, Eilon Greenstein, Vladislav Zolotarov, Dmitry Kravkov,
Michael Chan, Breno Leitao
In-Reply-To: <20100512110921.0e3f45fc@dhcp-lab-109.englab.brq.redhat.com>
Le mercredi 12 mai 2010 à 11:09 +0200, Stanislaw Gruszka a écrit :
> When stop device call netif_carrier_off() just after disabling TX queue to
> avoid possibility of netdev watchdog warning and ->ndo_tx_timeout() invocation.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> ---
This reminds me I saw some strange things in bnx2.c for a similar
symptom.
Commit e6bf95ffa8d6f8f4b7ee33ea01490d95b0bbeb6e
Would you take a look at this too ?
Or if this kind of trans_start refresh on all queues is really needed,
it should be a core network provided function, not implemented on every
driver...
Thanks :)
> drivers/net/bnx2x_main.c | 6 ++----
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/bnx2x_main.c b/drivers/net/bnx2x_main.c
> index 2bc35c7..57ff5b3 100644
> --- a/drivers/net/bnx2x_main.c
> +++ b/drivers/net/bnx2x_main.c
> @@ -8499,6 +8499,7 @@ static int bnx2x_nic_unload(struct bnx2x *bp, int unload_mode)
>
> /* Disable HW interrupts, NAPI and Tx */
> bnx2x_netif_stop(bp, 1);
> + netif_carrier_off(bp->dev);
>
> del_timer_sync(&bp->timer);
> SHMEM_WR(bp, func_mb[BP_FUNC(bp)].drv_pulse_mb,
> @@ -8524,8 +8525,6 @@ static int bnx2x_nic_unload(struct bnx2x *bp, int unload_mode)
>
> bp->state = BNX2X_STATE_CLOSED;
>
> - netif_carrier_off(bp->dev);
> -
> /* The last driver must disable a "close the gate" if there is no
> * parity attention or "process kill" pending.
> */
> @@ -13431,6 +13430,7 @@ static int bnx2x_eeh_nic_unload(struct bnx2x *bp)
> bp->rx_mode = BNX2X_RX_MODE_NONE;
>
> bnx2x_netif_stop(bp, 0);
> + netif_carrier_off(bp->dev);
>
> del_timer_sync(&bp->timer);
> bp->stats_state = STATS_STATE_DISABLED;
> @@ -13457,8 +13457,6 @@ static int bnx2x_eeh_nic_unload(struct bnx2x *bp)
>
> bp->state = BNX2X_STATE_CLOSED;
>
> - netif_carrier_off(bp->dev);
> -
> return 0;
> }
>
^ permalink raw reply
* Re: [PATCH RFC] vhost: fix barrier pairing
From: Juan Quintela @ 2010-05-12 9:22 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Rusty Russell, David S. Miller, Paul E. McKenney, kvm,
virtualization, netdev, linux-kernel
In-Reply-To: <20100511172633.GA9091@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> According to memory-barriers.txt, an smp memory barrier
> should always be paired with another smp memory barrier,
> and I quote "a lack of appropriate pairing is almost certainly an
> error".
>
> In case of vhost, failure to flush out used index
> update before looking at the interrupt disable flag
> could result in missed interrupts, resulting in
> networking hang under stress.
>
> This might happen when flags read bypasses used index write.
> So we see interrupts disabled and do not interrupt, at the
> same time guest writes flags value to enable interrupt,
> reads an old used index value, thinks that
> used ring is empty and waits for interrupt.
>
> Note: the barrier we pair with here is in
> drivers/virtio/virtio_ring.c, function
> vring_enable_cb.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
>
> Dave, I think this is needed in 2.6.34, I'll send a pull
> request after doing some more testing.
>
> Rusty, Juan, could you take a look as well please?
> Thanks!
I would have prefered to put it:
void vhost_add_used_and_signal(struct vhost_dev *dev,
struct vhost_virtqueue *vq,
unsigned int head, int len)
{
vhost_add_used(vq, head, len);
>>>> smp_mb();
vhost_signal(dev, vq);
}
Because it looks strange to have a barrier as the 1st instruction of a
function. And this way it is clearer (at least to me) what we are
protecting.
But on the other hand, we would have to put a comment explainingthat all
users of vhost_signal() have to put that smp_mb() so .....
Perhaps just improving the commet stating that the corresponding barrier
is there?
> Note: the barrier we pair with here is in
> drivers/virtio/virtio_ring.c, function
> vring_enable_cb.
Good catch.
Later, Juan.
^ 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