On 22 February 2013 13:26, PseudoCylon wrote:
>>> The OP problem is that we're not advertising the right capabilities
>>> when we associate, right?
>>
>> Correct.
>
> I didn't patch it right, but all of us agree on sta isn't sending
> correct param at association. With current code, sta sends bac
I have now observed this on more than one machine so it's time to
report it rather than ignore it as a fluke.
Over a month ago, I saw this several times on FreeBSD/ppc64 9.1-RC. The
ppc64 port is not exactly solid, so with more pressing issues to deal
with I ignored it.
Now, I see the same on a b
On Fri, Feb 22, 2013 at 12:05 PM, Bernhard Schmidt
wrote:
> On Friday, February 22, 2013 07:52:47 PM Adrian Chadd wrote:
>> Hm, it's possible in my sleep deprived state that I'm on the right but
>> wrong track here.
>>
>> The OP problem is that we're not advertising the right capabilities
>> when
>Number: 176362
>Category: kern
>Synopsis: Graphics screen comes back blank after switching to the text
>terminal on Intel Mobile 945GME chipset
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Number: 176361
>Category: bin
>Synopsis: [PATCH] Add recursive option to ctags
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: change
On Friday, February 22, 2013 07:52:47 PM Adrian Chadd wrote:
> Hm, it's possible in my sleep deprived state that I'm on the right but
> wrong track here.
>
> The OP problem is that we're not advertising the right capabilities
> when we associate, right?
Correct.
> Why aren't we just advertising
Hm, it's possible in my sleep deprived state that I'm on the right but
wrong track here.
The OP problem is that we're not advertising the right capabilities
when we associate, right?
Why aren't we just advertising the VAP ampdumax and ampdudensity no
matter what the operating mode? Why are we capp
Ah, damn. Sorry. I was thinking about the node versus vap
configuration and got confused.
IBSS is the same as the APmode of operation - you advertise what
you're capable of and sending stations just calculate the
MIN(ampdusize) and MAX(ampdudensity) when sending to you. Exactly the
same needs to b
On Friday, February 22, 2013 07:34:30 PM Adrian Chadd wrote:
> Hi,
>
> Why isn't it a per-node thing for the AP case?
>
> Ie, what should the AP do if the ampdu density it supports is 0 but
> the STA AMPDU density on the RX side is 8?
What made you think it isn't? ni_htparams is per-node(ni)?
I
Hi,
Why isn't it a per-node thing for the AP case?
Ie, what should the AP do if the ampdu density it supports is 0 but
the STA AMPDU density on the RX side is 8?
Adrian
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listin
On Friday, February 22, 2013 07:04:39 PM Adrian Chadd wrote:
> Hm, we need to use MIN(rxmax) and MAX(density) regardless, right?
>
> If an AP is transmitting to a STA that has a lower rxmax or higher
> density, it should obey that.
>
> The same rules apply for mesh, ibss, tdma operational modes.
Hm, we need to use MIN(rxmax) and MAX(density) regardless, right?
If an AP is transmitting to a STA that has a lower rxmax or higher
density, it should obey that.
The same rules apply for mesh, ibss, tdma operational modes.
So yes, what we should do is:
* initialise rxmax/density with the VAP c
The patch effectively reverts a previous change, which was to cap rxmax and
density by what the AP is capable of. I think the better approach would be to
initialize rxmax and density with the VAP capabilities before the condition
and use MIN() in STA mode to limit to AP caps.
--
Bernhard
_
The following reply was made to PR kern/162036; it has been noted by GNATS.
From: Fabian Keil
To: bug-follo...@freebsd.org
Cc:
Subject: kern/162036: [geom] Fatal trap 12: page fault while in kernel mode
-- Stopped at atomic_subtract_int+0x4
Date: Fri, 22 Feb 2013 17:59:13 +0100
--Sig_/ygxLXw
>Number: 176347
>Category: misc
>Synopsis: Add support for firewall deny lists (workstation type)
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Clas
>Number: 176344
>Category: misc
>Synopsis: Add support for firewall deny lists (workstation type)
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Clas
16 matches
Mail list logo
