Re: Bluetooth fixes for 2.6.20-rc5
Hi Dave, > > I have one of these and I played with it. They use HID over Bluetooth as > > protocol, but all reports are vendor specific. So you need a specific > > driver to make something useful out of these events. > > It really shouldn't be hard to reverse engineer this right? > Just press a button and see what it spits out? > > Sure, the rotational events from the motion sensor et al. might take a > little time to figure out, but it should be doable. some stuff has already been done in this area. I put some information and a link to it on my page: http://www.holtmann.org/linux/bluetooth/wiimote.html The hardest part at the moment is to get the speaker on the Wiimote doing something useful and I personally wanna get to the internal flash area of the Bluetooth chip. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
What's in netdev-2.6.git
This is the stuff queued for 2.6.21 in netdev-2.6.git#upstream. Nothing earthshakingly notable. A couple new drivers, a couple removed drivers, a bunch of driver updates. Adrian Bunk (4): remove the broken SKMC driver make hdlc_setup() static again remove the broken OAKNET driver bonding.h: "extern inline" -> "static inline" Akinobu Mita (1): net: use bitrev8 Arjan van de Ven (1): remove NETIF_F_TSO ifdefery Auke Kok (3): e1000: clean up debug output defines e1000: display flow control of link status at link up e1000: update version to 7.3.20-k2 Ayaz Abdulla (12): forcedeth: dma access forcedeth: ring access forcedeth: tx locking forcedeth: rx skb recycle forcedeth: optimized routines forcedeth: tx limiting forcedeth: tx data path optimization forcedeth: rx data path optimization forcedeth: irq data path optimization forcedeth: tx max work forcedeth: statistics supported forcedeth: statistics optimization Bruce Allan (1): e1000: clear ip csum info from context descriptor Cesar Eduardo Barros (1): driver for Silan SC92031 netdev Daniel Drake (6): zd1211rw: Generic HMAC initialization zd1211rw: 2 new ZD1211B device ID's zd1211rw: Consistency for address space constants zd1211rw: Remove addressing abstraction zd1211rw: Add ID for Linksys WUSBF54G zd1211rw: Add ID for ZyXEL ZyAIR G-220 v2 Divy Le Ray (1): Add support for the latest 1G/10G Chelsio adapter, T3. Francois Romieu (7): chelsio: move return, break and continue statements on their own line chelsio: the return statement is not a function chelsio: spaces, tabs and friends chelsio: useless curly braces chelsio: useless test in cxgb2::remove_one chelsio: misc cleanups in sge chelsio: tabulate the update of the statistic counters Jay Vosburgh (4): bonding: fix device name allocation error bonding: fix error check in sysfs creation bonding: modify sysfs support to permit multiple loads bonding: update version Jeff Garzik (3): Merge branch 'upstream-fixes' into upstream Merge branch 'master-e1000' of git://lost.foo-projects.org/~ahkok/git/netdev-2.6 into upstream Merge branch 'upstream-fixes' into upstream Jesse Brandeburg (4): e1000: simplify case handling gigabit at half duplex e1000: Fix MSI only interrupt handler routine e1000: fix NAPI performance on 4-port adapters e1000: tune our dynamic itr transmit packet accounting John W. Linville (1): softmac: avoid assert in ieee80211softmac_wx_get_rate Kai Engert (1): prism54: add ethtool -i interface Larry Finger (1): bcm43xx: Interrogate hardware-enable switch and update LEDs Linas Vepstas (13): Spidernet DMA coalescing Spidernet add net_ratelimit to suppress long output Spidernet remove rxramfull tasklet Spidernet cleanup un-needed API Spidernet RX skb mem leak Spidernet another skb mem leak Spidernet Cleanup return codes Spidernet RX Refill Spidernet Remove unused variable Spidernet RX Chain tail Spidernet Memory barrier Spidernet Avoid possible RX chain corruption Spidernet RX Debugging printout Michael Buesch (1): Update Prism54 MAINTAINERS entry Ron Mercer (1): qla3xxx: Add support for Qlogic 4032 chip. Stephen Hemminger (3): sky2: better power state management chelsio: NAPI speed improvement chelsio: more rx speedup Zhu Yi (1): ipw2200: add iwconfig rts/frag auto support MAINTAINERS |2 drivers/net/Kconfig | 56 drivers/net/Makefile |5 drivers/net/Space.c |4 drivers/net/bmac.c| 20 drivers/net/bnx2.c| 12 drivers/net/bonding/bond_main.c | 23 drivers/net/bonding/bond_sysfs.c | 15 drivers/net/bonding/bonding.h |9 drivers/net/chelsio/common.h |2 drivers/net/chelsio/cpl5_cmd.h| 18 drivers/net/chelsio/cxgb2.c | 149 - drivers/net/chelsio/elmer0.h | 40 drivers/net/chelsio/espi.c| 44 drivers/net/chelsio/fpga_defs.h |6 drivers/net/chelsio/gmac.h| 11 drivers/net/chelsio/ixf1010.c | 100 drivers/net/chelsio/mv88e1xxx.c | 27 drivers/net/chelsio/my3126.c | 16 drivers/net/chelsio/pm3393.c | 91 drivers/net/chelsio/sge.c | 328 +- drivers/net/chelsio/subr.c| 89 drivers/net/chelsio/tp.c | 62 drivers/net/chelsio/vsc7326.c | 139
[git patch] net driver fix
As the patch indicates, the Al Viro patch had already been merged into
my history (and another branch depending on it, making rebasing
difficult if not impossible), but since it was merged by Linus, the
actual patch isn't shown here by 'git diff'.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/mv643xx_eth.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
Al Viro (1):
s2io bogus memset
Dale Farnsworth (1):
mv643xx_eth: Fix race condition in mv643xx_eth_free_tx_descs
diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
index c41ae42..b3bf864 100644
--- a/drivers/net/mv643xx_eth.c
+++ b/drivers/net/mv643xx_eth.c
@@ -314,6 +314,13 @@ int mv643xx_eth_free_tx_descs(struct net_device *dev, int
force)
while (mp->tx_desc_count > 0) {
spin_lock_irqsave(&mp->lock, flags);
+
+ /* tx_desc_count might have changed before acquiring the lock */
+ if (mp->tx_desc_count <= 0) {
+ spin_unlock_irqrestore(&mp->lock, flags);
+ return released;
+ }
+
tx_index = mp->tx_used_desc_q;
desc = &mp->p_tx_desc_area[tx_index];
cmd_sts = desc->cmd_sts;
@@ -332,13 +339,13 @@ int mv643xx_eth_free_tx_descs(struct net_device *dev, int
force)
if (skb)
mp->tx_skb[tx_index] = NULL;
- spin_unlock_irqrestore(&mp->lock, flags);
-
if (cmd_sts & ETH_ERROR_SUMMARY) {
printk("%s: Error in TX\n", dev->name);
mp->stats.tx_errors++;
}
+ spin_unlock_irqrestore(&mp->lock, flags);
+
if (cmd_sts & ETH_TX_FIRST_DESC)
dma_unmap_single(NULL, addr, count, DMA_TO_DEVICE);
else
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/12] forcedeth: tx max work
Ayaz Abdulla wrote: This patch adds a limit to how much tx work can be done in each iteration of tx processing. If the max limit is reached, remaining tx completions will be handled by timer interrupt. Signed-Off-By: Ayaz Abdulla <[EMAIL PROTECTED]> applied 10-12 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [IPV6] RAW: Add checksum default defines for MH.
On Wed, Jan 24, 2007 at 04:05:41PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
>
> The only reason they (not myself :-)) want to put this in is
> because the RFC says that MIP6 implementation MUST compute
> checksum by default when it passes the MH to userspace. On
> the other hand, it also states that user space application SHOULD
> set IPV6_CHECKSUM to 4.
OK if the RFC says so then it's fine by me :)
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [IPV6] RAW: Add checksum default defines for MH.
In article <[EMAIL PROTECTED]> (at Wed, 24 Jan 2007 17:56:23 +1100), Herbert Xu <[EMAIL PROTECTED]> says: > David Miller <[EMAIL PROTECTED]> wrote: > > > > Did a complete agreement occur that this patch is ok? > > My only concern is that we're putting an arbitrary list of > protocols in the generic raw.c. What's the justification > for including these protocols in particular but not others? > > Is there any reason why the application can't just use the > existing IPV6_CHECKSUM socket option to set the same fields? Yes, it can. The only reason they (not myself :-)) want to put this in is because the RFC says that MIP6 implementation MUST compute checksum by default when it passes the MH to userspace. On the other hand, it also states that user space application SHOULD set IPV6_CHECKSUM to 4. --yoshfuji - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [IPV6] RAW: Add checksum default defines for MH.
From: Herbert Xu <[EMAIL PROTECTED]> Date: Wed, 24 Jan 2007 17:56:23 +1100 > David Miller <[EMAIL PROTECTED]> wrote: > > > > Did a complete agreement occur that this patch is ok? > > My only concern is that we're putting an arbitrary list of > protocols in the generic raw.c. What's the justification > for including these protocols in particular but not others? > > Is there any reason why the application can't just use the > existing IPV6_CHECKSUM socket option to set the same fields? My understanding in the MH case is that the kernel is going to make changes to the header that the user can't predict and thus it's impossible for them to set the correct checksum. I don't know what the justification is for ICMP6 though :-) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [IPV6] RAW: Add checksum default defines for MH.
David Miller <[EMAIL PROTECTED]> wrote:
>
> Did a complete agreement occur that this patch is ok?
My only concern is that we're putting an arbitrary list of
protocols in the generic raw.c. What's the justification
for including these protocols in particular but not others?
Is there any reason why the application can't just use the
existing IPV6_CHECKSUM socket option to set the same fields?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bluetooth fixes for 2.6.20-rc5
From: Marcel Holtmann <[EMAIL PROTECTED]> Date: Wed, 24 Jan 2007 08:38:53 +0100 > I have one of these and I played with it. They use HID over Bluetooth as > protocol, but all reports are vendor specific. So you need a specific > driver to make something useful out of these events. It really shouldn't be hard to reverse engineer this right? Just press a button and see what it spits out? Sure, the rotational events from the motion sensor et al. might take a little time to figure out, but it should be doable. > However it is fun to switch on the leds and play with rumble pack or > motion sensor. Hehe :-) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bluetooth fixes for 2.6.20-rc5
Hi Dave, > BTW, do you know if anyone has successfully used the Linux > Bluetooth stack to communicate with the Nintendo Wii > controllers? I am under the impression that they speak > bluetooth. :) I have one of these and I played with it. They use HID over Bluetooth as protocol, but all reports are vendor specific. So you need a specific driver to make something useful out of these events. However it is fun to switch on the leds and play with rumble pack or motion sensor. Regards Marcel - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] [SCTP]: Verify some mandatory parameters.
From: Brian Haley <[EMAIL PROTECTED]>
Date: Wed, 17 Jan 2007 15:22:21 -0500
> > --- a/net/sctp/sm_statefuns.c
> > +++ b/net/sctp/sm_statefuns.c
> > @@ -462,24 +461,6 @@ sctp_disposition_t sctp_sf_do_5_1C_ack(const struct
> > sctp_endpoint *ep,
>
> > - if (!init_tag) {
> > - struct sctp_chunk *reply = sctp_make_abort(asoc, chunk, 0);
> > - if (!reply)
> > - goto nomem;
>
> This introduced a compiler warning, easily fixed.
>
> Signed-off-by: Brian Haley <[EMAIL PROTECTED]>
Applied, thanks a lot Brian.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why would EPIPE cause socket port to change?
From: Herbert Xu <[EMAIL PROTECTED]> Date: Wed, 24 Jan 2007 16:58:33 +1100 > On Tue, Jan 23, 2007 at 12:26:52PM -0800, Stephen Hemminger wrote: > > > > Why does write cause an autobind? One would think that on a > > SOCK_STREAM socket, the write should just fail with ENOTCONN > > The autobind is occuring in generic code, i.e., inet_sendmsg(). > It will subsequently fail because the socket is not connected. This is one of those situations where the -ENOTCONN might be preferable, but we are not helping application writers one iota because the bazillion existing kernels running out there have the old behavior so app writers have to code for it anyways. So I think we should just leave things as they are. If you read the language Richard Stevens uses when describing both the usage and implementation of getsockname and getpeername in BSD, he makes it very clear exactly what these two interfaces are intended to be used for. They are to be invoked in situations where the application has no reason to know what the socket is bound to locally or remotely, and there are two real cases: 1) determining the result of an auto-bind 2) finding the remote address/port of a socket obtained via a fork/exec I'm sure there are some other minimally different variants, but those are the two main cases. This makes it doubly clear that uses such as the one in libnss-ldap were totally unintended, and should be avoided since every single OS behaves differently in this case. :-) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why would EPIPE cause socket port to change?
On Tue, Jan 23, 2007 at 12:26:52PM -0800, Stephen Hemminger wrote:
>
> Why does write cause an autobind? One would think that on a
> SOCK_STREAM socket, the write should just fail with ENOTCONN
The autobind is occuring in generic code, i.e., inet_sendmsg().
It will subsequently fail because the socket is not connected.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [IPV6] RAW: Add checksum default defines for MH.
From: Masahide NAKAMURA <[EMAIL PROTECTED]> Date: Wed, 3 Jan 2007 18:32:22 +0900 > Add checksum default defines for mobility header(MH) which > goes through raw socket. As the result kernel's behavior is > to handle MH checksum as default. > > This patch also removes verifying inbound MH checksum at > mip6_mh_filter() since it did not consider user specified > checksum offset and was redundant check with raw socket code. > > Signed-off-by: Masahide NAKAMURA <[EMAIL PROTECTED]> Did a complete agreement occur that this patch is ok? Thank you. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [IP] TUNNEL: Fix to be built with user application.
From: Masahide NAKAMURA <[EMAIL PROTECTED]> Date: Wed, 3 Jan 2007 18:42:53 +0900 > include/linux/if_tunnel.h is broken for user application > because it was changed to use __be32 which is required > to include linux/types.h in advance but didn't. > > (This issue is found when building MIPL2 daemon. We are not sure this > is the last header to be fixed about __be32.) > > Signed-off-by: Masahide NAKAMURA <[EMAIL PROTECTED]> > Signed-off-by: TAKAMIYA Noriaki <[EMAIL PROTECTED]> Patch applied, thank you. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [IPV6] fixed the size of the netlink message notified by inet6_rt_notify().
From: Patrick McHardy <[EMAIL PROTECTED]> Date: Wed, 17 Jan 2007 13:33:22 +0100 > Thomas Graf wrote: > > * Noriaki TAKAMIYA <[EMAIL PROTECTED]> 2007-01-16 14:01 > >> > >> I think the return value of rt6_nlmsg_size() should includes the > >> amount of RTA_METRICS. > >> > >>Signed-off-by: Noriaki TAKAMIYA <[EMAIL PROTECTED]> > > > > > > Acked-by: Thomas Graf <[EMAIL PROTECTED]> > > > Somewhat related: I have this patch for 2.6.21 to get rid of the > BUG_ON()s. I think this patch is a great idea, I'll stick this into my net-2.6.21 tree when I open that up (perhaps this weekend). - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [IPV6] fixed the size of the netlink message notified by inet6_rt_notify().
From: Thomas Graf <[EMAIL PROTECTED]> Date: Wed, 17 Jan 2007 11:50:06 +0100 > * Noriaki TAKAMIYA <[EMAIL PROTECTED]> 2007-01-16 14:01 > > Hi, > > > > I'm sorry to re-send... > > > > I think the return value of rt6_nlmsg_size() should includes the > > amount of RTA_METRICS. > > > > Regards, > > > > Signed-off-by: Noriaki TAKAMIYA <[EMAIL PROTECTED]> > > Acked-by: Thomas Graf <[EMAIL PROTECTED]> Applied, thanks Noriaki. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why would EPIPE cause socket port to change?
On Tue, 23 Jan 2007, David Miller wrote: > From: dean gaudet <[EMAIL PROTECTED]> > Date: Tue, 23 Jan 2007 12:11:01 -0800 (PST) > > > libnss-ldap has some code which attempts to determine if its private > > socket has been trampled on in between calls to the library... and to do > > this it caches getsockname/getpeername results and compares them every > > time the library is re-entered... and when there's a mismatch it leaks a > > socket (eventually crashing nscd if you're using that). i've been trying > > to band-aid over the problem: > > > > http://bugzilla.padl.com/show_bug.cgi?id=304 > > http://bugzilla.padl.com/show_bug.cgi?id=305 > > > > but i'm probably going to need to approach it from another direction -- > > make libnss-ldap monitor the ldap library results so it knows when there's > > been a read/write error so that it stops doing this > > getsockname/getpeername thing after the error has occured. > > Please do not write programs in this way. getsockname/getpeername > were never meant to be used in that way, and it's hella inefficient > to keep checking the socket like that to boot. > > I really don't see you gaining anything by making this check every > time the user calls into the library. > > If the application mucks with the communications channel socket, so > what, it's his application that will go tits up. > > Is there some tricky interaction between nscd and something like > libnss-ldap that makes this tom-foolery necessary? > oh heck yeah i totally agree -- it's not my code though, i'm just debugging it. -dean - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] tcp_output: Re: rare bad TCP checksum with 2.6.19?
From: Jarek Poplawski <[EMAIL PROTECTED]> Date: Mon, 22 Jan 2007 07:52:14 +0100 > [PATCH][NET] tcp_output: rare bad TCP checksum with 2.6.19 > > The patch "Replace CHECKSUM_HW by CHECKSUM_PARTIAL/CHECKSUM_COMPLETE" > changed to unconditional copying of ip_summed field from collapsed > skb. This patch reverts this change. > > The majority of substantial work including heavy testing > and diagnosing by: Michael Tokarev <[EMAIL PROTECTED]> > Possible reasons pointed by: Herbert Xu and Patrick McHardy. > > Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]> > > Acked-by: Herbert Xu <[EMAIL PROTECTED]> Applied, thanks a lot everyone. I'll take care of submitting this to 2.6.19-stable. Thanks again. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] process include/linux/if_{addr,link}.h with unifdef
From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Sun, 21 Jan 2007 20:13:19 +0100
> After commit d3dcc077bf88806201093f86325ec656e4dbfbce,
> include/linux/if_{addr,link}.h should be processed with unifdef.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Applied, thanks Adrian.
I believe at least the 2.6.19 -stable branch will need
this too, right? Please submit to -stable as needed,
and feel free to add my sign-off:
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bluetooth fixes for 2.6.20-rc5
From: Marcel Holtmann <[EMAIL PROTECTED]> Date: Mon, 22 Jan 2007 22:42:14 +0100 > Hi Dave, > > here are two additional fixes for the Bluetooth subsystem that should go > in before the final 2.6.20 release. It was possible that the well known > PSM could be bound by anybody. That should not be possible like TCP/IP > ports below 1024 are also restricted. The other one is a simple endian > fix. Please forward them to Linus as soon as possible. Pulled, thanks Marcel. BTW, do you know if anyone has successfully used the Linux Bluetooth stack to communicate with the Nintendo Wii controllers? I am under the impression that they speak bluetooth. :) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can someone please try...
On Tue, 2007-01-23 at 10:21 +0100, Michael Buesch wrote: > On Tuesday 23 January 2007 07:14, Pavel Roskin wrote: > > I have tried the patch, and it doesn't fix the problem. It's a separate > > problem. It happens when bcm43xx_interrupt_handler() is called on a > > device that has already been removed. > > That shouldn't happen and doesn't for me. > > > It looks like > > bcm43xx_wireless_core_stop() should be called from > > bcm43xx_one_core_detach(). > > No, well... . remove_interface should have been called by the stack, no? It is not. It's called if I bring the interface down with ifconfig. If I remove live interface with "rmmod bcm43xx_d80211", bcm43xx_one_core_detach() is called first, followed by kernel panic in bcm43xx_interrupt_handler(). And that's what I see in the code. Module removal calls bcm43xx_exit(). It unregisters the ssb driver first. The ssb layer calls bcm43xx_remove(), which calls bcm43xx_one_core_detach() before doing anything with the wireless stack or with interrupts. I tried to put bcm43xx_one_core_detach() to the end of bcm43xx_remove(), but the result was the same. Still, I think the solution lies in that direction. We should stop the hardware before dismantling any data structures. -- Regards, Pavel Roskin - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] drivers/net/irda/vlsi_ir.{h,c}: remove kernel 2.4 code
From: Samuel Ortiz <[EMAIL PROTECTED]> Date: Sun, 21 Jan 2007 23:36:58 +0200 > On Thu, Jan 18, 2007 at 10:56:13PM +0100, Adrian Bunk wrote: > > This patch removes kernel 2.4 compatibility code. > Looks correct to me, thanks. > > > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > Acked-by: Samuel Ortiz <[EMAIL PROTECTED]> Applied, thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why would EPIPE cause socket port to change?
From: dean gaudet <[EMAIL PROTECTED]> Date: Tue, 23 Jan 2007 12:11:01 -0800 (PST) > libnss-ldap has some code which attempts to determine if its private > socket has been trampled on in between calls to the library... and to do > this it caches getsockname/getpeername results and compares them every > time the library is re-entered... and when there's a mismatch it leaks a > socket (eventually crashing nscd if you're using that). i've been trying > to band-aid over the problem: > > http://bugzilla.padl.com/show_bug.cgi?id=304 > http://bugzilla.padl.com/show_bug.cgi?id=305 > > but i'm probably going to need to approach it from another direction -- > make libnss-ldap monitor the ldap library results so it knows when there's > been a read/write error so that it stops doing this > getsockname/getpeername thing after the error has occured. Please do not write programs in this way. getsockname/getpeername were never meant to be used in that way, and it's hella inefficient to keep checking the socket like that to boot. I really don't see you gaining anything by making this check every time the user calls into the library. If the application mucks with the communications channel socket, so what, it's his application that will go tits up. Is there some tricky interaction between nscd and something like libnss-ldap that makes this tom-foolery necessary? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.20-rc5] IPV6: skb is unexpectedly freed.
From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> Date: Wed, 24 Jan 2007 13:37:25 +0900 (JST) > In article <[EMAIL PROTECTED]> (at Wed, 24 Jan 2007 15:31:47 +1100), Herbert > Xu <[EMAIL PROTECTED]> says: > > > Masayuki Nakagawa <[EMAIL PROTECTED]> wrote: > > > > > > I suggest to use kfree_skb() instead of __kfree_skb(). > > > > I agree. In fact please do it for all paths in that function, i.e., > > just change __kfree_skb to kfree_skb rather than adding a special case > > for this path. > > I do think so, too. So do I, but initially I want to push his basic patch in so that I can push the same exact thing into -stable to fix this bug. So if you make the subsequent change, please make it relative to the original patch. Thank you. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.20-rc5] IPV6: skb is unexpectedly freed.
In article <[EMAIL PROTECTED]> (at Wed, 24 Jan 2007 15:31:47 +1100), Herbert Xu <[EMAIL PROTECTED]> says: > Masayuki Nakagawa <[EMAIL PROTECTED]> wrote: > > > > I suggest to use kfree_skb() instead of __kfree_skb(). > > I agree. In fact please do it for all paths in that function, i.e., > just change __kfree_skb to kfree_skb rather than adding a special case > for this path. I do think so, too. --yoshfuji - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.20-rc5] IPV6: skb is unexpectedly freed.
Masayuki Nakagawa <[EMAIL PROTECTED]> wrote:
>
> I suggest to use kfree_skb() instead of __kfree_skb().
I agree. In fact please do it for all paths in that function, i.e.,
just change __kfree_skb to kfree_skb rather than adding a special case
for this path.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dscape doesn't auto associate
On Tuesday 23 January 2007 20:48, Jon Smirl wrote: > I'll try running NetworkManager in the debugger and see if I can > figure out what is failing. NetworkManager is working ok for me on > non-dscape devices. > Dan, any idea what's happening? FWIW, I'm running NetworkManager 0.6.2 (from SuSE 10.1) with wpa_supplicant 0.5.7. > zd1211 has this problem too: > Error for wireless request "Set Encode" (8B2A) : > SET failed on device wlan1 ; Invalid argument. > Shouldn't happen if it works for rt2570. Both use software encryption. -Michael Wu pgpGy8QeW2zFa.pgp Description: PGP signature
Re: dscape doesn't auto associate
On Tuesday 23 January 2007 20:48, Jon Smirl wrote: > As for running as an AP: > rt2570 will start in Master mode > zd1211 refused to set Master mode > No master mode support in zd1211 yet - I haven't had time (and the other two developers don't work on the d80211 version yet). Only client mode is currently supported. -Michael Wu pgpgKymarwK0A.pgp Description: PGP signature
[PATCH 2.6.20-rc5] IPV6: skb is unexpectedly freed.
I encountered a kernel panic with my test program, which is a very simple IPv6 client-server program. The server side sets IPV6_RECVPKTINFO on a listening socket, and the client side just sends a message to the server. Then the kernel panic occurs on the server. (If you need the test program, please let me know. I can provide it.) This problem happens because a skb is forcibly freed in tcp_rcv_state_process(). When a socket in listening state(TCP_LISTEN) receives a syn packet, then tcp_v6_conn_request() will be called from tcp_rcv_state_process(). If the tcp_v6_conn_request() successfully returns, the skb would be discarded by __kfree_skb(). However, in case of a listening socket which was already set IPV6_RECVPKTINFO, an address of the skb will be stored in treq->pktopts and a ref count of the skb will be incremented in tcp_v6_conn_request(). But, even if the skb is still in use, the skb will be freed. Then someone still using the freed skb will cause the kernel panic. I suggest to use kfree_skb() instead of __kfree_skb(). Signed-off-by: Masayuki Nakagawa <[EMAIL PROTECTED]> --- --- linux-2.6/net/ipv4/tcp_input.c.orig 2007-01-17 13:25:10.0 -0800 +++ linux-2.6/net/ipv4/tcp_input.c 2007-01-17 13:28:48.0 -0800 @@ -4420,9 +4420,11 @@ int tcp_rcv_state_process(struct sock *s * But, this leaves one open to an easy denial of * service attack, and SYN cookies can't defend * against this problem. So, we drop the data -* in the interest of security over speed. +* in the interest of security over speed unless +* it's still in use. */ - goto discard; + kfree_skb(skb); + return 0; } goto discard; - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dscape doesn't auto associate
On 1/23/07, Michael Wu <[EMAIL PROTECTED]> wrote: On Tuesday 23 January 2007 18:23, Jon Smirl wrote: > I have to manually associate the dscape stack with my AP. Is this way > the code is supposed to work? Everything works ok after the manual > association. > It's suppose to work with wpa_supplicant which sets every parameter. NetworkManager uses wpa_supplicant so configuration can be pretty easy. Speaking of wpa_supplicant I've been unable to get to main site according to wikipedia for over a week. Has this project moved elsewhere? http://hostap.epitest.fi/wpa_supplicant If you really want to manually associate, set the channel, (e)ssid, and encryption (if any) in any order, and then set the bssid (ap) last. There will be patches to allow association by just setting the SSID for backwards compatibility with configuration scripts. -Michael Wu -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dscape doesn't auto associate
On 1/23/07, Michael Wu <[EMAIL PROTECTED]> wrote: On Tuesday 23 January 2007 18:23, Jon Smirl wrote: > I have to manually associate the dscape stack with my AP. Is this way > the code is supposed to work? Everything works ok after the manual > association. > It's suppose to work with wpa_supplicant which sets every parameter. NetworkManager uses wpa_supplicant so configuration can be pretty easy. Something isn't working right with NetworkManager for me. I have both zd1211 and rt2570 devices and neither will start automatically but I can get the going manually. I'll try running NetworkManager in the debugger and see if I can figure out what is failing. NetworkManager is working ok for me on non-dscape devices. As for running as an AP: rt2570 will start in Master mode zd1211 refused to set Master mode zd1211 has this problem too: Error for wireless request "Set Encode" (8B2A) : SET failed on device wlan1 ; Invalid argument. If you really want to manually associate, set the channel, (e)ssid, and encryption (if any) in any order, and then set the bssid (ap) last. There will be patches to allow association by just setting the SSID for backwards compatibility with configuration scripts. -Michael Wu -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dscape doesn't auto associate
On Tuesday 23 January 2007 18:23, Jon Smirl wrote: > I have to manually associate the dscape stack with my AP. Is this way > the code is supposed to work? Everything works ok after the manual > association. > It's suppose to work with wpa_supplicant which sets every parameter. NetworkManager uses wpa_supplicant so configuration can be pretty easy. If you really want to manually associate, set the channel, (e)ssid, and encryption (if any) in any order, and then set the bssid (ap) last. There will be patches to allow association by just setting the SSID for backwards compatibility with configuration scripts. -Michael Wu pgpzpfom9PxaA.pgp Description: PGP signature
Re: [PACKET]: Add PACKET_AUXDATA cmsg
On Wed, Jan 10, 2007 at 01:54:35PM +1100, Herbert Xu wrote:
>
> [PACKET]: Add optional checksum computation for recvmsg
Unfortunately I missed the fact the skb->cb is already used to store
the sockaddr. This patch fixes it up.
[PACKET]: Fix skb->cb clobbering between aux and sockaddr
Both aux data and sockaddr tries to use the same buffer which
obviously doesn't work. We just happen to have 4 bytes free in
the skb->cb if you take away the maximum length of sockaddr_ll.
That's just enough to store the one piece of info from aux data
that we can't generate at recvmsg(2) time.
This is what the following patch does.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index dab117e..4c7f9d7 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -60,6 +60,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -215,7 +216,15 @@ struct packet_sock {
#endif
};
-#define PACKET_SKB_CB(__skb) ((struct tpacket_auxdata *)((__skb)->cb))
+struct packet_skb_cb {
+ unsigned int origlen;
+ union {
+ struct sockaddr_pkt pkt;
+ struct sockaddr_ll ll;
+ } sa;
+};
+
+#define PACKET_SKB_CB(__skb) ((struct packet_skb_cb *)((__skb)->cb))
#ifdef CONFIG_PACKET_MMAP
@@ -296,7 +305,7 @@ static int packet_rcv_spkt(struct sk_buff *skb, struct
net_device *dev, struct
/* drop conntrack reference */
nf_reset(skb);
- spkt = (struct sockaddr_pkt*)skb->cb;
+ spkt = &PACKET_SKB_CB(skb)->sa.pkt;
skb_push(skb, skb->data-skb->mac.raw);
@@ -471,7 +480,6 @@ static int packet_rcv(struct sk_buff *skb, struct
net_device *dev, struct packet
u8 * skb_head = skb->data;
int skb_len = skb->len;
unsigned snaplen;
- struct tpacket_auxdata *aux;
if (skb->pkt_type == PACKET_LOOPBACK)
goto drop;
@@ -519,7 +527,10 @@ static int packet_rcv(struct sk_buff *skb, struct
net_device *dev, struct packet
skb = nskb;
}
- sll = (struct sockaddr_ll*)skb->cb;
+ BUILD_BUG_ON(sizeof(*PACKET_SKB_CB(skb)) + MAX_ADDR_LEN - 8 >
+sizeof(skb->cb));
+
+ sll = &PACKET_SKB_CB(skb)->sa.ll;
sll->sll_family = AF_PACKET;
sll->sll_hatype = dev->type;
sll->sll_protocol = skb->protocol;
@@ -530,14 +541,7 @@ static int packet_rcv(struct sk_buff *skb, struct
net_device *dev, struct packet
if (dev->hard_header_parse)
sll->sll_halen = dev->hard_header_parse(skb, sll->sll_addr);
- aux = PACKET_SKB_CB(skb);
- aux->tp_status = TP_STATUS_USER;
- if (skb->ip_summed == CHECKSUM_PARTIAL)
- aux->tp_status |= TP_STATUS_CSUMNOTREADY;
- aux->tp_len = skb->len;
- aux->tp_snaplen = snaplen;
- aux->tp_mac = 0;
- aux->tp_net = skb->nh.raw - skb->data;
+ PACKET_SKB_CB(skb)->origlen = skb->len;
if (pskb_trim(skb, snaplen))
goto drop_n_acct;
@@ -1106,7 +1110,7 @@ static int packet_recvmsg(struct kiocb *iocb, struct
socket *sock,
* it in now.
*/
- sll = (struct sockaddr_ll*)skb->cb;
+ sll = &PACKET_SKB_CB(skb)->sa.ll;
if (sock->type == SOCK_PACKET)
msg->msg_namelen = sizeof(struct sockaddr_pkt);
else
@@ -1131,11 +1135,21 @@ static int packet_recvmsg(struct kiocb *iocb, struct
socket *sock,
sock_recv_timestamp(msg, sk, skb);
if (msg->msg_name)
- memcpy(msg->msg_name, skb->cb, msg->msg_namelen);
+ memcpy(msg->msg_name, &PACKET_SKB_CB(skb)->sa,
+ msg->msg_namelen);
if (pkt_sk(sk)->auxdata) {
- struct tpacket_auxdata *aux = PACKET_SKB_CB(skb);
- put_cmsg(msg, SOL_PACKET, PACKET_AUXDATA, sizeof(*aux), aux);
+ struct tpacket_auxdata aux;
+
+ aux.tp_status = TP_STATUS_USER;
+ if (skb->ip_summed == CHECKSUM_PARTIAL)
+ aux.tp_status |= TP_STATUS_CSUMNOTREADY;
+ aux.tp_len = PACKET_SKB_CB(skb)->origlen;
+ aux.tp_snaplen = skb->len;
+ aux.tp_mac = 0;
+ aux.tp_net = skb->nh.raw - skb->data;
+
+ put_cmsg(msg, SOL_PACKET, PACKET_AUXDATA, sizeof(aux), &aux);
}
/*
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dscape doesn't auto associate
On Tue, 2007-01-23 at 18:23 -0500, Jon Smirl wrote: > I have to manually associate the dscape stack with my AP. Is this way > the code is supposed to work? Everything works ok after the manual > association. Yeah, you currently need to set the channel, BSSID and finally the SSID to get it to associate. > Is there documentation for this stack? Not much really. devicescape has some on their website. > Any special utilities for it? Nope. > I'd like to get my devices operating in master mode. You don't need to associate then ;) But I can't really tell you exactly how it's done. If you figure it out, add it to wireless.sipsolutions.net (will become linuxwireless.org) somewhere -- we can rearrange the material later. johannes signature.asc Description: This is a digitally signed message part
dscape doesn't auto associate
I have to manually associate the dscape stack with my AP. Is this way the code is supposed to work? Everything works ok after the manual association. Is there documentation for this stack? Any special utilities for it? I'd like to get my devices operating in master mode. -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/12] forcedeth: tx max work
Jeff Garzik wrote: Please resend patches 11 & 12 too. Whereever I stop applying patches, in a patch series, the remaining patches are dropped. Received patches 11 & 12. Maybe my email system was just slow. If so, sorry for the noise. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bcm43xx: Fix scaling error for 'iwlist freq' information
On Tuesday 23 January 2007 23:43, Larry Finger wrote: > The bcm43xx driver returns the available frequencies to 'iwlist freq' with > the wrong scaling. > > Signed-off-by: Larry Finger <[EMAIL PROTECTED]> > --- > > John, > > This is to be applied to wireless-2.6. It could also be sent upstream to > 2.6.20, > but it is not very important. ACKed. The previous rates-fix patch is also ACKed. > Larry > --- > > Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_wx.c > === > --- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_wx.c > +++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_wx.c > @@ -286,7 +286,7 @@ static int bcm43xx_wx_get_rangeparams(st > if (j == IW_MAX_FREQUENCIES) > break; > range->freq[j].i = j + 1; > - range->freq[j].m = geo->a[i].freq;//FIXME? > + range->freq[j].m = geo->a[i].freq * 10; > range->freq[j].e = 1; > j++; > } > @@ -294,7 +294,7 @@ static int bcm43xx_wx_get_rangeparams(st > if (j == IW_MAX_FREQUENCIES) > break; > range->freq[j].i = j + 1; > - range->freq[j].m = geo->bg[i].freq;//FIXME? > + range->freq[j].m = geo->bg[i].freq * 10; > range->freq[j].e = 1; > j++; > } > > --- > > > -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/12] forcedeth: statistics optimization
This patch optimizes the data paths that can support hw counters. It
removes the sw counted statistics.
This is the last patch for the optimization set. Bumping up version of
driver.
Signed-Off-By: Ayaz Abdulla <[EMAIL PROTECTED]>
--- orig/drivers/net/forcedeth.c2007-01-21 17:38:50.0 -0500
+++ new/drivers/net/forcedeth.c 2007-01-21 17:41:49.0 -0500
@@ -111,6 +111,7 @@
* 0.57: 14 May 2006: Mac address set in probe/remove and order
corrections.
* 0.58: 30 Oct 2006: Added support for sideband management unit.
* 0.59: 30 Oct 2006: Added support for recoverable error.
+ * 0.60: 20 Jan 2007: Code optimizations for rings, rx & tx data paths,
and stats.
*
* Known bugs:
* We suspect that on some hardware no TX done interrupts are generated.
@@ -127,7 +128,7 @@
#else
#define DRIVERNAPI
#endif
-#define FORCEDETH_VERSION "0.59"
+#define FORCEDETH_VERSION "0.60"
#define DRV_NAME "forcedeth"
#include
@@ -1351,10 +1352,19 @@
{
struct fe_priv *np = netdev_priv(dev);
- /* It seems that the nic always generates interrupts and doesn't
-* accumulate errors internally. Thus the current values in np->stats
-* are already up to date.
-*/
+ /* If the nic supports hw counters then retrieve latest values */
+ if (np->driver_data & (DEV_HAS_STATISTICS_V1|DEV_HAS_STATISTICS_V2)) {
+ nv_get_hw_stats(dev);
+
+ /* copy to net_device stats */
+ np->stats.tx_bytes = np->estats.tx_bytes;
+ np->stats.tx_fifo_errors = np->estats.tx_fifo_errors;
+ np->stats.tx_carrier_errors = np->estats.tx_carrier_errors;
+ np->stats.rx_crc_errors = np->estats.rx_crc_errors;
+ np->stats.rx_over_errors = np->estats.rx_over_errors;
+ np->stats.rx_errors = np->estats.rx_errors_total;
+ np->stats.tx_errors = np->estats.tx_errors_total;
+ }
return &np->stats;
}
@@ -1944,16 +1954,8 @@
np->get_tx_ctx->dma = 0;
if (flags & NV_TX2_LASTPACKET) {
- if (flags & NV_TX2_ERROR) {
- if (flags & NV_TX2_UNDERFLOW)
- np->stats.tx_fifo_errors++;
- if (flags & NV_TX2_CARRIERLOST)
- np->stats.tx_carrier_errors++;
- np->stats.tx_errors++;
- } else {
+ if (!(flags & NV_TX2_ERROR))
np->stats.tx_packets++;
- np->stats.tx_bytes += np->get_tx_ctx->skb->len;
- }
dev_kfree_skb_any(np->get_tx_ctx->skb);
np->get_tx_ctx->skb = NULL;
}
@@ -2290,7 +2292,6 @@
if (flags & NV_RX2_ERROR4) {
len = nv_getlen(dev, skb->data, len);
if (len < 0) {
- np->stats.rx_errors++;
dev_kfree_skb(skb);
goto next_pkt;
}
@@ -2303,11 +2304,6 @@
}
/* the rest are hard errors */
else {
- if (flags & NV_RX2_CRCERR)
- np->stats.rx_crc_errors++;
- if (flags & NV_RX2_OVERFLOW)
- np->stats.rx_over_errors++;
- np->stats.rx_errors++;
dev_kfree_skb(skb);
goto next_pkt;
}
@@ -4941,7 +4937,7 @@
np->txrxctl_bits |= NVREG_TXRXCTL_RXCHECK;
dev->features |= NETIF_F_HW_CSUM | NETIF_F_SG;
dev->features |= NETIF_F_TSO;
- }
+ }
np->vlanctl_bits = 0;
if (id->driver_data & DEV_HAS_VLAN) {
[PATCH 11/12] forcedeth: statistics supported
This patch introduces hw statistics for older devices that supported it.
It breaks up the counters supported into separate versions.
Signed-Off-By: Ayaz Abdulla <[EMAIL PROTECTED]>
--- orig/drivers/net/forcedeth.c2007-01-21 17:33:59.0 -0500
+++ new/drivers/net/forcedeth.c 2007-01-21 17:38:23.0 -0500
@@ -173,9 +173,10 @@
#define DEV_HAS_MSI_X 0x0080 /* device supports MSI-X */
#define DEV_HAS_POWER_CNTRL 0x0100 /* device supports power savings */
#define DEV_HAS_PAUSEFRAME_TX 0x0200 /* device supports tx pause frames */
-#define DEV_HAS_STATISTICS 0x0400 /* device supports hw statistics */
-#define DEV_HAS_TEST_EXTENDED 0x0800 /* device supports extended diagnostic
test */
-#define DEV_HAS_MGMT_UNIT 0x1000 /* device supports management unit */
+#define DEV_HAS_STATISTICS_V1 0x0400 /* device supports hw statistics
version 1 */
+#define DEV_HAS_STATISTICS_V2 0x0800 /* device supports hw statistics
version 2 */
+#define DEV_HAS_TEST_EXTENDED 0x1000 /* device supports extended diagnostic
test */
+#define DEV_HAS_MGMT_UNIT 0x2000 /* device supports management unit */
enum {
NvRegIrqStatus = 0x000,
@@ -487,7 +488,8 @@
/* Miscelaneous hardware related defines: */
#define NV_PCI_REGSZ_VER1 0x270
-#define NV_PCI_REGSZ_VER2 0x604
+#define NV_PCI_REGSZ_VER2 0x2d4
+#define NV_PCI_REGSZ_VER3 0x604
/* various timeout delays: all in usec */
#define NV_TXRX_RESET_DELAY4
@@ -605,9 +607,6 @@
{ "tx_carrier_errors" },
{ "tx_excess_deferral" },
{ "tx_retry_error" },
- { "tx_deferral" },
- { "tx_packets" },
- { "tx_pause" },
{ "rx_frame_error" },
{ "rx_extra_byte" },
{ "rx_late_collision" },
@@ -620,11 +619,17 @@
{ "rx_unicast" },
{ "rx_multicast" },
{ "rx_broadcast" },
+ { "rx_packets" },
+ { "rx_errors_total" },
+ { "tx_errors_total" },
+
+ /* version 2 stats */
+ { "tx_deferral" },
+ { "tx_packets" },
{ "rx_bytes" },
+ { "tx_pause" },
{ "rx_pause" },
- { "rx_drop_frame" },
- { "rx_packets" },
- { "rx_errors_total" }
+ { "rx_drop_frame" }
};
struct nv_ethtool_stats {
@@ -637,9 +642,6 @@
u64 tx_carrier_errors;
u64 tx_excess_deferral;
u64 tx_retry_error;
- u64 tx_deferral;
- u64 tx_packets;
- u64 tx_pause;
u64 rx_frame_error;
u64 rx_extra_byte;
u64 rx_late_collision;
@@ -652,13 +654,22 @@
u64 rx_unicast;
u64 rx_multicast;
u64 rx_broadcast;
+ u64 rx_packets;
+ u64 rx_errors_total;
+ u64 tx_errors_total;
+
+ /* version 2 stats */
+ u64 tx_deferral;
+ u64 tx_packets;
u64 rx_bytes;
+ u64 tx_pause;
u64 rx_pause;
u64 rx_drop_frame;
- u64 rx_packets;
- u64 rx_errors_total;
};
+#define NV_DEV_STATISTICS_V2_COUNT (sizeof(struct
nv_ethtool_stats)/sizeof(u64))
+#define NV_DEV_STATISTICS_V1_COUNT (NV_DEV_STATISTICS_V2_COUNT - 6)
+
/* diagnostics */
#define NV_TEST_COUNT_BASE 3
#define NV_TEST_COUNT_EXTENDED 4
@@ -1275,6 +1286,61 @@
pci_push(base);
}
+static void nv_get_hw_stats(struct net_device *dev)
+{
+ struct fe_priv *np = netdev_priv(dev);
+ u8 __iomem *base = get_hwbase(dev);
+
+ np->estats.tx_bytes += readl(base + NvRegTxCnt);
+ np->estats.tx_zero_rexmt += readl(base + NvRegTxZeroReXmt);
+ np->estats.tx_one_rexmt += readl(base + NvRegTxOneReXmt);
+ np->estats.tx_many_rexmt += readl(base + NvRegTxManyReXmt);
+ np->estats.tx_late_collision += readl(base + NvRegTxLateCol);
+ np->estats.tx_fifo_errors += readl(base + NvRegTxUnderflow);
+ np->estats.tx_carrier_errors += readl(base + NvRegTxLossCarrier);
+ np->estats.tx_excess_deferral += readl(base + NvRegTxExcessDef);
+ np->estats.tx_retry_error += readl(base + NvRegTxRetryErr);
+ np->estats.rx_frame_error += readl(base + NvRegRxFrameErr);
+ np->estats.rx_extra_byte += readl(base + NvRegRxExtraByte);
+ np->estats.rx_late_collision += readl(base + NvRegRxLateCol);
+ np->estats.rx_runt += readl(base + NvRegRxRunt);
+ np->estats.rx_frame_too_long += readl(base + NvRegRxFrameTooLong);
+ np->estats.rx_over_errors += readl(base + NvRegRxOverflow);
+ np->estats.rx_crc_errors += readl(base + NvRegRxFCSErr);
+ np->estats.rx_frame_align_error += readl(base + NvRegRxFrameAlignErr);
+ np->estats.rx_length_error += readl(base + NvRegRxLenErr);
+ np->estats.rx_unicast += readl(base + NvRegRxUnicast);
+ np->estats.rx_multicast += readl(base + NvRegRxMulticast);
+ np->estats.rx_broadcast += readl(base + NvRegRxBroadcast);
+ np->estats.rx_packets =
+ np->estats.rx_unicast +
+ np->estats.rx_multicast +
+ np->es
Re: [PATCH 10/12] forcedeth: tx max work
Ayaz Abdulla wrote: This patch adds a limit to how much tx work can be done in each iteration of tx processing. If the max limit is reached, remaining tx completions will be handled by timer interrupt. Signed-Off-By: Ayaz Abdulla <[EMAIL PROTECTED]> Thanks, will apply soon. Please resend patches 11 & 12 too. Whereever I stop applying patches, in a patch series, the remaining patches are dropped. I either apply a patch immediately, or delete it. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] bcm43xx: Fix scaling error for 'iwlist freq' information
The bcm43xx driver returns the available frequencies to 'iwlist freq' with the wrong scaling. Signed-off-by: Larry Finger <[EMAIL PROTECTED]> --- John, This is to be applied to wireless-2.6. It could also be sent upstream to 2.6.20, but it is not very important. Larry --- Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_wx.c === --- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_wx.c +++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_wx.c @@ -286,7 +286,7 @@ static int bcm43xx_wx_get_rangeparams(st if (j == IW_MAX_FREQUENCIES) break; range->freq[j].i = j + 1; - range->freq[j].m = geo->a[i].freq;//FIXME? + range->freq[j].m = geo->a[i].freq * 10; range->freq[j].e = 1; j++; } @@ -294,7 +294,7 @@ static int bcm43xx_wx_get_rangeparams(st if (j == IW_MAX_FREQUENCIES) break; range->freq[j].i = j + 1; - range->freq[j].m = geo->bg[i].freq;//FIXME? + range->freq[j].m = geo->bg[i].freq * 10; range->freq[j].e = 1; j++; } --- - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/12] forcedeth: tx max work
This patch adds a limit to how much tx work can be done in each
iteration of tx processing. If the max limit is reached, remaining tx
completions will be handled by timer interrupt.
Signed-Off-By: Ayaz Abdulla <[EMAIL PROTECTED]>
--- orig/drivers/net/forcedeth.c2007-01-19 11:13:59.0 -0500
+++ new/drivers/net/forcedeth.c 2007-01-21 17:33:02.0 -0500
@@ -210,7 +210,7 @@
* NVREG_POLL_DEFAULT=97 would result in an interval length of 1 ms
*/
NvRegPollingInterval = 0x00c,
-#define NVREG_POLL_DEFAULT_THROUGHPUT 970
+#define NVREG_POLL_DEFAULT_THROUGHPUT 970 /* backup tx cleanup if loop max
reached */
#define NVREG_POLL_DEFAULT_CPU 13
NvRegMSIMap0 = 0x020,
NvRegMSIMap1 = 0x024,
@@ -1859,14 +1859,15 @@
}
}
-static void nv_tx_done_optimized(struct net_device *dev)
+static void nv_tx_done_optimized(struct net_device *dev, int limit)
{
struct fe_priv *np = netdev_priv(dev);
u32 flags;
struct ring_desc_ex* orig_get_tx = np->get_tx.ex;
while ((np->get_tx.ex != np->put_tx.ex) &&
- !((flags = le32_to_cpu(np->get_tx.ex->flaglen)) & NV_TX_VALID)) {
+ !((flags = le32_to_cpu(np->get_tx.ex->flaglen)) & NV_TX_VALID) &&
+ (limit-- > 0)) {
dprintk(KERN_DEBUG "%s: nv_tx_done_optimized: flags 0x%x.\n",
dev->name, flags);
@@ -1973,7 +1974,7 @@
if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2)
nv_tx_done(dev);
else
- nv_tx_done_optimized(dev);
+ nv_tx_done_optimized(dev, np->tx_ring_size);
/* 3) if there are dead entries: clear everything */
if (np->get_tx_ctx != np->put_tx_ctx) {
@@ -2899,7 +2900,7 @@
break;
spin_lock(&np->lock);
- nv_tx_done_optimized(dev);
+ nv_tx_done_optimized(dev, TX_WORK_PER_LOOP);
spin_unlock(&np->lock);
#ifdef CONFIG_FORCEDETH_NAPI
@@ -3006,7 +3007,7 @@
break;
spin_lock_irqsave(&np->lock, flags);
- nv_tx_done_optimized(dev);
+ nv_tx_done_optimized(dev, TX_WORK_PER_LOOP);
spin_unlock_irqrestore(&np->lock, flags);
if (unlikely(events & (NVREG_IRQ_TX_ERR))) {
@@ -3163,6 +3164,11 @@
if (!(events & np->irqmask))
break;
+ /* check tx in case we reached max loop limit in tx isr */
+ spin_lock_irqsave(&np->lock, flags);
+ nv_tx_done_optimized(dev, TX_WORK_PER_LOOP);
+ spin_unlock_irqrestore(&np->lock, flags);
+
if (events & NVREG_IRQ_LINK) {
spin_lock_irqsave(&np->lock, flags);
nv_link_irq(dev);
Re: [PATCH 4/4] atl1: Ancillary C files for Attansic L1 driver
Randy Dunlap wrote: Stephen Hemminger wrote: On Tue, 23 Jan 2007 16:33:29 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: Stephen Hemminger wrote: IMHO the MSI disabling should be removed from drivers and be done in the PCI core. That is the consensus opinion. Currently drivers implement the MSI tests because the core PCI code hasn't been up to snuff. I (and others) have been discouraging that, but when a user faces a choice between working and non-working network, the pragmatic solution wins. Linus's remark (IIRC) was to not enable CONFIG_PCI_MSI then. Most distros, especially cutting edge ones like Fedora, will enable CONFIG_PCI_MSI. All efforts to get us to the point where we can remove the MSI tests from drivers are strongly supported... Jeff So far, either MSI works for all devices or is broken, so it makes sense to have a "msi=off" boot option (if there isn't already) There is one, but it's spelled "pci=nomsi". Yep. Thanks for repeating this, and refreshing the collective memory. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] atl1: Ancillary C files for Attansic L1 driver
Stephen Hemminger wrote: On Tue, 23 Jan 2007 16:33:29 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: Stephen Hemminger wrote: IMHO the MSI disabling should be removed from drivers and be done in the PCI core. That is the consensus opinion. Currently drivers implement the MSI tests because the core PCI code hasn't been up to snuff. I (and others) have been discouraging that, but when a user faces a choice between working and non-working network, the pragmatic solution wins. Linus's remark (IIRC) was to not enable CONFIG_PCI_MSI then. All efforts to get us to the point where we can remove the MSI tests from drivers are strongly supported... Jeff So far, either MSI works for all devices or is broken, so it makes sense to have a "msi=off" boot option (if there isn't already) There is one, but it's spelled "pci=nomsi". -- ~Randy - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] atl1: Ancillary C files for Attansic L1 driver
On Tue, 23 Jan 2007 16:33:29 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: > Stephen Hemminger wrote: > > IMHO the MSI disabling should be removed from drivers and be done > > in the PCI core. > > That is the consensus opinion. > > Currently drivers implement the MSI tests because the core PCI code > hasn't been up to snuff. I (and others) have been discouraging that, > but when a user faces a choice between working and non-working network, > the pragmatic solution wins. > > All efforts to get us to the point where we can remove the MSI tests > from drivers are strongly supported... > > Jeff So far, either MSI works for all devices or is broken, so it makes sense to have a "msi=off" boot option (if there isn't already) -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bcm43xx: Fix scaling error for 'iwlist rate' information
On Tuesday, 23 January 2007 21:26, Larry Finger wrote: > The bcm43xx scales the rate information supplied to a WE iwlist rate call > incorrectly. > > Signed-off-by: Larry Finger <[EMAIL PROTECTED]> > --- > > John, > > This fix should be applied to wireless-2.6. As it is a bug fix, it could also > be sent > to 2.6.20; however, it has no real effect on system operations, and it > doesn't mtter. Fixes the output of 'iwlist rate' for me. Thanks, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] atl1: Ancillary C files for Attansic L1 driver
Stephen Hemminger wrote: IMHO the MSI disabling should be removed from drivers and be done in the PCI core. That is the consensus opinion. Currently drivers implement the MSI tests because the core PCI code hasn't been up to snuff. I (and others) have been discouraging that, but when a user faces a choice between working and non-working network, the pragmatic solution wins. All efforts to get us to the point where we can remove the MSI tests from drivers are strongly supported... Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] partial resend: e1000 fixes and updates
Auke Kok wrote:
Jeff Garzik wrote:
Kok, Auke wrote:
Hi,
This patch series contains exclusively fixes for e1000. Some of these
patches were
already sent in december, but didn't make it into any usptream tree
yet. Most
importantly, it addresses two issues in the recently merged msi
interrupt
handler and dynamic itr code. A performance fix and some minor
cleanups are also
added. This brings the driver up to version 7.3.20-k2.
The summary below lists all patches. Once that were previously acked
are annotated
with (*)
These patches apply against netdev-2.6 #upstream-linus commit
77aab8bf22042d1658d4adbca8b71779e7f2d0ff. Please pull:
git pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6
upstream-linus
Sigh. I /know/ I've told you this before, but let's review the
branches again. NEVER EVER use branch 'upstream-linus'. That is for
Linus only.
gah, sorry about that.
I've moved it all over to #master-e1000 which applies against
bf81b46482c0fa8ea638e409d39768ea92a6b0f0 ("Linux 2.6.20-rc4 --Linus
Torvalds").
Please pull:
git pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 master-e1000
Strike my last email.
Pulled into #upstream.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git patches] net driver fixes
Auke Kok wrote: Jeff Garzik wrote: Auke Kok wrote: Jeff Garzik wrote: Please pull from 'upstream-linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-linus Jeff, is there a reason that you didn't pull the e1000 tree from us? I send you all the information 5 days ago, WITH the changes that you requested. I did pull the tree. The fixes were far more than just obvious one-liners, so they got pulled into #upstream. Forgive me for not seeing the 'pulled' message! I still don't see them in your tree on kernel.org either. Is it just slow again? hrm, no, at the time of your message everything has been mirrored out. So, WYSIWYG. I ACK'd your latest update of the patch series, so resend the pull info and I'll pull. Sorry about that. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mv643xx_eth: Fix race condition in mv643xx_eth_free_tx_descs
Dale Farnsworth wrote: From Dale Farnsworth <[EMAIL PROTECTED]> mv643xx_eth: Fix race condition in mv643xx_eth_free_tx_descs This bug was found and isolated by Thibaut VARENE <[EMAIL PROTECTED]> and Jarek Poplawski <[EMAIL PROTECTED]>. This patch is a modification of their fixes. We acquire and release the lock for each descriptor that is freed to minimize the time the lock is held. --- drivers/net/mv643xx_eth.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] atl1: Attansic L1 ethernet driver
Jay Cliburn wrote: Perhaps a dumb question, but when can I begin submitting differential patches? Now? I'd like to incorporate some of Arjan's and Randy's comments. Submit patches starting... now! :) Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] atl1: Ancillary C files for Attansic L1 driver
Il Tue, Jan 23, 2007 at 11:25:22AM -0800, Stephen Hemminger ha scritto:
> On Mon, 22 Jan 2007 21:00:04 +0100
> Luca Tettamanti <[EMAIL PROTECTED]> wrote:
>
> > Il Sun, Jan 21, 2007 at 09:33:39PM -0600, Jay Cliburn ha scritto:
> > > Randy Dunlap wrote:
> > > >On Sun, 21 Jan 2007 15:07:37 -0600 Jay Cliburn wrote:
> > > [snip]
> > > >>+
> > > >>+int enable_msi;
> > > >>+module_param(enable_msi, int, 0444);
> > > >>+MODULE_PARM_DESC(enable_msi, "Enable PCI MSI");
> > > >
> > > >Hm, I thought that we didn't want individual drivers having MSI config
> > > >options...
> > >
> > > Luca? This one was yours IIRC. Care to chime in?
> >
> > I remember that discussion, but since there's no sistem-wide MSI
> > blacklist (or whitelist) I don't think it's safe to enable it
> > unconditionally. Judging from bug reports on lkml it's not safe to
> > assume that MSI support is sane on non-Intel chipsets.
> >
> > Luca
>
> There is MSI blacklisting see drivers/pci/quirks.c code.
> But the blacklist isn't complete enough yet.
>
> IMHO the MSI disabling should be removed from drivers and be done
> in the PCI core. But it doesn't seem to have gotten widespread
> support.
Does the INTx madness (like this one:
http://marc.theaimsgroup.com/?l=linux-kernel&m=116668921431574&w=2
) affect also PCI-E INTx emulation?
Anyway...
Unconditionally enable MSI in atl1 driver. Also remove some useless
#ifdef since pci_{en,dis}able_msi() are no-op when MSI support is not
configured in.
Signed-off-by: Luca Tettamanti <[EMAIL PROTECTED]>
---
Patch against current netdev tree.
drivers/net/atl1/atl1.h |1 -
drivers/net/atl1/atl1_main.c | 22 +++---
drivers/net/atl1/atl1_param.c | 13 -
3 files changed, 7 insertions(+), 29 deletions(-)
diff --git a/drivers/net/atl1/atl1.h b/drivers/net/atl1/atl1.h
index 1d13e8f..0b30e1c 100644
--- a/drivers/net/atl1/atl1.h
+++ b/drivers/net/atl1/atl1.h
@@ -281,7 +281,6 @@ struct atl1_adapter {
struct atl1_smb smb;
struct atl1_cmb cmb;
- int enable_msi;
u32 pci_state[16];
};
diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c
index c0b1555..68e6cd1 100644
--- a/drivers/net/atl1/atl1_main.c
+++ b/drivers/net/atl1/atl1_main.c
@@ -1793,18 +1793,12 @@ s32 atl1_up(struct atl1_adapter *adapter)
goto err_up;
}
-#ifdef CONFIG_PCI_MSI
- if (adapter->enable_msi) {
- err = pci_enable_msi(adapter->pdev);
- if (err) {
- dev_info(&adapter->pdev->dev, "Unable to enable MSI:
%d\n", err);
- adapter->enable_msi = 0;
- }
- }
-#endif
- if (!adapter->enable_msi)
+ err = pci_enable_msi(adapter->pdev);
+ if (err) {
+ dev_info(&adapter->pdev->dev, "Unable to enable MSI: %d\n",
err);
irq_flags |= IRQF_SHARED;
-
+ }
+
err = request_irq(adapter->pdev->irq, &atl1_intr, irq_flags,
netdev->name, netdev);
if (unlikely(err))
@@ -1821,6 +1815,7 @@ s32 atl1_up(struct atl1_adapter *adapter)
free_irq(adapter->pdev->irq, netdev);
err_up:
+ pci_disable_msi(adapter->pdev);
/* free rx_buffers */
atl1_clean_rx_ring(adapter);
return err;
@@ -1836,10 +1831,7 @@ void atl1_down(struct atl1_adapter *adapter)
atl1_irq_disable(adapter);
free_irq(adapter->pdev->irq, netdev);
-#ifdef CONFIG_PCI_MSI
- if (adapter->enable_msi)
- pci_disable_msi(adapter->pdev);
-#endif
+ pci_disable_msi(adapter->pdev);
atl1_reset_hw(&adapter->hw);
adapter->cmb.cmb->int_stats = 0;
diff --git a/drivers/net/atl1/atl1_param.c b/drivers/net/atl1/atl1_param.c
index 4732f43..caa2d83 100644
--- a/drivers/net/atl1/atl1_param.c
+++ b/drivers/net/atl1/atl1_param.c
@@ -68,10 +68,6 @@ static int num_flash_vendor = 0;
module_param_array_named(flash_vendor, flash_vendor, int, &num_flash_vendor,
0);
MODULE_PARM_DESC(flash_vendor, "SPI flash vendor");
-int enable_msi;
-module_param(enable_msi, int, 0444);
-MODULE_PARM_DESC(enable_msi, "Enable PCI MSI");
-
#define DEFAULT_INT_MOD_CNT100 /* 200us */
#define MAX_INT_MOD_CNT65000
#define MIN_INT_MOD_CNT50
@@ -211,13 +207,4 @@ void __devinit atl1_check_options(struct atl1_adapter
*adapter)
adapter->hw.flash_vendor = (u8) (opt.def);
}
}
-
- { /* PCI MSI usage */
-
-#ifdef CONFIG_PCI_MSI
- adapter->enable_msi = enable_msi;
-#else
- adapter->enable_msi = 0;
-#endif
- }
}
Luca
--
Inquietudine sintetica
Solo, davanti all'ignoto
Tienimi stretto a te
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
On Tue, Jan 23, 2007 at 09:18:20AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> Hello.
New patch attached, incorporating Yoshijui and Vlads latest comments. I didn't
follow guidance on the ndisc_recv_ns comment, Yoshifuji, since Vlad had already
suggested an alternate solution in a previous post, but from looking at them
both, they should be equivalent.
Thanks & Regards
Neil
Signed-off-by: Neil Horman <[EMAIL PROTECTED]>
include/linux/if_addr.h |1
include/linux/ipv6.h|2 +
include/linux/sysctl.h |1
include/net/addrconf.h |4 +-
net/ipv6/addrconf.c | 56
net/ipv6/mcast.c|4 +-
net/ipv6/ndisc.c| 82 +++-
7 files changed, 117 insertions(+), 33 deletions(-)
diff --git a/include/linux/if_addr.h b/include/linux/if_addr.h
index d557e4c..43f3bed 100644
--- a/include/linux/if_addr.h
+++ b/include/linux/if_addr.h
@@ -39,6 +39,7 @@ enum
#define IFA_F_TEMPORARYIFA_F_SECONDARY
#defineIFA_F_NODAD 0x02
+#define IFA_F_OPTIMISTIC 0x04
#defineIFA_F_HOMEADDRESS 0x10
#define IFA_F_DEPRECATED 0x20
#define IFA_F_TENTATIVE0x40
diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
index f824113..5d37abf 100644
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@ -177,6 +177,7 @@ struct ipv6_devconf {
#endif
#endif
__s32 proxy_ndp;
+ __s32 optimistic_dad;
void*sysctl;
};
@@ -205,6 +206,7 @@ enum {
DEVCONF_RTR_PROBE_INTERVAL,
DEVCONF_ACCEPT_RA_RT_INFO_MAX_PLEN,
DEVCONF_PROXY_NDP,
+ DEVCONF_OPTIMISTIC_DAD,
DEVCONF_MAX
};
diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
index 81480e6..972a33a 100644
--- a/include/linux/sysctl.h
+++ b/include/linux/sysctl.h
@@ -570,6 +570,7 @@ enum {
NET_IPV6_RTR_PROBE_INTERVAL=21,
NET_IPV6_ACCEPT_RA_RT_INFO_MAX_PLEN=22,
NET_IPV6_PROXY_NDP=23,
+ NET_IPV6_OPTIMISTIC_DAD=24,
__NET_IPV6_MAX
};
diff --git a/include/net/addrconf.h b/include/net/addrconf.h
index 88df8fc..d248a19 100644
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -73,7 +73,9 @@ extern intipv6_get_saddr(struct dst_entry
*dst,
extern int ipv6_dev_get_saddr(struct net_device *dev,
struct in6_addr *daddr,
struct in6_addr *saddr);
-extern int ipv6_get_lladdr(struct net_device *dev, struct
in6_addr *);
+extern int ipv6_get_lladdr(struct net_device *dev,
+ struct in6_addr *,
+ unsigned char banned_flags);
extern int ipv6_rcv_saddr_equal(const struct sock *sk,
const struct sock *sk2);
extern voidaddrconf_join_solict(struct net_device *dev,
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 2a7e461..d2b01ec 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -830,7 +830,8 @@ retry:
ift = !max_addresses ||
ipv6_count_addresses(idev) < max_addresses ?
ipv6_add_addr(idev, &addr, tmp_plen,
- ipv6_addr_type(&addr)&IPV6_ADDR_SCOPE_MASK,
IFA_F_TEMPORARY) : NULL;
+ ipv6_addr_type(&addr)&IPV6_ADDR_SCOPE_MASK,
+ IFA_F_TEMPORARY|IFA_F_OPTIMISTIC) : NULL;
if (!ift || IS_ERR(ift)) {
in6_ifa_put(ifp);
in6_dev_put(idev);
@@ -1174,7 +1175,8 @@ int ipv6_get_saddr(struct dst_entry *dst,
}
-int ipv6_get_lladdr(struct net_device *dev, struct in6_addr *addr)
+int ipv6_get_lladdr(struct net_device *dev, struct in6_addr *addr,
+ unsigned char banned_flags)
{
struct inet6_dev *idev;
int err = -EADDRNOTAVAIL;
@@ -1185,7 +1187,7 @@ int ipv6_get_lladdr(struct net_device *dev, struct
in6_addr *addr)
read_lock_bh(&idev->lock);
for (ifp=idev->addr_list; ifp; ifp=ifp->if_next) {
- if (ifp->scope == IFA_LINK &&
!(ifp->flags&IFA_F_TENTATIVE)) {
+ if (ifp->scope == IFA_LINK && !(ifp->flags &
banned_flags)) {
ipv6_addr_copy(addr, &ifp->addr);
err = 0;
break;
@@ -1751,6 +1753,7 @@ ok:
update_lft = create = 1;
ifp->cstamp = jiffies;
+ ifp->flags |= IFA_F_OPTIMISTIC;
addrconf_dad_start(ifp, RTF_ADDRCONF|RTF_PREFIX_RT);
}
@@ -1945,7 +1948,11 @@ static int inet6_addr_add(int ifindex, struct in6_addr
*pfx, int plen,
Re: Soft lockups with dscape on wireless-dev tree
On 1/23/07, Michael Wu <[EMAIL PROTECTED]> wrote: On Tuesday 23 January 2007 12:10, Jon Smirl wrote: > I've hit this twice. This time I unplugged my USB hub which had the > device in it. > Please try the patch I posted earlier: http://marc.theaimsgroup.com/?l=linux-netdev&m=116841004113998&w=2 This patch appears to fix the problems I was having with Dscape soft lockup. I tried all of the ways if failed previously and none of them lockup now. Also can be found here: http://kernel.org/git/?p=linux/kernel/git/jbenc/dscape.git;a=commitdiff_plain;h=e3973cb079b24875af1f196d03569ce7eb517c92;hp=f85c9f7b6a0fe662b95595c51aed92d784e93c5e -Michael Wu -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] bcm43xx: Fix scaling error for 'iwlist rate' information
The bcm43xx scales the rate information supplied to a WE iwlist rate call
incorrectly.
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
John,
This fix should be applied to wireless-2.6. As it is a bug fix, it could also
be sent
to 2.6.20; however, it has no real effect on system operations, and it doesn't
mtter.
Larry
---
Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
===
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
@@ -261,22 +261,22 @@ static int bcm43xx_wx_get_rangeparams(st
if (phy->type == BCM43xx_PHYTYPE_A ||
phy->type == BCM43xx_PHYTYPE_G) {
range->num_bitrates = 8;
- range->bitrate[i++] = IEEE80211_OFDM_RATE_6MB;
- range->bitrate[i++] = IEEE80211_OFDM_RATE_9MB;
- range->bitrate[i++] = IEEE80211_OFDM_RATE_12MB;
- range->bitrate[i++] = IEEE80211_OFDM_RATE_18MB;
- range->bitrate[i++] = IEEE80211_OFDM_RATE_24MB;
- range->bitrate[i++] = IEEE80211_OFDM_RATE_36MB;
- range->bitrate[i++] = IEEE80211_OFDM_RATE_48MB;
- range->bitrate[i++] = IEEE80211_OFDM_RATE_54MB;
+ range->bitrate[i++] = IEEE80211_OFDM_RATE_6MB * 50;
+ range->bitrate[i++] = IEEE80211_OFDM_RATE_9MB * 50;
+ range->bitrate[i++] = IEEE80211_OFDM_RATE_12MB * 50;
+ range->bitrate[i++] = IEEE80211_OFDM_RATE_18MB * 50;
+ range->bitrate[i++] = IEEE80211_OFDM_RATE_24MB * 50;
+ range->bitrate[i++] = IEEE80211_OFDM_RATE_36MB * 50;
+ range->bitrate[i++] = IEEE80211_OFDM_RATE_48MB * 50;
+ range->bitrate[i++] = IEEE80211_OFDM_RATE_54MB * 50;
}
if (phy->type == BCM43xx_PHYTYPE_B ||
phy->type == BCM43xx_PHYTYPE_G) {
range->num_bitrates += 4;
- range->bitrate[i++] = IEEE80211_CCK_RATE_1MB;
- range->bitrate[i++] = IEEE80211_CCK_RATE_2MB;
- range->bitrate[i++] = IEEE80211_CCK_RATE_5MB;
- range->bitrate[i++] = IEEE80211_CCK_RATE_11MB;
+ range->bitrate[i++] = IEEE80211_CCK_RATE_1MB * 50;
+ range->bitrate[i++] = IEEE80211_CCK_RATE_2MB * 50;
+ range->bitrate[i++] = IEEE80211_CCK_RATE_5MB * 50;
+ range->bitrate[i++] = IEEE80211_CCK_RATE_11MB * 50;
}
geo = ieee80211_get_geo(bcm->ieee);
---
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why would EPIPE cause socket port to change?
On Tue, 23 Jan 2007 16:44:10 +1100
Herbert Xu <[EMAIL PROTECTED]> wrote:
> dean gaudet <[EMAIL PROTECTED]> wrote:
> > in the test program below the getsockname result on a TCP socket changes
> > across a write which produces EPIPE... here's a fragment of the strace:
> >
> > getsockname(3, {sa_family=AF_INET, sin_port=htons(37636),
> > sin_addr=inet_addr("127.0.0.1")}, [17863593746633850896]) = 0
> > ...
> > write(3, "hi!\n", 4)= 4
> > write(3, "hi!\n", 4)= -1 EPIPE (Broken pipe)
> > --- SIGPIPE (Broken pipe) @ 0 (0) ---
> > getsockname(3, {sa_family=AF_INET, sin_port=htons(59882),
> > sin_addr=inet_addr("127.0.0.1")}, [16927060683038654480]) = 0
> >
> > why does the port# change? this is on 2.6.19.1.
>
> Prior to the last write, the socket entered the CLOSED state meaning
> that the old port is no longer allocated to it. As a result, the
> last write operates on an unconnected socket which causes a new local
> port to be allocated as an autobind. It then fails because the socket
> is still not connected.
Why does write cause an autobind? One would think that on a
SOCK_STREAM socket, the write should just fail with ENOTCONN
>
> So any attempt to run getsockname after an error on the socket is
> simply buggy.
>
> Cheers,
--
Stephen Hemminger <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why would EPIPE cause socket port to change?
On Tue, 23 Jan 2007, Rick Jones wrote: > Herbert Xu wrote: > > Prior to the last write, the socket entered the CLOSED state meaning > > that the old port is no longer allocated to it. As a result, the > > last write operates on an unconnected socket which causes a new local > > port to be allocated as an autobind. It then fails because the socket > > is still not connected. > > > > So any attempt to run getsockname after an error on the socket is > > simply buggy. > > But falls within the principle of least surprise doesn't it? Unless the > application has called close() or bind(), it does seem like a reasonable > expectation that the port assignments are not changed. i sampled a few other OSes... netbsd returns EINVAL after close freebsd returns ECONNRESET after close OSX retains the same port number solaris 10 returns port 0 actually any of those behaviours seems more appropriate than randomly assigning a new port :) but i like the ENOTCONN suggestion from Michael Tokarev the best... it matches the ENOTCONN from getpeername. > > (fwiw this is one of two reasons i've found for libnss-ldap to leak > > sockets... causing nscd to crash.) > > Of course, that seems rather odd too - why does libnss-ldap check the socket > name on a socket after an EPIPE anyway? libnss-ldap has some code which attempts to determine if its private socket has been trampled on in between calls to the library... and to do this it caches getsockname/getpeername results and compares them every time the library is re-entered... and when there's a mismatch it leaks a socket (eventually crashing nscd if you're using that). i've been trying to band-aid over the problem: http://bugzilla.padl.com/show_bug.cgi?id=304 http://bugzilla.padl.com/show_bug.cgi?id=305 but i'm probably going to need to approach it from another direction -- make libnss-ldap monitor the ldap library results so it knows when there's been a read/write error so that it stops doing this getsockname/getpeername thing after the error has occured. -dean - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2.6.20 5/5] s2io: De-typedef driver.
Hi Jeff, Thanks for the comments. We have implemented the comments and resubmitted all five patch again. Thanks, ~Siva -Original Message- From: Jeff Garzik [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 23, 2007 11:18 AM To: Ananda Raju Cc: netdev@vger.kernel.org; Leonid Grossman; Alicia Pena; Ramkrishna Vepa; Sivakumar Subramani; Sreenivasa Honnur; Sriram Rapuru Subject: Re: [PATCH 2.6.20 5/5] s2io: De-typedef driver. Ananda Raju wrote: > Removed namespace collisions due to usage of nic_t as per Ralf's patch > ([EMAIL PROTECTED]). > > Signed-off-by: Sivakumar Subramani <[EMAIL PROTECTED]> ACK Please make the following the first line of your email body: From: Ralf Baechle <[EMAIL PROTECTED]> That will tell the patch importer to properly credit Ralf as the patch's author. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.20 4/5] s2io: Removed enabling of some of the unused interrupts.
Removed unused code in en_dis_able_nic_intrs(), TX_DMA_INTR, RX_DMA_INTR,
TX_XGXS_INTR, MC_INTR
Signed-off-by: Sivakumar Subramani <[EMAIL PROTECTED]>
---
diff -urpN patch3/drivers/net/s2io.c patch4/drivers/net/s2io.c
--- patch3/drivers/net/s2io.c 2007-01-24 01:11:17.0 +0530
+++ patch4/drivers/net/s2io.c 2007-01-24 01:12:01.0 +0530
@@ -1659,7 +1659,7 @@ static void en_dis_able_nic_intrs(struct
/* PIC Interrupts */
if ((mask & (TX_PIC_INTR | RX_PIC_INTR))) {
/* Enable PIC Intrs in the general intr mask register */
- val64 = TXPIC_INT_M | PIC_RX_INT_M;
+ val64 = TXPIC_INT_M;
if (flag == ENABLE_INTRS) {
temp64 = readq(&bar0->general_int_mask);
temp64 &= ~((u64) val64);
@@ -1697,70 +1697,6 @@ static void en_dis_able_nic_intrs(struct
}
}
- /* DMA Interrupts */
- /* Enabling/Disabling Tx DMA interrupts */
- if (mask & TX_DMA_INTR) {
- /* Enable TxDMA Intrs in the general intr mask register */
- val64 = TXDMA_INT_M;
- if (flag == ENABLE_INTRS) {
- temp64 = readq(&bar0->general_int_mask);
- temp64 &= ~((u64) val64);
- writeq(temp64, &bar0->general_int_mask);
- /*
-* Keep all interrupts other than PFC interrupt
-* and PCC interrupt disabled in DMA level.
-*/
- val64 = DISABLE_ALL_INTRS & ~(TXDMA_PFC_INT_M |
- TXDMA_PCC_INT_M);
- writeq(val64, &bar0->txdma_int_mask);
- /*
-* Enable only the MISC error 1 interrupt in PFC block
-*/
- val64 = DISABLE_ALL_INTRS & (~PFC_MISC_ERR_1);
- writeq(val64, &bar0->pfc_err_mask);
- /*
-* Enable only the FB_ECC error interrupt in PCC block
-*/
- val64 = DISABLE_ALL_INTRS & (~PCC_FB_ECC_ERR);
- writeq(val64, &bar0->pcc_err_mask);
- } else if (flag == DISABLE_INTRS) {
- /*
-* Disable TxDMA Intrs in the general intr mask
-* register
-*/
- writeq(DISABLE_ALL_INTRS, &bar0->txdma_int_mask);
- writeq(DISABLE_ALL_INTRS, &bar0->pfc_err_mask);
- temp64 = readq(&bar0->general_int_mask);
- val64 |= temp64;
- writeq(val64, &bar0->general_int_mask);
- }
- }
-
- /* Enabling/Disabling Rx DMA interrupts */
- if (mask & RX_DMA_INTR) {
- /* Enable RxDMA Intrs in the general intr mask register */
- val64 = RXDMA_INT_M;
- if (flag == ENABLE_INTRS) {
- temp64 = readq(&bar0->general_int_mask);
- temp64 &= ~((u64) val64);
- writeq(temp64, &bar0->general_int_mask);
- /*
-* All RxDMA block interrupts are disabled for now
-* TODO
-*/
- writeq(DISABLE_ALL_INTRS, &bar0->rxdma_int_mask);
- } else if (flag == DISABLE_INTRS) {
- /*
-* Disable RxDMA Intrs in the general intr mask
-* register
-*/
- writeq(DISABLE_ALL_INTRS, &bar0->rxdma_int_mask);
- temp64 = readq(&bar0->general_int_mask);
- val64 |= temp64;
- writeq(val64, &bar0->general_int_mask);
- }
- }
-
/* MAC Interrupts */
/* Enabling/Disabling MAC interrupts */
if (mask & (TX_MAC_INTR | RX_MAC_INTR)) {
@@ -1787,53 +1723,6 @@ static void en_dis_able_nic_intrs(struct
}
}
- /* XGXS Interrupts */
- if (mask & (TX_XGXS_INTR | RX_XGXS_INTR)) {
- val64 = TXXGXS_INT_M | RXXGXS_INT_M;
- if (flag == ENABLE_INTRS) {
- temp64 = readq(&bar0->general_int_mask);
- temp64 &= ~((u64) val64);
- writeq(temp64, &bar0->general_int_mask);
- /*
-* All XGXS block error interrupts are disabled for now
-* TODO
-*/
- writeq(DISABLE_ALL_INTRS, &bar0->xgxs_int_mask);
- } else if (flag == DISABLE_INTRS) {
- /*
-* Disable MC Intrs in the general intr mask register
-
[PATCH 2.6.20 3/5] s2io: Fixes in updating skb->truesize and code cleanup.
1. Fix for updating skb->truesize properly.
2. Disable NAPI only if more than one ring configured in case of MSI/MSI-X
interrupts. Previously we were disabling NAPI irrespective of number of
rings when MSI/MSI-X interrupts were used.
3. Code cleanup.
Signed-off-by: Sivakumar Subramani <[EMAIL PROTECTED]>
---
diff -urpN patch2/drivers/net/s2io.c patch3/drivers/net/s2io.c
--- patch2/drivers/net/s2io.c 2007-01-23 23:56:49.0 +0530
+++ patch3/drivers/net/s2io.c 2007-01-24 01:11:17.0 +0530
@@ -459,7 +459,7 @@ static int init_shared_mem(struct s2io_n
void *tmp_v_addr, *tmp_v_addr_next;
dma_addr_t tmp_p_addr, tmp_p_addr_next;
RxD_block_t *pre_rxd_blk = NULL;
- int i, j, blk_cnt, rx_sz, tx_sz;
+ int i, j, blk_cnt;
int lst_size, lst_per_page;
struct net_device *dev = nic->dev;
unsigned long tmp;
@@ -484,7 +484,6 @@ static int init_shared_mem(struct s2io_n
}
lst_size = (sizeof(TxD_t) * config->max_txds);
- tx_sz = lst_size * size;
lst_per_page = PAGE_SIZE / lst_size;
for (i = 0; i < config->tx_fifo_num; i++) {
@@ -584,7 +583,6 @@ static int init_shared_mem(struct s2io_n
size = (size * (sizeof(RxD1_t)));
else
size = (size * (sizeof(RxD3_t)));
- rx_sz = size;
for (i = 0; i < config->rx_ring_num; i++) {
mac_control->rings[i].rx_curr_get_info.block_index = 0;
@@ -625,6 +623,8 @@ static int init_shared_mem(struct s2io_n
rx_blocks->rxds = kmalloc(sizeof(rxd_info_t)*
rxd_count[nic->rxd_mode],
GFP_KERNEL);
+ if (!rx_blocks->rxds)
+ return -ENOMEM;
for (l=0; lrxd_mode];l++) {
rx_blocks->rxds[l].virt_addr =
rx_blocks->block_virt_addr +
@@ -2260,6 +2260,7 @@ static int fill_rxd_3buf(nic_t *nic, RxD
return -ENOMEM ;
}
frag_list = skb_shinfo(skb)->frag_list;
+ skb->truesize += frag_list->truesize;
frag_list->next = NULL;
tmp = (void *)ALIGN((long)frag_list->data, ALIGN_SIZE + 1);
frag_list->data = tmp;
@@ -3184,6 +3185,8 @@ static void alarm_intr_handler(struct s2
register u64 val64 = 0, err_reg = 0;
u64 cnt;
int i;
+ if (atomic_read(&nic->card_state) == CARD_DOWN)
+ return;
nic->mac_control.stats_info->sw_stat.ring_full_cnt = 0;
/* Handling the XPAK counters update */
if(nic->mac_control.stats_info->xpak_stat.xpak_timer_count < 72000) {
@@ -6579,7 +6582,6 @@ static int rx_osm_handler(ring_info_t *r
skb_put(skb, buf1_len);
skb->len += buf2_len;
skb->data_len += buf2_len;
- skb->truesize += buf2_len;
skb_put(skb_shinfo(skb)->frag_list, buf2_len);
sp->stats.rx_bytes += buf1_len;
@@ -6801,6 +6803,8 @@ static int s2io_verify_parm(struct pci_d
"Defaulting to INTA\n");
*dev_intr_type = INTA;
}
+ if ( (rx_ring_num > 1) && (*dev_intr_type != INTA) )
+ napi = 0;
if (rx_ring_mode > 3) {
DBG_PRINT(ERR_DBG, "s2io: Requested ring mode not supported\n");
DBG_PRINT(ERR_DBG, "s2io: Defaulting to 3-buffer mode\n");
@@ -7320,7 +7324,7 @@ int __init s2io_starter(void)
* Description: This function is the cleanup routine for the driver. It
unregist * ers the driver.
*/
-static void s2io_closer(void)
+static __exit void s2io_closer(void)
{
pci_unregister_driver(&s2io_driver);
DBG_PRINT(INIT_DBG, "cleanup done\n");
@@ -7641,6 +7645,7 @@ static void lro_append_pkt(nic_t *sp, lr
lro->last_frag->next = skb;
else
skb_shinfo(first)->frag_list = skb;
+ first->truesize += skb->truesize;
lro->last_frag = skb;
sp->mac_control.stats_info->sw_stat.clubbed_frms_cnt++;
return;
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.20 2/5] S2IO: Fixes for reset and link handling.
1. Fix for reset and link handling.
2. Allow for promiscuos mode and multicast state be maintained through
ifconfig up and down.
3. Support to print adapter serial number.
Signed-off-by: Sivakumar Subramani <[EMAIL PROTECTED]>
---
diff -urpN patch1/drivers/net/s2io.c patch2/drivers/net/s2io.c
--- patch1/drivers/net/s2io.c 2007-01-23 14:51:16.0 +0530
+++ patch2/drivers/net/s2io.c 2007-01-23 23:56:49.0 +0530
@@ -1416,7 +1416,7 @@ static int init_nic(struct s2io_nic *nic
val64 = TTI_DATA2_MEM_TX_UFC_A(0x10) |
TTI_DATA2_MEM_TX_UFC_B(0x20) |
- TTI_DATA2_MEM_TX_UFC_C(0x70) | TTI_DATA2_MEM_TX_UFC_D(0x80);
+ TTI_DATA2_MEM_TX_UFC_C(0x40) | TTI_DATA2_MEM_TX_UFC_D(0x80);
writeq(val64, &bar0->tti_data2_mem);
val64 = TTI_CMD_MEM_WE | TTI_CMD_MEM_STROBE_NEW_CMD;
@@ -1612,7 +1612,8 @@ static int init_nic(struct s2io_nic *nic
* that does not start on an ADB to reduce disconnects.
*/
if (nic->device_type == XFRAME_II_DEVICE) {
- val64 = EXT_REQ_EN | MISC_LINK_STABILITY_PRD(3);
+ val64 = FAULT_BEHAVIOUR | EXT_REQ_EN |
+ MISC_LINK_STABILITY_PRD(3);
writeq(val64, &bar0->misc_control);
val64 = readq(&bar0->pic_control2);
val64 &= ~(BIT(13)|BIT(14)|BIT(15));
@@ -1879,41 +1880,36 @@ static void en_dis_able_nic_intrs(struct
}
}
-static int check_prc_pcc_state(u64 val64, int flag, int rev_id, int herc)
+/**
+ * verify_pcc_quiescent- Checks for PCC quiescent state
+ * Return: 1 If PCC is quiescence
+ * 0 If PCC is not quiescence
+ */
+static int verify_pcc_quiescent(nic_t *sp, int flag)
{
- int ret = 0;
+ int ret = 0, herc;
+ XENA_dev_config_t __iomem *bar0 = sp->bar0;
+ u64 val64 = readq(&bar0->adapter_status);
+
+ herc = (sp->device_type == XFRAME_II_DEVICE);
if (flag == FALSE) {
- if ((!herc && (rev_id >= 4)) || herc) {
- if (!(val64 & ADAPTER_STATUS_RMAC_PCC_IDLE) &&
- ((val64 & ADAPTER_STATUS_RC_PRC_QUIESCENT) ==
-ADAPTER_STATUS_RC_PRC_QUIESCENT)) {
+ if ((!herc && (get_xena_rev_id(sp->pdev) >= 4)) || herc) {
+ if (!(val64 & ADAPTER_STATUS_RMAC_PCC_IDLE))
ret = 1;
- }
- }else {
- if (!(val64 & ADAPTER_STATUS_RMAC_PCC_FOUR_IDLE) &&
- ((val64 & ADAPTER_STATUS_RC_PRC_QUIESCENT) ==
-ADAPTER_STATUS_RC_PRC_QUIESCENT)) {
+ } else {
+ if (!(val64 & ADAPTER_STATUS_RMAC_PCC_FOUR_IDLE))
ret = 1;
- }
}
} else {
- if ((!herc && (rev_id >= 4)) || herc) {
+ if ((!herc && (get_xena_rev_id(sp->pdev) >= 4)) || herc) {
if (((val64 & ADAPTER_STATUS_RMAC_PCC_IDLE) ==
-ADAPTER_STATUS_RMAC_PCC_IDLE) &&
- (!(val64 & ADAPTER_STATUS_RC_PRC_QUIESCENT) ||
-((val64 & ADAPTER_STATUS_RC_PRC_QUIESCENT) ==
- ADAPTER_STATUS_RC_PRC_QUIESCENT))) {
+ADAPTER_STATUS_RMAC_PCC_IDLE))
ret = 1;
- }
} else {
if (((val64 & ADAPTER_STATUS_RMAC_PCC_FOUR_IDLE) ==
-ADAPTER_STATUS_RMAC_PCC_FOUR_IDLE) &&
- (!(val64 & ADAPTER_STATUS_RC_PRC_QUIESCENT) ||
-((val64 & ADAPTER_STATUS_RC_PRC_QUIESCENT) ==
- ADAPTER_STATUS_RC_PRC_QUIESCENT))) {
+ADAPTER_STATUS_RMAC_PCC_FOUR_IDLE))
ret = 1;
- }
}
}
@@ -1921,9 +1917,6 @@ static int check_prc_pcc_state(u64 val64
}
/**
* verify_xena_quiescence - Checks whether the H/W is ready
- * @val64 : Value read from adapter status register.
- * @flag : indicates if the adapter enable bit was ever written once
- * before.
* Description: Returns whether the H/W is ready to go or not. Depending
* on whether adapter enable bit was written or not the comparison
* differs and the calling function passes the input argument flag to
@@ -1932,24 +1925,63 @@ static int check_prc_pcc_state(u64 val64
* 0 If Xena is not quiescence
*/
-static int verify_xena_quiescence(nic_t *sp, u64 val64, int flag)
+static int verify_xena_quiescence(nic_t *sp)
{
- int ret = 0, herc;
- u64 tmp64 = ~((u64) val64);
- int rev_id = get_xena_rev_id(sp->pdev);
+ int mode;
+ XENA_dev_config_t __iomem *bar0 = sp->bar0;
+ u64 val64 = readq(&bar0->adapter_status);
+ mode
Re: [PATCH 4/4] atl1: Ancillary C files for Attansic L1 driver
On Mon, 22 Jan 2007 21:00:04 +0100 Luca Tettamanti <[EMAIL PROTECTED]> wrote: > Il Sun, Jan 21, 2007 at 09:33:39PM -0600, Jay Cliburn ha scritto: > > Randy Dunlap wrote: > > >On Sun, 21 Jan 2007 15:07:37 -0600 Jay Cliburn wrote: > > [snip] > > > > >>+ value = ioread16(hw->hw_addr + REG_PCIE_CAP_LIST); > > >>+ return ((value & 0xFF00) == 0x6C00) ? 0 : 1; > > > > > >Are there defines or enums for these? > > >Fewer magic numbers would be nice/helpful/readable. > > [snip] > > >>+ s32 ret; > > >>+ ret = atl1_write_phy_reg(hw, 29, 0x0029); > > > > > >Fewer magic numbers? > > > > Unfortunately, we don't have a spec. This is how the vendor coded it. > > > > [snip] > > >>+ > > >>+int enable_msi; > > >>+module_param(enable_msi, int, 0444); > > >>+MODULE_PARM_DESC(enable_msi, "Enable PCI MSI"); > > > > > >Hm, I thought that we didn't want individual drivers having MSI config > > >options... > > > > Luca? This one was yours IIRC. Care to chime in? > > I remember that discussion, but since there's no sistem-wide MSI > blacklist (or whitelist) I don't think it's safe to enable it > unconditionally. Judging from bug reports on lkml it's not safe to > assume that MSI support is sane on non-Intel chipsets. > > Luca There is MSI blacklisting see drivers/pci/quirks.c code. But the blacklist isn't complete enough yet. IMHO the MSI disabling should be removed from drivers and be done in the PCI core. But it doesn't seem to have gotten widespread support. -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
Hi Neil Neil Horman wrote: > + /* > + * This is not a dad solicitation, meaning we > may > + * need to respond to it, if we are > + * an optimistic node, go ahead, otherwise > + * ignore it Nit. Can you rephrase the comment just a bit. It seems a bit of a run-on sentence... The other comment from Yoshifuji-san still apply. Thanks -vlad - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Marvell Libertas 8388 802.11b/g USB driver (v2)
On Tue, 2007-01-23 at 19:30 +0100, Johannes Berg wrote: > .11s also introduces new frame types/subtypes that probably need to be > ACKed which usually the firmware won't do since it doesn't understand > those frame types/subtypes yet. This assertion might have been premature, it's entirely possible that the firmware acks those new unicast frames anyway. Best to just inject them and try, I suppose. johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH] Marvell Libertas 8388 802.11b/g USB driver (v2)
On 1/23/07, Johannes Berg <[EMAIL PROTECTED]> wrote: On Tue, 2007-01-23 at 12:59 -0500, Dan Williams wrote: > I believe it needs to at least support 4 address frames, which usually > requires firmware changes on fullmac cards, but fully softmac cards > (atheros, broadcom) probably would not. .11s also introduces new frame types/subtypes that probably need to be ACKed which usually the firmware won't do since it doesn't understand those frame types/subtypes yet. Daniel, would the Zydas employees be interested in supplying us with a MAC that would support the development of a software based 802.11s stack? -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Soft lockups with dscape on wireless-dev tree
On Tuesday 23 January 2007 12:10, Jon Smirl wrote: > I've hit this twice. This time I unplugged my USB hub which had the > device in it. > Please try the patch I posted earlier: http://marc.theaimsgroup.com/?l=linux-netdev&m=116841004113998&w=2 Also can be found here: http://kernel.org/git/?p=linux/kernel/git/jbenc/dscape.git;a=commitdiff_plain;h=e3973cb079b24875af1f196d03569ce7eb517c92;hp=f85c9f7b6a0fe662b95595c51aed92d784e93c5e -Michael Wu pgpOMGuxIjYio.pgp Description: PGP signature
Re: [PATCH] select: fix sys_select to not leak ERESTARTNOHAND to userspace
On Tue, Jan 23, 2007 at 10:02:49AM +1100, Andi Kleen wrote: > On Tuesday 23 January 2007 00:00, Neil Horman wrote: > > As it is currently written, sys_select checks its return code to convert > > ERESTARTNOHAND to EINTR. However, the check is within an if (tvp) clause, > > and so if select is called from userspace with a NULL timeval, then it is > > possible for the ERESTARTNOHAND errno to leak into userspace, which is > > incorrect. This patch moves that check outside of the conditional, and > > prevents the errno leak. > > > Patch looks good to me. > > -Andi Thanks for the response, but there is some question as to this patchs validity. I'm waiting on a reproducer to try and veryify the problem. Neil - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
On Mon, Jan 22, 2007 at 03:25:39PM -0500, Vlad Yasevich wrote:
> Hi Neil
Yeah, I think your right. I missed the implication of testing for (!dad) at the
top of that clause. I think we could accomplish the same thing by moving my
additions to the top of the clause, but I think your logic reads more cleanly.
New patch attached
Regards
Neil
Signed-off-by: Neil Horman <[EMAIL PROTECTED]>
include/linux/if_addr.h |1
include/linux/ipv6.h|1
include/linux/sysctl.h |1
include/net/addrconf.h |4 +-
net/ipv6/addrconf.c | 55 +++-
net/ipv6/mcast.c|4 +-
net/ipv6/ndisc.c| 82 +++-
7 files changed, 115 insertions(+), 33 deletions(-)
diff --git a/include/linux/if_addr.h b/include/linux/if_addr.h
index d557e4c..43f3bed 100644
--- a/include/linux/if_addr.h
+++ b/include/linux/if_addr.h
@@ -39,6 +39,7 @@ enum
#define IFA_F_TEMPORARYIFA_F_SECONDARY
#defineIFA_F_NODAD 0x02
+#define IFA_F_OPTIMISTIC 0x04
#defineIFA_F_HOMEADDRESS 0x10
#define IFA_F_DEPRECATED 0x20
#define IFA_F_TENTATIVE0x40
diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
index f824113..1a8edc1 100644
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@ -176,6 +176,7 @@ struct ipv6_devconf {
__s32 accept_ra_rt_info_max_plen;
#endif
#endif
+ __s32 use_optimistic_dad;
__s32 proxy_ndp;
void*sysctl;
};
diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
index 81480e6..972a33a 100644
--- a/include/linux/sysctl.h
+++ b/include/linux/sysctl.h
@@ -570,6 +570,7 @@ enum {
NET_IPV6_RTR_PROBE_INTERVAL=21,
NET_IPV6_ACCEPT_RA_RT_INFO_MAX_PLEN=22,
NET_IPV6_PROXY_NDP=23,
+ NET_IPV6_OPTIMISTIC_DAD=24,
__NET_IPV6_MAX
};
diff --git a/include/net/addrconf.h b/include/net/addrconf.h
index 88df8fc..d248a19 100644
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -73,7 +73,9 @@ extern intipv6_get_saddr(struct dst_entry
*dst,
extern int ipv6_dev_get_saddr(struct net_device *dev,
struct in6_addr *daddr,
struct in6_addr *saddr);
-extern int ipv6_get_lladdr(struct net_device *dev, struct
in6_addr *);
+extern int ipv6_get_lladdr(struct net_device *dev,
+ struct in6_addr *,
+ unsigned char banned_flags);
extern int ipv6_rcv_saddr_equal(const struct sock *sk,
const struct sock *sk2);
extern voidaddrconf_join_solict(struct net_device *dev,
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 2a7e461..316d771 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -830,7 +830,8 @@ retry:
ift = !max_addresses ||
ipv6_count_addresses(idev) < max_addresses ?
ipv6_add_addr(idev, &addr, tmp_plen,
- ipv6_addr_type(&addr)&IPV6_ADDR_SCOPE_MASK,
IFA_F_TEMPORARY) : NULL;
+ ipv6_addr_type(&addr)&IPV6_ADDR_SCOPE_MASK,
+ IFA_F_TEMPORARY|IFA_F_OPTIMISTIC) : NULL;
if (!ift || IS_ERR(ift)) {
in6_ifa_put(ifp);
in6_dev_put(idev);
@@ -1174,7 +1175,8 @@ int ipv6_get_saddr(struct dst_entry *dst,
}
-int ipv6_get_lladdr(struct net_device *dev, struct in6_addr *addr)
+int ipv6_get_lladdr(struct net_device *dev, struct in6_addr *addr,
+ unsigned char banned_flags)
{
struct inet6_dev *idev;
int err = -EADDRNOTAVAIL;
@@ -1185,7 +1187,7 @@ int ipv6_get_lladdr(struct net_device *dev, struct
in6_addr *addr)
read_lock_bh(&idev->lock);
for (ifp=idev->addr_list; ifp; ifp=ifp->if_next) {
- if (ifp->scope == IFA_LINK &&
!(ifp->flags&IFA_F_TENTATIVE)) {
+ if (ifp->scope == IFA_LINK && !(ifp->flags &
banned_flags)) {
ipv6_addr_copy(addr, &ifp->addr);
err = 0;
break;
@@ -1751,6 +1753,7 @@ ok:
update_lft = create = 1;
ifp->cstamp = jiffies;
+ ifp->flags |= IFA_F_OPTIMISTIC;
addrconf_dad_start(ifp, RTF_ADDRCONF|RTF_PREFIX_RT);
}
@@ -1945,7 +1948,11 @@ static int inet6_addr_add(int ifindex, struct in6_addr
*pfx, int plen,
ifp->prefered_lft = prefered_lft;
ifp->tstamp = jiffies;
spin_unlock_bh(&ifp->lock);
-
+ /*
+* Note that se
Re: [PATCH] Marvell Libertas 8388 802.11b/g USB driver (v2)
On Tue, 2007-01-23 at 12:59 -0500, Dan Williams wrote: > I believe it needs to at least support 4 address frames, which usually > requires firmware changes on fullmac cards, but fully softmac cards > (atheros, broadcom) probably would not. .11s also introduces new frame types/subtypes that probably need to be ACKed which usually the firmware won't do since it doesn't understand those frame types/subtypes yet. johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH] Marvell Libertas 8388 802.11b/g USB driver (v2)
On 1/23/07, Dan Williams <[EMAIL PROTECTED]> wrote: On Tue, 2007-01-23 at 12:14 -0500, Jon Smirl wrote: > On 1/23/07, Johannes Berg <[EMAIL PROTECTED]> wrote: > > On Tue, 2007-01-23 at 11:18 -0500, Jon Smirl wrote: > > > > > Is the 802.11s Draft 1.0 spec publicly available yet? It is supposed > > > to be making changes at the very lowest MAC layers. It will be hard to > > > be compatible with that from user space. > > > > Good point, it's not possible to implement this without changes to the > > MAC. > > > > > The software doesn't have to be written but there should be at least > > > some design work done on how 11s should fit into the existing world > > > for both a firmware and software implementation. I'd hate to see a > > > different implementation for each vendor and another one for the > > > software stack. > > > > Then we'll first have to find those vendors interested in actually > > changing their MAC to allow .11s I guess. > > I haven't seen the 11s spec, are devices with softmac implementations > flexible enough to implement it or do they need firmware changes too? I believe it needs to at least support 4 address frames, which usually requires firmware changes on fullmac cards, but fully softmac cards (atheros, broadcom) probably would not. I am working with the zd1211b which is also softmac. I'm willing to do some work on 11s support for dscape but I need a spec. I'll probably need some help too since I haven't worked on the wireless code before. -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why would EPIPE cause socket port to change?
Herbert Xu wrote:
dean gaudet <[EMAIL PROTECTED]> wrote:
in the test program below the getsockname result on a TCP socket changes
across a write which produces EPIPE... here's a fragment of the strace:
getsockname(3, {sa_family=AF_INET, sin_port=htons(37636),
sin_addr=inet_addr("127.0.0.1")}, [17863593746633850896]) = 0
...
write(3, "hi!\n", 4)= 4
write(3, "hi!\n", 4)= -1 EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---
getsockname(3, {sa_family=AF_INET, sin_port=htons(59882),
sin_addr=inet_addr("127.0.0.1")}, [16927060683038654480]) = 0
why does the port# change? this is on 2.6.19.1.
Prior to the last write, the socket entered the CLOSED state meaning
that the old port is no longer allocated to it. As a result, the
last write operates on an unconnected socket which causes a new local
port to be allocated as an autobind. It then fails because the socket
is still not connected.
So any attempt to run getsockname after an error on the socket is
simply buggy.
But falls within the principle of least surprise doesn't it? Unless the
application has called close() or bind(), it does seem like a reasonable
expectation that the port assignments are not changed.
(fwiw this is one of two reasons i've found for libnss-ldap to leak
sockets... causing nscd to crash.)
Of course, that seems rather odd too - why does libnss-ldap check the
socket name on a socket after an EPIPE anyway?
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
bonding: bug in balance-alb mode (incorrect update-ARP-replies)
Hello,
I've discovered a bug in the bonding module of the Linux Kernel, which
appears
only in bonding-mode balance-alb.
Description:
You have to setup a box with at least two NICs, a bonding device
enslaving
those, assign at least two IPs to the bond and make some traffic from a
different machine to one of those IPs.
If you delete that IP, the box will regardlessly send ARP-replies to the
machine which communicated to that IP before removing it.
This comes from the rx_hashtbl and the receive load balancing algorithm.
The bug is very serious if bonding is used in a cluster-environment
using
two nodes which are connected to the same subnet. If an IP-bound service
has
to failover to the other node, the old node would announce its
MAC-address
for the IP which isn't owned by the node anymore. So client-traffic in
the
same net would hit the old node.
A possible workaround could be the usage of balance-tlb instead of
balance-alb.
I've made a little patch which removes every entry from the rx_hashtbl, if
the
according IP is removed from the bond. The patch was made for Linux Kernel
version 2.6.19.
---8<---
diff -ur linux-2.6.19/drivers/net/bonding/bond_alb.c
linux/drivers/net/bonding/bond_alb.c
--- linux-2.6.19/drivers/net/bonding/bond_alb.c 2006-11-29
22:57:37.0 +0100
+++ linux/drivers/net/bonding/bond_alb.c2007-01-16
17:23:53.0 +0100
@@ -1677,3 +1677,38 @@
}
}
+void bond_alb_remove_ip_from_rlb(struct bonding *bond, u32 ip) {
+ struct alb_bond_info *bond_info = &(BOND_ALB_INFO(bond));
+ u32 curr_index;
+
+ dprintk("%s: removing entries from rx_hashtbl for IP %lx\n",
bond->dev->name, ip);
+ _lock_rx_hashtbl(bond);
+
+ curr_index = bond_info->rx_hashtbl_head;
+ while (curr_index != RLB_NULL_INDEX) {
+ struct rlb_client_info *curr =
&(bond_info->rx_hashtbl[curr_index]);
+ u32 next_index = bond_info->rx_hashtbl[curr_index].next;
+ u32 prev_index = bond_info->rx_hashtbl[curr_index].prev;
+
+ if (curr->ip_src == ip) {
+ dprintk("%s: entry %u matched\n", bond->dev->name,
curr_index);
+
+ if (curr_index == bond_info->rx_hashtbl_head) {
+ bond_info->rx_hashtbl_head = next_index;
+ }
+ if (prev_index != RLB_NULL_INDEX) {
+ bond_info->rx_hashtbl[prev_index].next =
next_index;
+ }
+ if (next_index != RLB_NULL_INDEX) {
+ bond_info->rx_hashtbl[next_index].prev =
prev_index;
+ }
+
+ rlb_init_table_entry(curr);
+ }
+
+ curr_index = next_index;
+ }
+
+ _unlock_rx_hashtbl(bond);
+}
+
diff -ur linux-2.6.19/drivers/net/bonding/bond_alb.h
linux/drivers/net/bonding/bond_alb.h
--- linux-2.6.19/drivers/net/bonding/bond_alb.h 2006-11-29
22:57:37.0 +0100
+++ linux/drivers/net/bonding/bond_alb.h2007-01-16
17:23:53.0 +0100
@@ -128,5 +128,6 @@
void bond_alb_monitor(struct bonding *bond);
int bond_alb_set_mac_address(struct net_device *bond_dev, void *addr);
void bond_alb_clear_vlan(struct bonding *bond, unsigned short vlan_id);
+void bond_alb_remove_ip_from_rlb(struct bonding *bond, u32 ip);
#endif /* __BOND_ALB_H__ */
diff -ur linux-2.6.19/drivers/net/bonding/bond_main.c
linux/drivers/net/bonding/bond_main.c
--- linux-2.6.19/drivers/net/bonding/bond_main.c2006-11-29
22:57:37.0 +0100
+++ linux/drivers/net/bonding/bond_main.c 2007-01-16
17:30:49.0 +0100
@@ -3356,6 +3356,12 @@
return NOTIFY_OK;
case NETDEV_DOWN:
bond->master_ip =
bond_glean_dev_ip(bond->dev);
+
+ /* remove IP from RLB hashtable if using
balance-alb mode: */
+ if (bond->params.mode == BOND_MODE_ALB) {
+ bond_alb_remove_ip_from_rlb(bond,
ifa->ifa_local);
+ }
+
return NOTIFY_OK;
default:
return NOTIFY_DONE;
---8<---
The function bond_alb_remove_ip_from_rlb is heavily based on the function
rlb_clear_vlan.
And here's a useful patch for debugging purposes (it outputs the rx_hashtbl
in
the proc-file of the bond):
---8<---
diff -ur linux-2.6.19/drivers/net/bonding/bond_alb.c
linux/drivers/net/bonding/bond_alb.c
--- linux-2.6.19/drivers/net/bonding/bond_alb.c 2007-01-16
18:59:32.0 +0100
+++ linux/drivers/net/bonding/bond_alb.c2007-01-16
18:48:15.0 +0100
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1677,6 +1678,45 @@
}
}
+void bond_alb_info_show(stru
Re: [PATCH] Marvell Libertas 8388 802.11b/g USB driver (v2)
On Tue, 2007-01-23 at 12:14 -0500, Jon Smirl wrote: > On 1/23/07, Johannes Berg <[EMAIL PROTECTED]> wrote: > > On Tue, 2007-01-23 at 11:18 -0500, Jon Smirl wrote: > > > > > Is the 802.11s Draft 1.0 spec publicly available yet? It is supposed > > > to be making changes at the very lowest MAC layers. It will be hard to > > > be compatible with that from user space. > > > > Good point, it's not possible to implement this without changes to the > > MAC. > > > > > The software doesn't have to be written but there should be at least > > > some design work done on how 11s should fit into the existing world > > > for both a firmware and software implementation. I'd hate to see a > > > different implementation for each vendor and another one for the > > > software stack. > > > > Then we'll first have to find those vendors interested in actually > > changing their MAC to allow .11s I guess. > > I haven't seen the 11s spec, are devices with softmac implementations > flexible enough to implement it or do they need firmware changes too? I believe it needs to at least support 4 address frames, which usually requires firmware changes on fullmac cards, but fully softmac cards (atheros, broadcom) probably would not. Dan - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cfg80211: Correct conditional compile of wext-common.c.
On Sun, 2007-01-21 at 18:19 +0100, Marcus Better wrote: > wext-common.o is required if CONFIG_WIRELESS_EXT is set. Looks like > `CONFIG_NET_WIRELESS' is a typo. > > Signed-off-by: Marcus Better <[EMAIL PROTECTED]> Acked-by: Johannes Berg <[EMAIL PROTECTED]> > --- a/net/wireless/Makefile > +++ b/net/wireless/Makefile > @@ -12,5 +12,5 @@ obj-ny := > > # this needs to be compiled in... > obj-$(CONFIG_CFG80211_WEXT_COMPAT) += wext-compat.o > -obj-$(CONFIG_CFG80211_WEXT_COMPAT)$(CONFIG_NET_WIRELESS) += wext-common.o > +obj-$(CONFIG_CFG80211_WEXT_COMPAT)$(CONFIG_WIRELESS_EXT) += wext-common.o > obj-y += $(obj-yy) $(obj-yn) $(obj-ny) signature.asc Description: This is a digitally signed message part
Re: [PATCH] Marvell Libertas 8388 802.11b/g USB driver (v2)
On Tue, 2007-01-23 at 12:14 -0500, Jon Smirl wrote: > I haven't seen the 11s spec, are devices with softmac implementations > flexible enough to implement it or do they need firmware changes too? I'm pretty sure bcm43xx would need firmware changes. johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH] Marvell Libertas 8388 802.11b/g USB driver (v2)
On 1/23/07, Johannes Berg <[EMAIL PROTECTED]> wrote: On Tue, 2007-01-23 at 11:18 -0500, Jon Smirl wrote: > Is the 802.11s Draft 1.0 spec publicly available yet? It is supposed > to be making changes at the very lowest MAC layers. It will be hard to > be compatible with that from user space. Good point, it's not possible to implement this without changes to the MAC. > The software doesn't have to be written but there should be at least > some design work done on how 11s should fit into the existing world > for both a firmware and software implementation. I'd hate to see a > different implementation for each vendor and another one for the > software stack. Then we'll first have to find those vendors interested in actually changing their MAC to allow .11s I guess. I haven't seen the 11s spec, are devices with softmac implementations flexible enough to implement it or do they need firmware changes too? -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Soft lockups with dscape on wireless-dev tree
I've hit this twice. This time I unplugged my USB hub which had the device in it. Jan 23 11:47:08 jonsmirl kernel: BUG: soft lockup detected on CPU#1! Jan 23 11:47:08 jonsmirl kernel: [softlockup_tick+156/224] softlockup_tick+0x9c/0xe0 Jan 23 11:47:08 jonsmirl kernel: [update_process_times+51/128] update_process_times+0x33/0x80 Jan 23 11:47:08 jonsmirl kernel: [smp_apic_timer_interrupt+115/144] smp_apic_timer_interrupt+0x73/0x90 Jan 23 11:47:08 jonsmirl kernel: [apic_timer_interrupt+40/48] apic_timer_interrupt+0x28/0x30 Jan 23 11:47:08 jonsmirl kernel: [partition_sched_domains+11/96] partition_sched_domains+0xb/0x60 Jan 23 11:47:08 jonsmirl kernel: [] patch_cr157+0x2b/0xc0 [zd1211rw_d80211] Jan 23 11:47:08 jonsmirl kernel: [lock_timer_base+67/80] lock_timer_base+0x43/0x50 Jan 23 11:47:08 jonsmirl kernel: [try_to_del_timer_sync+19/80] try_to_del_timer_sync+0x13/0x50 Jan 23 11:47:08 jonsmirl kernel: [del_timer_sync+14/32] del_timer_sync+0xe/0x20 Jan 23 11:47:08 jonsmirl kernel: [] ieee80211_if_shutdown+0x4a/0x100 [80211] Jan 23 11:47:08 jonsmirl kernel: [] ieee80211_stop+0x78/0x100 [80211] Jan 23 11:47:08 jonsmirl kernel: [dev_close+84/112] dev_close+0x54/0x70 Jan 23 11:47:08 jonsmirl kernel: [unregister_netdevice+395/528] unregister_netdevice+0x18b/0x210 Jan 23 11:47:08 jonsmirl kernel: [] __ieee80211_if_del+0x34/0x50 [80211] Jan 23 11:47:08 jonsmirl kernel: [] ieee80211_unregister_hw+0x79/0x210 [80211] Jan 23 11:47:08 jonsmirl kernel: [] disconnect+0x55/0xc0 [zd1211rw_d80211] Jan 23 11:47:08 jonsmirl kernel: [] usb_unbind_interface+0x38/0x80 [usbcore] Jan 23 11:47:08 jonsmirl kernel: [__device_release_driver+100/144] __device_release_driver+0x64/0x90 Jan 23 11:47:08 jonsmirl kernel: [device_release_driver+35/64] device_release_driver+0x23/0x40 Jan 23 11:47:08 jonsmirl kernel: [bus_remove_device+92/144] bus_remove_device+0x5c/0x90 Jan 23 11:47:08 jonsmirl kernel: [device_del+338/432] device_del+0x152/0x1b0 Jan 23 11:47:08 jonsmirl kernel: [] usb_disable_device+0x7e/0xe0 [usbcore] Jan 23 11:47:08 jonsmirl kernel: [] usb_disconnect+0x97/0x110 [usbcore] Jan 23 11:47:08 jonsmirl kernel: [] usb_disconnect+0x83/0x110 [usbcore] Jan 23 11:47:08 jonsmirl kernel: [] hub_thread+0x1ee/0xb70 [usbcore] Jan 23 11:47:08 jonsmirl kernel: [autoremove_wake_function+0/80] autoremove_wake_function+0x0/0x50 Jan 23 11:47:08 jonsmirl kernel: [] hub_thread+0x0/0xb70 [usbcore] Jan 23 11:47:08 jonsmirl kernel: [kthread+186/240] kthread+0xba/0xf0 Jan 23 11:47:08 jonsmirl kernel: [kthread+0/240] kthread+0x0/0xf0 Jan 23 11:47:08 jonsmirl kernel: [kernel_thread_helper+7/28] kernel_thread_helper+0x7/0x1c Jan 23 11:47:08 jonsmirl kernel: === This one on rmmod of the rt2500 dscape driver Jan 23 12:02:20 jonsmirl kernel: BUG: soft lockup detected on CPU#0! Jan 23 12:02:20 jonsmirl kernel: [softlockup_tick+156/224] softlockup_tick+0x9c/0xe0 Jan 23 12:02:20 jonsmirl kernel: [update_process_times+51/128] update_process_times+0x33/0x80 Jan 23 12:02:20 jonsmirl kernel: [smp_apic_timer_interrupt+115/144] smp_apic_timer_interrupt+0x73/0x90 Jan 23 12:02:20 jonsmirl kernel: [apic_timer_interrupt+40/48] apic_timer_interrupt+0x28/0x30 Jan 23 12:02:20 jonsmirl kernel: [lock_timer_base+67/80] lock_timer_base+0x43/0x50 Jan 23 12:02:20 jonsmirl kernel: [try_to_del_timer_sync+19/80] try_to_del_timer_sync+0x13/0x50 Jan 23 12:02:20 jonsmirl kernel: [del_timer_sync+14/32] del_timer_sync+0xe/0x20 Jan 23 12:02:20 jonsmirl kernel: [] ieee80211_if_shutdown+0x4a/0x100 [80211] Jan 23 12:02:20 jonsmirl kernel: [] rt2500usb_remove_interface+0xad/0xe0 [rt2500usb] Jan 23 12:02:20 jonsmirl kernel: [] ieee80211_stop+0x78/0x100 [80211] Jan 23 12:02:20 jonsmirl kernel: [dev_close+84/112] dev_close+0x54/0x70 Jan 23 12:02:20 jonsmirl kernel: [unregister_netdevice+395/528] unregister_netdevice+0x18b/0x210 Jan 23 12:02:20 jonsmirl kernel: [] __ieee80211_if_del+0x34/0x50 [80211] Jan 23 12:02:20 jonsmirl kernel: [] ieee80211_unregister_hw+0x79/0x210 [80211] Jan 23 12:02:20 jonsmirl kernel: [] rt2500usb_disconnect+0x41/0x70 [rt2500usb] Jan 23 12:02:20 jonsmirl kernel: [] usb_unbind_interface+0x38/0x80 [usbcore] Jan 23 12:02:20 jonsmirl kernel: [__device_release_driver+100/144] __device_release_driver+0x64/0x90 Jan 23 12:02:20 jonsmirl kernel: [driver_detach+195/208] driver_detach+0xc3/0xd0 Jan 23 12:02:20 jonsmirl kernel: [bus_remove_driver+103/144] bus_remove_driver+0x67/0x90 Jan 23 12:02:20 jonsmirl kernel: [driver_unregister+8/32] driver_unregister+0x8/0x20 Jan 23 12:02:20 jonsmirl kernel: [] usb_deregister+0x96/0xb0 [usbcore] Jan 23 12:02:20 jonsmirl kernel: [sys_delete_module+298/400] sys_delete_module+0x12a/0x190 Jan 23 12:02:20 jonsmirl kernel: [zeromap_page_range+354/400] zeromap_page_range+0x162/0x190 Jan 23 12:02:20 jonsmirl kernel: [do_munmap+390/480] do_munmap+0x186/0x1e0 Jan 23 12:02:20 jonsmirl kernel: [sysenter_past_esp+95/133] sysenter_past_esp+0x5f/0x85 Jan 23 12:02:20 jonsmirl kernel:
Re: [PATCH] mv643xx_eth: Fix race condition in mv643xx_eth_free_tx_descs
On 1/23/07, Dale Farnsworth <[EMAIL PROTECTED]> wrote:
From Dale Farnsworth <[EMAIL PROTECTED]>
mv643xx_eth: Fix race condition in mv643xx_eth_free_tx_descs
This bug was found and isolated by Thibaut VARENE <[EMAIL PROTECTED]>
and Jarek Poplawski <[EMAIL PROTECTED]>. This patch is a modification of their
fixes. We acquire and release the lock for each descriptor that is freed
to minimize the time the lock is held.
---
drivers/net/mv643xx_eth.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
index c41ae42..b3bf864 100644
--- a/drivers/net/mv643xx_eth.c
+++ b/drivers/net/mv643xx_eth.c
@@ -332,13 +339,13 @@ int mv643xx_eth_free_tx_descs(struct net
if (skb)
mp->tx_skb[tx_index] = NULL;
- spin_unlock_irqrestore(&mp->lock, flags);
-
if (cmd_sts & ETH_ERROR_SUMMARY) {
printk("%s: Error in TX\n", dev->name);
mp->stats.tx_errors++;
}
Note that this printk probably won't show immediately because IRQs are
disabled. But that's maybe not a big deal.
HTH
--
Thibaut VARENE
http://www.parisc-linux.org/~varenet/
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Marvell Libertas 8388 802.11b/g USB driver (v2)
On Tue, 2007-01-23 at 11:18 -0500, Jon Smirl wrote: > Is the 802.11s Draft 1.0 spec publicly available yet? It is supposed > to be making changes at the very lowest MAC layers. It will be hard to > be compatible with that from user space. Good point, it's not possible to implement this without changes to the MAC. > The software doesn't have to be written but there should be at least > some design work done on how 11s should fit into the existing world > for both a firmware and software implementation. I'd hate to see a > different implementation for each vendor and another one for the > software stack. Then we'll first have to find those vendors interested in actually changing their MAC to allow .11s I guess. johannes signature.asc Description: This is a digitally signed message part
[PATCH] mv643xx_eth: Fix race condition in mv643xx_eth_free_tx_descs
>From Dale Farnsworth <[EMAIL PROTECTED]>
mv643xx_eth: Fix race condition in mv643xx_eth_free_tx_descs
This bug was found and isolated by Thibaut VARENE <[EMAIL PROTECTED]>
and Jarek Poplawski <[EMAIL PROTECTED]>. This patch is a modification of their
fixes. We acquire and release the lock for each descriptor that is freed
to minimize the time the lock is held.
---
drivers/net/mv643xx_eth.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
index c41ae42..b3bf864 100644
--- a/drivers/net/mv643xx_eth.c
+++ b/drivers/net/mv643xx_eth.c
@@ -314,6 +314,13 @@ int mv643xx_eth_free_tx_descs(struct net
while (mp->tx_desc_count > 0) {
spin_lock_irqsave(&mp->lock, flags);
+
+ /* tx_desc_count might have changed before acquiring the lock */
+ if (mp->tx_desc_count <= 0) {
+ spin_unlock_irqrestore(&mp->lock, flags);
+ return released;
+ }
+
tx_index = mp->tx_used_desc_q;
desc = &mp->p_tx_desc_area[tx_index];
cmd_sts = desc->cmd_sts;
@@ -332,13 +339,13 @@ int mv643xx_eth_free_tx_descs(struct net
if (skb)
mp->tx_skb[tx_index] = NULL;
- spin_unlock_irqrestore(&mp->lock, flags);
-
if (cmd_sts & ETH_ERROR_SUMMARY) {
printk("%s: Error in TX\n", dev->name);
mp->stats.tx_errors++;
}
+ spin_unlock_irqrestore(&mp->lock, flags);
+
if (cmd_sts & ETH_TX_FIRST_DESC)
dma_unmap_single(NULL, addr, count, DMA_TO_DEVICE);
else
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH resend] bcm43xx-d80211: Fix DMA TX skb doublefree
This fixes a possible double-free of the TX skb buffers.
Always NULL the pointer after freeing.
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
--
I already sent this patch to you on 21 Dec 2006.
This is a pretty critical patch, so I'd like to make sure
it's in your merge queue and is not lost.
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
===
--- wireless-dev.orig/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
2006-12-07 17:25:19.0 +0100
+++ wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
2006-12-21 19:05:28.0 +0100
@@ -388,6 +388,7 @@ void free_descriptor_buffer(struct bcm43
dev_kfree_skb_irq(meta->skb);
else
dev_kfree_skb(meta->skb);
+ meta->skb = NULL;
}
}
@@ -1131,6 +1132,7 @@ void bcm43xx_dma_handle_txstatus(struct
meta->txstat.retry_count = status->frame_count - 1;
ieee80211_tx_status_irqsafe(bcm->ieee, meta->skb,
&(meta->txstat));
/* skb is freed by ieee80211_tx_status_irqsafe() */
+ meta->skb = NULL;
} else {
/* No need to call free_descriptor_buffer here, as
* this is only the txhdr, which is not allocated.
--
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] atl1: Attansic L1 ethernet driver
Jeff Garzik wrote: OK, I have merged the monolithic patch into jgarzik/netdev-2.6.git#atl1. Once I'm done merging patches tonight, I will merge this new 'atl1' branch into the 'ALL' meta-branch, which will auto-propagate this driver into Andrew Morton's -mm for testing. For future driver updates, please send a patch rather than the full driver diff. Perhaps a dumb question, but when can I begin submitting differential patches? Now? I'd like to incorporate some of Arjan's and Randy's comments. Thank you very much for accepting the driver. Jay - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH review] b44: Port to ssb subsystem
This patch ports b44 to the new SSB subsystem and makes
it possible to turn off PCI related stuff.
This patch is against my tree, where I have implemented the
ssb subsystem.
If you're all OK with this patch, I'd like apply it to my tree.
I think that's best. Although it's not wireless-related, it's
much easier to maintain this way.
This patch is tested on a b4401b0
This patch also makes it possible to run the driver on b47xx devices.
Index: bu3sch-wireless-dev/drivers/net/b44.c
===
--- bu3sch-wireless-dev.orig/drivers/net/b44.c 2007-01-23 17:10:05.0
+0100
+++ bu3sch-wireless-dev/drivers/net/b44.c 2007-01-23 17:15:05.0
+0100
@@ -1,7 +1,10 @@
-/* b44.c: Broadcom 4400 device driver.
+/* b44.c: Broadcom 44xx/47xx device driver.
*
* Copyright (C) 2002 David S. Miller (davem@redhat.com)
- * Fixed by Pekka Pietikainen ([EMAIL PROTECTED])
+ * Copyright (C) 2004 Pekka Pietikainen ([EMAIL PROTECTED])
+ * Copyright (C) 2004 Florian Schirmer ([EMAIL PROTECTED])
+ * Copyright (C) 2006 Felix Fietkau ([EMAIL PROTECTED])
+ * Copyright (C) 2007 Michael Buesch <[EMAIL PROTECTED]>
* Copyright (C) 2006 Broadcom Corporation.
*
* Distribute under GPL.
@@ -20,11 +23,13 @@
#include
#include
#include
+#include
#include
#include
#include
+
#include "b44.h"
#define DRV_MODULE_NAME"b44"
@@ -87,8 +92,8 @@
static char version[] __devinitdata =
DRV_MODULE_NAME ".c:v" DRV_MODULE_VERSION " (" DRV_MODULE_RELDATE ")\n";
-MODULE_AUTHOR("Florian Schirmer, Pekka Pietikainen, David S. Miller");
-MODULE_DESCRIPTION("Broadcom 4400 10/100 PCI ethernet driver");
+MODULE_AUTHOR("Felix Fietkau, Florian Schirmer, Pekka Pietikainen, David S.
Miller");
+MODULE_DESCRIPTION("Broadcom 44xx/47xx 10/100 PCI ethernet driver");
MODULE_LICENSE("GPL");
MODULE_VERSION(DRV_MODULE_VERSION);
@@ -96,17 +101,22 @@
module_param(b44_debug, int, 0);
MODULE_PARM_DESC(b44_debug, "B44 bitmapped debugging message enable value");
-static struct pci_device_id b44_pci_tbl[] = {
- { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_BCM4401,
- PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
- { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_BCM4401B0,
- PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
- { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_BCM4401B1,
- PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
- { } /* terminate list with empty entry */
-};
+#ifdef CONFIG_B44_PCI
+static const struct pci_device_id b44_pci_tbl[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_BCM4401) },
+ { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_BCM4401B0) },
+ { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_BCM4401B1) },
+ { 0 } /* terminate list with empty entry */
+};
MODULE_DEVICE_TABLE(pci, b44_pci_tbl);
+#endif /* CONFIG_B44_PCI */
+
+static const struct ssb_device_id b44_ssb_tbl[] = {
+ SSB_DEVICE(SSB_VENDOR_BROADCOM, SSB_DEV_ETHERNET, SSB_ANY_REV),
+ SSB_DEVTABLE_END
+};
+MODULE_DEVICE_TABLE(ssb, b44_ssb_tbl);
static void b44_halt(struct b44 *);
static void b44_init_rings(struct b44 *);
@@ -114,6 +124,7 @@
static int dma_desc_align_mask;
static int dma_desc_sync_size;
+static int instance;
static const char b44_gstrings[][ETH_GSTRING_LEN] = {
#define _B44(x...) # x,
@@ -121,35 +132,35 @@
#undef _B44
};
-static inline void b44_sync_dma_desc_for_device(struct pci_dev *pdev,
-dma_addr_t dma_base,
-unsigned long offset,
-enum dma_data_direction dir)
-{
- dma_sync_single_range_for_device(&pdev->dev, dma_base,
-offset & dma_desc_align_mask,
-dma_desc_sync_size, dir);
-}
-
-static inline void b44_sync_dma_desc_for_cpu(struct pci_dev *pdev,
- dma_addr_t dma_base,
- unsigned long offset,
- enum dma_data_direction dir)
-{
- dma_sync_single_range_for_cpu(&pdev->dev, dma_base,
- offset & dma_desc_align_mask,
- dma_desc_sync_size, dir);
+static inline void b44_sync_dma_desc_for_device(struct ssb_device *sdev,
+ dma_addr_t dma_base,
+ unsigned long offset,
+ enum dma_data_direction dir)
+{
+ dma_sync_single_range_for_device(&sdev->dev, dma_base,
+offset & dma_desc_align_mask,
+dma_desc_sync_size, dir);
+}
+
+static inline void b44_sync_dma_desc_for_cpu(struct ssb_device *sdev,
+dm
Re: [PATCH] Marvell Libertas 8388 802.11b/g USB driver (v2)
On 1/23/07, Johannes Berg <[EMAIL PROTECTED]> wrote: On Mon, 2007-01-22 at 10:20 -0500, Jon Smirl wrote: > What is the general solution for 802.11s? None yet. > I'm working on an embedded > design that would benefit from 11s support and I'd rather not have to > roll my own mesh implementation in user space. Well, there is no mesh implementation that I'm aware of, you'll want to stick it along with the userspace MLME into wpa_supplicant. Is the 802.11s Draft 1.0 spec publicly available yet? It is supposed to be making changes at the very lowest MAC layers. It will be hard to be compatible with that from user space. > I'd also like to get an > idea of what kind of hardware I need to design onto my board given > that the 8388 is not available general consumption. My system has > plenty of power and CPU available so a softmac type 11s solution is > the most cost effective. It seems to me that the design of a software > based 11s stack should be coordinated with the 8388 firmware one. It should, but afaik no one is really working on it either way. The software doesn't have to be written but there should be at least some design work done on how 11s should fit into the existing world for both a firmware and software implementation. I'd hate to see a different implementation for each vendor and another one for the software stack. -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
2.6.19.2 sky2/acpi crashes
Hi, I'm running a macbook with a Marvell ethernet controller, and I have a lots of freezes when using the ethernet controller under a load of ~100K/s. Since I'm running a 2.6.19.2 kernel, I'm able to get some report from the kernel. Here they are : Jan 23 09:30:57 cocoduo kernel: [ 662.92] NETDEV WATCHDOG: eth0: transmit timed out Jan 23 09:30:57 cocoduo kernel: [ 662.92] sky2 eth0: tx timeout Jan 23 09:30:57 cocoduo kernel: [ 662.92] sky2 eth0: transmit ring 493 .. 471 report=494 done=494 Jan 23 09:30:57 cocoduo kernel: [ 662.92] sky2 status report lost? Jan 23 09:31:06 cocoduo kernel: [ 672.832000] BUG: soft lockup detected on CPU#0! Jan 23 09:31:06 cocoduo kernel: [ 672.832000] [softlockup_tick+155/208] softlockup_tick+0x9b/0xd0 Jan 23 09:31:06 cocoduo kernel: [ 672.832000] [update_process_times+49/128] update_process_times+0x31/0x80 Jan 23 09:31:06 cocoduo kernel: [ 672.832000] [smp_apic_timer_interrupt+145/176] smp_apic_timer_interrupt+0x91/0xb0 Jan 23 09:31:06 cocoduo kernel: [ 672.832000] [apic_timer_interrupt+31/36] apic_timer_interrupt+0x1f/0x24 Jan 23 09:31:06 cocoduo kernel: [ 672.832000] [_spin_lock_bh+18/32] _spin_lock_bh+0x12/0x20 Jan 23 09:31:06 cocoduo kernel: [ 672.832000] [pg0+946878101/1068803072] sky2_tx_timeout+0xf5/0x1d0 [sky2] Jan 23 09:31:06 cocoduo kernel: [ 672.832000] [dev_watchdog+0/208] dev_watchdog+0x0/0xd0 Jan 23 09:31:06 cocoduo kernel: [ 672.832000] [dev_watchdog+192/208] dev_watchdog+0xc0/0xd0 Jan 23 09:31:06 cocoduo kernel: [ 672.832000] [run_timer_softirq+273/400] run_timer_softirq+0x111/0x190 Jan 23 09:31:06 cocoduo kernel: [ 672.832000] [__do_softirq+116/240] __do_softirq+0x74/0xf0 Jan 23 09:31:06 cocoduo kernel: [ 672.832000] [do_softirq+59/80] do_softirq+0x3b/0x50 Jan 23 09:31:06 cocoduo kernel: [ 672.832000] [smp_apic_timer_interrupt+150/176] smp_apic_timer_interrupt+0x96/0xb0 Jan 23 09:31:06 cocoduo kernel: [ 672.832000] [apic_timer_interrupt+31/36] apic_timer_interrupt+0x1f/0x24 Jan 23 09:31:06 cocoduo kernel: [ 672.832000] [pg0+943208348/1068803072] acpi_processor_idle+0x1fd/0x3b9 [processor] Jan 23 09:31:06 cocoduo kernel: [ 672.832000] [cpu_idle+116/208] cpu_idle+0x74/0xd0 Jan 23 09:31:06 cocoduo kernel: [ 672.832000] [start_kernel+872/1072] start_kernel+0x368/0x430 Jan 23 09:31:06 cocoduo kernel: [ 672.832000] [unknown_bootoption+0/624] unknown_bootoption+0x0/0x270 Jan 23 09:31:06 cocoduo kernel: [ 672.832000] === As most of the time, the keyboard gets locked and the network driver is down, I can get more informations. Here my hardware configuration : Apple Macbook 2GHz (x86, not amd64) 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile945GM/GMS/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03) 00:07.0 Performance counters: Intel Corporation Unknown device 27a3 (rev 03) 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 02) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 02) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02) 00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller IDE (rev 02) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02) 01:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 22) 02:00.0 Ethernet controller: Atheros Communications, Inc. Unknown device 001c (rev 01) 03:03.0 FireWire (IEEE 1394): Agere Systems FW323 (rev 61) I hope some fix could be released soon. -- Lionel Landwerlin <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Marvell Libertas 8388 802.11b/g USB driver (v2)
On Mon, 2007-01-22 at 10:20 -0500, Jon Smirl wrote: > What is the general solution for 802.11s? None yet. > I'm working on an embedded > design that would benefit from 11s support and I'd rather not have to > roll my own mesh implementation in user space. Well, there is no mesh implementation that I'm aware of, you'll want to stick it along with the userspace MLME into wpa_supplicant. > I'd also like to get an > idea of what kind of hardware I need to design onto my board given > that the 8388 is not available general consumption. My system has > plenty of power and CPU available so a softmac type 11s solution is > the most cost effective. It seems to me that the design of a software > based 11s stack should be coordinated with the 8388 firmware one. It should, but afaik no one is really working on it either way. johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH] bcm43xx: Fix problem with >1 GB RAM
On Tuesday 23 January 2007 16:18, Dan Williams wrote: > > At present, I have a problem getting NetworkManager to see the d80211 > > wireless interface. Once I get > > that solved, I plan to use my system to test with > 1 GB RAM on your git > > tree. In that case, I'll > > switch to the pci-form only if necessary. > > NM should show the interface if HAL sees the interface and has assigned > it a "net.80211" capability. We had all agreed that HAL should be a bit > smarter about detecting d80211 devices, but we were postponing that > until we figured out what to do with the master device. Now that we Jiri already has a working patch for that. I think he will commit it, soon. -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: adm8211 (from linville wireless-2.6) in xen guest
On Mon, 2007-01-22 at 14:30 -0500, Michael Wu wrote: > On Saturday 20 January 2007 07:19, Jan Evert van Grootheest wrote: > > Hi, > > > > Just writing to thank all of you that made the adm8211 driver in John > > Linvilles wireless-2.6 development tree (not the dscape one, which I > > will try also). > > > CC me then. :) Note that I only maintain the d80211 based adm8211 driver now, > but that driver doesn't have adhoc support yet. > > > One question, though. I'm trying to use it in ad-hoc mode. If there's no > > other station with the same essid, it just keeps mentioning that > > (besides the BCNTC and TSFTF messages) > > > > wlan0: No matching adhoc sta found. Creating IBSS 00:04:e2:3f:2a:70 CHAN=11 > > > > And the IBSS changes every time, which is about every 30 seconds. Is it > > really supposed to change the IBSS each time? > Probably not, but I never debugged adhoc mode enough. > > > The reason I ask is that my wife has a laptop with an Atheros chip in > > it. If it is configured for ad-hoc it creates the IBSS and sticks with > > it. So I now have two computers that have different behaviour in this > > respect. That in itself is not, I guess, a problem. But it seems to me > > that the random IBSS created by the adm8211 would result in two stations > > not seeing eachother or taking longer than necessary to find eachother? > > > Have you checked? I think the bssid should stop changing once another station > with the same ssid comes into range. Hmm; that's odd. If the card is set to adhoc mode and it cannot find another station, then it should just start up as the only station in the adhoc network. It ideally shouldn't be searching for another one since of course you don't really need more than one STA to form an adhoc network. In any case, concentration should go into the d80211 version of course :) Dan > > And one more question that I don't understand... the wlan0 interface > > does not appear in snmp queries. Any idea about that? > > > Nope. > > -Michael Wu - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bcm43xx: Fix problem with >1 GB RAM
On Mon, 2007-01-22 at 14:18 -0600, Larry Finger wrote: > Michael Buesch wrote: > > On Saturday 20 January 2007 17:18, Larry Finger wrote: > >> Some versions of the bcm43xx chips only support 30-bit DMA, which means > >> that the descriptors and buffers must be in the first 1 GB of RAM. On > >> the i386 and x86_64 architectures with more than 1 GB RAM, an incorrect > >> assignment may occur. This patch ensures that the various DMA addresses > >> are within the capability of the chip. Testing has been limited to x86_64 > >> as no one has an i386 system with more than 1 GB RAM. > >> > >> Signed-off-by: Larry Finger <[EMAIL PROTECTED]> > >> --- > > ..snip.. > > >>assert(!ring->tx); > >> > >> - dma_sync_single_for_cpu(&ring->bcm->pci_dev->dev, > >> - addr, len, DMA_FROM_DEVICE); > >> + pci_dma_sync_single_for_cpu(ring->bcm->pci_dev, > >> + addr, len, PCI_DMA_FROMDEVICE); > >> } > > > > Any special reason why you convert the DMA operations to the PCI > > stuff? I ask, because if this makes a difference, it affects the > > new SSB subsystem as well. > > When I looked at the b44 driver to see how that code handled the problem, it > used the pci-form of > the calls rather than the dma-version. Thus I switched early in the debug > process - even before I > had the necessary hardware. Once I got it working and understood the problem, > I never tried > restoring the dma-forms. > > At present, I have a problem getting NetworkManager to see the d80211 > wireless interface. Once I get > that solved, I plan to use my system to test with > 1 GB RAM on your git > tree. In that case, I'll > switch to the pci-form only if necessary. NM should show the interface if HAL sees the interface and has assigned it a "net.80211" capability. We had all agreed that HAL should be a bit smarter about detecting d80211 devices, but we were postponing that until we figured out what to do with the master device. Now that we think it will actually go away, it will be easier to find the actual wlan devices in sysfs or in /proc/net/wireless. I think HAL still looks in /proc/net/wireless to determine whether a network interface that it found is actually a wireless interface. The long and short of it is that if HAL says it has "net.80211" capability, NM should be able to find the device. Dan > > > >> static inline > >> @@ -194,8 +192,8 @@ void sync_descbuffer_for_device(struct b > > ..snip.. > > >> - goto out; > >> +no_dma: > >> +#ifdef CONFIG_BCM43XX_PIO > >> + printk(KERN_WARNING PFX "DMA not supported on this device." > >> + " Falling back to PIO.\n"); > >> + bcm->__using_pio = 1; > >> + BUG(); > > > > That isn't a BUG. Just remove this call, please. > > It was accidentally left in from my debugging. I have already submitted a > revised version to > Linville that removes this, and one other BUG statement that you didn't note. > > > >> + return -ENOSYS; > >> +#else > >> + printk(KERN_ERR PFX "FATAL: DMA not supported and PIO not configured. " > >> + "Please recompile the driver with PIO support.\n"); > >> + return -ENODEV; > >> +#endif /* CONFIG_BCM43XX_PIO */ > >> } > > ..snip.. > > >>u16 board_vendor; > >>u16 board_type; > > > > The rest is OK, I think. > > Thanks for the nice work. > > Thank you. It certainly was a lot easier with the necessary hardware in house. > > Larry > > - > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] airo.c: Description and function is not the same
On Sun, 2007-01-21 at 13:01 +0100, Richard Knutsson wrote: > Hello > > In the tour of converting local definitions of boolean-type/values, I > ran into airo.c's description of ex decapsulate(): > > * Returns: BOOLEAN - TRUE if packet should be dropped otherwise FALSE > > but returns SUCCESS (defined as 0) and ERROR (defined as -1). > > Also, shouldn't those functions be converted to return 'bool' when the > description say so (happy to do it). Does anyone use the Cisco MIC code anymore? I guess we can't just rip it out... It was a proprietary Cisco extension back before WPA. In any case, the comment should be changed to reflect the current return values of the function, and SUCCESS and ERROR in decapsulate() should be changed to 0 and -1 respectively; defining stuff like success/error just makes things ugly, and 0 and -1 are well-enough-known that there should be no question what they mean. Essentially, the code is using 0 and -1 as booleans anyway. I say get rid of SUCCESS & ERROR and just use 0 and -1, then change the comment. dan > Richard Knutsson > > - > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Re: kernel BUG in eth_alloc_tx_desc_index at drivers/net/mv643xx_eth.c:1069!
On 1/23/07, Thibaut VARENE <[EMAIL PROTECTED]> wrote: - As Jarek pointed out, you're checking twice the value of mp->tx_desc_count, which means dereferencing a pointer and accessing memory twice. I don't know how perf-critical this bit of code is, but I wonder which of keeping the lock for a long time or doing what you is better (I'm being anal and you probably know that better than me :) Forget that. That's an irq disabling lock, it's worse than anything else :) -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Re: kernel BUG in eth_alloc_tx_desc_index at drivers/net/mv643xx_eth.c:1069!
On 1/22/07, Dale Farnsworth <[EMAIL PROTECTED]> wrote: Jarek and Thibaut, Thank you both very much for your work finding and fixing this bug. Jarek, can you verify that the following patch fixes the problem you were seeing? -Dale Hi Dale, The patch seems to work fine. Just thinking out loud (as I really don't know this part of the kernel), here are a few remarks: - As Jarek pointed out, you're checking twice the value of mp->tx_desc_count, which means dereferencing a pointer and accessing memory twice. I don't know how perf-critical this bit of code is, but I wonder which of keeping the lock for a long time or doing what you is better (I'm being anal and you probably know that better than me :) - Also, lines 344-349, in the test condition, cmd_sts (an indirection to mp content) is accessed (dunno if it's ok to do that outside of the lock), and on line 346, mp->stats.tx.errors is incremented outside of the spinlock protection. But then, I don't know what that lock is meant to protect, just pointing this out :) Thanks for your help, I hope the fix will go upstream asap :) And about being the author of the patch, since I'm not, I don't really mind 8) HTH T-Bone -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why would EPIPE cause socket port to change?
On Tue, Jan 23, 2007 at 02:15:45PM +0300, Michael Tokarev wrote:
>
> Still, after the connection has been closed, there's no chance to do
> anything with the filedescriptor but to close it as well, right? Or
> can the fd be reused by making new connection with it, as if it were
> just returned from socket() call?
Yes you can connect out on it again if you're in TCP_CLOSE. The fact
that the port number has changed implies that you've entered TCP_CLOSE.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why would EPIPE cause socket port to change?
Herbert Xu wrote: > On Tue, Jan 23, 2007 at 02:10:39PM +0300, Michael Tokarev wrote: >> Well, but why getsockname() didn't just return ENOTCONN? > > It's perfectly valid to have a local port number without being connected. Er. You're right - I was confusing getSOCKname() and getPEERname(). Still, after the connection has been closed, there's no chance to do anything with the filedescriptor but to close it as well, right? Or can the fd be reused by making new connection with it, as if it were just returned from socket() call? If it's the former, than there's no reason to assign new local address to it. /mjt - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why would EPIPE cause socket port to change?
On Tue, Jan 23, 2007 at 02:10:39PM +0300, Michael Tokarev wrote:
>
> Well, but why getsockname() didn't just return ENOTCONN?
It's perfectly valid to have a local port number without being connected.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why would EPIPE cause socket port to change?
Herbert Xu wrote:
> dean gaudet <[EMAIL PROTECTED]> wrote:
>> in the test program below the getsockname result on a TCP socket changes
>> across a write which produces EPIPE... here's a fragment of the strace:
>>
>> getsockname(3, {sa_family=AF_INET, sin_port=htons(37636),
>> sin_addr=inet_addr("127.0.0.1")}, [17863593746633850896]) = 0
>> ...
>> write(3, "hi!\n", 4)= 4
>> write(3, "hi!\n", 4)= -1 EPIPE (Broken pipe)
>> --- SIGPIPE (Broken pipe) @ 0 (0) ---
>> getsockname(3, {sa_family=AF_INET, sin_port=htons(59882),
>> sin_addr=inet_addr("127.0.0.1")}, [16927060683038654480]) = 0
>>
>> why does the port# change? this is on 2.6.19.1.
>
> Prior to the last write, the socket entered the CLOSED state meaning
> that the old port is no longer allocated to it. As a result, the
> last write operates on an unconnected socket which causes a new local
> port to be allocated as an autobind. It then fails because the socket
> is still not connected.
Well, but why getsockname() didn't just return ENOTCONN?
> So any attempt to run getsockname after an error on the socket is
> simply buggy.
Yes it is. But so is not returning ENOTCONN from getsockname(). I think.
/mjt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XFRM does not rate limit messages from the kernel to userspace
Herbert Xu wrote: > Marco Berizzi <[EMAIL PROTECTED]> wrote: > > > > AFAIK it was applied to osw 2.4.2 > > Also changelog confirm this: > > > > v2.4.2 > > Indeed. Somehow I couldn't find the patch in the git tree that > I had here. It wasn't the 2.4 branch though. > > I presume you're using 2.4.x as well? Yes, I'm using openswan 2.4.7 > If so I'll neet to look at this again. thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XFRM does not rate limit messages from the kernel to userspace
Marco Berizzi <[EMAIL PROTECTED]> wrote:
>
> AFAIK it was applied to osw 2.4.2
> Also changelog confirm this:
>
> v2.4.2
Indeed. Somehow I couldn't find the patch in the git tree that
I had here. It wasn't the 2.4 branch though.
I presume you're using 2.4.x as well?
If so I'll neet to look at this again.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bcm43xx_d80211: Fix major memory corruption bug
On Sunday 21 January 2007 06:27, Pavel Roskin wrote: > Set phy->lo_control to NULL whenever it's freed. Failure to do so leads > to zeroing a block of memory that uses to hold *phy->lo_control, which > caused random crashes down the road. > > Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]> Applied, thanks. > --- > > drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c > b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c > index 3064322..62d4dc9 100644 > --- a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c > +++ b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c > @@ -3048,6 +3048,7 @@ static void bcm43xx_wireless_core_exit(struct > bcm43xx_wldev *dev) > if (phy->dyn_tssi_tbl) > kfree(phy->tssi2dbm); > kfree(phy->lo_control); > + phy->lo_control = NULL; > ssb_chipco_set_clockmode(chipco, SSB_CLKMODE_SLOW); > bcm43xx_vstack_free(&dev->genstack); > bcm43xx_set_status(dev, BCM43xx_STAT_UNINIT); > @@ -3179,6 +3180,7 @@ err_kfree_tssitbl: > kfree(phy->tssi2dbm); > err_kfree_lo_control: > kfree(phy->lo_control); > + phy->lo_control = NULL; > err_slowclock: > ssb_chipco_set_clockmode(chipco, SSB_CLKMODE_SLOW); > bcm43xx_set_status(dev, BCM43xx_STAT_UNINIT); > > > -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
