2008-08-04 21:14:51

by Larry Finger

[permalink] [raw]
Subject: [PATCH] p54: Fix regression due to commit b19fa1f

In commit b19fa1fa91845234961c64dbd564671aa7c0fd27, the configuration
parameter NETDEVICES_MULTIQUEUE was eliminated making multiple TX queues
the normal behavior. For p54usb, enabling multiple queues broke the driver.

The real failure is not known, but a temporary hack that forces only one
queue is presented here.

Signed-off-by: Larry Finger <[email protected]>
---

John,

This is clearly not the best fix, but there has been no action so far, and
it does fix the b19fa1f regression. Let's push this up to 2.6.27.

Larry


Index: linux-2.6/drivers/net/wireless/p54/p54common.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/p54/p54common.c
+++ linux-2.6/drivers/net/wireless/p54/p54common.c
@@ -150,7 +150,7 @@ void p54_parse_firmware(struct ieee80211
priv->tx_stats[1].limit = 4;
priv->tx_stats[2].limit = 3;
priv->tx_stats[3].limit = 1;
- dev->queues = 4;
+ dev->queues = 1; /* temp. hack, set to 1 as 4 breaks p54usb */
}
}
EXPORT_SYMBOL_GPL(p54_parse_firmware);


2008-08-06 22:54:20

by Christian Lamparter

[permalink] [raw]
Subject: Re: [PATCH] p54: Fix regression due to commit b19fa1f

On Monday 04 August 2008 23:14:51 Larry Finger wrote:
> In commit b19fa1fa91845234961c64dbd564671aa7c0fd27, the configuration
> parameter NETDEVICES_MULTIQUEUE was eliminated making multiple TX queues
> the normal behavior. For p54usb, enabling multiple queues broke the driver.
>
> The real failure is not known, but a temporary hack that forces only one
> queue is presented here.
>

The real problem seems to be that skb_get_queue_mapping doesn't
work the way it should when we process the firmwares callback. It's
always "0" and unfortunately also when it should be something else like
queue 1, 2 or 3..... problem solved?

However someone should really take a closer look at the multiqueue thing,
especially why it has to BLOCK/SPIN (uninterruptible?) when a queue is stopped
and tx returns therefore NETDEV_BUSY.
The is assumption that "a queue is in any case going to become free again" is
well-intentioned, but as my devices are crashing left & right on a daily basis
it's even dangerous for my RAID ;-).

(BTW: patch is diffed against 2.6.27-rc2)

Signed-off-by: Christian Lamparter <[email protected]>


Attachments:
(No filename) (1.09 kB)
p54-multiscrew.diff (825.00 B)
Download all attachments