Date: Sun, 27 Jul 2014 22:11:05 +0200 From: Hans Petter Selasky <hps@selasky.org> To: Adrian Chadd <adrian@freebsd.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: <53D55CD9.4000408@selasky.org> In-Reply-To: <CAJ-VmonefZWYRdF2mbhKQ-GVhUn-32nop1TsXKq=ZT3xP5mmsA@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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?53D55CD9.4000408>