On Sunday 26 November 2006 17:37, Daniel Drake wrote:
> Johannes Berg wrote:
> > The problem is that queue disabling isn't refcounted so that a scan that
> > collides with bcm43xx having disabled the queue for calibration might
> > re-enable the queue while bcm43xx is still calibrating.
>
> I agre
Johannes Berg wrote:
On Sun, 2006-11-26 at 13:25 -0500, Daniel Drake wrote:
No, we could stick with our existing setup if the stack did something
different.
But you do need full refcounting I guess.
No, I don't think we would need to move away from our existing method:
spin_lock_irqsave(
Johannes Berg wrote:
On Sun, 2006-11-26 at 13:25 -0500, Daniel Drake wrote:
No, we could stick with our existing setup if the stack did something
different.
But you do need full refcounting I guess.
Because for
the stack it wouldn't be required if it'd simply not start scanning when
queue i
On Sun, 2006-11-26 at 13:25 -0500, Daniel Drake wrote:
> No, we could stick with our existing setup if the stack did something
> different.
But you do need full refcounting I guess.
> > Because for
> > the stack it wouldn't be required if it'd simply not start scanning when
> > queue is disable
Johannes Berg wrote:
Would you actually need a fully refcounted enable/disable?
No, we could stick with our existing setup if the stack did something
different.
Because for
the stack it wouldn't be required if it'd simply not start scanning when
queue is disabled and stop scanning immediate
On Sun, 2006-11-26 at 11:37 -0500, Daniel Drake wrote:
> However the other reason for the patch (transmit
> queue needed for active scanning) is bogus,
I think that was just a misunderstanding.
> and the patch introduces a
> problem where session frames may be transmitted during scanning (usin
Johannes Berg wrote:
The problem is that queue disabling isn't refcounted so that a scan that
collides with bcm43xx having disabled the queue for calibration might
re-enable the queue while bcm43xx is still calibrating.
I agree with that part. However the other reason for the patch (transmit
q
On Sunday 26 November 2006 05:05, Daniel Drake wrote:
> Larry Finger wrote:
> > In the scan section of ieee80211softmac, network transmits are disabled.
> > Clearly, this does not make any sense as transmit is necessary for active
> > scanning, and transmits are not used when passive scanning.
>
>
On Sunday 26 November 2006 11:03, Johannes Berg wrote:
> On Sat, 2006-11-25 at 23:05 -0500, Daniel Drake wrote:
>
> > Surely disabling the queue actually makes sense, in order to avoid
> > frames designated for the "current session" being transmitted on
> > different channels during scanning?
>
On Sat, 2006-11-25 at 23:05 -0500, Daniel Drake wrote:
> Surely disabling the queue actually makes sense, in order to avoid
> frames designated for the "current session" being transmitted on
> different channels during scanning?
Also, for bcm43xx this isn't a problem since the firmware (optiona
On Sat, 2006-11-25 at 23:05 -0500, Daniel Drake wrote:
> Surely disabling the queue actually makes sense, in order to avoid
> frames designated for the "current session" being transmitted on
> different channels during scanning?
The problem is that queue disabling isn't refcounted so that a sca
Larry Finger wrote:
In the scan section of ieee80211softmac, network transmits are disabled.
Clearly, this does not make any sense as transmit is necessary for active
scanning, and transmits are not used when passive scanning.
Probe request frames are generated by softmac and do not go through
From: Michael Buesch <[EMAIL PROTECTED]>
In the scan section of ieee80211softmac, network transmits are disabled.
Clearly, this does not make any sense as transmit is necessary for active
scanning, and transmits are not used when passive scanning. In addition,
when SoftMAC re-enables transmits, it
13 matches
Mail list logo
