Hi. I've reviewed tests that scgcheck does to SCSI subsystem. It shown combination of several issues in both CAM, ahci(4) and cdrtools itself. Several small patches allow us to pass most of that tests: http://people.freebsd.org/~mav/sense/ ahci_resid.patch: Add support for reporting residual length on data underrun. SCSI commands often returns results shorter then expected. Returned value allows application to know/check how much data it really has. It is also important for sense fetching, as ATAPI and USB devices return sense as data in response to REQUEST_SENSE command. sense_resid.patch: When manually requesting sense data (ATAPI or USB), request only as much data as user requested (not the fixed structure size), and return respective sense residual length. pass_autosence.patch: Unless CAM_DIS_AUTOSENSE is set, always fetch sense if not done by SIM, independently of CAM_PASS_ERR_RECOVER. As soon as device freeze released before returning to user-level, user-level application by definition can't reliably fetch sense data if some other application (like hald) tries to access device same time. cdrtools.patch: Make libscg (part of cdrtools) on FreeBSD to submit wanted sense length to CAM and do not clear sense return buffer. It is mostly cosmetics, important probably only for scgcheck. Testers and reviewers welcome. I am especially interested in opinion about pass_autosence.patch -- may be we should lower sense fetching even deeper, to make it work for all cam_periph_runccb() consumers. -- Alexander Motin
On Fri, Nov 05, 2010 at 08:50:49PM +0200, Alexander Motin wrote:> Hi. > > I've reviewed tests that scgcheck does to SCSI subsystem. It shown > combination of several issues in both CAM, ahci(4) and cdrtools itself. > Several small patches allow us to pass most of that tests: > http://people.freebsd.org/~mav/sense/ > > ahci_resid.patch: Add support for reporting residual length on data > underrun. SCSI commands often returns results shorter then expected. > Returned value allows application to know/check how much data it really > has. It is also important for sense fetching, as ATAPI and USB devices > return sense as data in response to REQUEST_SENSE command. > > sense_resid.patch: When manually requesting sense data (ATAPI or USB), > request only as much data as user requested (not the fixed structure > size), and return respective sense residual length. > > pass_autosence.patch: Unless CAM_DIS_AUTOSENSE is set, always fetch > sense if not done by SIM, independently of CAM_PASS_ERR_RECOVER. As soon > as device freeze released before returning to user-level, user-level > application by definition can't reliably fetch sense data if some other > application (like hald) tries to access device same time. > > cdrtools.patch: Make libscg (part of cdrtools) on FreeBSD to submit > wanted sense length to CAM and do not clear sense return buffer. It is > mostly cosmetics, important probably only for scgcheck.Please don't commit this to the port directly but let it loop back via upstream (CC'ed) instead, otherwise we would need to obey the following, which is undesirable, especially if these really are mostly cosmetic issues: /* * Warning: you may change this source, but if you do that * you need to change the _scg_version and _scg_auth* string below. * You may not return "schily" for an SCG_AUTHOR request anymore. * Choose your name instead of "schily" and make clear that the version * string is related to a modified source. */> > Testers and reviewers welcome. I am especially interested in opinion > about pass_autosence.patch -- may be we should lower sense fetching even > deeper, to make it work for all cam_periph_runccb() consumers. >Marius
2010/11/5 Alexander Motin <mav@freebsd.org>:> Hi. > > I've reviewed tests that scgcheck does to SCSI subsystem. It shown > combination of several issues in both CAM, ahci(4) and cdrtools itself. > Several small patches allow us to pass most of that tests: > http://people.freebsd.org/~mav/sense/ > > ahci_resid.patch: Add support for reporting residual length on data > underrun. SCSI commands often returns results shorter then expected. > Returned value allows application to know/check how much data it really > has. It is also important for sense fetching, as ATAPI and USB devices > return sense as data in response to REQUEST_SENSE command. > > sense_resid.patch: When manually requesting sense data (ATAPI or USB), > request only as much data as user requested (not the fixed structure > size), and return respective sense residual length. > > pass_autosence.patch: Unless CAM_DIS_AUTOSENSE is set, always fetch > sense if not done by SIM, independently of CAM_PASS_ERR_RECOVER. As soon > as device freeze released before returning to user-level, user-level > application by definition can't reliably fetch sense data if some other > application (like hald) tries to access device same time. > > cdrtools.patch: Make libscg (part of cdrtools) on FreeBSD to submit > wanted sense length to CAM and do not clear sense return buffer. It is > mostly cosmetics, important probably only for scgcheck. > > Testers and reviewers welcome. I am especially interested in opinion > about pass_autosence.patch -- may be we should lower sense fetching even > deeper, to make it work for all cam_periph_runccb() consumers. >Hey mav, sorry to chime in after so long here, but have some of these patches been committed (as of r215179)? Which patches are still applicable for testing? I assume the cdrtools patch for sure... -Brandon
On Sun, Nov 14, 2010 at 9:32 AM, Alexander Motin <mav@freebsd.org> wrote:> Brandon Gooch wrote: >> On Sat, Nov 13, 2010 at 3:34 AM, Alexander Motin <mav@freebsd.org> wrote: >>> Now uncommitted pass_autosence.patch and possibly cdrtools.patch. >> >> OK. Patched kernel and cdrtools has resulted in a working cdrecord >> (burned an ISO successfully) and an endless stream of: >> >> ... >> (pass0:ata0:0:0:0): Requesting SCSI sense data >> (pass0:ata0:0:0:0): SCSI status error >> (pass0:ata0:0:0:0): Requesting SCSI sense data >> (pass0:ata0:0:0:0): SCSI status error >> (pass0:ata0:0:0:0): Requesting SCSI sense data >> (pass0:ata0:0:0:0): SCSI status error >> (pass0:ata0:0:0:0): Requesting SCSI sense data >> (pass0:ata0:0:0:0): SCSI status error >> ... > > I think it can be hald probing for media insertion. Probably we should > slightly reduce error logging verbosity. May be somehow make to not log > errors on requests submitted from user-level via pass driver. > >> But most important part: It works, and it burned very quickly! The CD >> was created, and fully functional (I booted the Fedora image and >> completed an installation). > > Nice!What are your thoughts on committing this (or something like it)? Should I just keep a local patch set for the semi-long-term? Do you have something else in the works? -Brandon
On Tue, Mar 8, 2011 at 8:29 AM, Jakub Lach <jakub_lach@mailplus.pl> wrote:> > Hello. > > Just ensuring that this issue would not be forgotten, > If I recall correctly, without added patches one > cannot burn CD with cdrtools, quite a problem > for media burning suite ;) > > best regards, > - Jakub Lachmav@ is working on graid(4), a replacement for ataraid(4) using the GEOM framework. This effort has taken precedence over a few outstanding patches he was working on, but he will eventually come back to it :) Perhaps another developer will step up and continue the work on the patches: http://people.freebsd.org/~mav/sense/ -Brandon
On 08/03/2011 16:15, Brandon Gooch wrote:> On Tue, Mar 8, 2011 at 8:29 AM, Jakub Lach<jakub_lach@mailplus.pl> wrote: >> >> Hello. >> >> Just ensuring that this issue would not be forgotten, >> If I recall correctly, without added patches one >> cannot burn CD with cdrtools, quite a problem >> for media burning suite ;) >> >> best regards, >> - Jakub Lach > > mav@ is working on graid(4), a replacement for ataraid(4) using the > GEOM framework. This effort has taken precedence over a few > outstanding patches he was working on, but he will eventually come > back to it :) > > Perhaps another developer will step up and continue the work on the patches: > > http://people.freebsd.org/~mav/sense/ > > -Brandon > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"I hope because I want to use ahci on my machines! :-) -- David Demelier
Buganini wrote:> does r22056{3,5,6,9} supercede these patches ?Yes. They solve problem from different side.> my dvd burning with ahci seems to be fixed by those commits, > without these patches. > > I've just burned a DVD successful, and it's readable.Yea, I've also burned few DVDs with cdrecord-devel for testing. -- Alexander Motin