Skip to contentSkip to conversation

kernel panic on 3.10.0-rc7

DISCUSSION Peizhao Hu 4 participants 8 messages Jul 1, 2013 – Jul 15, 2013 mac80211

lore
Share & tools
lore

Peizhao Hu

author
#0 lore raw

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

#1 lore raw
Quoted 10 lines · Peizhao Hu

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

Quoted 5 lines

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.

Quoted 73 lines
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

#2 lore raw
Quoted 17 lines · Sedat Dilek
Quoted 10 lines · Peizhao Hu

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

Quoted 5 lines

Is this a bug?

Kernel version
3.10.0-rc7

Quoted 6 lines

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

#3 lore raw
Quoted 66 lines · Krzysztof Mazur
Quoted 17 lines · Sedat Dilek
Quoted 10 lines · Peizhao Hu

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

Quoted 5 lines

Is this a bug?

Kernel version
3.10.0-rc7

Quoted 6 lines

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

Quoted 1 line

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

#4 lore raw
Quoted 4 lines · Felix Fietkau

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.

Quoted 79 lines · Peizhao Hu

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
Quoted 4 lines

--
Regards;

Peizhao

Krzysiek

#5 lore raw
Quoted 8 lines · Krzysztof Mazur
Quoted 4 lines · Felix Fietkau

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

#6 lore raw
Quoted 23 lines · Krzysztof Mazur
Quoted 8 lines · Krzysztof Mazur
Quoted 4 lines · Felix Fietkau

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)
Quoted 8 lines
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

#7 lore raw
Quoted 32 lines · Felix Fietkau
Quoted 23 lines · Krzysztof Mazur
Quoted 8 lines · Krzysztof Mazur
Quoted 4 lines · Felix Fietkau

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)
Quoted 8 lines
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>
Quoted 4 lines

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:

net/mac80211/rc80211_minstrel.c +7 -1
index ac7ef54..be17d52 100644
@@ -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