* b43/mac80211: RX rate_idx warning triggers
@ 2009-02-24 14:14 Michael Buesch
2009-02-27 17:19 ` Johannes Berg
0 siblings, 1 reply; 3+ messages in thread
From: Michael Buesch @ 2009-02-24 14:14 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
Any idea why this could happen?
[ 2860.155778] Badness at net/mac80211/rx.c:2488
[ 2860.155782] NIP: f2797fdc LR: f2784528 CTR: 00000000
[ 2860.155787] REGS: eeaf3d60 TRAP: 0700 Not tainted (2.6.29-rc5-wl-wltest)
[ 2860.155791] MSR: 00029032 <EE,ME,CE,IR,DR> CR: 22000446 XER: 20000000
[ 2860.155804] TASK = eea92d00[2771] 'Xorg' THREAD: eeaf2000
[ 2860.155807] GPR00: 00000001 eeaf3e10 eea92d00 edde9220 edc1a9c0 eeaf3e48 eeaf3e6c 000000ff
[ 2860.155818] GPR08: 00000002 000000ff 00000000 f2a30274 42000442 101f3d44 00000000 00000000
[ 2860.155829] GPR16: 0000029e 00000199 00000240 5168a060 00000099 c07d47cc 00000000 c09458c0
[ 2860.155839] GPR24: c09458c0 f27ade88 edde93d0 edde9220 eeaf3e48 edde93b4 edc1a9c0 edc1a9c0
[ 2860.155909] NIP [f2797fdc] __ieee80211_rx+0x8c/0x690 [mac80211]
[ 2860.155921] LR [f2784528] ieee80211_tasklet_handler+0x114/0x130 [mac80211]
[ 2860.155925] Call Trace:
[ 2860.155929] [eeaf3e10] [edde93c0] 0xedde93c0 (unreliable)
[ 2860.155942] [eeaf3e40] [f2784528] ieee80211_tasklet_handler+0x114/0x130 [mac80211]
[ 2860.155954] [eeaf3ea0] [c003e85c] tasklet_action+0x80/0x100
[ 2860.155961] [eeaf3ec0] [c003f240] __do_softirq+0x90/0x128
[ 2860.155970] [eeaf3f00] [c0006f74] do_softirq+0x58/0x5c
[ 2860.155975] [eeaf3f10] [c003f118] irq_exit+0x8c/0xb8
[ 2860.155980] [eeaf3f20] [c0007028] do_IRQ+0xb0/0xec
[ 2860.155988] [eeaf3f40] [c00171a8] ret_from_except+0x0/0x14
[ 2860.155992] --- Exception: 501 at 0xff05c40
[ 2860.155994] LR = 0xf6838e8
[ 2860.155996] Instruction dump:
[ 2860.156001] 80050024 70090200 408200c8 81250020 38000001 2f890000 419c0018 800b0010
[ 2860.156011] 7f890000 4fdce042 7c000026 5400fffe <0f000000> 2f800000 40beff98 55202036
We have the following code in b43:
604 if (phystat0 & B43_RX_PHYST0_OFDM)
605 status.rate_idx = b43_plcp_get_bitrate_idx_ofdm(plcp,
606 phytype == B43_PHYTYPE_A);
607 else
608 status.rate_idx = b43_plcp_get_bitrate_idx_cck(plcp);
609 if (unlikely(status.rate_idx == -1))
610 goto drop;
So IMO the only possible way for the WARN_ON to trigger is
(status->rate_idx >= sband->n_bitrates)
Why is rate_idx bigger than n_bitrates?
--
Greetings, Michael.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: b43/mac80211: RX rate_idx warning triggers
2009-02-24 14:14 b43/mac80211: RX rate_idx warning triggers Michael Buesch
@ 2009-02-27 17:19 ` Johannes Berg
2009-02-27 21:20 ` Michael Buesch
0 siblings, 1 reply; 3+ messages in thread
From: Johannes Berg @ 2009-02-27 17:19 UTC (permalink / raw)
To: Michael Buesch; +Cc: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 2788 bytes --]
On Tue, 2009-02-24 at 15:14 +0100, Michael Buesch wrote:
> Any idea why this could happen?
>
> [ 2860.155778] Badness at net/mac80211/rx.c:2488
> [ 2860.155782] NIP: f2797fdc LR: f2784528 CTR: 00000000
> [ 2860.155787] REGS: eeaf3d60 TRAP: 0700 Not tainted (2.6.29-rc5-wl-wltest)
> [ 2860.155791] MSR: 00029032 <EE,ME,CE,IR,DR> CR: 22000446 XER: 20000000
> [ 2860.155804] TASK = eea92d00[2771] 'Xorg' THREAD: eeaf2000
> [ 2860.155807] GPR00: 00000001 eeaf3e10 eea92d00 edde9220 edc1a9c0 eeaf3e48 eeaf3e6c 000000ff
> [ 2860.155818] GPR08: 00000002 000000ff 00000000 f2a30274 42000442 101f3d44 00000000 00000000
> [ 2860.155829] GPR16: 0000029e 00000199 00000240 5168a060 00000099 c07d47cc 00000000 c09458c0
> [ 2860.155839] GPR24: c09458c0 f27ade88 edde93d0 edde9220 eeaf3e48 edde93b4 edc1a9c0 edc1a9c0
> [ 2860.155909] NIP [f2797fdc] __ieee80211_rx+0x8c/0x690 [mac80211]
> [ 2860.155921] LR [f2784528] ieee80211_tasklet_handler+0x114/0x130 [mac80211]
> [ 2860.155925] Call Trace:
> [ 2860.155929] [eeaf3e10] [edde93c0] 0xedde93c0 (unreliable)
> [ 2860.155942] [eeaf3e40] [f2784528] ieee80211_tasklet_handler+0x114/0x130 [mac80211]
> [ 2860.155954] [eeaf3ea0] [c003e85c] tasklet_action+0x80/0x100
> [ 2860.155961] [eeaf3ec0] [c003f240] __do_softirq+0x90/0x128
> [ 2860.155970] [eeaf3f00] [c0006f74] do_softirq+0x58/0x5c
> [ 2860.155975] [eeaf3f10] [c003f118] irq_exit+0x8c/0xb8
> [ 2860.155980] [eeaf3f20] [c0007028] do_IRQ+0xb0/0xec
> [ 2860.155988] [eeaf3f40] [c00171a8] ret_from_except+0x0/0x14
> [ 2860.155992] --- Exception: 501 at 0xff05c40
> [ 2860.155994] LR = 0xf6838e8
> [ 2860.155996] Instruction dump:
> [ 2860.156001] 80050024 70090200 408200c8 81250020 38000001 2f890000 419c0018 800b0010
> [ 2860.156011] 7f890000 4fdce042 7c000026 5400fffe <0f000000> 2f800000 40beff98 55202036
>
> We have the following code in b43:
>
> 604 if (phystat0 & B43_RX_PHYST0_OFDM)
> 605 status.rate_idx = b43_plcp_get_bitrate_idx_ofdm(plcp,
> 606 phytype == B43_PHYTYPE_A);
> 607 else
> 608 status.rate_idx = b43_plcp_get_bitrate_idx_cck(plcp);
> 609 if (unlikely(status.rate_idx == -1))
> 610 goto drop;
>
> So IMO the only possible way for the WARN_ON to trigger is
> (status->rate_idx >= sband->n_bitrates)
>
> Why is rate_idx bigger than n_bitrates?
Did you ever see this again? It seems weird, since you never return any
value larger than the max afaict. Some form of corruption? Can you make
that warning should print out the entire skb->cb as a hex dump so we can
tell what's in there, and maybe the header of the 802.11 packet as well.
And please submit the patch, it'll be useful :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: b43/mac80211: RX rate_idx warning triggers
2009-02-27 17:19 ` Johannes Berg
@ 2009-02-27 21:20 ` Michael Buesch
0 siblings, 0 replies; 3+ messages in thread
From: Michael Buesch @ 2009-02-27 21:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
On Friday 27 February 2009 18:19:42 Johannes Berg wrote:
> On Tue, 2009-02-24 at 15:14 +0100, Michael Buesch wrote:
> > Any idea why this could happen?
> >
> > [ 2860.155778] Badness at net/mac80211/rx.c:2488
> > [ 2860.155782] NIP: f2797fdc LR: f2784528 CTR: 00000000
> > [ 2860.155787] REGS: eeaf3d60 TRAP: 0700 Not tainted (2.6.29-rc5-wl-wltest)
> > [ 2860.155791] MSR: 00029032 <EE,ME,CE,IR,DR> CR: 22000446 XER: 20000000
> > [ 2860.155804] TASK = eea92d00[2771] 'Xorg' THREAD: eeaf2000
> > [ 2860.155807] GPR00: 00000001 eeaf3e10 eea92d00 edde9220 edc1a9c0 eeaf3e48 eeaf3e6c 000000ff
> > [ 2860.155818] GPR08: 00000002 000000ff 00000000 f2a30274 42000442 101f3d44 00000000 00000000
> > [ 2860.155829] GPR16: 0000029e 00000199 00000240 5168a060 00000099 c07d47cc 00000000 c09458c0
> > [ 2860.155839] GPR24: c09458c0 f27ade88 edde93d0 edde9220 eeaf3e48 edde93b4 edc1a9c0 edc1a9c0
> > [ 2860.155909] NIP [f2797fdc] __ieee80211_rx+0x8c/0x690 [mac80211]
> > [ 2860.155921] LR [f2784528] ieee80211_tasklet_handler+0x114/0x130 [mac80211]
> > [ 2860.155925] Call Trace:
> > [ 2860.155929] [eeaf3e10] [edde93c0] 0xedde93c0 (unreliable)
> > [ 2860.155942] [eeaf3e40] [f2784528] ieee80211_tasklet_handler+0x114/0x130 [mac80211]
> > [ 2860.155954] [eeaf3ea0] [c003e85c] tasklet_action+0x80/0x100
> > [ 2860.155961] [eeaf3ec0] [c003f240] __do_softirq+0x90/0x128
> > [ 2860.155970] [eeaf3f00] [c0006f74] do_softirq+0x58/0x5c
> > [ 2860.155975] [eeaf3f10] [c003f118] irq_exit+0x8c/0xb8
> > [ 2860.155980] [eeaf3f20] [c0007028] do_IRQ+0xb0/0xec
> > [ 2860.155988] [eeaf3f40] [c00171a8] ret_from_except+0x0/0x14
> > [ 2860.155992] --- Exception: 501 at 0xff05c40
> > [ 2860.155994] LR = 0xf6838e8
> > [ 2860.155996] Instruction dump:
> > [ 2860.156001] 80050024 70090200 408200c8 81250020 38000001 2f890000 419c0018 800b0010
> > [ 2860.156011] 7f890000 4fdce042 7c000026 5400fffe <0f000000> 2f800000 40beff98 55202036
> >
> > We have the following code in b43:
> >
> > 604 if (phystat0 & B43_RX_PHYST0_OFDM)
> > 605 status.rate_idx = b43_plcp_get_bitrate_idx_ofdm(plcp,
> > 606 phytype == B43_PHYTYPE_A);
> > 607 else
> > 608 status.rate_idx = b43_plcp_get_bitrate_idx_cck(plcp);
> > 609 if (unlikely(status.rate_idx == -1))
> > 610 goto drop;
> >
> > So IMO the only possible way for the WARN_ON to trigger is
> > (status->rate_idx >= sband->n_bitrates)
> >
> > Why is rate_idx bigger than n_bitrates?
>
> Did you ever see this again? It seems weird, since you never return any
> value larger than the max afaict.
This was the only time I saw this after we patched b43 to not pass -1 anymore.
> Some form of corruption? Can you make
> that warning should print out the entire skb->cb as a hex dump so we can
> tell what's in there, and maybe the header of the 802.11 packet as well.
> And please submit the patch, it'll be useful :)
Yeah, lemme do that. But I can't reproduce it.
--
Greetings, Michael.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-02-27 21:21 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-02-24 14:14 b43/mac80211: RX rate_idx warning triggers Michael Buesch
2009-02-27 17:19 ` Johannes Berg
2009-02-27 21:20 ` Michael Buesch
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).