Christian,
I have not gotten very far with the problem in the subject; however, I
have a few things to report:
I got a dump of the TX queues when the disassociation event came
through. All were normal.
I tested with 2.6.31-rc2 from Linus's tree. It does _NOT_ have the
problem, thus it is something that was introduced in the process of
splitting p54common.{ch} into the component parts.
In comparing the code, I see that the variable 'cached_beacon' was
eliminated and the code that handles beacons was changed. When I made
the following change, the "no probe response" message went away - the
interface just hangs:
Index: wireless-testing/drivers/net/wireless/p54/txrx.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/p54/txrx.c
+++ wireless-testing/drivers/net/wireless/p54/txrx.c
@@ -386,7 +386,8 @@ static void p54_rx_frame_sent(struct p54
priv->beacon_req_id = cpu_to_le32(0);
dev_kfree_skb_any(entry);
- return ;
+ p54_wake_queues(priv);
+ return;
}
/*
Any thoughts?
Larry
On Thursday 09 July 2009 21:31:47 Larry Finger wrote:
> Christian,
>
> I have not gotten very far with the problem in the subject; however, I
> have a few things to report:
>
> I got a dump of the TX queues when the disassociation event came
> through. All were normal.
normal? as in completely empty? or just a soft dribble (possibly stalled)?
> I tested with 2.6.31-rc2 from Linus's tree. It does _NOT_ have the
> problem, thus it is something that was introduced in the process of
> splitting p54common.{ch} into the component parts.
>
> In comparing the code, I see that the variable 'cached_beacon' was
> eliminated and the code that handles beacons was changed. When I made
> the following change, the "no probe response" message went away - the
> interface just hangs:
cached_beacon is only relevant when you run an AP/MESH/(IBSS).
The cached_beacon code was removed because its very racy
(we never knew whenever the pointer was still valid, as p54_free_skb
could have freed that buffer already and did not NULL out the reference).
The replacement "beacon_req_id" suffers from the same flaw,
but at least its save against 2x kfree_skb.
so no, can you still toggle the LEDs (e.g /sys/class interface)
when the interface hangs? or is there some traffic
on a cooked monitor interface?
(iw phy phyX interface add monX type monitor; ifconfig monX up)
what could be related to that issue... and maybe even explain why I don't have
the very same issues are transmission errors:
---
diff --git a/drivers/net/wireless/p54/p54usb.c b/drivers/net/wireless/p54/p54usb.c
index e44460f..c0c2817 100644
--- a/drivers/net/wireless/p54/p54usb.c
+++ b/drivers/net/wireless/p54/p54usb.c
@@ -111,10 +111,12 @@ static void p54u_rx_cb(struct urb *urb)
struct p54u_rx_info *info = (struct p54u_rx_info *)skb->cb;
struct ieee80211_hw *dev = info->dev;
struct p54u_priv *priv = dev->priv;
+ int err;
skb_unlink(skb, &priv->rx_queue);
if (unlikely(urb->status)) {
+ printk(KERN_INFO "lost rx urb (%d)\n", urb->status);
dev_kfree_skb_irq(skb);
return;
}
@@ -153,7 +155,8 @@ static void p54u_rx_cb(struct urb *urb)
}
skb_queue_tail(&priv->rx_queue, skb);
usb_anchor_urb(urb, &priv->submitted);
- if (usb_submit_urb(urb, GFP_ATOMIC)) {
+ if ((err = usb_submit_urb(urb, GFP_ATOMIC))) {
+ printk(KERN_INFO "could not resubmit rx urb (%d)\n", err);
skb_unlink(skb, &priv->rx_queue);
usb_unanchor_urb(urb);
dev_kfree_skb_irq(skb);
@@ -244,9 +247,11 @@ static void p54u_tx_lm87(struct ieee80211_hw *dev, struct sk_buff *skb)
struct p54u_priv *priv = dev->priv;
struct urb *data_urb;
struct lm87_tx_hdr *hdr = (void *)skb->data - sizeof(*hdr);
+ int err;
data_urb = usb_alloc_urb(0, GFP_ATOMIC);
if (!data_urb) {
+ printk(KERN_ERR "could not alloc tx urb - oom\n");
p54_free_skb(dev, skb);
return;
}
@@ -261,7 +266,8 @@ static void p54u_tx_lm87(struct ieee80211_hw *dev, struct sk_buff *skb)
data_urb->transfer_flags |= URB_ZERO_PACKET;
usb_anchor_urb(data_urb, &priv->submitted);
- if (usb_submit_urb(data_urb, GFP_ATOMIC)) {
+ if ((err = usb_submit_urb(data_urb, GFP_ATOMIC))) {
+ printk(KERN_ERR "xmit urb failed (%d)\n", err);
usb_unanchor_urb(data_urb);
p54_free_skb(dev, skb);
}
---
if that doesn't work out (which will inevitably happen)...
I'm really out of ideas and if you can I request an (usbmon -iX -s 2400) dump
for inspiration from a crash/stall. Of course, it doesn't need to be
the whole log (~ 5 before and 20 after the freeze/disassoc) should be
more than enough to hopefully spot that *********** bug inside the driver.
Regards,
Chr