headers
Felipe Balbi | 1 Aug 01:26

Re: Q: support for AVM Fritz! WLAN USB in kernel 2.6.25+

On Fri, Aug 01, 2008 at 12:55:11AM +0200, Tilman Schmidt wrote:
> Oh, please ... You aren't seriously trying to tell me there's a *technical*
> reason for changing EXPORT_SYMBOL to EXPORT_SYMBOL_GPL, are you?

You really have no idea what you're talking about. If manufacturers
really don't wanna write gpl code, they have really sane api via
usbdev_fs.h or libusb to do it.

It's like we completely removed any possibility of closed source
drivers.

> That's not true. Reverting commit 782e70c6fc2290a0395850e8e02583b8b62264d8
> would be enough. But again, I am not asking for that. My question isn't
> about getting AVM's closed source driver to work with kernel 2.6.25+.
> I just want to know whether there is an open source alternative, nothing
> more.

Did you read the commit message?

"Over two years ago, the Linux USB developers stated that they believed
there was no way to create a USB kernel driver that was not under the
GPL.  This patch moves the USB apis to enforce that decision.

There are no known closed source USB drivers in the wild, so this patch
should cause no problems."

So a) it wasn't an over-the-night decision. It was stated publicly and
given a 2 years period for everybody to know about what would happen and
b) "there are no know closed source usb drivers in the wild",
unfortunately, it looks like nobody knew about AVM's closed source
(Continue reading)

Permalink | Reply | 12 comments |
headers
Larry Finger | 1 Aug 02:30
Favicon

[PATCH V3] rtl8187: Fix lockups due to concurrent access to config routine

Some users of the RTL8187B have experienced difficulties since commit
8f87dd7e540d455f8e7f11478133b85edc969c67 that introduced the power
management wext hooks. This difficulty has not made much sense until
it was realized that it was possible for mac80211 to make a call to the
config routine while that routine was already being executed. On this
device, it is necessary to loopback the TX when changing channels. Unless
this is properly restored, the device will lockup. A mutex now protects
the device state, and the private data in several places.

The problem was found by Herton Ronaldo Krzesinski <herton@...>,
who also suggested this type of fix.

Signed-off-by: Larry Finger <Larry.Finger@...>
Acked-by: Herton Ronaldo Krzesinski <herton@...>
Acked-by: Hin-Tak Leung <htl10@...>
---

John,

This is 2.6.27 material. V3 protects some additional routines where the
private data is being updated.

Larry
---

 rtl8187.h     |    4 ++++
 rtl8187_dev.c |   15 ++++++++++++++-
 2 files changed, 18 insertions(+), 1 deletion(-)

Index: wireless-testing/drivers/net/wireless/rtl8187.h
(Continue reading)

Permalink | Reply | 2 comments |
headers
Sujith | 1 Aug 03:23
Picon

Re: ath9k and N wireless on B frequencies

Jack Howarth wrote:
 > Stefanik,
 >    Yes, my mistake. I meant to say does ath9k
 > support the use of N protocols under the 802.11a
 > wireless frequencies. Does anyone know if ath9k
 > supports this?

Yes, it is supported.

Sujith
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Hin-Tak Leung | 1 Aug 04:29
Picon

Re: [PATCH V3] rtl8187: Fix lockups due to concurrent access to config routine

On 8/1/08, Larry Finger <Larry.Finger@...> wrote:
> Some users of the RTL8187B have experienced difficulties since commit
>  8f87dd7e540d455f8e7f11478133b85edc969c67 that introduced the power
>  management wext hooks. This difficulty has not made much sense until
>  it was realized that it was possible for mac80211 to make a call to the
>  config routine while that routine was already being executed. On this
>  device, it is necessary to loopback the TX when changing channels. Unless
>  this is properly restored, the device will lockup. A mutex now protects
>  the device state, and the private data in several places.
>
>  The problem was found by Herton Ronaldo Krzesinski <herton@...>,
>  who also suggested this type of fix.

Thanks for the work. I think we need a few more mutex locks.

The one-line message/explanation is a bit mis-worded though. There isn't a
"lockup" though. I would describe the problem as the driver's internal
state getting garbbaged. It is probably a performance "feature" that
routines in either the mac80211 layer or the usb layer returns before
they are done. (i.e. actions are simply
queued for near-future to act on). Maybe somebody else can explain this better?

Hin-Tak
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Jasper Bryant-Greene | 1 Aug 04:48
Picon

2.6.27-rc1-next-20080731 assoc problems

iwl4965, Netgear WNR854T 802.11n AP

I seem to be getting these problems from time to time since moving from
2.6.26 to 2.6.27-rc1-next-20080731:

[  457.500308] wlan0: authenticate with AP 00:18:4d:XX:XX:XX
[  457.506530] wlan0: authenticate with AP 00:18:4d:XX:XX:XX
[  457.508347] wlan0: authenticated
[  457.508359] wlan0: associate with AP 00:18:4d:XX:XX:XX
[  457.511967] wlan0: RX AssocResp from 00:18:4d:XX:XX:XX (capab=0x411
status=1 aid=0)
[  457.511978] wlan0: AP denied association (code=1)
[  457.704131] wlan0: associate with AP 00:18:4d:XX:XX:XX
[  457.708870] wlan0: RX AssocResp from 00:18:4d:XX:XX:XX (capab=0x411
status=1 aid=0)
[  457.708877] wlan0: AP denied association (code=1)
[  457.903773] wlan0: associate with AP 00:18:4d:XX:XX:XX
[  457.906330] wlan0: RX AssocResp from 00:18:4d:XX:XX:XX (capab=0x411
status=1 aid=0)
[  457.906333] wlan0: AP denied association (code=1)
[  458.105105] wlan0: association with AP 00:18:4d:XX:XX:XX timed out

Is it really my AP, as the messages suggest?

-jasper

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 2 comments |
headers
Larry Finger | 1 Aug 04:58
Favicon

Re: [PATCH V3] rtl8187: Fix lockups due to concurrent access to config routine

Hin-Tak Leung wrote:
> 
> Thanks for the work. I think we need a few more mutex locks.

I tried two other places: rtl8187_tx() and rtl8187_configure_filter. Both 
generated warnings as mac80211 had already had a lock in place. So far, I 
haven't seen any candidates, but the code surely needs a thorough audit.

> The one-line message/explanation is a bit mis-worded though. There isn't a
> "lockup" though. I would describe the problem as the driver's internal
> state getting garbbaged. It is probably a performance "feature" that
> routines in either the mac80211 layer or the usb layer returns before
> they are done. (i.e. actions are simply
> queued for near-future to act on). Maybe somebody else can explain this better?

The comment in the code that "the card will stop work until next reset" sounds 
as though it locks up. That was why I chose the wording that I did.

Larry

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
David Miller | 1 Aug 06:27
Favicon

Re: Kernel WARNING: at net/core/dev.c:1330 __netif_schedule+0x2c/0x98()

From: David Miller <davem <at> davemloft.net>
Date: Thu, 31 Jul 2008 05:29:32 -0700 (PDT)

> It's late here, but I'll start testing the following patch on my
> multiqueue capable cards after some sleep.

As a quick followup, I tested this on a machine where I had
a multiqueue interface and could reproduce the lockdep warnings,
and the patch makes them go away.

So I've pushed the patch into net-2.6 and will send it to Linus.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Jarek Poplawski | 1 Aug 08:48
Picon

Re: Kernel WARNING: at net/core/dev.c:1330 __netif_schedule+0x2c/0x98()

On Thu, Jul 31, 2008 at 05:29:32AM -0700, David Miller wrote:
> From: Jarek Poplawski <jarkao2 <at> gmail.com>
> Date: Sun, 27 Jul 2008 22:37:57 +0200
> 
> > Looks like enough to me. (Probably it could even share space with
> > the state.)

Alas I've some doubts here...

...
>  static inline void netif_tx_unlock(struct net_device *dev)
>  {
>  	unsigned int i;
>  
>  	for (i = 0; i < dev->num_tx_queues; i++) {
>  		struct netdev_queue *txq = netdev_get_tx_queue(dev, i);
> -		__netif_tx_unlock(txq);
> -	}
>  
> +		/* No need to grab the _xmit_lock here.  If the
> +		 * queue is not stopped for another reason, we
> +		 * force a schedule.
> +		 */
> +		clear_bit(__QUEUE_STATE_FROZEN, &txq->state);

The comments in asm-x86/bitops.h to set_bit/clear_bit are rather queer
about reordering on non x86: isn't eg. smp_mb_before_clear_bit()
useful  here?

> +		if (!test_bit(__QUEUE_STATE_XOFF, &txq->state))
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jarek Poplawski | 1 Aug 09:01
Picon

Re: Kernel WARNING: at net/core/dev.c:1330 __netif_schedule+0x2c/0x98()

On Fri, Aug 01, 2008 at 06:48:10AM +0000, Jarek Poplawski wrote:
> On Thu, Jul 31, 2008 at 05:29:32AM -0700, David Miller wrote:
...
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index 63d6bcd..69320a5 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -4200,6 +4200,7 @@ static void netdev_init_queues(struct net_device *dev)
> >  {
> >  	netdev_init_one_queue(dev, &dev->rx_queue, NULL);
> >  	netdev_for_each_tx_queue(dev, netdev_init_one_queue, NULL);
> > +	spin_lock_init(&dev->tx_global_lock);
> 
> This will probably need some lockdep annotations similar to
> _xmit_lock.

...BTW, we probably could also consider some optimization here: the
xmit_lock of the first queue could be treated as special, and only
the owner could do such a freezing. This would save changes of
functionality to non mq devices. On the other hand, it would need
remembering about this special treatment (so, eg. a separate lockdep
initialization than all the others).

Jarek P.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Miller | 1 Aug 09:00
Favicon

Re: Kernel WARNING: at net/core/dev.c:1330 __netif_schedule+0x2c/0x98()

From: Jarek Poplawski <jarkao2@...>
Date: Fri, 1 Aug 2008 06:48:10 +0000

> On Thu, Jul 31, 2008 at 05:29:32AM -0700, David Miller wrote:
> > +		/* No need to grab the _xmit_lock here.  If the
> > +		 * queue is not stopped for another reason, we
> > +		 * force a schedule.
> > +		 */
> > +		clear_bit(__QUEUE_STATE_FROZEN, &txq->state);
> 
> The comments in asm-x86/bitops.h to set_bit/clear_bit are rather queer
> about reordering on non x86: isn't eg. smp_mb_before_clear_bit()
> useful  here?

It doesn't matter, we need no synchronization here at all.

We unconditionally perform a __netif_schedule(), and that
will run the TX queue on the local cpu.  We will take the
_xmit_lock at least once time if in fact the queue was not
stopped before the first froze it.

> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index 63d6bcd..69320a5 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -4200,6 +4200,7 @@ static void netdev_init_queues(struct net_device *dev)
> >  {
> >  	netdev_init_one_queue(dev, &dev->rx_queue, NULL);
> >  	netdev_for_each_tx_queue(dev, netdev_init_one_queue, NULL);
> > +	spin_lock_init(&dev->tx_global_lock);
(Continue reading)

Permalink | Reply | 0 comments |

Gmane