Opened 14 years ago

Closed 13 years ago

#7499 closed bug (fixed)

[broadcom43xx] KDL - PANIC: unsupport modulation type 88

Reported by: umccullough Owned by: korli
Priority: normal Milestone: R1/alpha3
Component: Network & Internet/Wireless Version: R1/alpha2
Keywords: broadcom43xx wifi kdl Cc:
Blocked By: Blocking:
Platform: All

Description

Tested hrev41412 (gcc4) on my Dell Inspiron B130 with broadcom43xx wifi and when it tries to connect to an open SSID, it immediately panics with:

KERN: PANIC: unsupport modulation type 88
KERN: 
KERN: Welcome to Kernel Debugging Land...
KERN: Thread 79 "ic_taskq" running on CPU 0
KERN: stack trace for thread 79 "ic_taskq"
KERN:     kernel stack: 0x80755000 to 0x80759000
KERN: frame               caller     <image>:function + offset
KERN:  0 80758c6c (+  32) 800edaa7   <kernel_x86>:arch_debug_stack_trace + 0x000f
KERN:  1 80758c8c (+  16) 8007319e   <kernel_x86> stack_trace_trampoline(void*: NULL) + 0x000b
KERN:  2 80758c9c (+  12) 800f331a   <kernel_x86>:arch_debug_call_with_fault_handler + 0x001b
KERN:  3 80758ca8 (+  48) 80073695   <kernel_x86>:debug_call_with_fault_handler + 0x0052
KERN:  4 80758cd8 (+  80) 80074646   <kernel_x86> kernel_debugger_loop(char const*:  + 0x0226
KERN:  5 80758d28 (+  64) 800748d1   <kernel_x86> kernel_debugger_internal(char const*:  + 0x0112
KERN:  6 80758d68 (+  32) 80074ab4   <kernel_x86>:panic + 0x0023
KERN:  7 80758d88 (+ 128) 80595fd8   </boot/system/add-ons/kernel/drivers/dev/net/broadcom43xx>:bwi_encap + 0x032c
KERN:  8 80758e08 (+  80) 80597d5e   </boot/system/add-ons/kernel/drivers/dev/net/broadcom43xx>:bwi_start + 0x0242
KERN:  9 80758e58 (+  32) 805d97a0   </boot/system/add-ons/kernel/drivers/dev/net/broadcom43xx>:if_start + 0x0010
KERN: 10 80758e78 (+  64) 805da797   </boot/system/add-ons/kernel/drivers/dev/net/broadcom43xx>:if_transmit + 0x0133
KERN: 11 80758eb8 (+ 112) 805bcd7c   </boot/system/add-ons/kernel/drivers/dev/net/broadcom43xx>:ieee80211_start + 0x067c
KERN: 12 80758f28 (+  32) 805d97a0   </boot/system/add-ons/kernel/drivers/dev/net/broadcom43xx>:if_start + 0x0010
KERN: 13 80758f48 (+  64) 805c0219   </boot/system/add-ons/kernel/drivers/dev/net/broadcom43xx>:ieee80211_newstate_cb + 0x01cc
KERN: 14 80758f88 (+  80) 805dbad6   </boot/system/add-ons/kernel/drivers/dev/net/broadcom43xx>:tq_handle_thread + 0x008f
KERN: 15 80758fd8 (+  32) 8006616b   <kernel_x86> _create_kernel_thread_kentry() + 0x0015
KERN: 16 80758ff8 (+2139779080) 800699d8   <kernel_x86> thread_kthread_exit() + 0x0000

which I can 'co' from after several attempts - but then the dhcp request causes it to occur again.

This didn't happen with hrev40894 which I'm using with the same driver to write this bug report, so it appears to be a regression.

I will further search for the commit which broke it shortly.

Attachments (1)

syslog-20110509.log (238.8 KB ) - added by umccullough 14 years ago.
syslog with KDL

Download all attachments as: .zip

Change History (11)

by umccullough, 14 years ago

Attachment: syslog-20110509.log added

syslog with KDL

comment:1 by umccullough, 14 years ago

hrev41239 succeeds while hrev41240 panics with an unhandled page fault in broadcom43xx

comment:2 by umccullough, 14 years ago

hrev41251 fails with the same PANIC mentioned in this bug - so it was most likely the upgrade to freebsd 8.2 for the wifi drivers that caused the regression.

comment:3 by umccullough, 13 years ago

Owner: changed from axeld to korli
Status: newassigned

comment:4 by korli, 13 years ago

Please check again with hrev41425 whether another panic happens. Thanks!

comment:5 by umccullough, 13 years ago

Still occurs with hrev41428 (gcc4 build)

Same panic.

Last edited 13 years ago by umccullough (previous) (diff)

comment:6 by pulkomandy, 13 years ago

The message looks pretty much like it isn't worth a panic to me. The driver may stop working, but the whole OS, seriously ?

Looking at the code, it seems valid to fail in this case. The driver in FreeBSD current seems to still do it, and the enum for modulation type has only 7 values, so 88 is clearly out of range. Now to figure out why we get this value...

comment:7 by umccullough, 13 years ago

I think that removing the PANIC would be a suitable solution if this isn't going to be fixed again before Alpha 3.

comment:8 by korli, 13 years ago

Could you please check again with hrev41559 or newer on trunk?

comment:9 by umccullough, 13 years ago

It seems to be working again with hrev41581 that I just built from trunk!

Please +alpha3 and feel free close this :D

comment:10 by umccullough, 13 years ago

Resolution: fixed
Status: assignedclosed

Appears to be merged to alpha3 branch in hrev41594.

Closing this one :)

Note: See TracTickets for help on using tickets.