Great, is MFC planned?
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/Sense-fetching-Was-cdrtools-devel-tp3944480p4301306.html
Sent from the freebsd-stable mailing list archive at Nabble.com.
___
freebsd-stable@freebsd.org
does r22056{3,5,6,9} supercede these patches ?
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.
Thanks,
Buganini
___
freebsd-stable@freebsd.org mailing list
http:
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 cdr
On 11/13/10 20:34, Alexander Motin wrote:
> Brandon Gooch wrote:
>> 2010/11/5 Alexander Motin :
>>> 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 m
On 08/03/2011 16:15, Brandon Gooch wrote:
On Tue, Mar 8, 2011 at 8:29 AM, Jakub Lach 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,
- J
On Tue, Mar 8, 2011 at 8:29 AM, Jakub Lach 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 o
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
--
View this message in context:
http://old.nabble.com/Sense-fetching--Was%3A-cdrt
If FreeBSD writes any warning for SCSI commands send by cdrtools, then this is
definitely a kernel bug that needs to be fixed.
SCSI is a protocol that lives from aparently failing SCSI commands.
These warnings are related to "high level interaction" between cdrecord and the
drive. Only cdrecord
Brandon Gooch wrote:
> On Sun, Nov 14, 2010 at 9:32 AM, Alexander Motin wrote:
>> Brandon Gooch wrote:
>>> On Sat, Nov 13, 2010 at 3:34 AM, Alexander Motin wrote:
Now uncommitted pass_autosence.patch and possibly cdrtools.patch.
>>> OK. Patched kernel and cdrtools has resulted in a working c
On Sun, Nov 14, 2010 at 9:32 AM, Alexander Motin wrote:
> Brandon Gooch wrote:
>> On Sat, Nov 13, 2010 at 3:34 AM, Alexander Motin wrote:
>>> Now uncommitted pass_autosence.patch and possibly cdrtools.patch.
>>
>> OK. Patched kernel and cdrtools has resulted in a working cdrecord
>> (burned an IS
Brandon Gooch wrote:
> On Sat, Nov 13, 2010 at 3:34 AM, Alexander Motin 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:ata
On Sat, Nov 13, 2010 at 3:34 AM, Alexander Motin wrote:
> Brandon Gooch wrote:
>> 2010/11/5 Alexander Motin :
>>> 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 all
Brandon Gooch wrote:
> 2010/11/5 Alexander Motin :
>> 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/~m
2010/11/5 Alexander Motin :
> 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.patc
Alexander Motin wrote:
> > What is the requested size with the various HBAs in earlier kernels?
>
> For HBAs with automatic sense fetching -- as passed in sence_len request
> field. In case of libscg it was SSD_FULL_SIZE before and I've set it to
> be real value now. Returned sense_resid should b
Joerg Schilling wrote:
> Alexander Motin wrote:
>
>>> Compare the number of sense bytes I like to request (18) with the number
>>> previous FreeBSD versions did actually request. It is obvious that in case
>>> there is a resid reported onm an old kernel, libscg (with your chanhge)
>>> would
>
Alexander Motin wrote:
> > Compare the number of sense bytes I like to request (18) with the number
> > previous FreeBSD versions did actually request. It is obvious that in case
> > there is a resid reported onm an old kernel, libscg (with your chanhge)
> > would
> > believe that probably le
Joerg Schilling wrote:
> Alexander Motin wrote:
>
>>> 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 run
Alexander Motin wrote:
> > 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
> > ve
Joerg Schilling wrote:
> Alexander Motin 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 dist
Alexander Motin 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
Joerg Schilling wrote:
> Alexander Motin wrote:
>>> Your patch to libscg looks definitely OK if we only look at the new
>>> corrected
>>> kernel driver behavior.
>>>
>>> There is a problem:
>>>
>>> In case that there is a sense data residual > 0, libscg will asume that
>>> there
>>> is less sen
Alexander Motin wrote:
> > Your patch to libscg looks definitely OK if we only look at the new
> > corrected
> > kernel driver behavior.
> >
> > There is a problem:
> >
> > In case that there is a sense data residual > 0, libscg will asume that
> > there
> > is less sense data that really pr
Joerg Schilling wrote:
> Marius Strobl wrote:
>> On Fri, Nov 05, 2010 at 08:50:49PM +0200, Alexander Motin wrote:
>>> 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
Marius Strobl wrote:
> 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 o
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.freeb
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 leng
27 matches
Mail list logo