yongari [Wed, 4 Jan 2012 01:38:52 +0000 (01:38 +0000)]
MFC r227675:
Partially revert r218788. r218788 removed calling dc_setcfg() for
!DC_IS_ADMTEK in dc_miibus_statchg(). This change broke link
establishment of Intel 21143 with dcphy(4) where it stuck in
"ability detect" state without completing auto-negotiation.
Also nuke dc_if_media as it's not actually used.
yongari [Tue, 3 Jan 2012 23:44:05 +0000 (23:44 +0000)]
MFC r227512:
Overhaul bus_dma(9) usage in driver:
- Don't use a single big DMA block for all rings. Create separate
DMA area for each ring instead. Currently the following DMA
areas are created:
Event ring, standard RX ring, jumbo RX ring, RX return ring,
hardware MAC statistics and producer/consumer status area.
For Tigon II, mini RX ring and TX ring are additionally created.
- Added missing bus_dmamap_sync(9) in various TX/RX paths.
- TX ring is no longer created for Tigon 1 such that it saves more
resources on Tigon 1.
- Data sheet is not clear about alignment requirement of each ring
so use 32 bytes alignment for normal DMA area but use 64 bytes
alignment for jumbo RX ring where the extended RX descriptor
size is 64 bytes.
- For each TX/RX buffers use separate DMA tag(e.g. the size of a
DMA segment, total size of DMA segments etc).
- Tigon allows separate DMA area for event producer, RX return
producer and TX consumer which is really cool feature. This
means TX and RX path could be independently run in parallel.
However ti(4) uses a single driver lock so it's meaningless
to have separate DMA area for these producer/consumer such that
this change creates a single status DMA area.
- It seems Tigon has no limits on DMA address space and I also
don't see any problem with that but old comments in driver
indicates there could be issues on descriptors being located in
64bit region. Introduce a tunable, dev.ti.%d.dac, to disable
using 64bit DMA in driver. The default is 0 which means it would
use full 64bit DMA. If there are DMA issues, users can disable
it by setting the tunable to 0.
- Do not increase watchdog timer in ti_txeof(). Previously driver
increased the watchdog timer whenever there are queued TX frames.
- When stat ticks is set to 0, skip processing ti_stats_update(),
avoiding bus_dmamap_sync(9) and updating if_collisions counter.
- MTU does not include FCS bytes, replace it with
ETHER_VLAN_ENCAP_LEN.
With these changes, ti(4) should work on PAE environments.
Many thanks to Jay Borkenhagen for remote hardware access.
yongari [Tue, 3 Jan 2012 23:36:29 +0000 (23:36 +0000)]
MFC r227431-227432,227505,227509:
r227431:
style.
No functional changes.
r227432:
Remove dead ifdef. Driver should always check raised interrupt is
for the device.
r227505:
It's bad idea to allocate large memory, 4KB, from stack.
Pre-allocate the memory in device attach time. While I'm here
remove unnecessary reassignment of error variable as it was already
initialized. Also added a missing driver lock in TIIOCSETTRACE
handler.
r227509:
Export sysctl node for various interrupt moderation parameters and
have administrators control them. ti(4) provides a character
device to control various other features of driver via ioctls but
users had to write their own code to manipulate these parameters.
It seems some default values for these parameters are not optimal
on today's system but leave it as it was and let administrators
change them. The following parameters could be changed:
The interface has to be brought down and up again before a change
takes effect.
ti(4) controller supports hardware MAC counters with additional
DMA statistics. So it's doable to export these counters via
sysctl interface. Unfortunately, these counters are cumulative
such that driver have to either send an explicit clear command to
controller after extracting them or have to maintain internal
counters to get actual changes. Neither look good to me so
counters were not exported via sysctl.
yongari [Tue, 3 Jan 2012 21:16:00 +0000 (21:16 +0000)]
MFC r227347,227367:
r227347:
Retire 'options TI_PRIVATE_JUMBOS' and replace local jumbo
allocator with UMA backed jumbo allocator by default. Previously
ti(4) used sf_buf(9) interface for jumbo buffers but it was broken
at this moment such that enabling jumbo frame caused instant panic.
Due to the nature of sf_buf(9) it heavily relies on VM changes but
it seems ti(4) was not received much blessing from VM gurus. I
don't understand VM magic and implications used in driver either.
Switching to UMA backed jumbo allocator like other network drivers
will make jumbo frame work on ti(4).
While I'm here, fully allocate all RX buffers. This means ti(4) now
uses 512 RX buffer and 1024 mini RX buffers.
To use sf_buf(9) interface for jumbo buffers, introduce a new
'options TI_SF_BUF_JUMBO'. If it is proven that sf_buf(9) is better
for jumbo buffers, interesting developers can fix the issue in
future.
ti(4) still needs more bus_dma(9) cleanups and should use separate
DMA tag/map for each ring(standard, jumbo, mini, command, event
etc) but it should work on all platforms except PAE.
Special thanks to Jay[1] who provided complete remote debugging
access.
r227367:
Comment out TI_JUMBO_HDRSPLIT. TI_JUMBO_HDRSPLIT requires TI_SF_BUF_JUMBO.
yongari [Tue, 3 Jan 2012 20:48:28 +0000 (20:48 +0000)]
MFC r227311-227312,227318-227319,227322-227324:
r227311:
Remove ti_unit member variable in softc.
While I'm here use PCIR_BAR macro.
r227312:
o Remove unnecessary controller reinitialization.
o Do not blindly UP controller when MTU is changed. Reinitialize
controller only if driver is running.
o Remove useless ti_stop() in ti_watchdog() since ti_init_locked()
always invokes ti_stop().
r227318:
Track which ring was updated in RX handler and update only modified
ring. This should reduce unnecessary register accesses.
r227319:
Mini ring is not available on Tigon 1 so do not create DMA maps for
mini ring on Tigon 1 to save resources.
r227322:
Show RX buffer allocation failure and do not blindly send alive
message to firmware. Probably the correct way for this error is to
send a TI_CMD_CODE_STACK_DOWN message to firmware and let firmware
handle the rest.
r227323:
If ti_chipinit() fails in ti_stop(), ignore the error and release
all allocated TX/RX buffer resources. If the interface is brought
to up again after the error, we will leak allocated TX/RX buffers.
r227324:
Do not allow changing MTU to be less than the minimum.
yongari [Tue, 3 Jan 2012 20:24:56 +0000 (20:24 +0000)]
MFC r227091-227095,227098-227099:
r227091:
Make sure to unload loaded DMA area(descriptor, command, event ring).
r227092:
Announce IFCAP_LINKSTATE capability and let network stack know link
state changes. Hide superfluous link up/down message under
bootverbose since if_link_state_change(9) shows that information.
While I'm here, change baudrate with the resolved speed of the
established link instead of blindly setting it 1G. Unfortunately,
it seems there is no way to differentiate 10/100Mbps from
non-gigabit link so just assume we established a 100Mbps link if
current link is not a gigabit link.
r227093:
Introduce ti_ifmedia_upd_locked() to use in driver initialization
and add missing driver lock for both ti_ifmedia_upd() and
ti_ifmedia_sts().
r227094:
Don't clear upper 4bits from VLAN tag information. It's
responsibility of vlan(4) to extract VLAN id from the tag
information and vlan(4) correctly handles it.
r227095:
Don't abuse if_hwassist and make sure enabling corresponding TX/RX
checksum offloading and VLAN hardware tag insertion/stripping from
the currently enabled hardware offloading capabilities.
Previously if_hwassist, which was initialized to TX/RX checksum
offloading, was blindly used to enable both TX and RX checksum
offloading such that disabling either TX or RX checksum offloading
was not possible.
ti(4) controllers support TX/RX checksum offloading with VLAN
tagging so announce TX/RX checksum offloading capability over VLAN
to vlan(4).
Make VLAN hardware tag insertion/stripping honors currently enabled
interface capability instead of blindly enabling VLAN hardware
tagging. This change allows disabling hardware support of VLAN tag.
Because ti(4) supports VLAN oversized frames, make network stack
know the capability by setting if_hdrlen.
While I'm here, rewrite SIOCSIFCAP handler and make sure to
reinitialize controller whenever TX/RX checksum offloading and VLAN
hardware tagging option is changed. The requirement of controller
reinitialization comes from the limitation of Tigon I/II firmware.
Tigon I/II firmware requires all related RCBs should be
reinitialized whenever any of its hardware offloading capabilities
change.
vlan(4) is also notified whenever the parent interface's capability
changes such that it can correctly handle TX/RX checksum offloading
based on parent interface's enabled offloading capabilities.
RX checksum offloading handler was changed to make upper stack use
controller computed partial checksum value. Previously, ti(4) just
set the computed value for any frames(IPv4, IPv6) and the value was
not used in upper stack because driver didn't set CSUM_DATA_VALID
such that upper network stack had to recompute checksum of TCP/UDP
packets. I have no idea how this was not noticed for a long time.
With this change, upper network stack does not have to fully
recompute the checksum such that calculating pseudo checksum based
on partial checksum is sufficient to know whether received packet's
checksum is correct or not. However, I don't know why ti(4) does
not have controller compute pseudo checksum as controller has
ability to do it. I'm just guessing enabling that feature could
trigger a firmware bug or could be slower than computing it on host
side so just leave it as it was.
In order not to produce false positives, ti(4) now checks whether
controller actually computed IP or TCP/UDP checksum by checking
ti_flags field.
r227098:
Because ti(4) drops a driver lock in RX handler, check whether
driver is still running before re-enabling interrupts.
r227099:
Implement altq(4) support.
While I'm here fix a logic error in r227098 where it didn't
re-enable interrupts when TX queue is empty.
yongari [Tue, 3 Jan 2012 18:58:20 +0000 (18:58 +0000)]
MFC r227086-227089:
r227086:
Use ANSI function definations.
r227087:
No functional changes.
r227088:
Make ti(4) build with 'options TI_PRIVATE_JUMBOS'.
This was broken in r175872.
We have a UMA backed jumbo allocator and that is much better
implementation than having a local jumbo buffer allocator in
driver. This local allocator would be removed in near future but
fixing build before removal wouldn't be a bad idea.
fabient [Tue, 3 Jan 2012 16:35:00 +0000 (16:35 +0000)]
MFC r226514,r226526,r226986:
Add a flush of the current PMC log buffer before displaying the next top.
As the underlying block is 4KB if the PMC throughput is low the measurement
will be reported on the next tick. pmcstat(8) use the modified flush API to
reclaim current buffer before displaying next top.
rmacklem [Tue, 3 Jan 2012 16:32:33 +0000 (16:32 +0000)]
MFC: r227690
The old NFS client will crash due to the reply being m_freem()'d
twice if the server bogusly returns an error with the NFSERR_RETERR
bit (bit 31) set. No actual NFS error has this bit set, but it seems
that amd will sometimes do this. This patch makes sure the NFSERR_RETERR
bit is cleared to avoid a crash.
mav [Tue, 3 Jan 2012 12:47:55 +0000 (12:47 +0000)]
MFC r225839:
Import the rest of HID improvements from the branch:
- improve report descriptor parser in libusbhid to handle several kinds of
reports same time;
- add to the libusbhid API two functions wrapping respective kernel IOCTLs
for reading and writing reports;
- tune uhid IOCTL interface to allow reading and writing arbitrary report,
when multiple supported by the device;
- teach usbhidctl to set output and feature reports;
- make usbhidaction support all the same item names as bhidctl.
kib [Tue, 3 Jan 2012 10:30:27 +0000 (10:30 +0000)]
MFC r227102:
Provide typedefs for the type of bit mask for the page bits.
Use the defined types instead of int when manipulating masks.
Supposedly, it could fix support for 32KB page size in the
machine-independend VM layer.
MFC r227103:
Remove redundand definitions. The chunk was missed from r227102.
delphij [Tue, 3 Jan 2012 10:22:09 +0000 (10:22 +0000)]
MFC r226471 (se):
Add missing default values for daily/800.scrub-zfs for documentation
purposes. No functional change, since all parameters are set to their
default values.
MFC r226865 (delphij):
Increase default scrub threshold from 30 days to 5 weeks. Using
whole weeks makes it easier to predicate when the scrub would
happen.
kib [Tue, 3 Jan 2012 10:02:44 +0000 (10:02 +0000)]
MFC r228307:
Force linker error when created shared library contains a relocation
against text. Provide the override switch to turn off the strict
behaviour. Apparently, openssl libcrypto needs it due to assembler
code not being PIC.
yongari [Tue, 3 Jan 2012 00:22:57 +0000 (00:22 +0000)]
MFC r226814-226815,226820-226821,226864,226866-226867:
r226814:
Rename definition of BGE_SOFTWARE_GENCOMM_* to more readable ones.
The origin of GENCOMM seems to come from Alteon Tigon Host/NIC
interface definition where it defines general communications region
which is active when firmware is loaded and running. This region
was used in communication between the host and processor internal
to the Tigon chip.
Broadcom data sheet also defines the region as 'Software Gencomm'
in NetXtreme memory map but lacks detailed description of its
interface so it was hard to know which ones are used for which
interface.
This change shall slightly enhance readability.
No functional changes.
r226815:
Define MAC address mail box and use it instead of using
hard-coded value.
r226820:
Offset 0x6810 is RX-RISC event register. Rename BGE_CPU_EVENT with
BGE_RX_CPU_EVENT for readability.
Additionally define BGE_TX_CPU_EVENT for TX-RSIC event register(BCM570[0-4] only).
r226821:
SRAM offset 0x0C04 is used by driver to inform the IPMI/ASF firmware
about the various driver events like load, unload, reset, suspend,
restart, and ioctl operations.
Define driver's event rather than using hard-coded values. We don't
still send suspend/resume event to firmware.
Previously bge(4) used BGE_SDI_STATUS to send events. Because driver
has to access firmware mail box to inform current state, using
BGE_SDI_STATUS register was wrong. The end result was the same as
BGE_SDI_STATUS is 0x0C04.
No functional changes.
r226864:
Rename BGE_FW_DRV_ALIVE/BGE_FW_PAUSE to BGE_FW_CMD_DRV_ALIVE/BGE_FW_CMD_PAUSE.
Also add more firmware commands(not used yet).
No functional changes.
r226866:
Rename hard-coded value 1 << 14 with BGE_RX_CPU_DRV_EVENT.
This bit(SW event 7 in publicly available data sheet) is used to
make RX CPU handle a firmware command and the bit is automatically
cleared after RX CPU completed the command.
Generally firmware command takes the following steps.
1. Write BGE_SRAM_FW_CMD_MB with a command.
2. Write BGE_SRAM_FW_CMD_LEN_MB with the length of the command in bytes.
3. Write BGE_SRAM_FW_CMD_DATA_MB with actual command data.
4. Generate BGE_RX_CPU_EVENT and let firmware handle the command.
5. Wait for the ACK of the firmware command.
No functional changes.
r226867:
Define BGE_FW_HB_TIMEOUT_SEC and remove one more magic value.
bge(4) sends BGE_FW_CMD_DRV_ALIVE command to firmware every 2
seconds. BGE_FW_CMD_DRV_ALIVE command requires 4 bytes data. This
data contains timeout value in seconds until the next
BGE_FW_CMD_DRV_ALIVE command.
Broadcom recommends driver set the value 3 times longer than the
interval that it sends BGE_FW_CMD_DRV_ALIVE. Currently bge(4) uses
3 seconds so probably we have to increase it in future and use
different ALIVE command(e.g. BGE_FW_CMD_DRV_ALIVE3).
r226770:
Fix long standing bge_sysctl_debug_info() issues.
o Protect bge(4) status block access and register dump with driver lock.
o Add missing bus_dmamap_sync() before dumping status block.
o Use minimum status block size, 32 bytes, for status block dump on most
controllers except BCM5700 AX/BX.
While I'm here, make the handler show 5717 Plus in hardware flags.
r226804:
Make CPMU handle GPHY power down control on controllers that have
CPMU capability.
r226805:
It is known that all Broadcom controllers have 4GB boundary DMA
bug. Apply workaround to all controllers.
r226806:
Broadcom says BCM5755 or higher and BCM5906 have short DMA bug.
Apply workaround to these controllers.
r226807:
BCM5719 cannot handle DMA requests for DMA segments that have
larger than 4KB in size. However the maximum DMA segment size
created in DMA tag is 4KB, so we wouldn't encounter the issue here.
Just record this issue such that let developers not to create a DMA
segment that is larger than 4KB for BCM5719. It's possible to split
a DMA segment into multiple smaller ones in run time but I believe
it's not worth to implement that.
gjb [Mon, 2 Jan 2012 23:43:16 +0000 (23:43 +0000)]
MFC r228356:
r228356:
- Update du(1):
- Sort arguments alphabetically where appropriate
- '-B blocksize' is not mutually exclusive of '-h|-k|-m'
- Mention '-t' in synopsis
- Other wording improvements
- Update usage() output to reflect the new synopsis
- Other miscellaneous improvements
yongari [Mon, 2 Jan 2012 23:35:18 +0000 (23:35 +0000)]
MFC r226701:
Add support for ALi/ULi, now NVIDIA, M5261/M5263 PCI FastEthernet
controller which is found on ULi M1563 South Bridge & M1689 Bridge.
These controllers look like a tulip clone.
M5263 controller does not support MII bitbang so use DC_ROM
register to access MII registers. Like other tulip variants, ULi
controller uses a setup frame to configure RX filter and uses new
setup frame format. It's not clear to me whether the controller
supports a hash based multicast filtering so this patch uses 14
perfect multicast filter to filter multicast frames. If number of
multicast addresses is greater than 14, controller is put into a
mode that receives all multicast frames.
Due to lack of access to M5261, this change was not tested with
M5261 but it probably works. Many thanks to Marco who provided
remote access to M5263.
Tested by: Marco Steinbach <coco <> executive-computing dot de>,
Martin MATO <martin.mato <> orange dot fr>
yongari [Mon, 2 Jan 2012 23:17:45 +0000 (23:17 +0000)]
MFC r226699:
When driver is run for the first time there would be no established
link such that calling dc_setcfg() right after media change would
be meaningless unless controller in question is not Davicom DM9102.
Ideally dc_setcfg() should be called when speed/duplex is resolved
otherwise it would reprogram controller with wrong speed/duplex
information. Because MII status change callback already calls
dc_setcfg() I think calling dc_setcfg() in dc_init_locked() is
wrong. For instance, it would take some time to establish a link
after mii_mediachg(), so blindly calling dc_setcfg() right after
mii_mediachg() will always yield wrong media configuration.
Extend dc_ifmedia_upd() to handle media change and still allow
21143 and Davidcom controllers program speed/duplex regardless of
current resolved speed/duplex of link. In theory 21143 may not need
to call dc_setcfg() right after media change, but leave it as it is
because there are too many variants to test that change. Probably
dc(4) shall need a PHY reset in dc_ifmedia_upd() but it's hard to
verify correctness of the change.
This change reliably makes ULi M5263 establish a link.
While I'm here correctly report media change result. Previously it
always reported a success.
mav [Mon, 2 Jan 2012 18:06:48 +0000 (18:06 +0000)]
MFC r227464, r227471
Major GEOM MULTIPATH class rewrite:
- Improved locking and destruction process to fix crashes.
- Improved "automatic" configuration method to make it consistent and safe
by reading metadata back from all specified paths after writing to one.
- Added provider size check to reduce chance of ordering conflict with
other GEOM classes.
- Added "manual" configuration method without using on-disk metadata.
- Added "add" and "remove" commands to allow manage paths manually.
- Failed paths are no longer dropped from geom, but only marked as FAIL
and excluded from I/O operations.
- Automatically restore failed paths when all others paths are marked
as failed, for example, because of device-caused (not transport) errors.
- Added "fail" and "restore" commands to manually control FAIL flag.
- geom is now destroyed on last path disconnection.
- Added optional Active/Active mode support. Unlike Active/Passive
mode, load evenly distributed between all working paths. If supported by
the device, it allows to significantly improve performance, utilizing
bandwidth of all paths. It is controlled by -A option during creation.
Disabled by default now.
- Improved `status` and `list` commands output.
mav [Mon, 2 Jan 2012 17:56:45 +0000 (17:56 +0000)]
MFC r226816:
Clarify disks/volumes above 2TiB support in geom_raid:
- add support for volumes above 2TiB with Promise metadata format;
- enforse and document other limitations:
- Intel and Promise metadata formats do not support disks above 2TiB;
- NVIDIA metadata format does not support volumes above 2TiB.
mav [Mon, 2 Jan 2012 17:36:14 +0000 (17:36 +0000)]
MFC r227637:
Introduce CAM_SIM_POLLED SIM flag, indicating that it works in polling mode.
It blocks CAM SWI usage on requests completion, unneeded because of polling
and denied during kernel dumping because of blocked scheduler.
Before r198899 there was periph flag CAM_PERIPH_POLLED, but that was wrong,
because there is whole SIM is polled or handled by SWI, not a single periph.
mav [Mon, 2 Jan 2012 17:27:07 +0000 (17:27 +0000)]
MFC r226680:
Some dmesg cosmetics:
- for the legacy PCI ATA channels move channel number out of the device
description, same as it is for ahci(4), siis(4) and mvs(4);
- add device description for the ISA ATA channels.
mav [Mon, 2 Jan 2012 17:19:58 +0000 (17:19 +0000)]
MFC r228200:
Add hw.ahci.force tunable to control whether AHCI drivers should attach
to known AHCI-capable chips (AMD/NVIDIA), configured for legacy emulation.
Enabled by default to get additional performance and functionality of AHCI
when it can't be enabled by BIOS. Can be disabled to honor BIOS settings if
needed for some reason.
mav [Mon, 2 Jan 2012 17:13:56 +0000 (17:13 +0000)]
MFC r227635:
Change the way how "not implemented" AHCI channels handled. Instead of
completely skipping them, create ahcich devices for them to allocate unit
numbers, but mark them as disabled to prevent driver probe and attach.
Last time some BIOSes tend to report unused channels as "not implemented".
This change makes ahcichX devices numbering consistent, independently of
connected disks. It makes per-channel driver hints usable and CAM devices
wiring possible on such systems.
rmacklem [Mon, 2 Jan 2012 16:54:21 +0000 (16:54 +0000)]
MFC: r227543
Modify the new NFS client so that nfs_fsync() only calls ncl_flush()
for regular files. Since other file types don't write into the
buffer cache, calling ncl_flush() is almost a no-op. However, it does
clear the NMODIFIED flag and this shouldn't be done by nfs_fsync() for
directories.
mdf [Mon, 2 Jan 2012 16:14:52 +0000 (16:14 +0000)]
MFC r228444:
- Define true and false in sys/types.h for _KERNEL consumers, and
typedef bool. Due to macro expansion it seemed better to use a
typedef for kernel consumers (specifically ofed won't compile
without more changes if a define is used).
- <stdbool.h> should also not re-define bool/true/false if they are
defined by <sys/types.h>. It would probably be a programming error
to define _KERNEL for user-space code, but downstream consumers
like Isilon have already been including <stdbool.h> in kernel
sources, and this protects that usage.
- sizeof(_Bool) is not necessarily the same as sizeof(int), so kernel
modules should be rebuilt with this change. Bump __FreeBSD_version.
No KBI change is expected based on review of the code.
dim [Mon, 2 Jan 2012 13:21:34 +0000 (13:21 +0000)]
MFC r228868:
When building the kernel for amd64 with clang, don't attempt to use the
-frename-registers option, as it is not supported. No change for builds
with gcc.
dim [Mon, 2 Jan 2012 13:20:01 +0000 (13:20 +0000)]
MFC r228861:
Set WERROR= for the nve(4) module. This driver gives several warnings
with clang, which will probably never be fixed, as it is unmaintained,
and superseded by nfe(4).
dim [Mon, 2 Jan 2012 13:17:31 +0000 (13:17 +0000)]
MFC r228822:
When building the kernel with clang, it produces several warnings which
might be useful in some cases, but which are not severe enough to error
out the whole kernel build. Display them anyway, so there is at least
some incentive to fix them eventually.
Start with -Wtautological-compare warnings. These usually occur when
people check if unsigned quantities are negative, or similar cases. To
clean these up would be painful, and might give problems if the base
type which is compared against changes to signed later on.
MFC r228841:
Amend r228822 by not directly adding to CWARNFLAGS, but to an optional
CWARNEXTRA variable, which gets included into the initial CWARNFLAGS
setting. This makes it easier to override CWARNFLAGS with completely
custom settings (including enabling any disabled warnings).
Reminded by: arundel
MFC r228860:
Make another clang warning, -Wempty-body, non-fatal during kernel
builds. All the instances of this warning in our tree are completely
harmless. (Most of the empty bodies look to be used simply as reminder
for the developer to add something later.)
While here, assign to CWARNEXTRA with ?=, so it can be overridden
easily, if needed.
MFC r228867:
Make another clang warning, -Wparentheses-equality, non-fatal during
kernel builds. All the instances of this warning in our tree are
completely harmless, and many people seem to like adding extra
parentheses to make precedence clearer.
dim [Mon, 2 Jan 2012 13:12:53 +0000 (13:12 +0000)]
MFC r228801:
Remove -mfancy-math from LIB32CPUFLAGS for amd64. It has been default
for our gcc since more than three years (see r181534, which is also in
stable/9 and stable/8). This flag used to be for the benefit of the old
in-kernel math emulator, which was removed more than eight years ago.
dim [Mon, 2 Jan 2012 13:01:57 +0000 (13:01 +0000)]
MFC r228783:
When building with clang, disable -Wshift-count-negative and
-Wshift-count-overflow for sys/dev/ath/ath_hal/ah_regdomain.c, as it
gets multiple instances of the following warnings:
Both warnings are false positives, caused by LLVM PR 10030. For global
initializations, clang fails to detect that the branch of the ternary
operator causing the warning is dead.
MFC r228793:
Amend r228783 by also disabling -Wshift-count-negative
-Wshift-count-overflow warnings for the ath module.
MFC r228818:
Disable various warnings for the ath module in a more fine-grained way:
only add the option for the specific .c files that need them, like via
sys/conf/files.
dim [Mon, 2 Jan 2012 12:53:11 +0000 (12:53 +0000)]
MFC r228781:
When building with clang, disable -Warray-bounds for sys/dev/asr/asr.c,
as it gets the following warning:
sys/dev/asr/asr.c:1836:29: warning: array index of '58' indexes past the end of an array (that contains 1 element) [-Warray-bounds]
while ((len > 0) && (sg < &((PPRIVATE_SCSI_SCB_EXECUTE_MESSAGE)
^
sys/dev/asr/i2omsg.h:934:8: note: array 'Simple' declared here
I2O_SGE_SIMPLE_ELEMENT Simple[1];
^
This is a false positive, since I2O_SG_ELEMENT::Simple is not declared
as a C99 flexible array member, but in the old (but more portable) way.
At run-time, the proper number of array elements will hopefully have
been allocated.
MFC r228865:
Amend r228781 by also disabling -Warray-bounds warnings for the asr
module.
dim [Mon, 2 Jan 2012 12:50:19 +0000 (12:50 +0000)]
MFC r228779:
Start selectively disabling a few kernel build warnings for clang, since
there are some places in the kernel where fixing them is too disruptive,
or where there is a false positive.
In this case, disable -Wconstant-conversion for two aic7xxx-related
files, as they get the following warning on i386 (and possibly on other
32-bit arches):
sys/dev/aic7xxx/ahc_pci.c:112:10: warning: implicit conversion from 'long long' to 'bus_addr_t' (aka 'unsigned int') changes value from 549755813887 to 4294967295 [-Wconstant-conversion]
? 0x7FFFFFFFFFLL
~~^~~~~~~~~~~~~~
This is a false positive, since the code only passes the 0x7FFFFFFFFFLL
argument, if sizeof(bus_addr_t) is larger than 4 (e.g. on 64 bit arches,
or when PAE is enabled on i386). The code could be refactored to do
compile-time checks, but that is more disruptive.
MFC r228789:
Amend r228779 by also disabling -Wconstant-conversion warnings for the
aic7xxx module.
MFC r228805:
Disable -Wconstant-conversion warnings for the aic7xxx module in a more
fine-grained way: only add the option for the specific .c files that
need them, like via sys/conf/files.
rmacklem [Mon, 2 Jan 2012 04:25:25 +0000 (04:25 +0000)]
MFC: r227517
Move the setting of the default value for nm_wcommitsize to
before the nfs_decode_args() call in the new NFS client, so
that a specfied command line value won't be overwritten.
Also, modify the calculation for small values of desiredvnodes
to avoid an unusually large value or a divide by zero crash.
It seems that the default value for nm_wcommitsize is very
conservative and may need to change at some time.
kib [Mon, 2 Jan 2012 00:04:51 +0000 (00:04 +0000)]
MFC r228751:
Change the type of real_dev_bsize variable from long to u_int.
The DIOCGSECTORSIZE takes u_int * as an argument, using long *
causes failures on big-endian targets.
dim [Sun, 1 Jan 2012 23:53:16 +0000 (23:53 +0000)]
MFC r228722:
In usr.sbin/yp_mkdb/yp_mkdb.c, cast some printf field width parameters
to int, cast time_t to intmax_t, and use the corresponding printf length
modifier.
kib [Sun, 1 Jan 2012 23:51:18 +0000 (23:51 +0000)]
MFC r228306:
Most users of pipe(2) do not call fstat(2) on the returned pipe descriptors.
Optimize for the case, by lazily allocating the pipe inode number at the
fstat(2) time.
dim [Sun, 1 Jan 2012 23:49:11 +0000 (23:49 +0000)]
MFC r228714:
In usr.sbin/timed, fix several issues with printf formats:
- Cast time_t's to long, and print them with %ld.
- Print ptrdiff_t's with %td.
- Print ssize_t's and size_t's with %zd and %zu.
- Print int32_t's with %d.
Also, replace some int variables with the more appropriate size_t.
MFC r228719:
Some people pointed out long is 32-bit on some arches, while time_t is
64-bit, so better cast time_t to intmax_t, and use the appropriate
printf format strings.
MFC r228720:
Fix r228719; when you use intmax_t, you need stdint.h.
dim [Sun, 1 Jan 2012 23:45:21 +0000 (23:45 +0000)]
MFC r228713:
In contrib/tcpdump/print-icmp6.c, fix a problem where the comparison
against icmp6_hdr::icmp6_type is done incorrectly. (This fix has
already been applied upstream, but we do not have the latest version of
tcpdump.)
dim [Sun, 1 Jan 2012 23:39:56 +0000 (23:39 +0000)]
MFC r228678:
In usr.sbin/rpc.ypupdated/yp_dbupdate.c, use the appropriate printf
length modifier for time_t (after casting it to intmax_t).
MFC r228679:
In usr.sbin/rpc.ypupdated/yp_dbupdate.c, include stdint.h, so intmax_t
is known, otherwise it won't build.
Pointy hat to: dim
MFC r228680:
In usr.sbin/rpc.ypupdated/yp_dbupdate.c, since intmax_t is signed, just
like time_t, better use %jd instead of %ju. Strangely enough, neither
gcc, clang nor gcc 4.6 warn about this discrepancy...
kib [Sun, 1 Jan 2012 23:34:06 +0000 (23:34 +0000)]
MFC r227656:
Use the alternate form of the gcc extension that works even with
-ansi -pedantic without issuing a warning, and which is recommended
by gcc manual.
kib [Sun, 1 Jan 2012 23:12:43 +0000 (23:12 +0000)]
MFC r227696:
Do not use NULLVPTOLOWERVP() in the null_print(). If diagnostic is compiled
in, and show vnode is used from ddb on the faulty nullfs vnode, we get
panic instead of vnode dump.
dim [Sun, 1 Jan 2012 23:08:19 +0000 (23:08 +0000)]
MFC r228665:
Use NO_WCAST_ALIGN for usr.sbin/ndiscvt; because this is only built for
x86, any alignment warnings can be safely ignored. Define YY_NO_INPUT
in usr.sbin/ndiscvt/inf-token.l, so no unused lex functions are defined.