Hi. Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA stack, using only some controller drivers of old ata(4) by having `options ATA_CAM` enabled in all kernels by default. I have a wish to drop non-ATA_CAM ata(4) code, unused since that time from the head branch to allow further ATA code cleanup. Does any one here still uses legacy ATA stack (kernel explicitly built without `options ATA_CAM`) for some reason, for example as workaround for some regression? Does anybody have good ideas why we should not drop it now? -- Alexander Motin
On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote:> Hi. > > Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA > stack, using only some controller drivers of old ata(4) by having > `options ATA_CAM` enabled in all kernels by default. I have a wish to > drop non-ATA_CAM ata(4) code, unused since that time from the head > branch to allow further ATA code cleanup. > > Does any one here still uses legacy ATA stack (kernel explicitly built > without `options ATA_CAM`) for some reason, for example as workaround > for some regression?Yes, I use the legacy ATA stack.> Does anybody have good ideas why we should not drop > it now?Because it works? -- Steve
On 27.03.2013 23:32, Steve Kargl wrote:> On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote: >> Hi. >> >> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA >> stack, using only some controller drivers of old ata(4) by having >> `options ATA_CAM` enabled in all kernels by default. I have a wish to >> drop non-ATA_CAM ata(4) code, unused since that time from the head >> branch to allow further ATA code cleanup. >> >> Does any one here still uses legacy ATA stack (kernel explicitly built >> without `options ATA_CAM`) for some reason, for example as workaround >> for some regression? > > Yes, I use the legacy ATA stack.On 9.x or HEAD where new one is default?>> Does anybody have good ideas why we should not drop >> it now? > > Because it works?Any problems with new one? -- Alexander Motin
On Wed, Mar 27, 2013 at 11:35:35PM +0200, Alexander Motin wrote:> On 27.03.2013 23:32, Steve Kargl wrote: > > On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote: > >> Hi. > >> > >> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA > >> stack, using only some controller drivers of old ata(4) by having > >> `options ATA_CAM` enabled in all kernels by default. I have a wish to > >> drop non-ATA_CAM ata(4) code, unused since that time from the head > >> branch to allow further ATA code cleanup. > >> > >> Does any one here still uses legacy ATA stack (kernel explicitly built > >> without `options ATA_CAM`) for some reason, for example as workaround > >> for some regression? > > > > Yes, I use the legacy ATA stack. > > On 9.x or HEAD where new one is default?Head.> >> Does anybody have good ideas why we should not drop > >> it now? > > > > Because it works? > > Any problems with new one? >Last time I tested the new one, and this was several months ago, the system (a Dell Latitude D530 laptop) would not boot. -- Steve
On 28.03.2013 00:05, Steve Kargl wrote:> On Wed, Mar 27, 2013 at 11:35:35PM +0200, Alexander Motin wrote: >> On 27.03.2013 23:32, Steve Kargl wrote: >>> On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote: >>>> Hi. >>>> >>>> Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA >>>> stack, using only some controller drivers of old ata(4) by having >>>> `options ATA_CAM` enabled in all kernels by default. I have a wish to >>>> drop non-ATA_CAM ata(4) code, unused since that time from the head >>>> branch to allow further ATA code cleanup. >>>> >>>> Does any one here still uses legacy ATA stack (kernel explicitly built >>>> without `options ATA_CAM`) for some reason, for example as workaround >>>> for some regression? >>> >>> Yes, I use the legacy ATA stack. >> >> On 9.x or HEAD where new one is default? > > Head. > >>>> Does anybody have good ideas why we should not drop >>>> it now? >>> >>> Because it works? >> >> Any problems with new one? >> > > Last time I tested the new one, and this was several months > ago, the system (a Dell Latitude D530 laptop) would not boot.Probably we should just fix that. Any more info? -- Alexander Motin
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. Thanks, adrian
Am 27.03.2013 22:22, schrieb Alexander Motin:> Hi. > > Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA > stack, using only some controller drivers of old ata(4) by having > `options ATA_CAM` enabled in all kernels by default. I have a wish to > drop non-ATA_CAM ata(4) code, unused since that time from the head > branch to allow further ATA code cleanup. > > Does any one here still uses legacy ATA stack (kernel explicitly built > without `options ATA_CAM`) for some reason, for example as workaround > for some regression? Does anybody have good ideas why we should not drop > it now?Alexander, The regression in http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/157397 where the SATA NCQ slots stall for some Samsung drives in the new stack, and consequently hang the computer for prolonged episodes where it is in the NCQ error handling, disallows removal of the old driver. (Last checked with 9.1-RELEASE at current patchlevel.) Chances are that limiting the open queue slots to 31 might help, but that is hearsay from what Linux would be doing. Unless we get a fix, if you want to drop the old driver, you'll need to add features so that 1. the new driver to lets users (down-)configure the max. number of tagged openings 2. the new driver allows disabling NCQ altogether for individual drives 3. list the relevant Samsung drives in some quirks data base so that we avoid the stalls while permitting users to "open it up to 32 NCQ slots". So unless these are all addressed, I'd veto removal of the old ATA driver - sorry! Best regards Matthias -------------- 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/062917b4/attachment.sig>
Victor Balada Diaz
2013-Mar-31 13:04 UTC
Any objections/comments on axing out old ATA stack?
On Wed, Mar 27, 2013 at 11:22:14PM +0200, Alexander Motin wrote:> Hi. > > Since FreeBSD 9.0 we are successfully running on the new CAM-based ATA > stack, using only some controller drivers of old ata(4) by having > `options ATA_CAM` enabled in all kernels by default. I have a wish to > drop non-ATA_CAM ata(4) code, unused since that time from the head > branch to allow further ATA code cleanup. > > Does any one here still uses legacy ATA stack (kernel explicitly built > without `options ATA_CAM`) for some reason, for example as workaround > for some regression? Does anybody have good ideas why we should not drop > it now?Hello, At my previous job we had troubles with NCQ on some controllers. It caused failures and silent data corruption. As old ata code didn't use NCQ we just used it. I reported some of the problems on 8.2[1] but the problem existed with 8.3. I no longer have access to those systems, so i don't know if the problem still exists or have been fixed on newer versions. Regards. Victor. [1]: https://groups.google.com/forum/#!topic/muc.lists.freebsd.stable/dAMf028CtXM -- La prueba m?s fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros.