The AR9280 apparently has an issue with descriptors which straddle a page
boundary (4k). I'm not yet sure whether I should use PAGE_SIZE in the
calculations or whether I should use 4096; the reference code uses 4096.
This patch fiddles with descriptor allocation so a descriptor entry
doesn't straddle a 4kb address boundary. The descriptor memory allocation
is made larger to contain extra descriptors and then the descriptor
address is advanced to the next 4kb boundary where needed.
I've tested this both on Merlin (AR9280) and non-Merlin (in this case,
AR9160.)
Obtained from: Linux, Atheros
Approved by: re (kib)
from NetBSD, with some slight changes:
=========================================================================================
http://cvsweb.netbsd.org/bsdweb.cgi/src/libexec/tftpd/tftpd.8?only_with_tag=MAIN#rev1.22
Revision 1.22 or diffs], Fri Jan 8 21:05:14 2010 UTC (18 months, 2 weeks ago) by christos
Patrick Welche <prlw1@cam.ac.uk>
- add -p pathsep option
- make wrap to zero work, but produce a warning
While here:
- fix gcc warnings, in particular variable clobbered warnings
(compiling with fewer warnings does not really fix the problem)
=========================================================================================
These wording changes clarify the default rollover behavior
as a "kludge". Also, the block numbers and octet counts for 65535 blocks
and 32767 blocks are more accurate than the existing documented numbers.
Requested by: Pawan Gupta <pawang at juniper dot net>
Obtained from: Juniper Networks
Approved by: re (kib)
the block counter would rollover to 0 if a file larger
than 65535 blocks was transferred. With the default block size
of 512 octets per block, this is a file size of approximately 32 megabytes.
The new TFTP server code would report an error and stop transferring
the file if a file was larger than 65535 blocks.
This patch restores the old TFTP server's behavior to the new
TFTP server code. If a TFTP client transfers a file larger
than 65535 blocks, and does *not* specify the "rollover" option,
then automatically rollover the block counter to 0 every time
we reach 65535 blocks.
This restores interoperability with the FreeBSD 6 TFTP client.
Without this change, if a FreeBSD 6 TFTP client tried to
retrieve a file larger than 65535 blocks from a FreeBSD 9 TFTP server
, the transfer would fail.
The same file could be retrieved successfully if the same FreeBSD 6
TFTP client was used against a FreeBSD 6 TFTP server.
Approved by: re (kib)
Tested by: Pawan Gupta <pawang at juniper dot net>,
Obtained from: Juniper Networks
historic behavior (create the default base directory in pw.conf) before
I came up with a better fix for this.
Requested by: nwhitehorn
Approved by: re (kib)
failed after the file was created in nfs_create(). This would
probably only happen during a forced dismount. The old NFS client
does have a vput() for this case. Detected by pho during recent
testing, where an open syscall returned with a vnode still locked.
Tested by: pho
Approved by: re (kib)
MFC after: 2 weeks
This is a followup to r222032 and a reimplementation of it.
While that revision fixed the race for the smp_rv_waiters[2] exit
sentinel, it still left a possibility for a target CPU to access
stale or wrong smp_rv_func_arg in smp_rv_teardown_func.
To fix this race the slave CPUs signal when they are really fully
done with the rendezvous and the master CPU waits until all slaves
are done.
Diagnosed by: kib
Reviewed by: jhb, mlaier, neel
Approved by: re (kib)
MFC after: 2 weeks
in the case of a held dataset during remount.
Detailed description is available at:
https://www.illumos.org/issues/883
illumos-gate revision: 13380:161b964a0e10
Reviewed by: pjd
Approved by: re (kib)
Obtained from: Illumos (Bug #883)
MFC after: 3 days
as anonymous namespaces are local to the current translation.
GCC PR: c++/33094
Reviewed by: uqs
Approved by: re (kib)
Obtained from: gcc (branches/redhat/gcc-4_1-branch, rev. 129554, GPLv2)
MFC after: 1 week
allocated the device pager for the given handle, then the object
fictitious pages list and the object membership in the global object
list still need to be initialized. Otherwise, dev_pager_dealloc() will
traverse uninitialized pointers.
Reported and tested by: pho
Reviewed by: jhb
Approved by: re (kensmith)
MFC after: 1 week
This seems to indicate whether to program the NIC for fractional 5ghz
mode (ie, 5mhz spaced channels, rather than 10 or 20mhz spacing) or not.
The default (0) seems to mean "only program fractional mode if needed".
A different value (eg 1) seems to always enable fractional 5ghz mode
regardless of the frequency.
Obtained from: Atheros
Approved by: re (kib)
Calibration/PCI data that's written to flash (rather than EEPROM attached
to the NIC) is typically already in host-endian. The existing checks
end up swapping 16 bit words incorrectly - the correct solution would be
to read the magic value and determine the EEPROM endianness from that.
(This is what Linux does.)
This doesn't completely enable embedded use of the AR9285/AR9287 -
notably, the EEPROM read methods need to be made generic and available
to all EEPROM drivers. I'll worry about that later.
Approved by: re (kib)
* I messed up the order of parameter true/false; oops!
* AR_PHY_RADAR_1 was being written at the wrong place, and was writing
potential garbage to the hardware.
Approved by: re (kib)
memtesting, which can easily save seconds to minutes of boot time.
The tunable name is kept general to allow reusing the code in
alternate frameworks.
Requested by: many
Discussed on: arch (a while a go)
Obtained from: Sandvine Incorporated
Reviewed by: sbruno
Approved by: re (kib)
MFC after: 2 weeks
* Teach the AR5212/AR5416 ANI code to use the RX filter methods, rather
than calling the RX filter routines directly.
* Make HAL_ANI_PRESENT and HAL_ANI_MODE unconditionally available,
regardless of whether ah_ani_function is masking it.
* (Mostly) fully disable ANI if interference mitigation is disabled.
When disabled, the ANI code doesn't touch any ANI/PHY registers,
leaving them the default value. This is in line with what the
Atheros reference driver does.
* Correctly set the ANI parameters during ANI reset, rather than
when ANI is enabled. In this way, if ANI is disabled or enabled
whilst the NIC is not active (and there's no current channel),
bogus parameters or a NULL pointer deference doesn't occur.
There's still some lingering issues - notably, the MIB events/interrupts
aren't fully disabled, so MIB interrupts still occur. I'll worry about
that later.
Approved by: re (kib)
This in particular fixes radar PHY handling - on the AR5212
NIC, one enables the AR_PHY_ERR_RADAR bit in AR_PHY_ERR;
the AR5416 and later also needs a bit set in AR_RX_FILTER.
A follow-up commit is needed to convert the AR5416 ANI code
to use this particular method, as it's currently using the
AR5212 methods directly.
Obtained from: Atheros
Approved by: re (kib)
- Fix usbhidctl and usbhidaction to handle HID devices with multiple
report ids, such as multimedia keyboards.
- Add collection type and report id to the `usbhidctl -r` output. They
are important for proper device understanding and debugging.
- Fix usbhidaction tool to properly handle items having report_count
more then 1.
Approved by: re (kib)
MFC after: 2 weeks
the ADC calibrations if the NIC is in 5ghz 11a or 5ghz HT/20 modes.
I've been told that the dual-ADC is only engaged in turbo/40mhz modes.
Since Sowl (AR9160) seems to return valid-looking calibration data
in 5ghz 20MHz modes, I'm only disabling it for Merlin for now.
It may turn out I can disable it for all chipsets and only enable
it for 40MHz modes.
Approved by: re (kib)
It looks like this was mixed up with the AR9285 calibration code.
This code is now more in line with what Linux ath9k and Atheros
reference drivers do.
Obtained from: Atheros
Approved by: re (kib)
event of a broken or busy fan due to returning incorrect error codes from
the FCU sysctl handler.
Reported by: Path Mather <paul at gromit dot dlib dot vt dot edu>1
Approved by: re (kib)
Although this may not be what the original sysctl was designed to do,
it feels a bit more "expected".
Before, if ANI is disabled, the initial ANI parameters are still written
to the hardware, even if they're not enabled. "ANI enabled" would then
adjust the noise immunity parameters dynamically. Disabling ANI would
simply leave the existing noise immunity parameters where they are,
and disable the dynamic part.
The problem is that disabling ANI doesn't leave the hardware in
a consistent, predictable state - so asking a user to disable ANI
wouldn't actually reset the NIC to a consistent set of PHY signal
detection parameters, resulting in an unpredictable/unreliable outcome.
This makes it difficult to get reliable debugging information from
the user.
Approved by: re (kib)
coordinates, such as digitizers and touch-screens, leaving these devices
to uhid(4) and user-level. Specially patched xf86-input-mouse driver can
handle them, that isn't done and can't be done properly with ums(4)
because of mouse(4) protocol limitations.
Approved by: re (kib)
Slot field of the PxCMD register may point to an empty command slot.
That breaks command timeout detection logic, making impossible to find
what command actually caused timeout, and leading to infinite wait.
Workaround that by checking whether pointed command slot is really used
and can timeout in its time. And if not, fallback to the dumb algorithm
used with FBS -- let all commands to time out and then fail all of them.
Approved by: re (kib)
MFC after: 1 week
respond to any commands. I've found that because of multiple command
retries, each of which cause 30s timeout, bus reset and another retry or
requeue for many commands, it may take ages to eventually drop the
failed device. The odd thing is that those retries continue even after
XPT considered device as dead and invalidated it.
This patch makes cam_periph_error() to block any command retries after
periph was marked as invalid. With that patch all activity completes in
1-2 minutes, just after several timeouts, required to consider device
death. This should make ZFS, gmirror, graid, etc. operation more robust.
Reviewed by: mjacob@ on scsi@
Approved by: re (kib)
data when 'show drives' succeeds, often resulting in a failing exit code
even though the command worked fine.
Reviewed by: bz
Approved by: re (kib)
MFC after: 3 days
the right SIM in case the HBA is RAID-capable but the target in question is
not a hot spare or member of a RAID volume.
- Report the loss and addition of SAS and SATA targets detected via PHY link
status changes and signalled by MPI_EVENT_SAS_DEVICE_STATUS_CHANGE to cam(4)
as lost devices and trigger rescans as appropriate. Without this it can take
quite some time until a lost device actually is no longer tried to be used,
if it ever stops. [1]
- Handle MPI_EVENT_IR2, MPI_EVENT_LOG_ENTRY_ADDED, MPI_EVENT_SAS_DISCOVERY
and MPI_EVENT_SAS_PHY_LINK_STATUS silently as these serve no additional
purpose beyond adding cryptic entries to logs.
Thanks to Hans-Joerg Sirtl for providing one of the HBAs these changes were
developed with and RIP to the mainboard that didn't survive testing them.
PR: 157534 [1]
Approved by: re (kib)
MFC after: 2 weeks
- Sprinkle some const where appropriate.
- Consistently use target_id_t for the target parameter of mpt_map_physdisk()
and mpt_is_raid_volume().
- Fix some whitespace bugs.
Approved by: re (kib)
recommended to allow root users in the jail to access the host system.
PR: docs/156853
Submitted by: crees
Patch by: crees
Approved by: re (kib) for BETA1
you were stuck in an endless loop.
Reported by: kensmith
Approved by: re (kib) for BETA1
Pointy hat to: bz - wonder why I had not tested legacy IP thoroughly..
This is done per request/suggestion from John Baldwin
who introduced the option. Trying to resume normal
system operation after a panic is very unpredictable
and dangerous. It will become even more dangerous
when we allow a thread in panic(9) to penetrate all
lock contexts.
I understand that the only purpose of this option was
for testing scenarios potentially resulting in panic.
Suggested by: jhb
Reviewed by: attilio, jhb
X-MFC-After: never
Approved by: re (kib)
