davide [Sat, 23 Jun 2012 17:46:42 +0000 (17:46 +0000)]
MFC r237196:
Disable hwpmc(4) support for Intel Xeon Sandy Bridge (Model 0x2D).
Due to some differences in MSRs between Xeon Sandy Bridge and Core Sandy
Bridge (Model 0x2A), wrmsr() may generate in a GP# fault exception and so a
panic of the machine.
davide [Sat, 23 Jun 2012 17:39:40 +0000 (17:39 +0000)]
MFC r237195:
The variable 'error' in sys_poll() is initialized in declaration to value
zero but in any case is overwritten by successive copyin(), making the
previous initialization useless. Remove this.
As an added bonus this fixes a style(9) bug.
mav [Sat, 23 Jun 2012 07:45:14 +0000 (07:45 +0000)]
MFC r237335:
Check status of cam_periph_hold() inside cdclose(). If cd device was
invalidated while open, cam_periph_hold() will return error and won't
get the reference. Following reference release will crash the system.
delphij [Sat, 23 Jun 2012 00:37:32 +0000 (00:37 +0000)]
MFC r237348:
Currently the code uses gzFile * for a zlib file descriptor, which
is not correct. The code works by accident because gzFile is
currently defined as void *, and internally it would be casted from
or to its real type.
A newer version of zlib will instead define it as a pointer to a
specific type pointer (namely, struct gzFile_s *). This therefore
would cause stricter checks and compiler would catch this type
mismatch.
This change does not cause any changes to the resulting binary,
as validated with md5(1).
marius [Thu, 21 Jun 2012 13:39:56 +0000 (13:39 +0000)]
MFC: r232582 (partial)
- Switch ARM to TLS Variant I.
- Fix TLS allocation for Variant I: both rtld and libc allocators
assume that tls_static_space includes space for TLS structure.
So increment calculated static size by the size of it.
ae [Thu, 21 Jun 2012 12:47:21 +0000 (12:47 +0000)]
MFC r237057:
Always reconstruct partition entries in the PMBR when Boot Camp is
disabled. This helps to easily recover from situations when PMBR is
damaged and contains no entries.
marius [Thu, 21 Jun 2012 11:23:38 +0000 (11:23 +0000)]
MFC: r235348, r236191, r236497
Add glue/support for the SAM9XE512-based Ethernut 5 boards. Currently,
all integrated and on-board peripherals except NAND Flash (missing NAND
framework/integration) are working.
marius [Thu, 21 Jun 2012 11:16:05 +0000 (11:16 +0000)]
MFC: r236496
- Loop up to 3 seconds when waiting for a device to get ready. [1]
- Make the device description match the driver name.
- Identify the chip variant based on the JEDEC and use that information
to use the proper values for page count, offset and size instead of
hardcoding a AT45DB642x with 2^N byte page support disabled.
- Take advantage of bioq_takefirst().
- Given that CONTINUOUS_ARRAY_READ_HF (0x0b) command isn't even mentioned
in Atmel's DataFlash Application Note, as suggested by the previous
comment may not work on all all devices and actually doesn't properly
on at least AT45DB321D (JEDEC 0x1f2701), rewrite at45d_task() to use
CONTINUOUS_ARRAY_READ (0xe8) for reading instead. This rewrite is laid
out in a way allowing to easily add support for BIO_DELETE later on.
- Add support for reads and writes not starting on a page boundary.
- Verify the flash content after writing.
- Let at45d_task() gracefully handle errors on SPI transfers and the
device not becoming ready afterwards again. [1]
- Use DEVMETHOD_END. [1]
- Use NULL instead of 0 for pointers. [1]
marius [Thu, 21 Jun 2012 11:10:49 +0000 (11:10 +0000)]
MFC: r237239
Revert the part of r236495 (MFC'ed to stable/9 in r237095) that
introduced checking of SPI_SR_TXEMPTY for TX transfer completion as
for reasons unknown this occasionally causes SPI_SR_RXBUFF and
SPI_SR_ENDRX to not rise.
In any case, once the RX part of the transfer is done it's obvious
that the preceding TX part had finished and checking of SPI_SR_TXEMPTY
was introduced to rule out a possible cause for the data corruption
mentioned in r236495 but which didn't turn out to be the problem
anyway.
marius [Thu, 21 Jun 2012 11:06:29 +0000 (11:06 +0000)]
MFC: r230242, r237102, r237236
- Add support for the FT2232 based egnite Turtelizer 2 JTAG/RS232 Adapter.
This includes adding support for skipping FTDI interfaces used for JTAG
leaving them for userland and just attaching to the RS232 half, similarly
to how the corresponding Linux drivers handles these kind of adapters.
While at it, sort uftdi_devs and return BUS_PROBE_SPECIFIC (because
uftdi_probe() alters the instance variables for better or worse as do
other probe routines of USB drivers) instead of 0.
- Remove duplicated entries for BeagleBone.
- Use DEVMETHOD_END.
- Use NULL instead of 0 for pointers.
- Remove some stray lines.
mav [Thu, 21 Jun 2012 10:28:59 +0000 (10:28 +0000)]
MFC r236952:
- Limit r214102 workaround to only x86. On arm it causes more problems
then solves because of cache coherency issues. This fixes periodic error
messages on console and command timeouts.
- Patch SATA PHY configuration for 65nm SoCs to improve SNR same as
Linux does.
mckusick [Thu, 21 Jun 2012 04:02:07 +0000 (04:02 +0000)]
MFC of 236937
In softdep_setup_inomapdep() we may have to allocate both inodedep
and bmsafemap dependency structures in inodedep_lookup() and
bmsafemap_lookup() respectively. The setup of these structures must
be done while holding the soft-dependency mutex. If the inodedep is
allocated first, it may be freed in the I/O completion callback when
the mutex is released to allocate the bmsafemap. If the bmsafemap is
allocated first, it may be freed in the I/O completion callback when
the mutex is released to allocate the inodedep.
To resolve this problem, bmsafemap_lookup has had a parameter added
that allows a pre-malloc'ed bmsafemap to be passed in so that it does
not need to release the mutex to create a new bmsafemap. The
softdep_setup_inomapdep() routine pre-malloc's a bmsafemap dependency
before acquiring the mutex and starting to build the inodedep with a
call to inodedep_lookup(). The subsequent call to bmsafemap_lookup()
is passed this pre-allocated bmsafemap entry so that it need not
release the mutex if it needs to create a new one.
mckusick [Thu, 21 Jun 2012 03:58:10 +0000 (03:58 +0000)]
MFC of 236825
When synchronously syncing a device (MNT_WAIT), wait for buffers
to become available. Otherwise we may excessively spin and fail
with ``fsync: giving up on dirty''.
mav [Wed, 20 Jun 2012 16:51:14 +0000 (16:51 +0000)]
MFC r236814:
One more major cam_periph_error() rewrite to improve error handling and
reporting. It includes:
- removing of error messages controlled by bootverbose, replacing them
with more universal and informative debugging on CAM_DEBUG_INFO level,
that is now built into the kernel by default;
- more close following to the arguments submitted by caller, such as
SF_PRINT_ALWAYS, SF_QUIET_IR and SF_NO_PRINT; consumer knows better which
errors are usual/expected at this point and which are really informative;
- adding two new flags SF_NO_RECOVERY and SF_NO_RETRY to allow caller
specify how much assistance it needs at this point; previously consumers
controlled that by not calling cam_periph_error() at all, but that made
behavior inconsistent and debugging complicated;
- tuning debug messages and taken actions order to make debugging output
more readable and cause-effect relationships visible;
- making camperiphdone() (common device recovery completion handler) to
also use cam_periph_error() in most cases, instead of own dumb code;
- removing manual sense fetching code from cam_periph_error(); I was told
by number of people that it is SIM obligation to fetch sense data, so this
code is useless and only significantly complicates recovery logic;
- making ada, da and pass driver to use cam_periph_error() with new limited
recovery options to handle error recovery and debugging in common way;
as one of results, CAM_REQUEUE_REQ and other retrying statuses are now
working fine with pass driver, that caused many problems before.
- reverting r186891 by raj@ to avoid burning few seconds in tight DELAY()
loops on device probe, while device simply loads media; I think that problem
may already be fixed in other way, and even if it is not, solution must be
different.
mav [Wed, 20 Jun 2012 14:36:09 +0000 (14:36 +0000)]
MFC r236712:
To make CAM debugging easier, compile in some debug flags (CAM_DEBUG_INFO,
CAM_DEBUG_CDB, CAM_DEBUG_PERIPH and CAM_DEBUG_PROBE) by default.
List of these flags can be modified with CAM_DEBUG_COMPILE kernel option.
CAMDEBUG kernel option still enables all possible debug, if not overriden.
Additional 50KB of kernel size is a good price for the ability to debug
problems without rebuilding the kernel. In case where size is important,
debugging can be compiled out by setting CAM_DEBUG_COMPILE option to 0.
kib [Tue, 19 Jun 2012 10:04:36 +0000 (10:04 +0000)]
MFC r236976:
For incompleted block allocations or frees, the inode block count usage
must be recalculated. The blk_check pass of suj checker explicitely marks
inodes which owned such blocks as needing block count adjustment. But
ino_adjblks() is only called by cg_trunc pass, which is performed before
blk_check. As result, the block use count for such inodes is left wrong.
This causes full fsck run after journaled run to still find inconsistencies
like 'INCORRECT BLOCK COUNT I=14557 (328 should be 0)' in phase 1.
Fix this issue by running additional adj_blk pass after blk_check, which
updates the field.
mjacob [Sun, 17 Jun 2012 21:28:11 +0000 (21:28 +0000)]
MFC of r236427
Clean up and complete the incomplete deferred enable code.
Make the default role NONE if target mode is selected. This
allows ctl(8) to switch to/from target mode via knob settings.
If we default to role 'none', this causes a reset of the
24XX f/w which then causes initiators to wake up and notice
when we come online.
dougb [Sun, 17 Jun 2012 21:06:36 +0000 (21:06 +0000)]
Improve the functionality of the PORTS_MODULES knob by adding
LOCALBASE/bin and sbin to PATH, which allows dependencies to be found;
adding SRC_BASE and OSVERSION to match the new kernel, and putting the
related builds under MAKEOBJDIRPREFIX so that they only need to be built
once per kernel.
In addition to the PR this includes ideas/contributions from crees
and matthew.
PR: ports/161452
Submitted by: Garrett Cooper <yanegomi@gmail.com>
marius [Sun, 17 Jun 2012 11:16:14 +0000 (11:16 +0000)]
MFC: r237107
- As a baind-aid, disable ATAPI DMA when using ATA_CAM for these controllers
as well as it causes the kernel to hang during boot.
Reported and tested by: Kevin Oberman
- Use NULL instead of 0 for a pointer.
marius [Sun, 17 Jun 2012 09:42:56 +0000 (09:42 +0000)]
MFC: r237101
Fix a braino in r236469 (MFC'ed to stable/9 in r236468); the number of
DMA tags required for handling MAXPHYS should be based on PAGE_SIZE rather
than SYM_CONF_DMA_BOUNDARY.
While at it, reuse the SYM_CONF_MAX_SG macro for specifying the maximum
number of DMA tags so sym(4) itself doesn't size memory beyond what's
required for handling MAXPHYS.
kib [Sun, 17 Jun 2012 07:14:58 +0000 (07:14 +0000)]
MFC r236848:
Use the previous stack entry protection and max protection to correctly
propagate the stack execution permissions when stack is grown down.
kib [Sat, 16 Jun 2012 13:22:55 +0000 (13:22 +0000)]
MFC r236456:
Use plain store for atomic_store_rel on x86, instead of implicitly
locked xchg instruction. IA32 memory model guarantees that store has
release semantic, since stores cannot pass loads or stores.
kib [Fri, 15 Jun 2012 10:38:14 +0000 (10:38 +0000)]
MFC r226342 (by marcel):
In elf32_trans_prot() and when compiling for amd64 or ia64, add
PROT_EXECUTE when PROT_READ is needed. By default i386 allows
execution when reading is allowed and JDK 1.4.x depends on that.
MFC r226343 (by marcel):
In sys_obreak() and when compiling for amd64 or ia64, when the process
is ILP32 (i.e. i386) grant execute permissions by default. The JDK 1.4.x
depends on being able to execute from the heap on i386.
MFC r226347 (by marcel):
In freebsd32_mmap() and when compiling for amd64 or ia64, also
ask for execute permissions when read permissions are wanted.
This is needed for JDK 1.4.x on i386.
MFC r226348 (by marcel):
Wrap mprotect(2).
MFC r226349 (by marcel):
Wrap mprotect(2) so that we can add execute permissions when read
permissions are requested. This is needed on amd64 and ia64 for
JDK 1.4.x.
MFC r226353 (by marcel):
Use PTRIN().
MFC r226388:
Control the execution permission of the readable segments for
i386 binaries on the amd64 and ia64 with the sysctl, instead of
unconditionally enabling it.
MFC note: the syscall tables were regenerated in r226349 and committed
together with changes to non-generated files. The merge includes
syscall tables regenerated after the merge, for stable/9.
mav [Fri, 15 Jun 2012 06:13:12 +0000 (06:13 +0000)]
MFC r236737:
Add IDs for Marvell 88SE9220/9230/9235 PCIe 2.0 x2 6Gbps SATA controllers.
Marvell 88SE9230 was confirmed to work, the rest two are just guessed.
ghelmer [Thu, 14 Jun 2012 21:48:14 +0000 (21:48 +0000)]
MFC 235739-235740,236402:
Apply style(9) to return and switch/case statements.
Add checks for memory allocation failures in appropriate places, and
avoid creating bad entries in the grp list as a result of memory allocation
failures while building new entries.
Style(9) improvements: remove unnecessary parenthesis, improve order
of local variable declarations, remove bogus casts, and resolve long
lines.
obrien [Thu, 14 Jun 2012 20:44:56 +0000 (20:44 +0000)]
MFC: r236338, r236339, r236346, r236347, r236365, & r236977
* Deprecate the FreeBSD make's ":U" (to-upper case) and ":L" (to-lower case)
modifiers for ":tu" and ":tl".
* make it easier to test newly-built make.
* Add "-V '${VAR}'" variable expansion from Portable Berkeley Make.
* regression test for '-V' command line option and the :t[lu] modifiers.
marius [Thu, 14 Jun 2012 20:05:12 +0000 (20:05 +0000)]
MFC: r236495
- Prepend the device description with "AT91" to reflect its nature. [1]
- Move DMA tag and map creature to at91_spi_activate() where the other
resource allocation also lives. [1]
- Flesh out at91_spi_deactivate(). [1]
- Work around the "Software Reset must be Written Twice" erratum.
- For now, run the bus at the slowest speed possible in order to work
around data corruption on transit even seen with 9 MHz on ETHERNUT5
(15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as
a poor man's work-around for the "NPCSx rises if no data data is to be
transmitted" erratum of RM9200. Being able to use the appropriate bus
speed would require:
1) Adding a proper work-around for the RM9200 bug consisting of taking
the chip select control away from the SPI peripheral and managing it
directly as a GPIO line.
2) Taking the maximum frequencies supported by the actual board and the
slave devices into account and basing the whole thing on the master
clock instead of hardcoding a divisor as previously done.
3) Fixing the above mentioned data corruption.
- KASSERT that TX/RX command and data sizes match on transfers.
- Introduce a mutex ensuring that only one child device is running a SPI
transfer at a time. [1]
- Add preliminary, #ifdef'ed out support for setting the chip select. [1]
- Use the RX instead of the TX commando size when setting up the RX side
of a transfer.
- For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the
completion of the TX part of transfers before stopping the whole thing
again.
- Use DEVMETHOD_END. [1]
- Use NULL instead of 0 for pointers. [1, partially]
marius [Thu, 14 Jun 2012 19:55:19 +0000 (19:55 +0000)]
MFC: r236579
The workaround added in r151650 for handling firmwares that don't allow
a single device to be opened multiple times concurrently unfortunately
isn't sufficient with ZFS. This is due to the fact, that ZFS may open
different partitions of a single device simultaneously. So the best we
can do in this case is to cache the lastly used device path and close
and open devices in ofwd_strategy() as needed.
glebius [Thu, 14 Jun 2012 07:51:37 +0000 (07:51 +0000)]
Merge 236560 and following 236563,236598 from head:
Optimise kern_sendfile(): skip cycling through the entire mbuf chain in
m_cat(), storing pointer to last mbuf in chain in local variable and
attaching new mbuf to the end of chain.
Submitter reports that CPU load dropped for > 10% on a web server
serving large files with this optimisation.
glebius [Thu, 14 Jun 2012 07:40:18 +0000 (07:40 +0000)]
Merge r236671 from head:
Merge revision 1.715 from OpenBSD:
date: 2010/12/24 20:12:56; author: henning; state: Exp; lines: +3 -3
in pf_src_connlimit, the indices to sk->addr were swapped.
tracked down and diff sent by Robert B Mills <rbmills at sdf.lonestar.org>
thanks, very good work! ok claudio
mav [Wed, 13 Jun 2012 20:31:30 +0000 (20:31 +0000)]
MFC r230188i (by das):
Correct some bugs that resulted from arm/_fpmath.h being blindly copied
from the x86 version, which has a completely different long double
format.
dim [Wed, 13 Jun 2012 19:53:29 +0000 (19:53 +0000)]
MFC r233098:
Make sure libgcc_s is finished building in _startup_libs before
building libcxxrt with high -j levels. The workaround in
libc++/Makefile isn't necessary once that race is solved.
jhb [Wed, 13 Jun 2012 19:04:39 +0000 (19:04 +0000)]
Ensure that the beginning of the DSS is aligned on a chunk boundary.
If the _end symbol used an address with the low bit set, then the initial
arena could end up with corrupted rb trees causing a crash during the
first call to malloc().
This is a direct commit to stable/9 as it does not affect the version
of malloc in HEAD.
pluknet [Wed, 13 Jun 2012 14:47:03 +0000 (14:47 +0000)]
MFC r234188,r234463,r234465:
- Update the swi_add prototype after struct ithd was split up into
struct intr_event and struct intr_thread. [1]
- Update the rest of struct ithd references.
- net_ih and softclock_ih cookies have gone away.
- Document swi_remove(9).
dim [Tue, 12 Jun 2012 21:03:24 +0000 (21:03 +0000)]
MFC r236578:
Fix build of aicasm when CC=clang. This was due to a side-effect of the
EARLY_BUILD macro: the -Qunused-arguments flag isn't passed anymore when
building this particular program. However, with clang 3.1 and -Werror,
such unused argument warnings are flagged as errors, causing buildkernel
to fail at this stage, due to the -nostdinc flag passed during linking.
Since the -nostdinc flag isn't actually needed, just remove it.
projects / FreeBSD / stable / 9.git / log