svn commit: r269127 - head/sys/dev/usb/wlan

[Adrian Chadd]

On 26 July 2014 12:13, Hans Petter Selasky <hps at selasky.org> wrote:
> On 07/26/14 20:36, Adrian Chadd wrote:
>>
>> Hi,
>>
>> We should likely review how the PLCP bits are being used and why it's
>> getting a rate of 0 in the first place.
>>
>> So, why's it getting a rate of 0 passed into the transmit path?
>>
>>
>
> Hi Adrian,
>
> Here is the backtrace of the panic:
>
> Fatal trap 18: integer divide fault while in kernel mode
> cpuid = 2; apic id = 02
> instruction pointer     = 0x20:0xffffffff807826cf
> stack pointer           = 0x28:0xffffff8000305090
> frame pointer           = 0x28:0xffffff80003050a0
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 15 (usbus0)
> trap number             = 18
> panic: integer divide fault
> cpuid = 2
> KDB: stack backtrace:
> #0 0xffffffff809257e6 at kdb_backtrace+0x66
> #1 0xffffffff808eb3ae at panic+0x1ce
> #2 0xffffffff80cd2c30 at trap_fatal+0x290
> #3 0xffffffff80cd3480 at trap+0x250
> #4 0xffffffff80cbc783 at calltrap+0x8
> #5 0xffffffff80783d90 at ural_start+0x1d0
> #6 0xffffffff809aa2ea at if_transmit+0xea
> #7 0xffffffff809ef7b2 at ieee80211_start+0x542
> #8 0xffffffff809aa2ea at if_transmit+0xea
> #9 0xffffffff809ae8b3 at ether_output_frame+0x33
> #10 0xffffffff809aee30 at ether_output+0x530
> #11 0xffffffff80a186b4 at ip_output+0xd74
> #12 0xffffffff80a87d2a at tcp_output+0xfea
> #13 0xffffffff80a82222 at tcp_do_segment+0xc02
> #14 0xffffffff80a85219 at tcp_input+0xa29
> #15 0xffffffff80a155fa at ip_input+0xaa
> #16 0xffffffff809b7808 at netisr_dispatch_src+0x218
> #17 0xffffffff809ae3fd at ether_demux+0x14d

Hm, so at some point that rate was not assigned to something. Can you
trace the ural_start path to see where it's supposed to be calculating
the rate?


-a