Joerg Schilling wrote: > Alexander Motin <mav_at_FreeBSD.org> wrote: >>>>> Given the fact that many drives will probably only return 18 bytes of sense >>>>> data, this will happen every time libscg is told to fetch more sense than the >>>>> drive is willing to return. >>>>> >>>>> Is there a way to distinct an old kernel from a new one? >>>> I don't see the problem. Previous kernel in most cases reported >>>> sesnse_resid == 0, lying that there is more sense data then really is. >>>> New one should report real (often positive) value. In both cases >>>> sesnse_resid value measured from the value submitted to the kernel. >>> Did the old kernel return a zero sense_resid for any implemented SCSI >>> transport? Libscg is a generic SCSI transport library and cdrecord is just one >>> user of this lib. >> Not sure I understand your question. Zero sesnse_resid is absolutely >> normal situation if device gave same amount of sense as application >> requested. As I can see, many of SCSI controllers report sesnse_resid >> properly. I may assume that some, like atapicd don't -- in that case >> you'll also see 0 there. > > FreeBSD-CAM did try to fetcth more than 18 bytes of sense data and it may be > that some drives did return only 18 bytes. In this case, I would asume that > there is a resid > 0. As I have said, many drivers return resid properly, but some others - don't. These changes should just improve situation. >>> Do you know the CAM behavior for other SCSI transports? >> I don't have real SCSI CD to test, but a as I can see, most of SCSI >> controllers return sense data automatically. Sense fetching changes >> should not affect/break anything there. > > The question still remains whether the previous implementation did return resid >> 0 in some cases. In this case, I would need to implement both variants in the > libscg adaption layer and I would need to know whether I am running on an old > version or on a new version kernel. Do you know of a simple method to implement > this distinction? Yes, some drivers were permanently reporting zero resid, while others (mostly real SCSI) were reporting proper values. Now it is the same, just more cases should work properly. Why do you want/need to distinguish them? You should already handle non-zero resid properly. Zero resid may be wrong in some cases, but at first I don't see fatal problem from it and at second I don't see what can you do about it. If I am missing something - sorry, explain it to me please. -- Alexander MotinReceived on Thu Nov 11 2010 - 09:29:12 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:09 UTC