between kernel virtual address and physical address anymore. This so
that we can link the kernel at some virtual address without having
to worry whether the corresponding physical memory exists and is
available. The PBVM uses 64KB pages that are mapped to physical
addresses using a page table. The page table is at least 1 EFI page
in size, but can grow up to 1MB. This effectively gives us a memory
size between 32MB and 8GB -- i.e. enough to load a DVD image if one
wants to.
The loader assigns physical memory based on the EFI memory map and
makes sure that all physical memory is naturally aligned and a power
of 2. At this time there's no consideration for allocating physical
memory that is close to the BSP.
The kernel is informed about the physical address of the page table
and its size and can locate all PBVM pages through it.
The loader does not wire the PBVM page table yet. Instead it wires
all of the PBVM with a single translation. This is fine for now,
but a follow-up commit will fix it. We cannot handle more than 32MB
right now.
Note that the loader will map as much of the loaded kernel and
modules as possible, but it's up to the kernel to handle page faults
for references that aren't mapped. To make that easier, the page
table is mapped at a fixed virtual address.
o Move the backing store in the top half of region 0 now that
region 4 is re-assigned to be part of the kernel.
o De-emphasize VM_MAX_ADDRESS. It's really not used anywhere and probably
means something different than the limit for process address space (we
have VM_MAXUSER_ADDRESS for that).
o Exclude the gateway page from VM_MAXUSER_ADDRESS (i.e. make it the same
as VM_MAX_ADDRESS).
support for it. Note that while sparc64 also supports the static TLS
model and thus tls_model("initial-exec"), using the default model
turned out to yield slightly better buildstone performance.
- Emitt an error when encountering an unsupported and in case of the
kernel also for unaligned relocations.
- Fix R_SPARC_LOX10 relocations. Apparently these are hardly ever used.
- Add the _RF_X committed in r212998 also to the tables in the sparc64
reloc.c in order reduce differences between the kernel and the userland
source. This results in no functional change though.
- Fix further inconsistencies in the abbreviations of the names of the
relocations.
- Further whitespace fixes.
Obtained from: NetBSD [1]
* elf64-sparc.c (sparc64_elf_relocate_section): Adjust addend of
dynamic relocs against section symbols for the output section vma.
However, with the addition of TLS support in the upstream rev. 1.104
this fix was essentially reverted. After factoring out the common parts
of elf32-sparc.c and elf64-sparc.c a comment was added to elfxx-sparc.c
in the upstream rev. 1.27 as part of unrelated changes, saying that the
fix from elf64-sparc.c rev. 1.61 indeed should be implemented, but given
that some unspecified OS has a broken ld.so expecting broken relocations
deliberately is omitted.
As the current behavior actually violates the SPARC ABI, FreeBSD never
had such a broken ld.so and this is actually causing problems with at
least kernel modules linked with binutils 2.17.50 committed in r218822
without the workaround committed in r219340 in place, re-implement the
above fix in a way so that is only applied if the output format is
ELFOSABI_FREEBSD. In the upstream version it probably would make sense
to invert this check and only skip adjusting the addend for the OS with
the broken ld.so, once it's determine which one that is.
Approved by: dim
This is a minor cosmetic change - the users are more likely to want to
increase (rather than decrease) default kernel stack size,
which is already 4 pages on amd64.
MFC after: 4 days
Linux ath9k.
The ath9k ar9002_hw_init_cal() isn't entirely clear about what
is supposed to be called for what chipsets, so I'm ignoring the
rest of it and just porting the AR9285 init cal path as-is and
leaving the rest alone. Subsequent commits may also tidy up the
Merlin (AR9285) and other chipset support.
Obtained from: Linux ath9k
The ath9k driver has a unified boundary/pdadc function, whereas
ours is split into two (one for each EEPROM type.) This is why
the AR9280 check is done here where we could safely assume it'll
always be AR9280 or later.
this is incorrect for Kite (AR9285) and any future chipsets that
override the EEPROM related routines.
It meant that a direct call to set the TX power would call the v14 EEPROM
AR5416/AR9280 calibration routines, rather than the v4k EEPROM routines
for the AR9285. It thus read the incorrect values from the EEPROM and
programmed garbage PDADC and TX power values into the hardware.
c65292b04b98d6a76d58c5a54ca8f81463bf24de to support new SIOCGIFDESCR
ioctl interface which was too late for libpcap 1.1.1.
Reported by: brucec
Noticed by: wxs
The test was support to check if SUID/SGID bits are removed on first
write, but actually we were checking if they were removed after close.
Now we can check if SUID/SGID bits are gone after first write.
While here add checks to see if when both SUID and SGID bits are set they are
both cleared on first write.
