Any objections/comments on axing out old ATA stack?

[Matthias Andree]

Am 28.03.2013 16:31, schrieb Scott Long:
> 
> On Mar 28, 2013, at 8:00 AM, Ian Lepore <ian at FreeBSD.org> wrote:
> 
>> On Thu, 2013-03-28 at 09:17 +0200, Alexander Motin wrote:
>>> On 28.03.2013 02:43, Adrian Chadd wrote:
>>>> My main concern with the new stuff is that it requires CAM and that's
>>>> reasonably big compared to the standalone ATA code.
>>>>
>>>> It'd be nice if we could slim down the CAM stack a bit first; it makes
>>>> embedding it on the smaller devices really freaking painful.
>>>
>>> Are there many boards now with ATA, but without USB? But I agree, it 
>>> should be checked.
>>>
>>
>> It's not necessarily what the boards have but how they're used.  We use
>> industrial SBCs at work that have ata compact flash sockets on the board
>> which we do use, and usb interfaces which we don't use.
>>
>> I've never tested the new ata+cam stuff on some of these boards, most
>> based on Cyrix, Via, Geode, and VortexD86 chipsets.  The older ata code
>> works, but not always very well -- for example, we usually have to set
>> hw.ata.ata_dma=0 for absolutely no reason we've ever been able to figure
>> out except that if we leave it enabled we get DMA errors and panics on
>> some CF cards and not on others.  I have no idea whether to expect such
>> things to be better, worse, or no different by changing to the ata+cam
>> way of doing things (but I don't really have time to do extensive
>> testing right now either).
>>
> 
> 
> The legacy ATA code was hard to maintain, very buggy (as you point out), and
> is essentially unmaintained.  Also, IIRC, the legacy stack simply cannot support
> NCQ tagged queueing.

...which is exactly why it currently is the only way to get certain
Samsung drives to cooperate reliably, without stalling the kernel for
prolonged times (minutes) making the computer essentially unusable once
it gets under I/O load (such as "make -C /usr/src -j4 buildworld") - as
the new ahci+ata+cam+... would.

Details including PR reference in my other message in this thread.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20130331/a01eeb60/attachment.sig>