[Cbe-oss-dev] Playstation 3 BD-ROM access and LV1_DENIED_BY_POLICY

[Nicholas A. Bellinger]

On Fri, 2007-08-03 at 11:54 +0900, Masakazu Mokuno wrote:
> On Thu, 02 Aug 2007 09:29:08 -0700
> "Nicholas A. Bellinger" <nab at kernel.org> wrote:
> 
> > On Thu, 2007-08-02 at 08:33 -0700, Geoff Levand wrote:
> > > Nicholas A. Bellinger wrote:
> > > 
> > > > 1) Why has this changed after working for me for months, and through 30+
> > > > different commerical BD-ROMs under 2.6.16, only to now be denied with
> > > > *BOTH* kernels with LV1_DENIED_BY_POLICY after a single boot into
> > > > 2.6.23-rc1..?
> > > 
> > > 
> > > It seems strange that it didn't work when you reverted to the 2.6.16 kernel.
> > > My guess, and only a guess, is that your method was in error, or that, as
> > > Ralf suggested, the drive has now changed its behavior, perhaps because with
> > > the new Linux driver there was an interaction with the drive such that entered
> > > a new state, whereas with the old driver there was not such an interaction and
> > > the drive never entered the state.
> > > 
> > 
> > The problem is very specific from my point of view.  Where I was once
> > able to issue the ATAPI command descriptor block (CDB) REPORT_KEY
> > through the hypervisor under GuestOS, I am no longer able to do so on my
> > machine.
> 
> Strange... The PS3 stroage driver of 2.6.16 should not support
> GPCMD_REPORT_KEY (0xa4) except if you added an entry for the command to
> the driver.  The driver has a list of supported SCSI commands,
> drivers/block/ps3pf_strage.c:scsi_cmd_info_table_atapi[256].
> If a requested SCSI command was not in the list, the driver would reply
> with the sense key of ILLEGAL_REQUEST and would not pass the command to the
> hypervisor.  Geert's new driver, mainlined in 2.6.23, will pass any
> commands to the hypervisor.
> 

Thank you for this information.  I since been able to resolve my issue
on 2.6.16 (which ended up being my fault), and was able to determine
that the issue on 2.6.23-rc1 is due to
drivers/scsi/scsi_lib.c:scsi_execute_async() rejecting READ_10 and
TEST_UNIT_READY commands in certain cases (perhaps a race in
drivers/scsi/ps3rom.c..?) using this API that was causing the win32 side
to throw exceptions.

Using 2.6.16 with the legacy drivers/scsi/scsi_lib.c:scsi_do_req() API,
I was able to successfully issue the CDBs requried in order to watch HD
content from the PS3's BD-ROM via iSCSI to the win32 machines, as I have
been doing for a number of months now.  The error on my part was that my
code was picking up scsi_execute_async(), which I forgot existed in
2.6.16, instead of the legacy API, and hence was falling under the still
yet to be determined with scsi_execute_async().

> IIRC, REPORT_KEY command itself has not been supported since first
> release of the hypervisor (firmware) version 1.00.
> 
> So my guess for REPORT_KEY issue is that something of your initiater
> side has been changed in the meantime.
> 
> 

Apparently, the win32 HD decoders do not require REPORT_KEY, SEND_KEY,
et al, which now makes sense after your message considering that I had
never had to modify any of the original 2.6.16 code to get successful
iSCSI export up of the BD-ROM before I ran into these problems on
2.6.23-rc1.

My apologies for the confusion, and many, many thanks to Geoff and
yourself and Geoff for the prompt responses, and pointing me in the
right direction to get my issue resolved.  Your most valuable of time is
greately appreciated.

--nab

PS: Geoff, I will have to owe you a beer.  Thanks again.

> --
> Masakazu MOKUNO
>