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 <chunkeey@xxxxxx>
--- a/drivers/net/wireless/p54/p54common.c.orig 2008-08-07 00:27:35.000000000 +0200
+++ b/drivers/net/wireless/p54/p54common.c 2008-08-07 00:30:38.000000000 +0200
@@ -413,12 +413,12 @@ static void p54_rx_frame_sent(struct iee
last_addr = range->end_addr;
__skb_unlink(entry, &priv->tx_queue);
memset(&info->status, 0, sizeof(info->status));
- priv->tx_stats[skb_get_queue_mapping(skb)].len--;
entry_hdr = (struct p54_control_hdr *) entry->data;
entry_data = (struct p54_tx_control_allocdata *) entry_hdr->data;
if ((entry_hdr->magic1 & cpu_to_le16(0x4000)) != 0)
pad = entry_data->align[0];
+ priv->tx_stats[le32_to_cpu(entry_data->frame_type - 4)].len--;
if (!(info->flags & IEEE80211_TX_CTL_NO_ACK)) {
if (!(payload->status & 0x01))
info->flags |= IEEE80211_TX_STAT_ACK;
