- Generate fake channel interrupts even if channel busy with previous
request to let it finish. Without this, dumping requests were just queued
and never processed.
- Drop pre-dump requests queue on dumping. ATA code, working in dumping
(interruptless) mode, unable to handle long request queue. Actually, to get
coherent dump we anyway should do as few unrelated actions as possible.
and partially r188903. Revert breaks new drives detection on reinit to the
state as it was before me, but fixes series of new bugs reported by some
people.
Unconditional queueing of ata_completed() calls can lead to deadlock if
due to timeout ata_reinit() was called at the same thread by previous
ata_completed(). Calling of ata_identify() on ata_reinit() in current
implementation opens numerous races and deadlocks.
Problems I was touching here are still exist and should be addresed, but
probably in different way.
kernel dumping case.
ata_completed() may initiate ata_reinit() on error, that may lead to drives
attach or detach. Attach and detach are sending requests to drives and sleep
waiting for results. But ata_finish() can be called directly from
interrupt handler where sleeping is prohibited, so we must break this chain
somewhere. This place seems to fit best.
expected in acd_fixate().
This should fix various problems folks are having with 'burncd' reporting
"burncd: ioctl(CDRIOCFIXATE): Input/output error" during the fixate phase
when "fixate" is issued together with the "data" command.
PR: 95979
Submitted by: Jaakko Heinonen <jh@saunalahti.fi>
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.
The problem is that the PM support is part of a much larger WIP here, but due to popular demand I decided to get some of it imported.
Also I forgot the mention:
HW sponsored by: Vitsch Electronics / VEHosting
Support is working on the Silicon Image SiI3124/3132.
Support is working on some AHCI chips but far from all.
Remember this is WIP, so test reports and (constructive) suggestions are welcome!
ATAPI request, do not clear the ATA_R_DEBUG flag. This allows a request
marked as requiring debug traces to produce these traces also during
the completion of the autosense processing.
Reviewed by: sos
MFC after: 2 weeks
When the disk has an error, it will now print SMART
instead of 'Unknown CMD'.
PR: kern/93368
Submitted by: Garry Belka <garry at NetworkPhysics dot COM>
Approved by: sos
to call back for completition and something else is holding the taskqueue
waiting for ATA to return data.
This should clear up the "semaphore timeout !! DANGER Will Robinson !!"
in most situations, and log "taskqueue timeout - completing request directly"
instead, with a delayed "WARNING - freeing taskqueue zombie request" when
the taskqueue finally calls us back with the now stale request.
(It would have been nice if there was a way to remove a scheduled item from
a taskqueue, but that is not currently implemented in the kernel).
A real fix for this is in the works but wont make it to 6.1RELEASE
definite MFC candidate.
This also removes the warning timeout on the taskqueues stalling as
I'm tired of getting ATA error reports for problems in other parts ;)
Misc cosmetic and comment cleanups now we are here.
o ATA is now fully newbus'd and split into modules.
This means that on a modern system you just load "atapci and ata"
to get the base support, and then one or more of the device
subdrivers "atadisk atapicd atapifd atapist ataraid".
All can be loaded/unloaded anytime, but for obvious reasons you
dont want to unload atadisk when you have mounted filesystems.
o The device identify part of the probe has been rewritten to fix
the problems with odd devices the old had, and to try to remove
so of the long delays some HW could provoke. Also probing is done
without the need for interrupts, making earlier probing possible.
o SATA devices can be hot inserted/removed and devices will be created/
removed in /dev accordingly.
NOTE: only supported on controllers that has this feature:
Promise and Silicon Image for now.
On other controllers the usual atacontrol detach/attach dance is
still needed.
o Support for "atomic" composite ATA requests used for RAID.
o ATA RAID support has been rewritten and and now supports these
metadata formats:
"Adaptec HostRAID"
"Highpoint V2 RocketRAID"
"Highpoint V3 RocketRAID"
"Intel MatrixRAID"
"Integrated Technology Express"
"LSILogic V2 MegaRAID"
"LSILogic V3 MegaRAID"
"Promise FastTrak"
"Silicon Image Medley"
"FreeBSD PseudoRAID"
o Update the ioctl API to match new RAID levels etc.
o Update atacontrol to know about the new RAID levels etc
NOTE: you need to recompile atacontrol with the new sys/ata.h,
make world will take care of that.
NOTE2: that rebuild is done differently from the old system as
the rebuild is now done piggybacked on read requests to the
array, so atacontrol simply starts a background "dd" to rebuild
the array.
o The reinit code has been worked over to be much more robust.
o The timeout code has been overhauled for races.
o Support of new chipsets.
o Lots of fixes for bugs found while doing the modulerization and
reviewing the old code.
Missing or changed features from current ATA:
o atapi-cd no longer has support for ATAPI changers. Todays its
much cheaper and alot faster to copy those CD images to disk
and serve them from there. Besides they dont seem to be made
anymore, maybe for that exact reason.
o ATA RAID can only read metadata from all the above metadata formats,
not write all of them (Promise and Highpoint V2 so far). This means
that arrays can be picked up from the BIOS, but they cannot be
created from FreeBSD. There is more to it than just the missing
write metadata support, those formats are not unique to a given
controller like Promise and Highpoint formats, instead they exist
for several types, and even worse, some controllers can have
different formats and its impossible to tell which one.
The outcome is that we cannot reliably create the metadata of those
formats and be sure the controller BIOS will understand it.
However write support is needed to update/fail/rebuild the arrays
properly so it sits fairly high on the TODO list.
o So far atapicam is not supported with these changes. When/if this
will change is up to the maintainer of atapi-cam so go there for
questions.
HW donated by: Webveveriet AS
HW donated by: Frode Nordahl
HW donated by: Yahoo!
HW donated by: Sentex
Patience by: Vife and my boys (and even the cats)
