Date: Sun, 27 Jul 2014 13:15:17 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Hans Petter Selasky <hps@selasky.org> Cc: "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org> Subject: Re: svn commit: r269127 - head/sys/dev/usb/wlan Message-ID: <CAJ-VmonV=mt5_6xZa-naD%2BS3mPKE14wTUnTyFJrBnE3aA8MRMw@mail.gmail.com> In-Reply-To: <53D55CD9.4000408@selasky.org> References: <201407261606.s6QG61le092895@svn.freebsd.org> <CAJ-Vmo=gy99iyOwoeCBKKMTAba1CycJgQBO2ti2=eFR_9ht-UQ@mail.gmail.com> <53D3FDEC.5040000@selasky.org> <CAJ-VmonefZWYRdF2mbhKQ-GVhUn-32nop1TsXKq=ZT3xP5mmsA@mail.gmail.com> <53D55CD9.4000408@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <hps@selasky.org> wrote: > On 07/27/14 02:10, Adrian Chadd wrote: >> >> On 26 July 2014 12:13, Hans Petter Selasky <hps@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmonV=mt5_6xZa-naD%2BS3mPKE14wTUnTyFJrBnE3aA8MRMw>