Revision 195ca3b122c02cf21ce64f211d9474600da80e80 authored by Rajkumar Manoharan on 15 March 2012, 17:35:28 UTC, committed by John W. Linville on 26 March 2012, 19:07:25 UTC
When we have downlink traffic alone and the station is going thru bgscan, the client is out of operating channel for around 1000ms which is too long. The mac80211 decides when to switch back to oper channel based on tx queue, bad latency and listen time. As the station does not have tx traffic, the bgscan can easily affect downlink throughput. By reducing the listen time, it helps the associated AP to retain the downstream rate. Cc: Paul Stewart <pstew@google.com> Tested-by: Gary Morain <gmorain@google.com> Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
1 parent 66266b3
debugging-modules.txt
Debugging Modules after 2.6.3
-----------------------------
In almost all distributions, the kernel asks for modules which don't
exist, such as "net-pf-10" or whatever. Changing "modprobe -q" to
"succeed" in this case is hacky and breaks some setups, and also we
want to know if it failed for the fallback code for old aliases in
fs/char_dev.c, for example.
In the past a debugging message which would fill people's logs was
emitted. This debugging message has been removed. The correct way
of debugging module problems is something like this:
echo '#! /bin/sh' > /tmp/modprobe
echo 'echo "$@" >> /tmp/modprobe.log' >> /tmp/modprobe
echo 'exec /sbin/modprobe "$@"' >> /tmp/modprobe
chmod a+x /tmp/modprobe
echo /tmp/modprobe > /proc/sys/kernel/modprobe
Note that the above applies only when the *kernel* is requesting
that the module be loaded -- it won't have any effect if that module
is being loaded explicitly using "modprobe" from userspace.
Computing file changes ...
