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
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
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
On 11/13/10 20:34, Alexander Motin wrote:
Brandon Gooch wrote:
2010/11/5 Alexander Motin m...@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
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
On Tue, Mar 8, 2011 at 8:29 AM, Jakub Lach jakub_l...@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@
On 08/03/2011 16:15, Brandon Gooch wrote:
On Tue, Mar 8, 2011 at 8:29 AM, Jakub Lachjakub_l...@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
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
On Sun, Nov 14, 2010 at 9:32 AM, Alexander Motin m...@freebsd.org wrote:
Brandon Gooch wrote:
On Sat, Nov 13, 2010 at 3:34 AM, Alexander Motin m...@freebsd.org wrote:
Now uncommitted pass_autosence.patch and possibly cdrtools.patch.
OK. Patched kernel and cdrtools has resulted in a working
Brandon Gooch wrote:
On Sun, Nov 14, 2010 at 9:32 AM, Alexander Motin m...@freebsd.org wrote:
Brandon Gooch wrote:
On Sat, Nov 13, 2010 at 3:34 AM, Alexander Motin m...@freebsd.org wrote:
Now uncommitted pass_autosence.patch and possibly cdrtools.patch.
OK. Patched kernel and cdrtools has
Brandon Gooch wrote:
On Sat, Nov 13, 2010 at 3:34 AM, Alexander Motin m...@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:
...
Brandon Gooch wrote:
2010/11/5 Alexander Motin m...@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:
On Sat, Nov 13, 2010 at 3:34 AM, Alexander Motin m...@freebsd.org wrote:
Brandon Gooch wrote:
2010/11/5 Alexander Motin m...@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
2010/11/5 Alexander Motin m...@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/
Alexander Motin m...@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?
Joerg Schilling wrote:
Alexander Motin m...@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
Alexander Motin m...@freebsd.org 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
Joerg Schilling wrote:
Alexander Motin m...@freebsd.org 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
Alexander Motin m...@freebsd.org 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
Joerg Schilling wrote:
Alexander Motin m...@freebsd.org 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 m...@freebsd.org 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
Marius Strobl mar...@alchemy.franken.de 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
Joerg Schilling wrote:
Marius Strobl mar...@alchemy.franken.de 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
Alexander Motin m...@freebsd.org 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
Joerg Schilling wrote:
Alexander Motin m...@freebsd.org 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
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
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:
27 matches
Mail list logo
