FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=release%2F8.2.0 2010-11-23T21:22:18Z 2010-11-23T21:22:18Z Alexander Motin mav@FreeBSD.org 2010-11-23T21:22:18Z urn:sha1:206faf167a52e585cb6d4c715858df5666c3a860 Mark command submission timeouts as timeouts. This should trigger device resets and increase chances of getting device back again. 2010-11-23T21:20:27Z Alexander Motin mav@FreeBSD.org 2010-11-23T21:20:27Z urn:sha1:078dd01a39e769861bcfacaacb6769f12578e349 Add support for odd-sized PIO transfers, sometimes used by ATAPI. 2010-09-30T04:03:14Z Nathan Whitehorn nwhitehorn@FreeBSD.org 2010-09-30T04:03:14Z urn:sha1:37d498616ff08841c90ec3ad2d56f89ee83a9755 Fix a problem where device detection would work unreliably on Serverworks K2 SATA controllers. The chip's status register must be read first, and as a long, for other registers to be correctly updated after a command, and this includes the command sequence in device detection as well as the previously handled case after interrupts. While here, clean up some previous hacks related to this controller. 2010-09-16T02:44:23Z Alexander Motin mav@FreeBSD.org 2010-09-16T02:44:23Z urn:sha1:a848350888c744a1976ee7c4a5a4b631bc01b235 SATA1.x SiliconImage controllers on power-on reset TFD Status register into value 0xff. On hot-plug this value confuses ata_generic_reset() device presence detection logic. As soon as we already know drive presence from SATA hard reset, hint ata_generic_reset() to wait for device signature until success or full timeout. 2010-06-11T14:06:35Z Nathan Whitehorn nwhitehorn@FreeBSD.org 2010-06-11T14:06:35Z urn:sha1:972b06a770fc8c9fc965fd9ec117597090649cf5 Some revisions of the Serverworks K2 SATA controller have a data corruption bug where if an ATA command is issued before DMA is started, data will become available to the controller before it knows what to do with it. This results in either data corruption or a controller crash. This patch remedies the problem by adopting the workaround employed by Linux and Darwin: starting the DMA engine prior to sending the ATA command. Reviewed by: mav Approved by: re (kib) 2009-12-12T10:37:31Z Alexander Motin mav@FreeBSD.org 2009-12-12T10:37:31Z urn:sha1:71e7360ed94d5ffb14ab957e0bfb620760c841e7 Introduce ATA_CAM kernel option, turning ata(4) controller drivers into cam(4) interface modules. When enabled, this option deprecates all ata(4) peripheral drivers (ad, acd, ...) and interfaces and allows cam(4) drivers (ada, cd, ...) and interfaces to be natively used instead. As side effect of this, ata(4) mode setting code was completely rewritten to make controller API more strict and permit above change. While doing this, SATA revision was separated from PATA mode. It allows DMA-incapable SATA devices to operate and makes hw.ata.(ata|atapi)_dma tunable work again. Also allow ata(4) controller drivers (except some specific or broken ones) to handle larger data transfers. Previous constraint of 64K was artificial and is not really required by PCI ATA BM specification or hardware. Submitted by: nwitehorn (powerpc part) 2009-11-23T08:45:17Z Alexander Motin mav@FreeBSD.org 2009-11-23T08:45:17Z urn:sha1:555a8009dd201e72edb2dc12af87e1d11600629f - Remove most of direct relations between ATA(4) peripherial and controller levels. It makes logic more transparent and is a mandatory step to wrap ATA(4) controller level into ATA-native CAM SIM. - Tune AHCI and SATA2 SiI drivers memory allocation a bit to allow bigger I/O transaction sizes without additional cost. 2008-05-08T17:55:44Z Peter Grehan grehan@FreeBSD.org 2008-05-08T17:55:44Z urn:sha1:a384947e923445d99aafa1388b79a761afc6bb75 Handle cases where dma function pointers may be NULL, and where the max_iosize can't be derived from a DMA data structure. For the latter, revert to the prior behaviour of using DFLTPHYS for the max i/o size when there is no other data. Reviewed by: marcel No objection by: sos 2008-04-17T12:29:35Z Søren Schmidt sos@FreeBSD.org 2008-04-17T12:29:35Z urn:sha1:104c094e0674fcaccab37258f5bf53b8471bd396 This avoids calling busdma in the request processing path which caused a traumatic performance degradation. Allocation has be postponed to after we know how many devices we possible can have on portmulitpliers to save some space. 2008-04-14T18:34:24Z Søren Schmidt sos@FreeBSD.org 2008-04-14T18:34:24Z urn:sha1:d90a6aaeb271d0717e0d862d028f2cfd20d13ed5 Fix or rather bring ENOMEM problems back to the state it was before. Temporarily disable PortMultipliers on AHCI devices.