mac80211 deadlock detection triggering with rt61pci

mac80211 deadlock detection triggering with rt61pci

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 367 bytes --]

Hi Ivo,

I'm not sure whether this still happens in current versions or not, but
kerneloops is reporting a number of mac80211 warnings due to the TX
deadlock detection:
http://www.kerneloops.org/searchweek.php?search=ieee80211_master_start_xmit

The rt2x00 mac code seems fine, did it change recently which could
explain this warning triggering?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: mac80211 deadlock detection triggering with rt61pci

[Ivo van Doorn]

Hi,

> I'm not sure whether this still happens in current versions or not, but
> kerneloops is reporting a number of mac80211 warnings due to the TX
> deadlock detection:
> http://www.kerneloops.org/searchweek.php?search=ieee80211_master_start_xmit
> 
> The rt2x00 mac code seems fine, did it change recently which could
> explain this warning triggering?

Interesting, the TX code did change for 2.6.27 recently with the DMA changes
by GertJan, I think the Fedora kernels which are showing the above panics already
contain those patches,

John, Does Fedora kernel 2.6.25.10-86.fc9.x86_64 contain rt2x00 2.1.8?

I also have some reports about a queue corruption in rt61pci and although I haven't
figured out how that corruption is caused, I do think the above panics might somehow
be related.

Thanks for the report,

Ivo

Re: mac80211 deadlock detection triggering with rt61pci

[Ivo van Doorn]

On Friday 18 July 2008, Ivo van Doorn wrote:
> Hi,
> 
> > I'm not sure whether this still happens in current versions or not, but
> > kerneloops is reporting a number of mac80211 warnings due to the TX
> > deadlock detection:
> > http://www.kerneloops.org/searchweek.php?search=ieee80211_master_start_xmit
> > 
> > The rt2x00 mac code seems fine, did it change recently which could
> > explain this warning triggering?
> 
> Interesting, the TX code did change for 2.6.27 recently with the DMA changes
> by GertJan, I think the Fedora kernels which are showing the above panics already
> contain those patches,
> 
> John, Does Fedora kernel 2.6.25.10-86.fc9.x86_64 contain rt2x00 2.1.8?
> 
> I also have some reports about a queue corruption in rt61pci and although I haven't
> figured out how that corruption is caused, I do think the above panics might somehow
> be related.

It might be me, but looking at those traces, aren't they triggered by:

static int ieee80211_tx(struct net_device *dev, struct sk_buff *skb)
{
...
		if (WARN_ON(queue >= ieee80211_num_regular_queues(&local->hw)))
			goto drop;
...
}

Which would suggest that when MAC80211_QOS is disabled, the skb_queue_mapping
still returns something higher then 1.

Ivo

Re: mac80211 deadlock detection triggering with rt61pci

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 555 bytes --]

On Sat, 2008-07-19 at 16:47 +0200, Ivo van Doorn wrote:
> On Friday 18 July 2008, Ivo van Doorn wrote:

> It might be me, but looking at those traces, aren't they triggered by:
> 
> static int ieee80211_tx(struct net_device *dev, struct sk_buff *skb)
> {
> ...
> 		if (WARN_ON(queue >= ieee80211_num_regular_queues(&local->hw)))
> 			goto drop;
> ...
> }
> 
> Which would suggest that when MAC80211_QOS is disabled, the skb_queue_mapping
> still returns something higher then 1.

Oh, interesting, could be, I'll check it out.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: mac80211 deadlock detection triggering with rt61pci

[Ivo van Doorn]

On Saturday 19 July 2008, Johannes Berg wrote:
> On Sat, 2008-07-19 at 16:47 +0200, Ivo van Doorn wrote:
> > On Friday 18 July 2008, Ivo van Doorn wrote:
> 
> > It might be me, but looking at those traces, aren't they triggered by:
> > 
> > static int ieee80211_tx(struct net_device *dev, struct sk_buff *skb)
> > {
> > ...
> > 		if (WARN_ON(queue >= ieee80211_num_regular_queues(&local->hw)))
> > 			goto drop;
> > ...
> > }
> > 
> > Which would suggest that when MAC80211_QOS is disabled, the skb_queue_mapping
> > still returns something higher then 1.
> 
> Oh, interesting, could be, I'll check it out.

I think I was wrong, just received a report which indeed marked the line:
	if (WARN_ON_ONCE(retries > 5))

recent mac80211 patches had moved the WARN_ON line more then I thought. ;)

In any case, I am still not sure why this bug is being triggered, but I am following a lead
with the rt2x00 errors that come directly before the WARN_ON is being triggered.

Ivo