The new driver changed the size of the mfi_dcmd_frame structure in such a
way that a MFI_IOC_PASSTHRU ioctl from an old amd64 binary is treated as an
MFI_IOC_PASSTHRU32 ioctl in the new driver. As a result, the user pointer
is treated as the buffer length. mfi_user_command() doesn't have a bounds
check on the buffer length, so it passes a really big value to malloc()
which panics when it tries to exhaust the kmem_map. Fix this two ways:
- Only honor MFI_IOC_PASSTHRU32 if the binary has the SV_ILP32 flag set,
otherwise treat it as an unknown ioctl.
- Add a bounds check on the buffer length passed by the user. For now
it fails any user attempts to use a buffer larger than 1MB.
While here, fix a few other nits:
- Remove an unnecessary check for a NULL return from malloc(M_WAITOK).
- Use the ENOTTY errno for invalid ioctl commands instead of ENOENT.
MFC after: 3 days
The RX EDMA support requires a modified approach to the RX descriptor
handling.
Specifically:
* There's now two RX queues - high and low priority;
* The RX queues are implemented as FIFOs; they're now an array of pointers
to buffers;
* .. and the RX buffer and descriptor are in the same "buffer", rather than
being separate.
So to that end, this commit abstracts out most of the RX related functions
from the bulk of the driver. Notably, the RX DMA/buffer allocation isn't
updated, primarily because I haven't yet fleshed out what it should look
like.
Whilst I'm here, create a set of matching but mostly unimplemented EDMA
stubs.
Tested:
* AR9280, station mode
TODO:
* Thorough AP and other mode testing for non-EDMA chips;
* Figure out how to allocate RX buffers suitable for RX EDMA, including
correctly setting the mbuf length to compensate for the RX descriptor
and completion status area.
This driver does not yet handle multiple chip selects properly.
Note that the NAND infrastructure does not perform full page
reads or writes, which means that this driver cannot make use
of the hardware ECC that is otherwise present.
of interrupts of direct children. Have the bus_config_intr and
bus_teardown_intr methods implemented by bus_generic_config_intr and
bus_generic_teardown_intr (resp) as we don't need to do anything
special outselves.
This removes all the ``#ifdef $arch'' code that was there because powerpc
didn't have a proper nexus and people tend to copy and paste stuff.
names to shorten them. PulseAudio reported to have problems with names
longer then 63 chars and at least in XMMS long names are inconvinient.
Reported by: hselasky
MFC after: 3 days
Adjust power_profile script to handle the new world order as well.
Some vendors are opting out of a C2 state and only defining C1 & C3. This
leads the acpi_cpu display to indicate that the machine supports C1 & C2
which is caused by the (mis)use of the index of the cx_state array as the
ACPI_STATE_CX value.
e.g. the code was pretending that cx_state[i] would
always convert to i by subtracting 1.
cx_state[2] == ACPI_STATE_C3
cx_state[1] == ACPI_STATE_C2
cx_state[0] == ACPI_STATE_C1
however, on certain machines this would lead to
cx_state[1] == ACPI_STATE_C3
cx_state[0] == ACPI_STATE_C1
This didn't break anything but led to a display of:
* dev.cpu.0.cx_supported: C1/1 C2/96
Instead of
* dev.cpu.0.cx_supported: C1/1 C3/96
MFC after: 2 weeks
Asus laptops. It is alike to acpi_asus(4), but uses WMI interface instead
of separate ACPI device.
On Asus EeePC T101MT netbook it allows to handle hotkeys and on/off WLAN,
Bluetooth, LCD backlight, camera, cardreader and touchpad.
On Asus UX31A ultrabook it allows to handle hotkeys, on/off WLAN, Bluetooth,
Wireless LED, control keyboard backlight brightness, monitor temperature
and fan speed. LCD brightness control doesn't work now for unknown reason,
possibly requiring some video card initialization.
Sponsored by: iXsystems, Inc.
as an EDMA check function.
For the AR9003 and later NICs, different TX/RX DMA and descriptor handling
code will be conditional on the EDMA check.
Obtained from: Qualcomm Atheros
* Add a new ANI variable, for AR9003 and later chips;
* The AR9003 and later series chips support two RX queues now, so start
down the road of supporting that;
* Add some new TX queue types - uAPSD is possible on earlier chips,
but PAPRD is relevant to AR9003 and later.
Obtained from: Qualcomm Atheros, Linux ath9k
On systems with HZ=100 it caused Intel eDP video output initialization
(and Xorg startup) to take several minutes instead of several seconds.
Reviewed by: kib
MFC after: 3 days
14.00.00.01-fbsd.
Their description of the changes is as follows:
1. Copyright contents has been changed in all respective .c
and .h files
2. Support for WRITE12 and READ12 for direct-io (warpdrive only)
has been added.
3. Driver has added checks to see if Drive has READ_CAP_16
support before sending it down to the device.
If SPC3_SID_PROTECT flag is set in the inquiry data, the
device supports protection information, and must support
the 16 byte read capacity command, otherwise continue without
sending read cap 16. This will optimize driver performance,
since it will not send READ_CAP_16 to the drive which does
not have support of READ_CAP_16.
4. With new approach, "MPTIOCTL_RESET_ADAPTER" IOCTL will not
use DELAY() which is busy loop implementation.
It will use <msleep> (Better way to sleep without busy
loop). Also from the HBA reset code path and some other
places, DELAY() is replaced with msleep() or "pause()",
which is based on sleep/wakeup style calls. Driver use
msleep()/pause() instead of DELAY based on CAN_SLEEP/NO_SLEEP
flags to avoid busy loop which is not required all the
time.e.a
a. While driver is getting loaded, driver calls most of the
commands with NO_SLEEP.
b. When Driver is functional and it needs Reinit of HBA,
CAN_SLEEP flag is used.
5. <mpslsi> driver is not Endian safe. It will not work on Big
Endian machines like Sparc and PowerPC platforms because it
assumes it is running on a Little Endian machine.
Driver code is modified such way that it does not assume CPU
arch is Little Endian.
a. All places where Driver interacts from HBA to Host, it
converts Little Endian format to CPU format.
b. All places where Driver interacts from Host to HBA, it
converts CPU format to Little Endian.
6. Findout memory leaks in FreeBSD Driver and resolve those,
such as memory leak in targ's luns creation/deletion.
Also added additional checks to see memory allocation
success/fail.
7. Add loginfo prints as debug message, i.e. When FW sends any
loginfo, Driver should print those as debug message.
This will help for debugging purpose.
8. There is possibility to get config request timeout. Current
driver is able to detect config request timetout, but it does
not do anything on config_request timeout. Driver should
call mps_reinit() if any request_poll (which is called as
part of config_request) is time out.
9. cdb length check is required for 32 byte CDB. Add correct mpi
control value for 32 bit CDB as below while submitting SCSI IO
Request to controller.
mpi_control |= 4 << MPI2_SCSIIO_CONTROL_ADDCDBLEN_SHIFT;
10. Check the actual status of Message unit reset
(mps_message_unit_reset).Previously FreeBSD Driver just writes
MPI2_FUNCTION_IOC_MESSAGE_UNIT_RESET and never check the ack
(it just wait for 50 millisecond). So, Driver now check the
status of "MPI2_FUNCTION_IOC_MESSAGE_UNIT_RESET" after writing
it to the FW.
Now it also checking for whether doorbell ack uses msleep with
proper sleep flags, instead of <DELAY>.
11. Previously CAM does not detect Multi-Lun Devices. In order to
detect Multi-Lun Devices by CAM the driver needs following change
set:
a. There is "max_lun" field which Driver need to set based on
hw/fw support. Currently LSI released driver does not set
this field.
b. Default of "max_lun" should not be 0 in OS, but it is
currently set to 0 in CAM layer.
c. Export max_lun capacity to 255
12. Driver will not reset target info after port enable complete and
also do Device removal when Device remove from FW. The detail
description is as follows
a. When Driver receive WD PD add events, it will add all
information in driver local data structure.
b. Only for WD, we have below checks after port enable
completes, where driver clear off all information retrieved
at #1.
if ((sc->WD_available &&
(sc->WD_hide_expose == MPS_WD_HIDE_ALWAYS)) ||
(sc->WD_valid_config && (sc->WD_hide_expose ==
MPS_WD_HIDE_IF_VOLUME)) {
// clear off target data structure.
}
It is mainly not to attach PDs to OS.
FreeBSD does bus rescan as older Parallel scsi style. So Driver
needs to handle which Drive is visible to OS. That is a reason
we have to clear off targ information for PDs.
Again, above logic was implemented long time ago. Similar concept
we have for non-wd also. For that, LSI have introduced different
logic to hide PDs.
Eventually, because of above gap, when Phy goes offline, we
observe below failure. That is what Driver is not doing complete
removal of device with FW. (which was pointed by Scott)
Apr 5 02:39:24 Freebsd7 kernel: mpslsi0: mpssas_prepare_remove
Apr 5 02:39:24 Freebsd7 kernel: mpssas_prepare_remove 497 : invalid handle 0xe
Now Driver will not reset target info after port enable complete
and also will do Device removal when Device remove from FW.
13. Returning "CAM_SEL_TIMEOUT" instead of "CAM_TID_INVALID"
error code on request to the Target IDs that have no devices
conected at that moment. As if "CAM_TID_INVALID" error code
is returned to the CAM Layaer then it results in a huge chain
of errors in verbose kernel messages on boot and every
hot-plug event.
Submitted by: Sreekanth Reddy <Sreekanth.Reddy@lsi.com>
MFC after: 3 days
the request up the tree in order to be on the safe side. Growing windows
in this case would mean to switch resources to positive decoding and
it's unclear how to correctly handle this. At least with ALi/ULi M5249
PCI-PCI bridges, this also just doesn't work out of the box.
Reviewed by: jhb
MFC after: 3 days
queue is empty or the firmware will go nuts.
PR: kern/167806
Tested by: osa@, Brandon Gooch (earlier version),
Bojan Petrovic (earlier version)
MFC after: 3 days
the TX queue is empty, there won't be a TX done notification, effectly
resulting in an mbuf leak. The correct way to handle this is to free
up mbufs on both BA and TX done notifications up to the last sent seqno.
Tested by: osa@
MFC after: 3 days
with AMPDU aggregate delimiters.
If there's an OFDM restart during an aggregate, the hardware ACKs
the previous frame, but communicates the RXed frame to the hardware
as having had CRC delimiter error + OFDM_RESTART phy error.
The frame however didn't have a CRC error and since the hardware ACKed
the aggregate to the sender, it thinks the frame was received.
Since I have no idea how often this occurs in the real world, add a
debug statement so trigger whenever this occurs. I'd appreciate an
email if someone finds this particular situation is triggered.
The Linux ath9k btcoex code is based off of this code.
Note this doesn't actually implement functional btcoex; there's some
driver glue and a whole lot of verification that is required.
On the other hand, I do have the AR9285+BT and AR9287+BT NICs which
this code supports..
Obtained from: Qualcomm Atheros, Linux ath9k
to attach to target capable HBAs that implement the old immediate
notify (XPT_IMMED_NOTIFY) and notify acknowledge (XPT_NOTIFY_ACK)
CCBs. The new API has been in place since SVN change 196008 in
2009.
The solution is two-fold: fix CTL to handle the responses from the
HBAs, and convert the HBA drivers in question to use the new API.
These drivers have not been tested with CTL, so how well they will
interoperate with CTL is unknown.
scsi_target.c: Update the userland target example code to use the
new immediate notify API.
scsi_ctl.c: Detect when an immediate notify CCB is returned
with CAM_REQ_INVALID or CAM_PROVIDE_FAIL status,
and just free it.
Fix a duplicate assignment.
aic79xx.c,
aic79xx_osm.c: Update the aic79xx driver to use the new API.
Target mode is not enabled on for this driver, so
the changes will have no practical effect.
aic7xxx.c,
aic7xxx_osm.c: Update the aic7xxx driver to use the new API.
sbp_targ.c: Update the firewire target code to work with the
new API.
mpt_cam.c: Update the mpt(4) driver to work with the new API.
Target mode is only enabled for Fibre Channel
mpt(4) devices.
MFC after: 3 days
exported via PCI passthrough.
- Do not check for a specific physical function (PF) before claiming a device.
Different PFs have different device-ids so this check is redundant anyway.
- Obtain the PF# from the WHOAMI register instead of pci_get_function().
- Setup the memory windows using the real BAR0 address, not what the VM says it
is.
Obtained from: Chelsio Communications
