Hi, Ok. So, which one of those is showing up as 0?
Maybe refactor out the rate lookup code and if it's zero, log an error and reset it to either 2 (for 11ng) or 12 (11a.) '2' isn't valid for 11a - the minimum rate is 6mb. -a On 27 July 2014 13:11, Hans Petter Selasky <h...@selasky.org> wrote: > On 07/27/14 02:10, Adrian Chadd wrote: >> >> On 26 July 2014 12:13, Hans Petter Selasky <h...@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? >> > > Rate comes from this: > > tp = &vap->iv_txparms[ieee80211_chan2mode(ni->ni_chan)]; > if (IEEE80211_IS_MULTICAST(wh->i_addr1)) > rate = tp->mcastrate; > else if (tp->ucastrate != IEEE80211_FIXED_RATE_NONE) > rate = tp->ucastrate; > else > rate = ni->ni_txrate; > > --HPS _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
