LinuxLists.cc - ipw2200 stalls on high load

2008-01-26 13:29:44

Subject: ipw2200 stalls on high load

Hello,

my wireless connection stalls after like 5 seconds once the downloading
performance passes around 600 KiB/sec. I noticed in dmesg the following:
| ipw2200: Firmware error detected. Restarting.
I can't tell if this is a regression because my wireless was never that
fast. It still works perfectly with my other link that is capable of
about 230 KiB/sec.

In [1] you can see debug output generated by the ipw2200 module which
was loaded with debug=0x3fff on v2.6.24 mainline kernel and firmware
3.0. Both wireless links are WPA encrypted. iwconfig reports for that
interface:

| Mode:Managed Frequency:2.422 GHz Access Point:
| Bit Rate:48 Mb/s Tx-Power=20 dBm Sensitivity=8/0
| Retry limit:7 RTS thr:off Fragment thr:off
| Encryption key: Security mode:open
| Power Management:off
| Link Quality=83/100 Signal level=-47 dBm Noise level=-89 dBm
| Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
| Tx excessive retries:0 Invalid misc:0 Missed beacon:10

Regards,
Sebastian

[1] http://download.breakpoint.cc/ipw2200-debug.txt 643 KiB

2008-01-28 22:54:28

by Sebastian Siewior

[permalink] [raw]

Subject: Re: [Ipw2100-devel] ipw2200 stalls on high load

* Cahill, Ben M | 2008-01-28 10:53:59 [-0800]:

>Could you try once more, this time with debug=0x43fff? ... this will
>provide additional details as to the cause of the firmware error.
Strange thing. Can't trigger it anymore. It wasn't a problem earlier.
I get back to you with the new debug options as soon as I can get it
captured.

>-- Ben --
Thanks,
Sebastian

2008-01-30 22:57:40

by Sebastian Siewior

[permalink] [raw]

Subject: Re: ipw2200 stalls on high load

* Chatre, Reinette | 2008-01-28 10:40:16 [-0800]:

>On ,Sebastian Siewior wrote:
>
>> Hello,
>>
>> my wireless connection stalls after like 5 seconds once the
>> downloading performance passes around 600 KiB/sec. I noticed in dmesg
>> the following:
>>> ipw2200: Firmware error detected. Restarting.
>
>Could you please submit a bug at http://www.bughost.org to enable us to
>track this problem?
Sure. #1487 looks very close. The firmware version seems to be different
as well as the "the driver messsage". Do you want me to open a new one or
should I follow-up?

>Thank you
>
>Reinette
>
Regards,
Sebastian

2008-01-30 22:48:05

by Sebastian Siewior

[permalink] [raw]

Subject: Re: [Ipw2100-devel] ipw2200 stalls on high load

* Cahill, Ben M | 2008-01-28 10:53:59 [-0800]:

>Could you try once more, this time with debug=0x43fff? ... this will
>provide additional details as to the cause of the firmware error.

Voila [1].

>-- Ben --

Regards,
Sebastian

[1] http://download.breakpoint.cc/ipw2200-debug2.txt 641 KiB

2008-01-28 18:42:55

by Reinette Chatre

[permalink] [raw]

Subject: RE: ipw2200 stalls on high load

On ,Sebastian Siewior wrote:

> Hello,
>
> my wireless connection stalls after like 5 seconds once the
> downloading performance passes around 600 KiB/sec. I noticed in dmesg
> the following:
>> ipw2200: Firmware error detected. Restarting.

Could you please submit a bug at http://www.bughost.org to enable us to
track this problem?

Thank you

Reinette

2008-01-28 18:54:07

by Cahill, Ben M

[permalink] [raw]

Subject: RE: [Ipw2100-devel] ipw2200 stalls on high load

Could you try once more, this time with debug=0x43fff? ... this will
provide additional details as to the cause of the firmware error.

-- Ben --

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On
> Behalf Of Sebastian Siewior
> Sent: Saturday, January 26, 2008 8:30 AM
> To: Zhu, Yi; James Ketrenos
> Cc: [email protected];
> [email protected]
> Subject: [Ipw2100-devel] ipw2200 stalls on high load
>
> Hello,
>
> my wireless connection stalls after like 5 seconds once the
> downloading performance passes around 600 KiB/sec. I noticed
> in dmesg the following:
> | ipw2200: Firmware error detected. Restarting.
> I can't tell if this is a regression because my wireless was
> never that fast. It still works perfectly with my other link
> that is capable of about 230 KiB/sec.
>
> In [1] you can see debug output generated by the ipw2200
> module which was loaded with debug=0x3fff on v2.6.24 mainline
> kernel and firmware 3.0. Both wireless links are WPA
> encrypted. iwconfig reports for that
> interface:
>
> | Mode:Managed Frequency:2.422 GHz Access Point:
> | Bit Rate:48 Mb/s Tx-Power=20 dBm Sensitivity=8/0
> | Retry limit:7 RTS thr:off Fragment thr:off
> | Encryption key: Security mode:open
> | Power Management:off
> | Link Quality=83/100 Signal level=-47 dBm Noise level=-89 dBm Rx
> | invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> | Tx excessive retries:0 Invalid misc:0 Missed beacon:10
>
> Regards,
> Sebastian
>
> [1] http://download.breakpoint.cc/ipw2200-debug.txt 643 KiB
>
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by: Microsoft Defy all
> challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> ipw2100-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ipw2100-devel
>

2008-02-05 16:51:54

by Cahill, Ben M

[permalink] [raw]

Subject: RE: [Ipw2100-devel] ipw2200 stalls on high load

>
> That would mean that count never gets above 8, and that the
> RX queue is never restocked. The (count >= 8) part might be
> specific to the
> 3945/4965 drivers, since they apparently restock the RX queue
> in blocks of 8.

That's right, the 3945 and 4965 hardware like to see the index change on
boundaries of 8. You'll see that, somewhere in the driver code, the
lower 3 bits of the index get masked to 0. I don't know what 2200's
requirements are in this regard.

-- Ben --

2008-02-04 18:23:52

by Reinette Chatre

[permalink] [raw]

Subject: RE: ipw2200 stalls on high load

On Monday, February 04, 2008 4:37 AM, Dan Williams wrote:

> Something like the following? Turns out the rxq->processed
> isn't really
> used that much, and 3945/4965 don't use that field at all (but use
> ->read exclusively instead). And since it appears that the replenish
> function is simpler in the 2200, it doesn't need to be split like
> 3945/4965. I haven't been able to stress my 2200 enough to trigger
> the new codepath though.

Thank you very much!

Sebastian, does this change work for you?

Reinette

(patch kept below ...)

>
>
> diff --git a/drivers/net/wireless/ipw2200.c
> b/drivers/net/wireless/ipw2200.c
> index 3e6ad7b..8856eea 100644
> --- a/drivers/net/wireless/ipw2200.c
> +++ b/drivers/net/wireless/ipw2200.c
> @@ -3365,7 +3365,6 @@ static void ipw_rx_queue_reset(struct
> ipw_priv *priv,
> /* Set us so that we have processed and used all
> buffers, but have
> * not restocked the Rx queue with fresh buffers */
rxq->read =
> rxq->write = 0; - rxq->processed = RX_QUEUE_SIZE - 1;
> rxq->free_count = 0;
> spin_unlock_irqrestore(&rxq->lock, flags);
> }
> @@ -3607,7 +3606,22 @@ static int ipw_load(struct ipw_priv *priv)
> * Driver allocates buffers of this size for Rx
> */
>
> -static inline int ipw_queue_space(const struct clx2_queue *q) +/**
> + * ipw_rx_queue_space - Return number of free slots available
> in queue.
> + */
> +static int ipw_rx_queue_space(const struct ipw_rx_queue *q) +{
> + int s = q->read - q->write;
> + if (s <= 0)
> + s += RX_QUEUE_SIZE;
> + /* keep some buffer to not confuse full and empty queue */ +
s -= 2;
> + if (s < 0)
> + s = 0;
> + return s;
> +}
> +
> +static inline int ipw_tx_queue_space(const struct clx2_queue *q) {
> int s = q->last_used - q->first_empty;
> if (s <= 0)
> @@ -4947,7 +4961,7 @@ static int ipw_queue_tx_reclaim(struct
> ipw_priv *priv,
> priv->tx_packets++;
> }
> done:
> - if ((ipw_queue_space(q) > q->low_mark) &&
> + if ((ipw_tx_queue_space(q) > q->low_mark) &&
> (qindex >= 0) &&
> (priv->status & STATUS_ASSOCIATED) &&
> netif_running(priv->net_dev))
> netif_wake_queue(priv->net_dev);
> @@ -4965,7 +4979,7 @@ static int ipw_queue_tx_hcmd(struct
> ipw_priv *priv, int hcmd, void *buf,
> struct clx2_queue *q = &txq->q;
> struct tfd_frame *tfd;
>
> - if (ipw_queue_space(q) < (sync ? 1 : 2)) {
> + if (ipw_tx_queue_space(q) < (sync ? 1 : 2)) {
> IPW_ERROR("No space for Tx\n");
> return -EBUSY;
> }
> @@ -5070,7 +5084,7 @@ static void ipw_rx_queue_restock(struct
> ipw_priv *priv)
>
> spin_lock_irqsave(&rxq->lock, flags);
> write = rxq->write;
> - while ((rxq->write != rxq->processed) && (rxq->free_count)) {
> + while ((ipw_rx_queue_space(rxq) > 0) && (rxq->free_count)) {
> element = rxq->rx_free.next;
> rxb = list_entry(element, struct
> ipw_rx_mem_buffer, list);
> list_del(element);
> @@ -5187,7 +5201,6 @@ static struct ipw_rx_queue
> *ipw_rx_queue_alloc(struct ipw_priv *priv)
> /* Set us so that we have processed and used all
> buffers, but have
> * not restocked the Rx queue with fresh buffers */
rxq->read =
> rxq->write = 0; - rxq->processed = RX_QUEUE_SIZE - 1;
> rxq->free_count = 0;
>
> return rxq;
> @@ -8223,13 +8236,18 @@ static void ipw_rx(struct ipw_priv *priv)
> struct ieee80211_hdr_4addr *header;
> u32 r, w, i;
> u8 network_packet;
> + u8 fill_rx = 0;
> + u32 count = 0;
> DECLARE_MAC_BUF(mac);
> DECLARE_MAC_BUF(mac2);
> DECLARE_MAC_BUF(mac3);
>
> r = ipw_read32(priv, IPW_RX_READ_INDEX);
> w = ipw_read32(priv, IPW_RX_WRITE_INDEX);
> - i = (priv->rxq->processed + 1) % RX_QUEUE_SIZE;
> + i = priv->rxq->read;
> +
> + if (ipw_rx_queue_space (priv->rxq) > (RX_QUEUE_SIZE / 2))
> + fill_rx = 1;
>
> while (i != r) {
> rxb = priv->rxq->queue[i];
> @@ -8404,11 +8422,21 @@ static void ipw_rx(struct ipw_priv *priv)
> list_add_tail(&rxb->list, &priv->rxq->rx_used);
>
> i = (i + 1) % RX_QUEUE_SIZE;
> +
> + /* If there are a lot of unsued frames, restock
> the Rx queue
> + * so the ucode won't assert */
> + if (fill_rx) {
> + count++;
> + if (count >= 8) {
> + priv->rxq->read = i;
> + ipw_rx_queue_replenish(priv);
> + count = 0;
> + }
> + }
> }
>
> /* Backtrack one entry */
> - priv->rxq->processed = (i ? i : RX_QUEUE_SIZE) - 1; -
> + priv->rxq->read = i;
> ipw_rx_queue_restock(priv);
> }
>
> @@ -10336,7 +10364,7 @@ static int ipw_tx_skb(struct ipw_priv
> *priv, struct ieee80211_txb *txb,
> q->first_empty = ipw_queue_inc_wrap(q->first_empty, q->n_bd);
> ipw_write32(priv, q->reg_w, q->first_empty);
>
> - if (ipw_queue_space(q) < q->high_mark)
> + if (ipw_tx_queue_space(q) < q->high_mark)
> netif_stop_queue(priv->net_dev);
>
> return NETDEV_TX_OK;
> @@ -10357,7 +10385,7 @@ static int
> ipw_net_is_queue_full(struct net_device *dev, int pri)
> struct clx2_tx_queue *txq = &priv->txq[0];
> #endif /* CONFIG_IPW2200_QOS */
>
> - if (ipw_queue_space(&txq->q) < txq->q.high_mark)
> + if (ipw_tx_queue_space(&txq->q) < txq->q.high_mark)
return 1;
>
> return 0;
> diff --git a/drivers/net/wireless/ipw2200.h
> b/drivers/net/wireless/ipw2200.h
> index fdc187e..72884e2 100644
> --- a/drivers/net/wireless/ipw2200.h
> +++ b/drivers/net/wireless/ipw2200.h
> @@ -719,7 +719,6 @@ struct ipw_rx_mem_buffer {
> struct ipw_rx_queue {
> struct ipw_rx_mem_buffer pool[RX_QUEUE_SIZE + RX_FREE_BUFFERS];
> struct ipw_rx_mem_buffer *queue[RX_QUEUE_SIZE];
> - u32 processed; /* Internal index to last
> handled Rx packet */
> u32 read; /* Shared index to newest
> available Rx buffer */
> u32 write; /* Shared index to oldest
> written Rx packet */
> u32 free_count; /* Number of pre-allocated
> buffers in rx_free */
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-wireless" in the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html

2008-02-04 22:45:08

by Sebastian Siewior

[permalink] [raw]

Subject: Re: ipw2200 stalls on high load

2008-02-05 08:35:19

by Sebastian Siewior

[permalink] [raw]

Subject: Re: ipw2200 stalls on high load

* Dan Williams | 2008-02-04 18:24:10 [-0500]:

>Could you put some debugging information into ipw_rx() to print out the
>values of r and i right before the while (i != r) loop, and inside the
>if (fill_rx) block later down what count and i are?
Sure:

[ 1849.374846] Before while 0x0000001c != 0x0000001d
[ 1849.378151] Before while 0x0000001d != 0x0000001e
[ 1849.378970] Before while 0x0000001e != 0x0000001f
[ 1849.381220] Before while 0x0000001f != 0x00000000
[ 1849.383092] Before while 0x00000000 != 0x00000001
[ 1849.385513] Before while 0x00000001 != 0x00000002
[ 1849.387636] Before while 0x00000002 != 0x00000003
[ 1849.389580] Before while 0x00000003 != 0x00000004
[ 1849.391561] Before while 0x00000004 != 0x00000005
[ 1849.393720] Before while 0x00000005 != 0x00000006
[ 1849.395799] Before while 0x00000006 != 0x00000007
[ 1849.397941] Before while 0x00000007 != 0x00000008
[ 1849.399885] Before while 0x00000008 != 0x00000009
[ 1849.402127] Before while 0x00000009 != 0x0000000a
[ 1849.405144] Before while 0x0000000a != 0x0000000b
[ 1849.406376] Before while 0x0000000b != 0x0000000c
[ 1849.409953] Before while 0x0000000c != 0x0000000d
[ 1849.410070] fill_rx block, count: 0x00000000 i: 0x0000000d
[ 1849.410492] Before while 0x0000000d != 0x0000000e
[ 1849.410610] fill_rx block, count: 0x00000000 i: 0x0000000e
[ 1849.412598] Before while 0x0000000e != 0x0000000f
[ 1849.412716] fill_rx block, count: 0x00000000 i: 0x0000000f
[ 1849.414930] Before while 0x0000000f != 0x00000010
[ 1849.415048] fill_rx block, count: 0x00000000 i: 0x00000010
[ 1849.417127] Before while 0x00000010 != 0x00000011
[ 1849.417244] fill_rx block, count: 0x00000000 i: 0x00000011
[ 1849.419324] Before while 0x00000011 != 0x00000012
[ 1849.419441] fill_rx block, count: 0x00000000 i: 0x00000012
[ 1849.421367] Before while 0x00000012 != 0x00000013
[ 1849.421486] fill_rx block, count: 0x00000000 i: 0x00000013
[ 1849.423275] Before while 0x00000013 != 0x00000014
[ 1849.423392] fill_rx block, count: 0x00000000 i: 0x00000014
[ 1849.425472] Before while 0x00000014 != 0x00000015
[ 1849.425591] fill_rx block, count: 0x00000000 i: 0x00000015
[ 1849.427461] Before while 0x00000015 != 0x00000016
[ 1849.427579] fill_rx block, count: 0x00000000 i: 0x00000016
[ 1849.429440] Before while 0x00000016 != 0x00000017
[ 1849.429557] fill_rx block, count: 0x00000000 i: 0x00000017
[ 1849.431618] Before while 0x00000017 != 0x00000018
[ 1849.431736] fill_rx block, count: 0x00000000 i: 0x00000018
[ 1849.434472] Before while 0x00000018 != 0x00000019
[ 1849.434590] fill_rx block, count: 0x00000000 i: 0x00000019
[ 854.288510] ipw2200: Firmware error detected. Restarting.
[ 1109.987456] Before while 0x00000000 != 0x00000001
[ 854.530339] Before while 0x00000001 != 0x00000002
[ 854.566437] Before while 0x00000002 != 0x00000003
[ 854.596029] Before while 0x00000003 != 0x00000004
[ 854.620725] Before while 0x00000004 != 0x00000005
[ 854.621141] Before while 0x00000005 != 0x00000006
[ 854.621189] Before while 0x00000006 != 0x00000007
[ 854.633339] Before while 0x00000007 != 0x00000008
[ 854.634229] Before while 0x00000008 != 0x00000009
[ 854.639772] Before while 0x00000009 != 0x0000000a
[ 854.639812] Before while 0x0000000a != 0x0000000b
[ 854.674365] Before while 0x0000000b != 0x0000000c
[ 854.697891] Before while 0x0000000c != 0x0000000d
[ 854.721436] Before while 0x0000000d != 0x0000000e
[ 854.744974] Before while 0x0000000e != 0x0000000f
[ 854.768516] Before while 0x0000000f != 0x00000010
[ 854.792058] Before while 0x00000010 != 0x00000011
[ 854.816046] Before while 0x00000011 != 0x00000012
[ 854.816127] Before while 0x00000012 != 0x00000013
[ 854.816172] Before while 0x00000013 != 0x00000014
[ 854.816688] Before while 0x00000014 != 0x00000015
[ 854.857375] Before while 0x00000015 != 0x00000016
[ 855.047194] Before while 0x00000016 != 0x00000017
[ 855.048013] Before while 0x00000017 != 0x00000018

I'm not sure why the timestamps aren't incrementing.

>Also, what's the procedure to reproduce this again? I couldn't get that
>bit to trigger but I wasn't really sure what to do to stress the 2200
>that far, otherwise I could have tested the patch more before posting.

I did not get this when do something like:
| ssh box 'cat /dev/zero' > /dev/null

but it works fine with a firefox download from the same machine. It was
triggered after a download of 22.9 MiB at rate of about 664 KiB (this is
what the download window says).

>Thanks,
>Dan

Sebastian

2008-02-04 12:37:48

by Dan Williams

[permalink] [raw]

Subject: RE: ipw2200 stalls on high load

On Fri, 2008-02-01 at 14:29 -0800, Chatre, Reinette wrote:
> On , Sebastian Siewior wrote:
>
> > * Chatre, Reinette | 2008-01-28 10:40:16 [-0800]:
> >
> >> On ,Sebastian Siewior wrote:
> >>
> >>> Hello,
> >>>
> >>> my wireless connection stalls after like 5 seconds once the
> >>> downloading performance passes around 600 KiB/sec. I noticed in
> >>> dmesg the following:
> >>>> ipw2200: Firmware error detected. Restarting.
> >>
> >> Could you please submit a bug at http://www.bughost.org to enable us
> >> to track this problem?
> > Sure. #1487 looks very close. The firmware version seems to be
> > different as well as the "the driver messsage". Do you want me to
> > open a new one or should I follow-up?
>
> This bug may be similar to the bug that was fixed for the 3945 and 4965.
> See the patch "iwlwifi: fix ucode assertion for RX queue overrun" for
> these drivers. We need somebody to port this change to the ipw2200.
> Recently there has also been talk about these issues on the
> ipw3945-devel mailing list.

Something like the following? Turns out the rxq->processed isn't really
used that much, and 3945/4965 don't use that field at all (but use
->read exclusively instead). And since it appears that the replenish
function is simpler in the 2200, it doesn't need to be split like
3945/4965. I haven't been able to stress my 2200 enough to trigger the
new codepath though.

diff --git a/drivers/net/wireless/ipw2200.c b/drivers/net/wireless/ipw2200.c
index 3e6ad7b..8856eea 100644
--- a/drivers/net/wireless/ipw2200.c
+++ b/drivers/net/wireless/ipw2200.c
@@ -3365,7 +3365,6 @@ static void ipw_rx_queue_reset(struct ipw_priv *priv,
/* Set us so that we have processed and used all buffers, but have
* not restocked the Rx queue with fresh buffers */
rxq->read = rxq->write = 0;
- rxq->processed = RX_QUEUE_SIZE - 1;
rxq->free_count = 0;
spin_unlock_irqrestore(&rxq->lock, flags);
}
@@ -3607,7 +3606,22 @@ static int ipw_load(struct ipw_priv *priv)
* Driver allocates buffers of this size for Rx
*/

-static inline int ipw_queue_space(const struct clx2_queue *q)
+/**
+ * ipw_rx_queue_space - Return number of free slots available in queue.
+ */
+static int ipw_rx_queue_space(const struct ipw_rx_queue *q)
+{
+ int s = q->read - q->write;
+ if (s <= 0)
+ s += RX_QUEUE_SIZE;
+ /* keep some buffer to not confuse full and empty queue */
+ s -= 2;
+ if (s < 0)
+ s = 0;
+ return s;
+}
+
+static inline int ipw_tx_queue_space(const struct clx2_queue *q)
{
int s = q->last_used - q->first_empty;
if (s <= 0)
@@ -4947,7 +4961,7 @@ static int ipw_queue_tx_reclaim(struct ipw_priv *priv,
priv->tx_packets++;
}
done:
- if ((ipw_queue_space(q) > q->low_mark) &&
+ if ((ipw_tx_queue_space(q) > q->low_mark) &&
(qindex >= 0) &&
(priv->status & STATUS_ASSOCIATED) && netif_running(priv->net_dev))
netif_wake_queue(priv->net_dev);
@@ -4965,7 +4979,7 @@ static int ipw_queue_tx_hcmd(struct ipw_priv *priv, int hcmd, void *buf,
struct clx2_queue *q = &txq->q;
struct tfd_frame *tfd;

- if (ipw_queue_space(q) < (sync ? 1 : 2)) {
+ if (ipw_tx_queue_space(q) < (sync ? 1 : 2)) {
IPW_ERROR("No space for Tx\n");
return -EBUSY;
}
@@ -5070,7 +5084,7 @@ static void ipw_rx_queue_restock(struct ipw_priv *priv)

spin_lock_irqsave(&rxq->lock, flags);
write = rxq->write;
- while ((rxq->write != rxq->processed) && (rxq->free_count)) {
+ while ((ipw_rx_queue_space(rxq) > 0) && (rxq->free_count)) {
element = rxq->rx_free.next;
rxb = list_entry(element, struct ipw_rx_mem_buffer, list);
list_del(element);
@@ -5187,7 +5201,6 @@ static struct ipw_rx_queue *ipw_rx_queue_alloc(struct ipw_priv *priv)
/* Set us so that we have processed and used all buffers, but have
* not restocked the Rx queue with fresh buffers */
rxq->read = rxq->write = 0;
- rxq->processed = RX_QUEUE_SIZE - 1;
rxq->free_count = 0;

return rxq;
@@ -8223,13 +8236,18 @@ static void ipw_rx(struct ipw_priv *priv)
struct ieee80211_hdr_4addr *header;
u32 r, w, i;
u8 network_packet;
+ u8 fill_rx = 0;
+ u32 count = 0;
DECLARE_MAC_BUF(mac);
DECLARE_MAC_BUF(mac2);
DECLARE_MAC_BUF(mac3);

r = ipw_read32(priv, IPW_RX_READ_INDEX);
w = ipw_read32(priv, IPW_RX_WRITE_INDEX);
- i = (priv->rxq->processed + 1) % RX_QUEUE_SIZE;
+ i = priv->rxq->read;
+
+ if (ipw_rx_queue_space (priv->rxq) > (RX_QUEUE_SIZE / 2))
+ fill_rx = 1;

while (i != r) {
rxb = priv->rxq->queue[i];
@@ -8404,11 +8422,21 @@ static void ipw_rx(struct ipw_priv *priv)
list_add_tail(&rxb->list, &priv->rxq->rx_used);

i = (i + 1) % RX_QUEUE_SIZE;
+
+ /* If there are a lot of unsued frames, restock the Rx queue
+ * so the ucode won't assert */
+ if (fill_rx) {
+ count++;
+ if (count >= 8) {
+ priv->rxq->read = i;
+ ipw_rx_queue_replenish(priv);
+ count = 0;
+ }
+ }
}

/* Backtrack one entry */
- priv->rxq->processed = (i ? i : RX_QUEUE_SIZE) - 1;
-
+ priv->rxq->read = i;
ipw_rx_queue_restock(priv);
}

@@ -10336,7 +10364,7 @@ static int ipw_tx_skb(struct ipw_priv *priv, struct ieee80211_txb *txb,
q->first_empty = ipw_queue_inc_wrap(q->first_empty, q->n_bd);
ipw_write32(priv, q->reg_w, q->first_empty);

- if (ipw_queue_space(q) < q->high_mark)
+ if (ipw_tx_queue_space(q) < q->high_mark)
netif_stop_queue(priv->net_dev);

return NETDEV_TX_OK;
@@ -10357,7 +10385,7 @@ static int ipw_net_is_queue_full(struct net_device *dev, int pri)
struct clx2_tx_queue *txq = &priv->txq[0];
#endif /* CONFIG_IPW2200_QOS */

- if (ipw_queue_space(&txq->q) < txq->q.high_mark)
+ if (ipw_tx_queue_space(&txq->q) < txq->q.high_mark)
return 1;

return 0;
diff --git a/drivers/net/wireless/ipw2200.h b/drivers/net/wireless/ipw2200.h
index fdc187e..72884e2 100644
--- a/drivers/net/wireless/ipw2200.h
+++ b/drivers/net/wireless/ipw2200.h
@@ -719,7 +719,6 @@ struct ipw_rx_mem_buffer {
struct ipw_rx_queue {
struct ipw_rx_mem_buffer pool[RX_QUEUE_SIZE + RX_FREE_BUFFERS];
struct ipw_rx_mem_buffer *queue[RX_QUEUE_SIZE];
- u32 processed; /* Internal index to last handled Rx packet */
u32 read; /* Shared index to newest available Rx buffer */
u32 write; /* Shared index to oldest written Rx packet */
u32 free_count; /* Number of pre-allocated buffers in rx_free */

2008-02-05 15:09:36

by Dan Williams

[permalink] [raw]

Subject: Re: ipw2200 stalls on high load

On Tue, 2008-02-05 at 09:35 +0100, Sebastian Siewior wrote:
> * Dan Williams | 2008-02-04 18:24:10 [-0500]:
>
> >Could you put some debugging information into ipw_rx() to print out the
> >values of r and i right before the while (i != r) loop, and inside the
> >if (fill_rx) block later down what count and i are?
> Sure:
>
> [ 1849.374846] Before while 0x0000001c != 0x0000001d
> [ 1849.378151] Before while 0x0000001d != 0x0000001e
> [ 1849.378970] Before while 0x0000001e != 0x0000001f
> [ 1849.381220] Before while 0x0000001f != 0x00000000
> [ 1849.383092] Before while 0x00000000 != 0x00000001
> [ 1849.385513] Before while 0x00000001 != 0x00000002
> [ 1849.387636] Before while 0x00000002 != 0x00000003
> [ 1849.389580] Before while 0x00000003 != 0x00000004
> [ 1849.391561] Before while 0x00000004 != 0x00000005
> [ 1849.393720] Before while 0x00000005 != 0x00000006
> [ 1849.395799] Before while 0x00000006 != 0x00000007
> [ 1849.397941] Before while 0x00000007 != 0x00000008
> [ 1849.399885] Before while 0x00000008 != 0x00000009
> [ 1849.402127] Before while 0x00000009 != 0x0000000a
> [ 1849.405144] Before while 0x0000000a != 0x0000000b
> [ 1849.406376] Before while 0x0000000b != 0x0000000c
> [ 1849.409953] Before while 0x0000000c != 0x0000000d
> [ 1849.410070] fill_rx block, count: 0x00000000 i: 0x0000000d
> [ 1849.410492] Before while 0x0000000d != 0x0000000e
> [ 1849.410610] fill_rx block, count: 0x00000000 i: 0x0000000e
> [ 1849.412598] Before while 0x0000000e != 0x0000000f
> [ 1849.412716] fill_rx block, count: 0x00000000 i: 0x0000000f
> [ 1849.414930] Before while 0x0000000f != 0x00000010
> [ 1849.415048] fill_rx block, count: 0x00000000 i: 0x00000010
> [ 1849.417127] Before while 0x00000010 != 0x00000011
> [ 1849.417244] fill_rx block, count: 0x00000000 i: 0x00000011
> [ 1849.419324] Before while 0x00000011 != 0x00000012
> [ 1849.419441] fill_rx block, count: 0x00000000 i: 0x00000012
> [ 1849.421367] Before while 0x00000012 != 0x00000013
> [ 1849.421486] fill_rx block, count: 0x00000000 i: 0x00000013
> [ 1849.423275] Before while 0x00000013 != 0x00000014
> [ 1849.423392] fill_rx block, count: 0x00000000 i: 0x00000014
> [ 1849.425472] Before while 0x00000014 != 0x00000015
> [ 1849.425591] fill_rx block, count: 0x00000000 i: 0x00000015
> [ 1849.427461] Before while 0x00000015 != 0x00000016
> [ 1849.427579] fill_rx block, count: 0x00000000 i: 0x00000016
> [ 1849.429440] Before while 0x00000016 != 0x00000017
> [ 1849.429557] fill_rx block, count: 0x00000000 i: 0x00000017
> [ 1849.431618] Before while 0x00000017 != 0x00000018
> [ 1849.431736] fill_rx block, count: 0x00000000 i: 0x00000018
> [ 1849.434472] Before while 0x00000018 != 0x00000019
> [ 1849.434590] fill_rx block, count: 0x00000000 i: 0x00000019
> [ 854.288510] ipw2200: Firmware error detected. Restarting.
> [ 1109.987456] Before while 0x00000000 != 0x00000001
> [ 854.530339] Before while 0x00000001 != 0x00000002
> [ 854.566437] Before while 0x00000002 != 0x00000003
> [ 854.596029] Before while 0x00000003 != 0x00000004
> [ 854.620725] Before while 0x00000004 != 0x00000005
> [ 854.621141] Before while 0x00000005 != 0x00000006
> [ 854.621189] Before while 0x00000006 != 0x00000007
> [ 854.633339] Before while 0x00000007 != 0x00000008
> [ 854.634229] Before while 0x00000008 != 0x00000009
> [ 854.639772] Before while 0x00000009 != 0x0000000a
> [ 854.639812] Before while 0x0000000a != 0x0000000b
> [ 854.674365] Before while 0x0000000b != 0x0000000c
> [ 854.697891] Before while 0x0000000c != 0x0000000d
> [ 854.721436] Before while 0x0000000d != 0x0000000e
> [ 854.744974] Before while 0x0000000e != 0x0000000f
> [ 854.768516] Before while 0x0000000f != 0x00000010
> [ 854.792058] Before while 0x00000010 != 0x00000011
> [ 854.816046] Before while 0x00000011 != 0x00000012
> [ 854.816127] Before while 0x00000012 != 0x00000013
> [ 854.816172] Before while 0x00000013 != 0x00000014
> [ 854.816688] Before while 0x00000014 != 0x00000015
> [ 854.857375] Before while 0x00000015 != 0x00000016
> [ 855.047194] Before while 0x00000016 != 0x00000017
> [ 855.048013] Before while 0x00000017 != 0x00000018
>
> I'm not sure why the timestamps aren't incrementing.

This seems to indicate that on your machine ipw_rx() is only ever called
for one packet, i.e. the firmware never seems to write more than one
packet into the ring buffer for the host to read, or maybe the host is
fast enough that it can process each interrupt.

That would mean that count never gets above 8, and that the RX queue is
never restocked. The (count >= 8) part might be specific to the
3945/4965 drivers, since they apparently restock the RX queue in blocks
of 8. Can you try to change the:

if (count >= 8)

to

if (count)

and see what that does for you? Also, can you log the value of
"ipw_rx_queue_space (priv->rxq)" on the same line as your "fill_rx
block" printk?

Thanks!
Dan

> >Also, what's the procedure to reproduce this again? I couldn't get that
> >bit to trigger but I wasn't really sure what to do to stress the 2200
> >that far, otherwise I could have tested the patch more before posting.
>
> I did not get this when do something like:
> | ssh box 'cat /dev/zero' > /dev/null
>
> but it works fine with a firefox download from the same machine. It was
> triggered after a download of 22.9 MiB at rate of about 664 KiB (this is
> what the download window says).
>
> >Thanks,
> >Dan
>
> Sebastian

2008-02-06 04:57:06

by Dan Williams

[permalink] [raw]

Subject: Re: ipw2200 stalls on high load

On Wed, 2008-02-06 at 00:53 +0100, Sebastian Siewior wrote:
> * Dan Williams | 2008-02-05 10:09:14 [-0500]:
>
> >That would mean that count never gets above 8, and that the RX queue is
> >never restocked. The (count >= 8) part might be specific to the
> >3945/4965 drivers, since they apparently restock the RX queue in blocks
> >of 8. Can you try to change the:
> >
> >if (count >= 8)
> >
> >to
> >
> >if (count)
> >
> >and see what that does for you? Also, can you log the value of
> >"ipw_rx_queue_space (priv->rxq)" on the same line as your "fill_rx
> >block" printk?
>
> This gives the following from time to time:
> | [ 3327.863414] fill_rx block, count: 0x00000000 i: 0x0000000e, ipw_rx_queue_space: 0x00000011
> | [ 3329.704780] fill_rx block, count: 0x00000000 i: 0x00000003, ipw_rx_queue_space: 0x00000011
> | [ 3331.532242] fill_rx block, count: 0x00000000 i: 0x0000001a, ipw_rx_queue_space: 0x00000011
> | [ 3333.306232] fill_rx block, count: 0x00000000 i: 0x00000009, ipw_rx_queue_space: 0x00000011
> | [ 3335.062033] fill_rx block, count: 0x00000000 i: 0x00000018, ipw_rx_queue_space: 0x00000011
> | [ 3336.983284] fill_rx block, count: 0x00000000 i: 0x0000000e, ipw_rx_queue_space: 0x00000011
> | [ 3338.792414] fill_rx block, count: 0x00000000 i: 0x00000005, ipw_rx_queue_space: 0x00000011
> | [ 3340.624946] fill_rx block, count: 0x00000000 i: 0x00000012, ipw_rx_queue_space: 0x00000011
> | [ 3343.179358] fill_rx block, count: 0x00000000 i: 0x00000015, ipw_rx_queue_space: 0x00000011
>
> and I had no firmware restart this time. It seems that it got fixed :)
> thx.

Ok, I'll prepare a final patch then.

Thanks,
Dan

2008-02-08 07:50:34

by Sebastian Siewior

[permalink] [raw]

Subject: Re: ipw2200 stalls on high load

* Dan Williams | 2008-02-05 23:56:47 [-0500]:

>Ok, I'll prepare a final patch then.
Okey, thanks for working on that.

>Thanks,
>Dan

Sebastian

2008-02-01 22:38:06

by Reinette Chatre

[permalink] [raw]

Subject: RE: ipw2200 stalls on high load

On , Sebastian Siewior wrote:

> * Chatre, Reinette | 2008-01-28 10:40:16 [-0800]:
>
>> On ,Sebastian Siewior wrote:
>>
>>> Hello,
>>>
>>> my wireless connection stalls after like 5 seconds once the
>>> downloading performance passes around 600 KiB/sec. I noticed in
>>> dmesg the following:
>>>> ipw2200: Firmware error detected. Restarting.
>>
>> Could you please submit a bug at http://www.bughost.org to enable us
>> to track this problem?
> Sure. #1487 looks very close. The firmware version seems to be
> different as well as the "the driver messsage". Do you want me to
> open a new one or should I follow-up?

This bug may be similar to the bug that was fixed for the 3945 and 4965.
See the patch "iwlwifi: fix ucode assertion for RX queue overrun" for
these drivers. We need somebody to port this change to the ipw2200.
Recently there has also been talk about these issues on the
ipw3945-devel mailing list.

Please do add any information you deem important to the bug report.
Please follow the same debug level as the previous comments to that bug.

Unfortunately we are focused on the iwlwifi driver right now - we hope
we get around to this in a reasonable time.

Reinette

2008-02-05 23:53:51

by Sebastian Siewior

[permalink] [raw]

Subject: Re: ipw2200 stalls on high load

* Dan Williams | 2008-02-05 10:09:14 [-0500]:

>That would mean that count never gets above 8, and that the RX queue is
>never restocked. The (count >= 8) part might be specific to the
>3945/4965 drivers, since they apparently restock the RX queue in blocks
>of 8. Can you try to change the:
>
>if (count >= 8)
>
>to
>
>if (count)
>
>and see what that does for you? Also, can you log the value of
>"ipw_rx_queue_space (priv->rxq)" on the same line as your "fill_rx
>block" printk?

This gives the following from time to time:
| [ 3327.863414] fill_rx block, count: 0x00000000 i: 0x0000000e, ipw_rx_queue_space: 0x00000011
| [ 3329.704780] fill_rx block, count: 0x00000000 i: 0x00000003, ipw_rx_queue_space: 0x00000011
| [ 3331.532242] fill_rx block, count: 0x00000000 i: 0x0000001a, ipw_rx_queue_space: 0x00000011
| [ 3333.306232] fill_rx block, count: 0x00000000 i: 0x00000009, ipw_rx_queue_space: 0x00000011
| [ 3335.062033] fill_rx block, count: 0x00000000 i: 0x00000018, ipw_rx_queue_space: 0x00000011
| [ 3336.983284] fill_rx block, count: 0x00000000 i: 0x0000000e, ipw_rx_queue_space: 0x00000011
| [ 3338.792414] fill_rx block, count: 0x00000000 i: 0x00000005, ipw_rx_queue_space: 0x00000011
| [ 3340.624946] fill_rx block, count: 0x00000000 i: 0x00000012, ipw_rx_queue_space: 0x00000011
| [ 3343.179358] fill_rx block, count: 0x00000000 i: 0x00000015, ipw_rx_queue_space: 0x00000011

and I had no firmware restart this time. It seems that it got fixed :)
thx.

Sebastian

2008-02-04 23:24:21

by Dan Williams

[permalink] [raw]

Subject: Re: ipw2200 stalls on high load

On Mon, 2008-02-04 at 23:45 +0100, Sebastian Siewior wrote:
> * Chatre, Reinette | 2008-02-04 10:23:49 [-0800]:
>
> >On Monday, February 04, 2008 4:37 AM, Dan Williams wrote:
> >
> >> Something like the following? Turns out the rxq->processed
> >> isn't really
> >> used that much, and 3945/4965 don't use that field at all (but use
> >> ->read exclusively instead). And since it appears that the replenish
> >> function is simpler in the 2200, it doesn't need to be split like
> >> 3945/4965. I haven't been able to stress my 2200 enough to trigger
> >> the new codepath though.
> >
> >Thank you very much!
> Yes, thanks for the patch.
>
> >Sebastian, does this change work for you?
> No, it doesn't. I get the following:

Could you put some debugging information into ipw_rx() to print out the
values of r and i right before the while (i != r) loop, and inside the
if (fill_rx) block later down what count and i are?

Also, what's the procedure to reproduce this again? I couldn't get that
bit to trigger but I wasn't really sure what to do to stress the 2200
that far, otherwise I could have tested the patch more before posting.

Thanks,
Dan

> | ipw2200: Firmware error detected. Restarting.
> | ipw2200: Start IPW Error Log Dump:
> | ipw2200: Status: 0x800000E0, Config: 00000347
> | ipw2200: NMI_INTERRUPT 493005888 0x000003b4 0x00000000 0x00000250 0x0000f420 0x00000000
> | ipw2200: DMA_STATUS 493005892 0x00027980 0x00027740 0x01540002 0x00000000 0x00000000
> | ipw2200: DMA_STATUS 493005895 0x00028400 0x00028670 0x00540001 0x00000000 0x00000001
> | ipw2200: DMA_STATUS 493005899 0x00028000 0x00028190 0x00540001 0x00000000 0x00000002
> | ipw2200: DMA_STATUS 493005903 0x00400000 0x00408000 0x00408000 0x00000087 0x00000003
> | ipw2200: 492475810 0x00000008 50
> | ipw2200: 492475836 0x0000003c 264
> | ipw2200: 492475841 0x0002a9c0 74
> | ipw2200: 492475846 0x00000042 208
> | ipw2200: 492477710 0x00000008 32
> | ipw2200: 492477738 0x00000008 50
> | ipw2200: 492477790 0x0000003c 264
> | ipw2200: 492477796 0x0002a930 74
> | ipw2200: 492477800 0x00000042 208
> | ipw2200: 492479989 0x00000008 32
> | ipw2200: 492480017 0x00000008 50
> | ipw2200: 492480043 0x0000003c 264
> | ipw2200: 492480048 0x0002a990 74
> | ipw2200: 492480053 0x00000042 208
> | ipw2200: 492481989 0x00000008 32
> | ipw2200: 492482017 0x00000008 50
> | ipw2200: 492482051 0x0000003c 264
> | ipw2200: 492482056 0x0002a970 74
> | ipw2200: 492482061 0x00000042 208
> | ipw2200: 492484133 0x00000008 32
> | ipw2200: 492484161 0x00000008 50
> | ipw2200: 492484189 0x0000003c 264
> | ipw2200: 492484194 0x0002a880 74
> | ipw2200: 492484199 0x00000042 208
> | ipw2200: 492498961 0x00000001 198
> | ipw2200: 492499005 0x0002a8e0 67
> | ipw2200: 492499025 0x0000026c 61
> | ipw2200: 492507155 0x00000389 140
> | ipw2200: 492507158 0x00000061 139
> | ipw2200: 492507161 0x00000392 140
> | ipw2200: 492507169 0x00000001 136
> | ipw2200: 492507173 0x0000029c 138
> | ipw2200: 492507177 0x000002ca 138
> | ipw2200: 492507180 0x00000177 84
> | ipw2200: 492507185 0x00000005 81
> | ipw2200: 492507188 0x00000003 82
> | ipw2200: 492507191 0x00000006 83
> | ipw2200: 492507196 0x0000039f 140
> | ipw2200: 492507199 0x00000006 139
> | ipw2200: 492507202 0x000003ad 139
> | ipw2200: 492509617 0x00000001 32
> | ipw2200: 492509620 0x0000023f 179
> | ipw2200: 492509624 0x00000633 140
> | ipw2200: 492509627 0x00000640 140
> | ipw2200: 492509631 0x00000177 84
> | ipw2200: 492509635 0x00000006 81
> | ipw2200: 492509638 0x00000004 82
> | ipw2200: 492509641 0x00000007 83
> | ipw2200: 492509645 0x0000054d 183
> | ipw2200: 492509651 0x00000009 184
> | ipw2200: 492509654 0x00000455 189
> | ipw2200: 492509657 0x00000000 189
> | ipw2200: 492509661 0x00000007 184
> | ipw2200: 492509664 0x00000004 183
> | ipw2200: 492509669 0x0000042b 191
> | ipw2200: 492448433 0x0000003d 264
> | ipw2200: 492448438 0x0002a960 74
> | ipw2200: 492448547 0x000000b1 200
> | ipw2200: 492450315 0x00000008 32
> | ipw2200: 492450343 0x00000008 50
> | ipw2200: 492450369 0x0000003d 264
> | ipw2200: 492450374 0x0002a9e0 74
> | ipw2200: 492450483 0x000000b1 200
> | ipw2200: 492452305 0x00000008 32
> | ipw2200: 492452333 0x00000008 50
> | ipw2200: 492452359 0x0000003d 264
> | ipw2200: 492452364 0x0002a9a0 74
> | ipw2200: 492452473 0x000000b1 200
> | ipw2200: 492454503 0x00000008 32
> | ipw2200: 492454531 0x00000008 50
> | ipw2200: 492454557 0x0000003d 264
> | ipw2200: 492454562 0x0002a960 74
> | ipw2200: 492454671 0x000000b1 200
> | ipw2200: 492456782 0x00000008 32
> | ipw2200: 492456810 0x00000008 50
> | ipw2200: 492456836 0x0000003d 264
> | ipw2200: 492456841 0x0002a9e0 74
> | ipw2200: 492456950 0x000000b1 200
> | ipw2200: 492458746 0x00000008 32
> | ipw2200: 492458774 0x00000008 50
> | ipw2200: 492458800 0x0000003d 264
> | ipw2200: 492458805 0x0002a9a0 74
> | ipw2200: 492458914 0x000000b1 200
> | ipw2200: 492459161 0x00000001 198
> | ipw2200: 492459201 0x0002a8e0 67
> | ipw2200: 492459221 0x0000026c 61
> | ipw2200: 492459341 0x00000008 32
> | ipw2200: 492459352 0x0000000b 35
> | ipw2200: 492459356 0x0000000b 24
> | ipw2200: 492459365 0x00000172 25
> | ipw2200: 492459369 0x0002a8e0 98
> | ipw2200: 492461603 0x00000008 32
> | ipw2200: 492461631 0x00000008 50
> | ipw2200: 492461657 0x0000003c 264
> | ipw2200: 492461662 0x0002a990 74
> | ipw2200: 492461771 0x000000b1 200
> | ipw2200: 492463197 0x00000008 32
> | ipw2200: 492463225 0x00000008 50
> | ipw2200: 492463251 0x0000003c 264
> | ipw2200: 492463256 0x0002a9c0 74
> | ipw2200: 492463365 0x000000b1 200
> | ipw2200: 492465224 0x00000008 32
> | ipw2200: 492465252 0x00000008 50
> | ipw2200: 492465290 0x0000003c 264
> | ipw2200: 492465296 0x0002a930 74
> | ipw2200: 492465404 0x000000b1 200
> | ipw2200: 492467359 0x00000008 32
> | ipw2200: 492467387 0x00000008 50
> | ipw2200: 492467413 0x0000003c 264
> | ipw2200: 492467418 0x0002a990 74
> | ipw2200: 492467527 0x000000b1 200
> | ipw2200: 492469413 0x00000008 32
> | ipw2200: 492469441 0x00000008 50
> | ipw2200: 492469467 0x0000003c 264
> | ipw2200: 492469472 0x0002a9c0 74
> | ipw2200: 492469581 0x000000b1 200
> | ipw2200: 492471611 0x00000008 32
> | ipw2200: 492471639 0x00000008 50
> | ipw2200: 492471665 0x0000003c 264
> | ipw2200: 492471670 0x0002a930 74
> | ipw2200: 492471779 0x000000b1 200
> | ipw2200: 492473854 0x00000008 32
> | ipw2200: 492473882 0x00000008 50
> | ipw2200: 492473908 0x0000003c 264
> | ipw2200: 492473913 0x0002a990 74
> | ipw2200: 492474022 0x000000b1 200
> | ipw2200: 492474164 0x00000042 208
> | ipw2200: 492475782 0x00000008 32
> | ipw2200: U ipw_load initial device response after 10ms
> | ipw2200: U ipw_stop_master stop master 0ms
> | ipw2200: U ipw_load_ucode Microcode OK, rev. 53594 (0xd15a) dev. 3 (0x3) of 11/22/04 20:27
> | ipw2200: U ipw_load device response after 50ms
>
> I can provide you a full log if you want.
> >Reinette
> >
>
> Sebastian