ipw2200 stalls on high load

ipw2200 stalls on high load

[Sebastian Siewior]

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

RE: ipw2200 stalls on high load

[Chatre, Reinette]

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

Re: ipw2200 stalls on high load

[Sebastian Siewior]

* 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

RE: ipw2200 stalls on high load

[Chatre, Reinette]

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

RE: ipw2200 stalls on high load

[Dan Williams]

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 */

RE: ipw2200 stalls on high load

[Chatre, Reinette]

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ipw2200 stalls on high load

[Sebastian Siewior]

* 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:

| 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

Re: ipw2200 stalls on high load

[Dan Williams]

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

Re: ipw2200 stalls on high load

[Sebastian Siewior]

* 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

Re: ipw2200 stalls on high load

[Dan Williams]

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

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

[Cahill, Ben M]

> 
> 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 --

Re: ipw2200 stalls on high load

[Sebastian Siewior]

* 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

Re: ipw2200 stalls on high load

[Dan Williams]

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

Re: ipw2200 stalls on high load

[Sebastian Siewior]

* 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

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

[Cahill, Ben M]

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: ipw2100-devel-bounces@lists.sourceforge.net 
> [mailto:ipw2100-devel-bounces@lists.sourceforge.net] On 
> Behalf Of Sebastian Siewior
> Sent: Saturday, January 26, 2008 8:30 AM
> To: Zhu, Yi; James Ketrenos
> Cc: ipw2100-devel@lists.sourceforge.net; 
> linux-wireless@vger.kernel.org
> 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
> ipw2100-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ipw2100-devel
> 

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

[Sebastian Siewior]

* 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

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

[Sebastian Siewior]

* 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