Hi,
Is there anyone has the same problem with me? I have a cm9 radio card
with the node.
The kernel compiled and booted alright, but crashed short after I set it
up in the ad hoc mode. From the debug message output, it looks like
something wrong with the rate control mechanism when it is trying to the
rate (minstreal_get_rate function in this case).
Is this a bug?
Kernel version
3.10.0-rc7
root@alix-router:~# i[ 250.809354] BUG: unable to handle kernel NULL
pointe8
[ 250.812875] IP: [<d0952afa>] minstrel_get_rate+0x1a/0x220 [mac80211]
[ 250.812875] *pde = 00000000
[ 250.812875] Oops: 0000 [#1] SMP
[ 250.812875] Modules linked in: ath5k ath mac80211 cfg80211 arc4
gpio_cs55]
[ 250.812875] CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted
3.10.0-rc7-cca+ 1
[ 250.812875] Workqueue: phy0 ieee80211_iface_work [mac80211]
[ 250.812875] task: c002bfc0 ti: c0076000 task.ti: c0076000
[ 250.812875] EIP: 0060:[<d0952afa>] EFLAGS: 00010292 CPU: 0
[ 250.812875] EIP is at minstrel_get_rate+0x1a/0x220 [mac80211]
[ 250.812875] EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: cc2bf1c0
[ 250.812875] ESI: ce6cf900 EDI: c0077d00 EBP: c0077cac ESP: c0077c94
[ 250.812875] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 250.812875] CR0: 8005003b CR2: 00000038 CR3: 0c245000 CR4: 00000090
[ 250.812875] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[ 250.812875] DR6: ffff0ff0 DR7: 00000400
[ 250.812875] Stack:
[ 250.812875] 00017901 cc101500 00000180 cc133500 d0967920 cc2bf1e1
c0077cd
[ 250.812875] c0077d00 00000180 ce525170 00000000 cc2bf1e0 c0077d00
cc2bf10
[ 250.812875] c0077d24 c0077d30 d0927651 c02c5550 c0077cec d092001c
cc1335c
[ 250.812875] Call Trace:
[ 250.812875] [<d091a8dd>] rate_control_get_rate+0x9d/0xe0 [mac80211]
[ 250.812875] [<d0927651>] ieee80211_beacon_get_tim+0x1a1/0x330 [mac80211]
[ 250.812875] [<d092001c>] ? ieee80211_assign_beacon+0x1bc/0x1c0
[mac80211]
[ 250.812875] [<d0da3fb9>] ath5k_beacon_update+0x29/0x340 [ath5k]
[ 250.812875] [<d0d99366>] ? ath5k_hw_get_frame_duration+0xa6/0xc0 [ath5k]
[ 250.812875] [<d0d99140>] ? ath5k_hw_set_ifs_intervals+0x110/0x1b0
[ath5k]
[ 250.812875] [<d0da92d3>] ath5k_bss_info_changed+0x113/0x1f0 [ath5k]
[ 250.812875] [<d0da91c0>] ? ath5k_configure_filter+0x1c0/0x1c0 [ath5k]
[ 250.812875] [<d0908903>] ieee80211_bss_info_change_notify+0xc3/0x1c0
[ma]
[ 250.812875] [<d09141db>] ? __ieee80211_sta_join_ibss+0x19b/0x660
[mac802]
[ 250.812875] [<d091442c>] __ieee80211_sta_join_ibss+0x3ec/0x660
[mac80211]
[ 250.812875] [<c157be33>] ? printk+0x4d/0x4f
[ 250.812875] [<d0915b4d>] ieee80211_ibss_work+0x31d/0x3d0 [mac80211]
[ 250.812875] [<d0916d2d>] ieee80211_iface_work+0x18d/0x310 [mac80211]
[ 250.812875] [<c105025f>] process_one_work+0x10f/0x380
[ 250.812875] [<c104e485>] ? start_worker+0x25/0x30
[ 250.812875] [<c1051000>] ? manage_workers.isra.24+0x180/0x290
[ 250.812875] [<c105120a>] worker_thread+0xfa/0x310
[ 250.812875] [<c1051110>] ? manage_workers.isra.24+0x290/0x290
[ 250.812875] [<c1056674>] kthread+0x94/0xa0
[ 250.812875] [<c158b1f7>] ret_from_kernel_thread+0x1b/0x28
[ 250.812875] [<c10565e0>] ? flush_kthread_worker+0x90/0x90
[ 250.812875] Code: 3d fe 93 f0 5d c3 90 90 90 90 90 90 90 90 90 90 90
55 88
[ 250.812875] EIP: [<d0952afa>] minstrel_get_rate+0x1a/0x220 [mac80211]
SS:4
[ 250.812875] CR2: 0000000000000038
[ 250.815950] ---[ end trace 87b8337e77cb6664 ]---
[ 250.817834] Kernel panic - not syncing: Fatal exception in interrupt
--
Regards;
Peizhao
On Mon, Jul 15, 2013 at 11:48:33AM +0200, Felix Fietkau wrote:
> On 2013-07-15 11:35 AM, Krzysztof Mazur wrote:
> > On Mon, Jul 15, 2013 at 11:27:30AM +0200, Krzysztof Mazur wrote:
> >> On Mon, Jul 15, 2013 at 11:06:27AM +0200, Felix Fietkau wrote:
> >> > Please post the actual message output. Saying "it looks like something
> >> > wrong with the rate control mechanism" doesn't give me anything useful
> >> > to work with.
> >> >
> >>
> >> Sorry, I added you to Cc after I removed the original Oops.
> >>
> >
> > On my system the NULL pointer dereference occurs at 0x806389b0,
> > and the minstrel_get_rate() looks like:
> >
> > 80638990 <minstrel_get_rate>:
> > 80638990: 83 ec 1c sub $0x1c,%esp
> > 80638993: 89 7c 24 14 mov %edi,0x14(%esp)
> > 80638997: 8b 7c 24 20 mov 0x20(%esp),%edi
> > 8063899b: 89 5c 24 0c mov %ebx,0xc(%esp)
> > 8063899f: 89 cb mov %ecx,%ebx
> > 806389a1: 89 6c 24 18 mov %ebp,0x18(%esp)
> > 806389a5: 89 c5 mov %eax,%ebp
> > 806389a7: 89 d0 mov %edx,%eax
> > 806389a9: 89 74 24 10 mov %esi,0x10(%esp)
> > 806389ad: 8b 77 0c mov 0xc(%edi),%esi
> > * 806389b0: 0f b6 49 38 movzbl 0x38(%ecx),%ecx *
> > 806389b4: 8d 56 20 lea 0x20(%esi),%edx
> > 806389b7: 89 54 24 04 mov %edx,0x4(%esp)
> > 806389bb: 89 da mov %ebx,%edx
> > 806389bd: 88 4c 24 0b mov %cl,0xb(%esp)
> > 806389c1: 89 f9 mov %edi,%ecx
> > 806389c3: e8 38 2f fe ff call 8061b900 <rate_control_send_low>
> My x86 assembly is a a bit rusty (I usually work with ARM and MIPS), so
> I'm having trouble figuring out the exact line of code here. Please use
> gdb to track it down.
>
The priv_sta is NULL and it's later dereferenced in:
bool prev_sample = mi->prev_sample;
static void
minstrel_get_rate(void *priv, struct ieee80211_sta *sta,
void *priv_sta, struct ieee80211_tx_rate_control *txrc)
{
struct sk_buff *skb = txrc->skb;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct minstrel_sta_info *mi = priv_sta;
struct minstrel_priv *mp = priv;
struct ieee80211_tx_rate *rate = &info->control.rates[0];
struct minstrel_rate *msr, *mr;
unsigned int ndx;
bool mrr_capable;
bool prev_sample = mi->prev_sample;
int delta;
int sampling_ratio;
With:
diff --git a/net/mac80211/rc80211_minstrel.c b/net/mac80211/rc80211_minstrel.c
index ac7ef54..be17d52 100644
--- a/net/mac80211/rc80211_minstrel.c
+++ b/net/mac80211/rc80211_minstrel.c
@@ -290,9 +290,15 @@ minstrel_get_rate(void *priv, struct ieee80211_sta *sta,
struct minstrel_rate *msr, *mr;
unsigned int ndx;
bool mrr_capable;
- bool prev_sample = mi->prev_sample;
+ bool prev_sample;
int delta;
int sampling_ratio;
+
+ if (!mi) {
+ printk("Oops, mi is NULL\n");
+ return;
+ }
+ prev_sample = mi->prev_sample;
/* management/no-ack frames do not use rate control */
if (rate_control_send_low(sta, priv_sta, txrc))
the system no longer crashes and just prints a message.
Krzysiek
On Mon, Jul 1, 2013 at 8:55 AM, Peizhao Hu <[email protected]> wrote:
> Hi,
>
> Is there anyone has the same problem with me? I have a cm9 radio card with
> the node.
>
> The kernel compiled and booted alright, but crashed short after I set it up
> in the ad hoc mode. From the debug message output, it looks like something
> wrong with the rate control mechanism when it is trying to the rate
> (minstreal_get_rate function in this case).
>
> Is this a bug?
>
> Kernel version
> 3.10.0-rc7
>
Please, always add your kernel-config and some outputs like dmesg and
lspci/lsusb for better understanding.
2nd, try v3.10 (released a few hours ago)... There were wireless
patches pushed after v3.10-rc7.
Then report again.
- Sedat -
[1] Please, check docs sites on <wireless.git.org> on how-to report
wireless issues.
> root@alix-router:~# i[ 250.809354] BUG: unable to handle kernel NULL
> pointe8
> [ 250.812875] IP: [<d0952afa>] minstrel_get_rate+0x1a/0x220 [mac80211]
> [ 250.812875] *pde = 00000000
> [ 250.812875] Oops: 0000 [#1] SMP
> [ 250.812875] Modules linked in: ath5k ath mac80211 cfg80211 arc4
> gpio_cs55]
> [ 250.812875] CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 3.10.0-rc7-cca+
> 1
> [ 250.812875] Workqueue: phy0 ieee80211_iface_work [mac80211]
> [ 250.812875] task: c002bfc0 ti: c0076000 task.ti: c0076000
> [ 250.812875] EIP: 0060:[<d0952afa>] EFLAGS: 00010292 CPU: 0
> [ 250.812875] EIP is at minstrel_get_rate+0x1a/0x220 [mac80211]
> [ 250.812875] EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: cc2bf1c0
> [ 250.812875] ESI: ce6cf900 EDI: c0077d00 EBP: c0077cac ESP: c0077c94
> [ 250.812875] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> [ 250.812875] CR0: 8005003b CR2: 00000038 CR3: 0c245000 CR4: 00000090
> [ 250.812875] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> [ 250.812875] DR6: ffff0ff0 DR7: 00000400
> [ 250.812875] Stack:
> [ 250.812875] 00017901 cc101500 00000180 cc133500 d0967920 cc2bf1e1
> c0077cd
> [ 250.812875] c0077d00 00000180 ce525170 00000000 cc2bf1e0 c0077d00
> cc2bf10
> [ 250.812875] c0077d24 c0077d30 d0927651 c02c5550 c0077cec d092001c
> cc1335c
> [ 250.812875] Call Trace:
> [ 250.812875] [<d091a8dd>] rate_control_get_rate+0x9d/0xe0 [mac80211]
> [ 250.812875] [<d0927651>] ieee80211_beacon_get_tim+0x1a1/0x330 [mac80211]
> [ 250.812875] [<d092001c>] ? ieee80211_assign_beacon+0x1bc/0x1c0
> [mac80211]
> [ 250.812875] [<d0da3fb9>] ath5k_beacon_update+0x29/0x340 [ath5k]
> [ 250.812875] [<d0d99366>] ? ath5k_hw_get_frame_duration+0xa6/0xc0 [ath5k]
> [ 250.812875] [<d0d99140>] ? ath5k_hw_set_ifs_intervals+0x110/0x1b0
> [ath5k]
> [ 250.812875] [<d0da92d3>] ath5k_bss_info_changed+0x113/0x1f0 [ath5k]
> [ 250.812875] [<d0da91c0>] ? ath5k_configure_filter+0x1c0/0x1c0 [ath5k]
> [ 250.812875] [<d0908903>] ieee80211_bss_info_change_notify+0xc3/0x1c0
> [ma]
> [ 250.812875] [<d09141db>] ? __ieee80211_sta_join_ibss+0x19b/0x660
> [mac802]
> [ 250.812875] [<d091442c>] __ieee80211_sta_join_ibss+0x3ec/0x660
> [mac80211]
> [ 250.812875] [<c157be33>] ? printk+0x4d/0x4f
> [ 250.812875] [<d0915b4d>] ieee80211_ibss_work+0x31d/0x3d0 [mac80211]
> [ 250.812875] [<d0916d2d>] ieee80211_iface_work+0x18d/0x310 [mac80211]
> [ 250.812875] [<c105025f>] process_one_work+0x10f/0x380
> [ 250.812875] [<c104e485>] ? start_worker+0x25/0x30
> [ 250.812875] [<c1051000>] ? manage_workers.isra.24+0x180/0x290
> [ 250.812875] [<c105120a>] worker_thread+0xfa/0x310
> [ 250.812875] [<c1051110>] ? manage_workers.isra.24+0x290/0x290
> [ 250.812875] [<c1056674>] kthread+0x94/0xa0
> [ 250.812875] [<c158b1f7>] ret_from_kernel_thread+0x1b/0x28
> [ 250.812875] [<c10565e0>] ? flush_kthread_worker+0x90/0x90
> [ 250.812875] Code: 3d fe 93 f0 5d c3 90 90 90 90 90 90 90 90 90 90 90 55
> 88
> [ 250.812875] EIP: [<d0952afa>] minstrel_get_rate+0x1a/0x220 [mac80211]
> SS:4
> [ 250.812875] CR2: 0000000000000038
> [ 250.815950] ---[ end trace 87b8337e77cb6664 ]---
> [ 250.817834] Kernel panic - not syncing: Fatal exception in interrupt
>
>
>
> --
> Regards;
>
> Peizhao
>
> --
> 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
On 2013-07-15 10:52 AM, Krzysztof Mazur wrote:
> On Mon, Jul 01, 2013 at 09:37:19AM +0200, Sedat Dilek wrote:
>> On Mon, Jul 1, 2013 at 8:55 AM, Peizhao Hu <[email protected]> wrote:
>> > Hi,
>> >
>> > Is there anyone has the same problem with me? I have a cm9 radio card with
>> > the node.
>> >
>> > The kernel compiled and booted alright, but crashed short after I set it up
>> > in the ad hoc mode. From the debug message output, it looks like something
>> > wrong with the rate control mechanism when it is trying to the rate
>> > (minstreal_get_rate function in this case).
>> >
>> > Is this a bug?
>> >
>> > Kernel version
>> > 3.10.0-rc7
>> >
>>
>> Please, always add your kernel-config and some outputs like dmesg and
>> lspci/lsusb for better understanding.
>> 2nd, try v3.10 (released a few hours ago)... There were wireless
>> patches pushed after v3.10-rc7.
>> Then report again.
>>
>
> I have the same problem. I'm using:
>
> 02:04.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02)
> Subsystem: Hewlett-Packard Company Broadcom 802.11b/g WLAN
> Flags: bus master, fast devsel, latency 64, IRQ 21
> Memory at d0000000 (32-bit, non-prefetchable) [size=8K]
> Kernel driver in use: b43-pci-bridge
>
> with b43 driver and I can easily trigger similar Oops with:
> # ip link set wlan0 up
> # iwlist scan
>
> The bug is introduced by commit 06d961a8e210035bff7e82f466107f9ab4a8fd94
> ("mac80211/minstrel: use the new rate control API").
> The v3.9 is ok and the v3.11-rc1 is still bad. I haven't checked
> wireless tree yet.
>
> Wireless related part of my .config:
> [...]
> CONFIG_WIRELESS=y
> CONFIG_WEXT_CORE=y
> CONFIG_WEXT_PROC=y
> CONFIG_CFG80211=y
> CONFIG_CFG80211_DEFAULT_PS=y
> CONFIG_CFG80211_WEXT=y
> CONFIG_MAC80211=y
> CONFIG_MAC80211_HAS_RC=y
> CONFIG_MAC80211_RC_MINSTREL=y
> CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y
> CONFIG_MAC80211_RC_DEFAULT="minstrel"
> CONFIG_RFKILL=y
> CONFIG_RFKILL_INPUT=y
> [...]
> CONFIG_WLAN=y
> CONFIG_B43=y
> CONFIG_B43_SSB=y
> CONFIG_B43_PCI_AUTOSELECT=y
> CONFIG_B43_PCICORE_AUTOSELECT=y
> CONFIG_B43_PIO=y
> CONFIG_B43_PHY_LP=y
>
> Krzysiek
Please post the actual message output. Saying "it looks like something
wrong with the rate control mechanism" doesn't give me anything useful
to work with.
- Felix
On Mon, Jul 15, 2013 at 11:06:27AM +0200, Felix Fietkau wrote:
> Please post the actual message output. Saying "it looks like something
> wrong with the rate control mechanism" doesn't give me anything useful
> to work with.
>
Sorry, I added you to Cc after I removed the original Oops.
On Mon, Jul 1, 2013 at 8:55 AM, Peizhao Hu wrote:
> Hi,
>
> Is there anyone has the same problem with me? I have a cm9 radio card with
> the node.
>
> The kernel compiled and booted alright, but crashed short after I set it up
> in the ad hoc mode. From the debug message output, it looks like something
> wrong with the rate control mechanism when it is trying to the rate
> (minstreal_get_rate function in this case).
>
> Is this a bug?
>
> Kernel version
> 3.10.0-rc7
>
> root@alix-router:~# i[ 250.809354] BUG: unable to handle kernel NULL
> pointe8
> [ 250.812875] IP: [<d0952afa>] minstrel_get_rate+0x1a/0x220 [mac80211]
> [ 250.812875] *pde = 00000000
> [ 250.812875] Oops: 0000 [#1] SMP
> [ 250.812875] Modules linked in: ath5k ath mac80211 cfg80211 arc4
> gpio_cs55]
> [ 250.812875] CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 3.10.0-rc7-cca+
> 1
> [ 250.812875] Workqueue: phy0 ieee80211_iface_work [mac80211]
> [ 250.812875] task: c002bfc0 ti: c0076000 task.ti: c0076000
> [ 250.812875] EIP: 0060:[<d0952afa>] EFLAGS: 00010292 CPU: 0
> [ 250.812875] EIP is at minstrel_get_rate+0x1a/0x220 [mac80211]
> [ 250.812875] EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: cc2bf1c0
> [ 250.812875] ESI: ce6cf900 EDI: c0077d00 EBP: c0077cac ESP: c0077c94
> [ 250.812875] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> [ 250.812875] CR0: 8005003b CR2: 00000038 CR3: 0c245000 CR4: 00000090
> [ 250.812875] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> [ 250.812875] DR6: ffff0ff0 DR7: 00000400
> [ 250.812875] Stack:
> [ 250.812875] 00017901 cc101500 00000180 cc133500 d0967920 cc2bf1e1
> c0077cd
> [ 250.812875] c0077d00 00000180 ce525170 00000000 cc2bf1e0 c0077d00
> cc2bf10
> [ 250.812875] c0077d24 c0077d30 d0927651 c02c5550 c0077cec d092001c
> cc1335c
> [ 250.812875] Call Trace:
> [ 250.812875] [<d091a8dd>] rate_control_get_rate+0x9d/0xe0 [mac80211]
> [ 250.812875] [<d0927651>] ieee80211_beacon_get_tim+0x1a1/0x330 [mac80211]
> [ 250.812875] [<d092001c>] ? ieee80211_assign_beacon+0x1bc/0x1c0
> [mac80211]
> [ 250.812875] [<d0da3fb9>] ath5k_beacon_update+0x29/0x340 [ath5k]
> [ 250.812875] [<d0d99366>] ? ath5k_hw_get_frame_duration+0xa6/0xc0 [ath5k]
> [ 250.812875] [<d0d99140>] ? ath5k_hw_set_ifs_intervals+0x110/0x1b0
> [ath5k]
> [ 250.812875] [<d0da92d3>] ath5k_bss_info_changed+0x113/0x1f0 [ath5k]
> [ 250.812875] [<d0da91c0>] ? ath5k_configure_filter+0x1c0/0x1c0 [ath5k]
> [ 250.812875] [<d0908903>] ieee80211_bss_info_change_notify+0xc3/0x1c0
> [ma]
> [ 250.812875] [<d09141db>] ? __ieee80211_sta_join_ibss+0x19b/0x660
> [mac802]
> [ 250.812875] [<d091442c>] __ieee80211_sta_join_ibss+0x3ec/0x660
> [mac80211]
> [ 250.812875] [<c157be33>] ? printk+0x4d/0x4f
> [ 250.812875] [<d0915b4d>] ieee80211_ibss_work+0x31d/0x3d0 [mac80211]
> [ 250.812875] [<d0916d2d>] ieee80211_iface_work+0x18d/0x310 [mac80211]
> [ 250.812875] [<c105025f>] process_one_work+0x10f/0x380
> [ 250.812875] [<c104e485>] ? start_worker+0x25/0x30
> [ 250.812875] [<c1051000>] ? manage_workers.isra.24+0x180/0x290
> [ 250.812875] [<c105120a>] worker_thread+0xfa/0x310
> [ 250.812875] [<c1051110>] ? manage_workers.isra.24+0x290/0x290
> [ 250.812875] [<c1056674>] kthread+0x94/0xa0
> [ 250.812875] [<c158b1f7>] ret_from_kernel_thread+0x1b/0x28
> [ 250.812875] [<c10565e0>] ? flush_kthread_worker+0x90/0x90
> [ 250.812875] Code: 3d fe 93 f0 5d c3 90 90 90 90 90 90 90 90 90 90 90 55
> 88
> [ 250.812875] EIP: [<d0952afa>] minstrel_get_rate+0x1a/0x220 [mac80211]
> SS:4
> [ 250.812875] CR2: 0000000000000038
> [ 250.815950] ---[ end trace 87b8337e77cb6664 ]---
> [ 250.817834] Kernel panic - not syncing: Fatal exception in interrupt
>
>
>
> --
> Regards;
>
> Peizhao
Krzysiek
On Mon, Jul 01, 2013 at 09:37:19AM +0200, Sedat Dilek wrote:
> On Mon, Jul 1, 2013 at 8:55 AM, Peizhao Hu <[email protected]> wrote:
> > Hi,
> >
> > Is there anyone has the same problem with me? I have a cm9 radio card with
> > the node.
> >
> > The kernel compiled and booted alright, but crashed short after I set it up
> > in the ad hoc mode. From the debug message output, it looks like something
> > wrong with the rate control mechanism when it is trying to the rate
> > (minstreal_get_rate function in this case).
> >
> > Is this a bug?
> >
> > Kernel version
> > 3.10.0-rc7
> >
>
> Please, always add your kernel-config and some outputs like dmesg and
> lspci/lsusb for better understanding.
> 2nd, try v3.10 (released a few hours ago)... There were wireless
> patches pushed after v3.10-rc7.
> Then report again.
>
I have the same problem. I'm using:
02:04.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02)
Subsystem: Hewlett-Packard Company Broadcom 802.11b/g WLAN
Flags: bus master, fast devsel, latency 64, IRQ 21
Memory at d0000000 (32-bit, non-prefetchable) [size=8K]
Kernel driver in use: b43-pci-bridge
with b43 driver and I can easily trigger similar Oops with:
# ip link set wlan0 up
# iwlist scan
The bug is introduced by commit 06d961a8e210035bff7e82f466107f9ab4a8fd94
("mac80211/minstrel: use the new rate control API").
The v3.9 is ok and the v3.11-rc1 is still bad. I haven't checked
wireless tree yet.
Wireless related part of my .config:
[...]
CONFIG_WIRELESS=y
CONFIG_WEXT_CORE=y
CONFIG_WEXT_PROC=y
CONFIG_CFG80211=y
CONFIG_CFG80211_DEFAULT_PS=y
CONFIG_CFG80211_WEXT=y
CONFIG_MAC80211=y
CONFIG_MAC80211_HAS_RC=y
CONFIG_MAC80211_RC_MINSTREL=y
CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y
CONFIG_MAC80211_RC_DEFAULT="minstrel"
CONFIG_RFKILL=y
CONFIG_RFKILL_INPUT=y
[...]
CONFIG_WLAN=y
CONFIG_B43=y
CONFIG_B43_SSB=y
CONFIG_B43_PCI_AUTOSELECT=y
CONFIG_B43_PCICORE_AUTOSELECT=y
CONFIG_B43_PIO=y
CONFIG_B43_PHY_LP=y
Krzysiek
On 2013-07-15 11:35 AM, Krzysztof Mazur wrote:
> On Mon, Jul 15, 2013 at 11:27:30AM +0200, Krzysztof Mazur wrote:
>> On Mon, Jul 15, 2013 at 11:06:27AM +0200, Felix Fietkau wrote:
>> > Please post the actual message output. Saying "it looks like something
>> > wrong with the rate control mechanism" doesn't give me anything useful
>> > to work with.
>> >
>>
>> Sorry, I added you to Cc after I removed the original Oops.
>>
>
> On my system the NULL pointer dereference occurs at 0x806389b0,
> and the minstrel_get_rate() looks like:
>
> 80638990 <minstrel_get_rate>:
> 80638990: 83 ec 1c sub $0x1c,%esp
> 80638993: 89 7c 24 14 mov %edi,0x14(%esp)
> 80638997: 8b 7c 24 20 mov 0x20(%esp),%edi
> 8063899b: 89 5c 24 0c mov %ebx,0xc(%esp)
> 8063899f: 89 cb mov %ecx,%ebx
> 806389a1: 89 6c 24 18 mov %ebp,0x18(%esp)
> 806389a5: 89 c5 mov %eax,%ebp
> 806389a7: 89 d0 mov %edx,%eax
> 806389a9: 89 74 24 10 mov %esi,0x10(%esp)
> 806389ad: 8b 77 0c mov 0xc(%edi),%esi
> * 806389b0: 0f b6 49 38 movzbl 0x38(%ecx),%ecx *
> 806389b4: 8d 56 20 lea 0x20(%esi),%edx
> 806389b7: 89 54 24 04 mov %edx,0x4(%esp)
> 806389bb: 89 da mov %ebx,%edx
> 806389bd: 88 4c 24 0b mov %cl,0xb(%esp)
> 806389c1: 89 f9 mov %edi,%ecx
> 806389c3: e8 38 2f fe ff call 8061b900 <rate_control_send_low>
My x86 assembly is a a bit rusty (I usually work with ARM and MIPS), so
I'm having trouble figuring out the exact line of code here. Please use
gdb to track it down.
- Felix
On Mon, Jul 15, 2013 at 11:27:30AM +0200, Krzysztof Mazur wrote:
> On Mon, Jul 15, 2013 at 11:06:27AM +0200, Felix Fietkau wrote:
> > Please post the actual message output. Saying "it looks like something
> > wrong with the rate control mechanism" doesn't give me anything useful
> > to work with.
> >
>
> Sorry, I added you to Cc after I removed the original Oops.
>
On my system the NULL pointer dereference occurs at 0x806389b0,
and the minstrel_get_rate() looks like:
80638990 <minstrel_get_rate>:
80638990: 83 ec 1c sub $0x1c,%esp
80638993: 89 7c 24 14 mov %edi,0x14(%esp)
80638997: 8b 7c 24 20 mov 0x20(%esp),%edi
8063899b: 89 5c 24 0c mov %ebx,0xc(%esp)
8063899f: 89 cb mov %ecx,%ebx
806389a1: 89 6c 24 18 mov %ebp,0x18(%esp)
806389a5: 89 c5 mov %eax,%ebp
806389a7: 89 d0 mov %edx,%eax
806389a9: 89 74 24 10 mov %esi,0x10(%esp)
806389ad: 8b 77 0c mov 0xc(%edi),%esi
* 806389b0: 0f b6 49 38 movzbl 0x38(%ecx),%ecx *
806389b4: 8d 56 20 lea 0x20(%esi),%edx
806389b7: 89 54 24 04 mov %edx,0x4(%esp)
806389bb: 89 da mov %ebx,%edx
806389bd: 88 4c 24 0b mov %cl,0xb(%esp)
806389c1: 89 f9 mov %edi,%ecx
806389c3: e8 38 2f fe ff call 8061b900 <rate_control_send_low>
Krzysiek