On 28 July 2014 14:05, Hans Petter Selasky wrote:
> On 07/28/14 22:52, Adrian Chadd wrote:
>>
>> The whole rate control thing from net80211 has to be upgraded. Drivers
>> shouldn't be using ni->ni_txrate for anything other than informational
>> purposes, yet .. well, that's not the case.
>
>
> Hi,
On 07/28/14 22:52, Adrian Chadd wrote:
The whole rate control thing from net80211 has to be upgraded. Drivers
shouldn't be using ni->ni_txrate for anything other than informational
purposes, yet .. well, that's not the case.
Hi,
Should the rate be extracted from the NET80211 header instead, an
On 28 July 2014 13:50, Hans Petter Selasky wrote:
> On 07/27/14 22:15, Adrian Chadd wrote:
>>
>> Ok. So, which one of those is showing up as 0?
>
>
> Hi,
>
> I think it is the last one. I cannot test this again until later this year,
> because I don't have access to the AP which is causing this :-
On 07/27/14 22:15, Adrian Chadd wrote:
Ok. So, which one of those is showing up as 0?
Hi,
I think it is the last one. I cannot test this again until later this
year, because I don't have access to the AP which is causing this :-(
Is it possible you can add a function to the net80211 stack,
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 wrote:
> On 07/27/14 02:1
On 07/27/14 02:10, Adrian Chadd wrote:
On 26 July 2014 12:13, Hans Petter Selasky 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
On 26 July 2014 12:13, Hans Petter Selasky 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?
>>
>>
>
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 di
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?
-a
On 26 July 2014 09:06, Hans Petter Selasky wrote:
> Author: hselasky
> Date: Sat Jul 26 16:06:01 2014
> New Rev
Author: hselasky
Date: Sat Jul 26 16:06:01 2014
New Revision: 269127
URL: http://svnweb.freebsd.org/changeset/base/269127
Log:
Fix for division by zero.
MFC after:3 days
Modified:
head/sys/dev/usb/wlan/if_rum.c
head/sys/dev/usb/wlan/if_ural.c
head/sys/dev/usb/wlan/if_zyd.c
head
10 matches
Mail list logo