[Stgt-devel] I have found a small problem in the MMC code ...

[ronnie sahlberg]

Can you send me a network trace of this?

Since Read TOC returns the blob size as the first two bytes of data it
should not return
CHECK CONDITION even if there is more data than the initiator asked for.

I think this command might return CHECK CONDITION if there is no disk
in the drive, or if there is a
blank disk.

Please send me a sample capture to test with and Ill compare to a few
read dvd drives.



On Tue, Jul 29, 2008 at 7:16 AM, Richard Sharpe
<realrichardsharpe at gmail.com> wrote:
> Hi,
>
> I have found what I think is a small problem in the MMC code, although
> I am not sure.
>
> I am trying to use cdrecord to write to a DVD Jukebox I have set up
> following Ronnie's example and my code changes.
>
> When the client asks for the TOC, it seems to give us too small an
> allocation length (four bytes) and of course, we give it back only
> what is asked for ... it looks like maybe cdrecord is doing this,
> because the Linux kernel seems to offer a buffer of 12 (at least that
> is what the code says).
>
> In any event, this causes the first write that CD record requests to
> return a CHECK_CONDITION. cdrecord then recovers and the writing of my
> 8GB DVD :-) completes ...
>
> I will have to check the specs carefully, but I wonder if we should be
> returning CHECK_CONDITION as the response to the request for the
> request to read the TOC/PMA/ATIP or is the client supposed to check
> that there was more data than the buffer could hold and then reissue
> the command?
> _______________________________________________
> Stgt-devel mailing list
> Stgt-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/stgt-devel
>