Define _FILE_OFFSET_BITS to 64, so that even 32-bit systems would accept
64-bit addresses and pass then to mmap() correctly. It could be useful
on systems with a 64-bit kernel and 32-bit userspace.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3421 0192ed92-7a03-0410-a25b-9323aeb14dbd
PCI resource addresses are 64-bit on i386 with PAE, so they won't fit
unsigned long. Provide compatibility for older kernels. Reported by
Diego Dujovne.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3399 0192ed92-7a03-0410-a25b-9323aeb14dbd
Remove the old SIOCGATHDIAG ioctl (return -EOPNOTSUPP), and add a new ioctl (SIOCGATHHALDIAG) that passes the struct through ifr_data. Also, return -EOPNOTSUPP for unknown IOCTL numbers.
Incidently, I can't find anything that actually uses the old IOCTL.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3389 0192ed92-7a03-0410-a25b-9323aeb14dbd
This patch differs from the original in that beacon synchronised calibration is not condifured during CAC as no beacons are sent.
Thanks to nbd.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3358 0192ed92-7a03-0410-a25b-9323aeb14dbd
This changeset adds a node statistic. If this is not liked, I encourage it to be fixed; I might learn something.
Thanks nbd.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3334 0192ed92-7a03-0410-a25b-9323aeb14dbd
So, ccmp_attach is called for each new key. Hence, only try to allocate a software context if IEEE80211_KEY_SWCRYPT is specified. Also, if we need a software context and fail, fail immediately; thus, the check in ccmp_setkey can be eleminated, as it is not actually a separate condition.
I think that when I touched this last, I was confused about the purpose of ccmp_attach.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3322 0192ed92-7a03-0410-a25b-9323aeb14dbd
With 0.9.30.13 ANI control appears to be broken. ANI is designed only for client (STA/AHDEMO) only mode. This function updates the data used for ANI, so we will only call it for client only mode. This may will not affect ANI problems in client only mode.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3321 0192ed92-7a03-0410-a25b-9323aeb14dbd
both i386 and x86_64. When calculating TARGET for x86 platform, use
CONFIG_X86 and CONFIG_X86_64 rather than ARCH.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3318 0192ed92-7a03-0410-a25b-9323aeb14dbd
time in ms, or the number of beacons for the
beacon miss alarm. If we haven't had a beacon
in this period, the alarm is sounded and
action (i.e. roaming) is taken.
This patch changes the storage of the beacon
miss threshold to integral beacon count but
corrects the previous intent.
The default beacon miss alarm is going to be
850ms which is half way between the two hard
coded limits that were there before.
The old hard coded limits assumed that the
beacon interval was 100ms and set the limit to
10 (1000ms) for software beacon miss timer
and 7 for hardware beacon miss timer.
The new default is 850ms (the midpoint between
the two previous defaults). This value is rounded
up to the next nearest beacon interval.
There is no upper bound on the beacon miss
threshold specified, since it may need to be
wildly inflated with 25ms beacon interval, or
wildly reduced with 1000ms beacon interval.
The minimum is still 2 beacons, regardless of
the beacon interval.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3314 0192ed92-7a03-0410-a25b-9323aeb14dbd
Section mismatch checker in the forthcoming Linux 2.6.25 complains about
ath_pci_drv_id and recommends to rename it. Rename ath_pci_drv_id to
ath_pci_driver, which is consistent with other PCI drivers.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3312 0192ed92-7a03-0410-a25b-9323aeb14dbd
* Based on patches from nbd
* av_beacon_alloc code has been reimplemented using atomic bit operations; I think this is safe for SMP
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3310 0192ed92-7a03-0410-a25b-9323aeb14dbd
dropped frames a little more consistent and
fixes an issue in hardstart where I was being
too aggressive about requeing.
I thought the slab allocator would stop handing
out skbuff instances before the system was out
of free memory based upon some kind of limit on
the number of buffers, but this was nonsense.
Therefore, it is NOT a good idea to requeue
when skb allocation fails because this pretty
much basically means we are out of free memory.
Keeping the packets we do not have the RAM to
send and then stopping the transmit queue has
very bad side effects under low/zero memory
conditions.
Symptoms may include OOM killer and panics,
among other things.
It's better to drop tx packets when there's no
more RAM than to lock all the tx packets up
in the transmit queue. Even if more skb
become freed up in the slab cache due to
transmissions already in progress, evil things
still happen.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3308 0192ed92-7a03-0410-a25b-9323aeb14dbd
messages from 1000 to 192 and drop the length
needed to display the [atomic] node count.
Slamming this much data on the stack can cause
stack overflows with 4k stacks quite easily,
especially when hard interrupts occur and
extend a stack that is already almost full.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3307 0192ed92-7a03-0410-a25b-9323aeb14dbd
