| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
interface supported by mvs(4) are 88SX, while AHCI-like chips are 88SE.
PR: kern/165271
Submitted by: Jia-Shiun Li <jiashiun@gmail.com>
MFC after: 1 week
|
| |
|
|
|
|
|
| |
Reviewed by: mav
Approved by: scottl
|
|
|
|
|
|
|
|
|
|
| |
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.
MFC after: 1 month
|
|
|
|
|
| |
Suggested by: jhb @ and marius @
MFC after: 1 week
|
|
|
|
|
|
|
|
| |
to kern/subr_bus.c. Simplify this function so that it no longer
depends on malloc() to execute. Identify a few other places where
it makes sense to use device_delete_all_children().
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
This means that their use is restricted to a single C file.
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
| |
Approved by: re (blackend)
MFC after: 1 week
|
|
|
|
|
|
|
|
|
| |
Mac with this chipset does not initialize AHCI mode unless it is started
from EFI loader. However, legacy ATA mode works.
Submitted by: jkim@ (original version)
Approved by: re (kib)
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
PR: kern/157843
MFC after: 1 week
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
without waiting for device readiness (or at least not updating FIS receive
area in time). To workaround that, special quirk was added earlier to wait
for the FIS receive area update. But it was found that under same PCI ID
0x91231b4b and revision 0x11 there are two completely different chip
versions (firmware?): HBA and RAID. The problem is that RAID version in
some cases, such as hot-plug, does not update FIS receive area at all!
To workaround that, differentiate the chip versions by their capabilities,
and, if RAID version found, skip FIS receive area update waiting and read
device signature from the PxSIG register instead. This method doesn't work
for HBA version when PMP attached, so keep using previous workaround there.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(SEMB) is unable to communicate to Storage Enclosure Processor (SEP), in
response to hard and soft resets it should among other things return value
0x7F in Status register. The weird side is that it means DRQ bit set, which
tells that reset request is not completed. It would be fine if SEMB was the
only device on port. But if SEMB connected to PMP or built into it, it may
block access to other devices sharing same SATA port.
Make some tunings/fixes to soft-reset handling to workaround the issue:
- ahci(4): request CLO on the port after soft reset to ignore DRQ bit;
- siis(4): gracefully reinitialize port after soft reset timeout (hardware
doesn't detect reset request completion in this case);
- mvs(4): if PMP is used, send dummy soft-reset to the PMP port to make it
clear DRQ bit for us.
For now this makes quirks in ata_pmp.c, hiding SEMB ports of SiI3726/SiI4726
PMPs, less important. Further, if hardware permit, I hope to implement real
SEMB support.
|
|
|
|
|
|
|
|
|
| |
When supported by hardware, this allows to control per-port activity, locate
and fault LEDs via the led(4) API for localization and status reporting
purposes. Supporting AHCI controllers may transmit that information to the
backplane controllers via SGPIO interface. Backplane controllers interpret
received statuses in some way (IBPI standard) to report them using present
indicators.
|
|
|
|
| |
to Seth Heasley for preparing the changes.
|
|
|
|
|
| |
Submitted by: dchagin
MFC after: 1 week
|
| |
|
|
|
|
|
| |
in no more then 10ms. If we detected no device presence within that time,
there is no reason to wait longer.
|
| |
|
| |
|
|
|
|
|
| |
- Do not call ahci_start() before device signature received. It is required
by the specification and caused non-fatal reset timeouts on AMD chipsets.
|
|
|
|
|
|
|
|
|
|
|
|
| |
- use ATA_SE_EXCHANGED (SError.DIAG.X) bit to detect hot-plug events when
power-management enabled and ATA_SE_PHY_CHANGED (SError.DIAG.N) can't be
trusted;
- on controllers supporting staggered spin-up (SS) put unused channels
into Listen state instead of Off. It should still save some power, but
allow plug-in events to be detected;
- on controllers supporting cold presence detection (CPD), when power
management enabled, use CPD events to detect hot-plug in addition to PHY
events.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- make SATA SIMs announce capabilities to handle SDB with Notification bit;
- make PMP driver honor this SIMs capability;
- make SATA XPT to negotiate and enable this feature for ATAPI devices.
This feature allows supporting SATA ATAPI devices to inform system about
some events happened, that may require attention. In my case this allows
LG GH22LS50 SATA DVR-RW drive to report tray open/close events. Events
reported to CAM in form of AC_SCSI_AEN async. Further they could be used
as a hints for checking device status and reporting media change to upper
layers, for example, via spoiling mechanism of GEOM.
|
|
|
|
|
|
|
|
|
| |
Instead of spinning in a tight loop for up to 15 seconds, polling for device
readiness while it spins up, return reset completion just after PHY reports
"connect well" or 100ms connection timeout. If device was found, use callout
for checking device readiness with 100ms period up to full 31 second timeout.
This fixes system freeze for 5-10 seconds on drives hot plug-in.
|
| |
|
|
|
|
| |
Submitted by: Jonas Jonsson <fatbrain@gmail.com>
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
active I/O to several disks (copying large file on ZFS) causes timeout after
just a few seconds of run. Single port 88SX6111 seems like not affected.
Skip reading transferred bytes count for these controllers. It works for
88SX6111, but 88SX6145 always returns zero there. Haven't tested others,
but better to be safe.
|
|
|
|
|
|
|
|
|
|
|
| |
- SMBus Controller
- SATA Controller
- HD Audio Controller
- Watchdog Controller
Thanks to Seth Heasley (seth.heasley@intel.com) for providing us code.
MFC after 3 days
|
|
|
|
|
|
| |
- SATA controller
- Watchdog timer
- SMBus controller
|
|
|
|
|
|
|
|
|
|
|
|
| |
These controllers consist of two Marvell 88SE9128 6Gbps SATA chips and
PLX PCIe bridge. As result, they seem to be agree to work with ahci(4)
as usual HBAs. The only noticed issue is that RAID BIOS disables all
drive caches during boot, though `camcontrol cmd ...` is able to fix that.
Those who wants RAID functionality can still use closed proprietary driver
from HighPoint site.
MFC after: 1 week
|
|
|
|
|
|
| |
PR: kern/152926
Submitted by: Mike Tancsa <mike@sentex.net>
MFC after: 1 week
|
|
|
|
| |
Submitted by: Artem Belevich
|
|
|
|
| |
I/O length on underruns, that often happens for some SCSI commands.
|
| |
|
|
|
|
|
|
|
| |
port multiplier some command triggers false positive timeout, but then
completes normally.
MFC after: 2 weeks
|
|
|
|
|
| |
Add Intel Cougar Point PCH SATA Controller DeviceIDs. Correct some existing
entries for Intel Ibex Peak (5 Series/3400 Series) PCH SATA controllers.
|
|
|
|
|
| |
GEOM. This information needed for proper soft-RAID's on-disk metadata
reading and writing.
|
|
|
|
| |
unreliable under load. Linux does the same.
|
|
|
|
|
| |
Found with: Coverity Prevent(tm)
CID: 4130
|
|
|
|
|
| |
Found with: Coverity Prevent(tm)
CID: 3424
|
| |
|
| |
|
|
|
|
| |
and reset it on resume.
|
| |
|
|
|
|
|
|
|
| |
- device initiated power management (some devices support only this way);
- Automatic Partial to Slumber Transition (more power saving);
- DMA auto-activation (expected to slightly improve performance).
More features could be added later, when hardware supports.
|