Add support for Pre-Boot Virtual Memory (PBVM) to the loader.
PBVM allows us to link the kernel at a fixed virtual address without
having to make any assumptions about the physical memory layout. On
the SGI Altix 350 for example, there's no usuable physical memory
below 192GB. Also, the PBVM allows us to control better where we're
going to physically load the kernel and its modules so that we can
make sure we load the kernel in memory that's close to the BSP.
The PBVM is managed by a simple page table. The minimum size of the
page table is 4KB (EFI page size) and the maximum is currently set
to 1MB. A page in the PBVM is 64KB, as that's the maximum alignment
one can specify in a linker script. The bottom line is that PBVM is
between 64KB and 8GB in size.
The loader maps the PBVM page table at a fixed virtual address and
using a single translations. The PBVM itself is also mapped using a
single translation for a maximum of 32MB.
While here, increase the heap in the EFI loader from 512KB to 2MB
and set the stage for supporting relocatable modules.
- Pacific/Apia will have DST on 2 April instead of 3 April in 2011.
- Turkye will go to DST on 28 April instead of 27 April in 2011.
- Cuba will go to DST on 20 April in 2011.
Obtained from: ftp://elsie.nci.nih.gov/pub/
The compiler will truncate the 32-bit return value of mv_gpio_value_get()
to match the 8-bit return value of mv_gpio_in(). A conditional expression
is used to have mv_gpio_in() always return 0 or 1 instead.
Calling rfork_thread(3) does not interoperate with pthreads and global state
is not properly protected.
Remove the BUGS section suggesting LinuxThreads entirely. With the current
pthread library libthr, all threads are kernel-level entities so there seems
little reason to use LinuxThreads.
soon as possible for stack protector. However, dummy timecounter does not
have enough entropy and we don't need to sacrifice Pentium class and later.
Pointed out by: Maxim Dounin (mdounin at mdounin dot ru)
This does a few things in particular:
* Abstracts out the gain control settings into a separate function;
* Configure antenna diversity, LNA and antenna gain parameters;
* Configure ob/db entries - the later v4k EEPROM modal revisions have
multiple OB/DB parameters which are used for some form of
calibration. Although the radio does have defaults for each,
the EEPROM can override them.
This resolves the AR2427 related issues I've been seeing and makes
it stable at all 11g rates for both TX and RX.
These already worked: $# ${#} ${##} ${#-} ${#?}
These now work as well: ${#+word} ${#-word} ${##word} ${#%word}
There is an ambiguity in the standard with ${#?}: it could be the length of
$? or it could be $# giving an error in the (impossible) case that it is not
set. We continue to use the former interpretation as it seems more useful.
in the archive instead of spinning through it to get a file count for the
progress bar. This speeds up installation a lot on systems with slow
CD drives.
The offsets didn't match the assumption that nfarray[] is ordered by the
chainmask bits and programmed via the register order in ar5416_cca_regs[].
This repairs that damage and ensures that chain 1 is programmed correctly.
(And extension channels will now be programmed correctly also.)
This fixes some of the stuck beacons I've been seeing on my AR9160/AR5416
setups - because Chain 1 would be programmed -80 or -85 dBm, which is
higher than the actual noise floor and thus convincing the radio that
indeed it can't ever transmit.
uses of ic_curchan occur. Due to the nature of a scan, switching
channels constantly and all this happening without any kind of locks
held, it might happen that ic_curchan points to nowhere leading to
panics. Fix this by not allowing frame injections while in SCAN state.
Tested by: Paul B. Mahol <onemda at gmail.com>
If multiple networks are available the max bandwidth is one
condition used for selecting the "best" BSS. To achieve that
we should consider all parameters which affect the max RX rate.
This includes 20/40MHz, SGI and the of course the MCS set.
If the TX MCS parameters are available we should use those,
because an AP announcing support for receiving frames at 450Mbps
might only be able to transmit at 150Mbps (1T3R). I haven't seen
devices with support for transmitting at higher rates then
receiving, so prefering TX over RX information should be safe.
While here, remove the hardcoded assumption that MCS15 is the max
possible MCS rate, use MCS31 instead which really is the highest
rate (according to the 802.11n std). Also, fix a mismatch of an
40MHz/SGI check.
Contrary to the rateset information in legacy frames the MCS Set
field also contains TX capability information in cases where the
number of available TX and RX spartial streams differ. Because a
rateset doesn't contain that information we have to pull the
those directly from the hardware capabilities.
