exact same (subsystem) device and vendor IDs. However, the reference
design for the OXu16PCI954 uses a 14.7456 MHz clock (as does the EXSYS
EX-41098-2 equipped with these), while at least the OX16PCI954 defaults
to a 1.8432 MHz one. According to the datasheets of these chips, the
only difference in PCI configuration space is that OXu16PCI954 have
a revision ID of 1 while the other two are at 0. So employ the latter
for determining the default clock rates of this family.
Note that one might think that the actual clock could be derived from
the Clock Prescaler Register (CPR) of these chips. Unfortunately, this
is not that case and its use and content are orthogonal to the frequency
of the crystal employed.
Tested with an EXSYS EX-41098-2, which identifies and attaches as:
pcib4@pci0:19:0:0: class=0x060400 card=0x02dd1014 chip=0x10801b21
rev=0x03 hdr=0x01
vendor = 'ASMedia Technology Inc.'
device = 'ASM1083/1085 PCIe to PCI Bridge'
class = bridge
subclass = PCI-PCI
puc0@pci0:20:4:0: class=0x070006 card=0x00001415 chip=0x95011415
rev=0x01 hdr=0x00
vendor = 'Oxford Semiconductor Ltd'
device = 'OX16PCI954 (Quad 16950 UART) function 0 (Uart)'
class = simple comms
subclass = UART
puc1@pci0:20:4:1: class=0x068000 card=0x00001415 chip=0x95111415
rev=0x01 hdr=0x00
vendor = 'Oxford Semiconductor Ltd'
device = 'OX16PCI954 (Quad 16950 UART) function 1 (8bit bus)'
class = bridge
puc2@pci0:20:8:0: class=0x070006 card=0x00001415 chip=0x95011415
rev=0x01 hdr=0x00
vendor = 'Oxford Semiconductor Ltd'
device = 'OX16PCI954 (Quad 16950 UART) function 0 (Uart)'
class = simple comms
subclass = UART
puc3@pci0:20:8:1: class=0x068000 card=0x00001415 chip=0x95111415
rev=0x01 hdr=0x00
vendor = 'Oxford Semiconductor Ltd'
device = 'OX16PCI954 (Quad 16950 UART) function 1 (8bit bus)'
class = bridge
pci20: <ACPI PCI bus> on pcib4
puc0: <Oxford Semiconductor OX16PCI954 UARTs> port 0x5000-0x501f,
0x5020-0x503f mem 0xc6000000-0xc6000fff,0xc6001000-0xc6001fff irq 16 at
device 4.0 on pci20
uart1: <16950 or compatible> at port 1 on puc0
uart2: <16950 or compatible> at port 2 on puc0
uart3: <16950 or compatible> at port 3 on puc0
uart4: <16950 or compatible> at port 4 on puc0
puc1: <Oxford Semiconductor OX9160/OX16PCI954 UARTs (function 1)> port
0x5040-0x505f,0x5060-0x507f mem 0xc6002000-0xc6002fff,0xc6003000-0xc6003fff
irq 16 at device 4.1 on pci20
puc2: <Oxford Semiconductor OX16PCI954 UARTs> port 0x5080-0x509f,
0x50a0-0x50bf mem 0xc6004000-0xc6004fff,0xc6005000-0xc6005fff irq 16 at
device 8.0 on pci20
uart5: <16950 or compatible> at port 1 on puc2
uart6: <16950 or compatible> at port 2 on puc2
uart7: <16950 or compatible> at port 3 on puc2
uart8: <16950 or compatible> at port 4 on puc2
puc3: <Oxford Semiconductor OX9160/OX16PCI954 UARTs (function 1)> port
0x50c0-0x50df,0x50e0-0x50ff mem 0xc6006000-0xc6006fff,0xc6007000-0xc6007fff
irq 16 at device 8.1 on pci20
MFC after: 2 weeks
check which variant we are on, and if it is a VFPv3 or v4, and has 32
double registers we save these. This fixes VFP support on Raspberry Pi.
While here clean fmrx and fmxr up to use the register names from vfp.h
as opposed to the raw register names.
bitmap using sys/bitset. This is much simpler, has lower space
overhead and is cheaper in most cases.
- Use a second bitmap for invariants asserts and improve the quality of
the asserts as well as the number of erroneous conditions that we will
catch.
- Drastically simplify sizing code. Special case refcnt zones since they
will be going away.
- Update stale comments.
Sponsored by: EMC / Isilon Storage Division
Basically the situation is as follows:
- When using Clang + armv6, we should not need any intrinsics. It should
support it, even though due to a target misconfiguration it does not.
We should fix this in Clang.
- When using Clang + noarmv6, provide __atomic_* functions that disable
interrupts.
- When using GCC + armv6, we can provide __sync_* intrinsics, similar to
what we did for MIPS. As ARM and MIPS are quite similar, simply base
this implementation on the one I did for MIPS.
- When using GCC + noarmv6, disable the interrupts, like we do for
Clang.
This implementation still lacks functions for noarmv6 userspace. To be
done.
- Define __SYNC_ATOMICS in case we're using the __sync_*() API. This is
not used by <stdatomic.h> itself, but may be useful for some of the
intrinsics code to determine whether it should build the
machine-dependent intrinsic functions.
- Make is_lock_free() work in kernelspace. For now, assume atomics in
kernelspace are always lock free. This is a quite reasonable
assumption, as we surely shouldn't implement the atomic fallbacks for
arbitrary sizes.
- When looping, check for the pending suspension. Otherwise, other
usermode thread which races with the looping one, could try to
prevent the process from stopping or exiting.
- Add missed checks for the faults from casuword*(). The code is
structured in a way which makes the loops exit if the specified
address is invalid, since both fuword() and casuword() return -1 on
the fault. But if the address is mapped readonly, the typical value
read by fuword() is different from -1, while casuword() returns -1.
Absent the checks for casuword() faults, this is interpreted as the
race with other thread and causes non-interruptible spinning in the
kernel.
Reported and tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Before this change state creating sequence was:
1) lock wire key hash
2) link state's wire key
3) unlock wire key hash
4) lock stack key hash
5) link state's stack key
6) unlock stack key hash
7) lock ID hash
8) link into ID hash
9) unlock ID hash
What could happen here is that other thread finds the state via key
hash lookup after 6), locks ID hash and does some processing of the
state. When the thread creating state unblocks, it finds the state
it was inserting already non-virgin.
Now we perform proper interlocking between key hash locks and ID hash
lock:
1) lock wire & stack hashes
2) link state's keys
3) lock ID hash
4) unlock wire & stack hashes
5) link into ID hash
6) unlock ID hash
To achieve that, the following hacking was performed in pf_state_key_attach():
- Key hash mutex is marked with MTX_DUPOK.
- To avoid deadlock on 2 key hash mutexes, we lock them in order determined
by their address value.
- pf_state_key_attach() had a magic to reuse a > FIN_WAIT_2 state. It unlinked
the conflicting state synchronously. In theory this could require locking
a third key hash, which we can't do now.
Now we do not remove the state immediately, instead we leave this task to
the purge thread. To avoid conflicts in a short period before state is
purged, we push to the very end of the TAILQ.
- On success, before dropping key hash locks, pf_state_key_attach() locks
ID hash and returns.
Tested by: Ian FREISLICH <ianf clue.co.za>
While the changes in r245820 are in line with the ext2 spec,
the code derived from UFS can use negative values so it is
better to relax some types to keep them as they were, and
somewhat more similar to UFS. While here clean some casts.
Some of the original types are still wrong and will require
more work.
Discussed with: bde
MFC after: 3 days
real shared object and libssp_nonshared.a.
This was the last showstopper that prevented from enabling SSP for ports
by default. portmgr@ performed a buildworld which showed no significant
breakage with this patch.
Details:
On i386 for PIC objects, gcc uses the __stack_chk_fail_local hidden
symbol instead of calling __stack_chk_fail directly [1]. This happen
not only with our gcc-4.2.1 but also with the latest gcc-4.8. If you
want the very nasty details, see [2].
OTOH the problem doesn't exist on other architectures. It also doesn't
exist with Clang as the latter will somehow manage to create the
function in the object file at compile time (contrary to only
referencing it through a symbol that will be brought in at link time).
In a perfect world, when an object file is compiled with
-fstack-protector, it will be linked into a binary or a DSO with this
same flag as well, so GCC will add libssp_nonshared.a to the linker
command-line. Unfortunately, we don't control softwares in ports and we
may have such broken DSO. This is the whole point of this patch.
You can reproduce the problem on i386 by compiling a source file into an
object file with "-fstack-protector-all -fPIE" and linking it
into a binary without "-fstack-protector".
This ld script automatically proposes libssp_nonshared.a along with the
real libc DSO to the linker. It is important to understand that the
object file contained in this library will be pulled in the resulting
binary _only if_ the linker notices one of its symbols is needed (i.e.
one of the SSP symbol is missing).
A theorical performance impact could be when compiling, but my testing
showed less than 0.1% of difference.
[1] For 32-bit code gcc saves the PIC register setup by using
__stack_chk_fail_local hidden function instead of calling
__stack_chk_fail directly. See comment line 19460 in:
src/contrib/gcc/config/i386/i386.c
[2] When compiling a source file to an object file, if you use something
which is external to the compilation unit, GCC doesn't know yet if
this symbol will be inside or outside the DSO. So it expects the
worst case and routes the symbol through the GOT, which means
additional space and extra relocation for rtld(1).
Declaring a symbol has hidden tells GCC to use the optimal route (no
GOT), but on the other hand this means the symbol has to be provided
in the same DSO (namely libssp_nonshared.a).
On i386, GCC actually uses an hidden symbol for SSP in PIC objects
to save PIC register setup, as said in [1].
PR: ports/138228
PR: ports/168010
Reviewed by: kib, kan
2011-11-14 Jim Ingham <jingham@apple.com>
* dwarf2read.c (read_type_die): Handle DW_TAG_unspecified_type.
(read_tag_unspecified_type): New function, add a type for the
DW_TAG_unspecified_type die.
Obtained from: Apple, gdb-1752
Only four specific ATA PIO commands transfer several sectors per DRQ block
(interrupt). All other ATA PIO commands transfer one sector or 512 bytes
at one time. Hardcode these exceptions in mvs(4) with ATA_CAM option.
This fixes timeout of READ LOG EXT command used by `smartctl -x /dev/adaX`.
Also it fixes timeout of DOWNLOAD_MICROCODE on `camcontrol fwdownload`.
The reference HAL pushes a config group parameter to the driver layer
to inform it which particular chip behaviour to implement.
This particular value tags it as an AR9285.
The AR9485 chip and AR933x SoC both implement LNA diversity.
There are a few extra things that need to happen before this can be
flipped on for those chips (mostly to do with setting up the different
bias values and LNA1/LNA2 RSSI differences) but the first stage is
putting this code into the driver layer so it can be reused.
This has the added benefit of making it easier to expose configuration
options and diagnostic information via the ioctl API. That's not yet
being done but it sure would be nice to do so.
Tested:
* AR9285, with LNA diversity enabled
* AR9285, with LNA diversity disabled in EEPROM
SPC-4 specification states that serial number may be property of device,
but not a specific logical unit. People reported about FC storages using
serial number in that way, making it unusable for purposes of LUN multipath
detection. SPC-4 states that designators associated with logical unit from
the VPD page 83h "Device Identification" should be used for that purpose.
Report first of them in the new attribute in such preference order: NAA,
EUI-64, T10 and SCSI name string.
While there, make GEOM DISK properly report GEOM::ident in XML output also
using d_getattr() method, if available. This fixes serial numbers reporting
for SCSI disks in `geom disk list` output and confxml.
Discussed with: gibbs, ken
Sponsored by: iXsystems, Inc.
MFC after: 2 weeks
the release/generate-release.sh script by nwhitehorn.
This script can use optional configuration file to override defaults,
making running multiple serialzied builds with different specific
configurations or architecture-specific tunings quite easy.
Sample overrideable options are included in the release.conf.sample
file.
Approved by: kib (mentor)
MFC After: 2 weeks
X-MFC-To: stable/9 only
d_getattr(). Since these drivers use disk(9) KPI and not directly GEOM, use
of that function means KPI layering violation, causing extra g_io_deliver()
call for the request.
While GEOM in general has provider opened while sending BIO_GETATTR,
GEOM DISK does not really need to open disk to read medium-unrelated
attributes for own use.
Proposed by: ken
Explicitly use GNU cpp for preprocessing.
Remove explicit debugging code.
Change some variable names to be less confusing.
Improve some comments.
Improve indentation.
PR: 162211
168785
MFC after: 2 weeks
This adds some new NetBSD releases and makes some simple formatting changes.
With this commit NetBSD and FreeBSD should have identical files.
DragonflyFBSD has the version immediately prior to this commit.
When committing to this file please try to coordinate with all three groups.
Submitted by: Alan Barrett <apb@cequrux.com>
