Weongyo Jeong <weongyo.je...@gmail.com> writes:
> On Thu, Feb 26, 2009 at 06:04:17PM -0800, Sam Leffler wrote:
>> Bengt Ahlgren wrote:
>> >Weongyo Jeong <weongyo.je...@gmail.com> writes:
>> >
>> >>On Thu, Feb 26, 2009 at 01:20:36PM +0900, Nathan Butcher wrote:
>> >>
>> >>>I have a Buffalo WLI-U2-KG54-AI wireless USB adaptor.
>> >>>It has been malfunctioning for quite a while under FreeBSD7.0 and 7.1
>> >>>
>> >>>Typically, It works for a while until eventually it stalls data
>> >>>transfers completely. It always seems to do this after an unspecified
>> >>>amount of time.
>> >>>
>> >>>I know the hardware isn't at fault because the device works fine under
>> >>>Linux.
>> >>>
>> >>Could you please check that `ifconfig <ifname> -bgscan' disabling the
>> >>background scan helps your symptom?
>> >
>> >The above sounds like the same problem as this:
>> >
>> >http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011376.html
>> >http://lists.freebsd.org/pipermail/freebsd-mobile/2009-February/011343.html
>> >
>> >The problem is in the background scanning logic in sys/net80211.
>>
>> I don't see how you come to this conclusion. ural is a totally
>> different driver than ath and so far as I can recall you never found the
>> cause for your problem w/ ath. Most of the usb wireless drivers do a
>> haphazard job of synchronizing async tasks like bg scan with the
>> foreground tx/rx processing. This can lead to firmware and/or usb
>> issues. ath does not have these issues but I am aware of at least one
>> problem w/ bg scanning in ath under RELENG_7 (that is not present in HEAD).
>
> I agree with sam because I saw some cases like stalls during background
> scanning that most of them I think it's caused by H/W miss-operation or
> miss-configuration by mistakes of driver.
Looking into if_ural (1.69.6.1 - 7.1R version), it partly has the same
calls to net80211 which causes problems for ath.
At line 1477, it has the same test as ath has to check for bg
scanning:
if (ic->ic_flags & IEEE80211_F_SCAN)
ieee80211_cancel_scan(ic);
That means that ieee80211_cancel_scan won't be called in the window
between when scan_next is run (which resets IEEE80211_F_SCAN), and
ieee80211_bg_scan is called the next time (setting IEEE80211_F_SCAN
again). This is the same problem as ath has.
But I can't find that ural calls ieee80211_pwrsave to queue packets if
a bgscan was running. It seems that it just merrily tries to send
packets despite scanning is going on.
Please note that even though ieee80211_cancel_scan IS called, that
won't take effect until the next clock tick. So if the output routine
just carries on with sending a packet, it will do so in the middle of
the scan. This is something that should be fixed in net80211.
So, I find that ural also suffers from the problem with the scanning
logic in net80211.
Bengt
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
