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

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

[Geert Uytterhoeven]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1360 bytes --]

On Fri, 3 Aug 2007, Geoff Levand wrote:
> Nicholas A. Bellinger wrote:
> > 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.
> 
> If you get more info on what was happening here, please report it to Geert
> so he can investigate.  He should return next week.

Indeed.

Perhaps because ps3rom cannot queue more than 1 command?
I'm CCing the SCSI guys, just in case this rings a bell.

With kind regards,
 
Geert Uytterhoeven
Software Architect

Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
 
Phone:    +32 (0)2 700 8453	
Fax:      +32 (0)2 700 8622	
E-mail:   Geert.Uytterhoeven@sonycom.com	
Internet: http://www.sony-europe.com/
 	
Sony Network and Software Technology Center Europe	
A division of Sony Service Centre (Europe) N.V.	
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium	
VAT BE 0413.825.160 · RPR Brussels	
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619

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

[James Bottomley]

On Mon, 2007-08-06 at 15:38 +0200, Geert Uytterhoeven wrote:
> On Fri, 3 Aug 2007, Geoff Levand wrote:
> > Nicholas A. Bellinger wrote:
> > > 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.
> > 
> > If you get more info on what was happening here, please report it to Geert
> > so he can investigate.  He should return next week.
> 
> Indeed.
> 
> Perhaps because ps3rom cannot queue more than 1 command?
> I'm CCing the SCSI guys, just in case this rings a bell.

Without details, it's really hard to speculate.  The problem description
is manifestly strange for two reasons

     1. READ_10 should never be issued via scsi_execute_async.  There's
        no ULD in the current kernel that does this.  The READ_X/WRITE_X
        commands are issued through the filesystem path.
     2. There's no command filter in there either:  I can imagine an eh
        problem where the LLD isn't accepting the TUR because it still
        thinks the just recovered command is outstanding.

So could we have some actual details?

James

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

[Geert Uytterhoeven]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2308 bytes --]

On Mon, 6 Aug 2007, James Bottomley wrote:
> On Mon, 2007-08-06 at 15:38 +0200, Geert Uytterhoeven wrote:
> > On Fri, 3 Aug 2007, Geoff Levand wrote:
> > > Nicholas A. Bellinger wrote:
> > > > 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.
> > > 
> > > If you get more info on what was happening here, please report it to Geert
> > > so he can investigate.  He should return next week.
> > 
> > Indeed.
> > 
> > Perhaps because ps3rom cannot queue more than 1 command?
> > I'm CCing the SCSI guys, just in case this rings a bell.
> 
> Without details, it's really hard to speculate.  The problem description
> is manifestly strange for two reasons
> 
>      1. READ_10 should never be issued via scsi_execute_async.  There's
>         no ULD in the current kernel that does this.  The READ_X/WRITE_X
>         commands are issued through the filesystem path.
>      2. There's no command filter in there either:  I can imagine an eh
>         problem where the LLD isn't accepting the TUR because it still
>         thinks the just recovered command is outstanding.
> 
> So could we have some actual details?

Nicholas is using the PS3 as an iSCSI target for watching BD-ROM content on
other machines. That's probably where the weird command submission comes from.

He will hopefully fill in the rest...

With kind regards,
 
Geert Uytterhoeven
Software Architect

Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
 
Phone:    +32 (0)2 700 8453	
Fax:      +32 (0)2 700 8622	
E-mail:   Geert.Uytterhoeven@sonycom.com	
Internet: http://www.sony-europe.com/
 	
Sony Network and Software Technology Center Europe	
A division of Sony Service Centre (Europe) N.V.	
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium	
VAT BE 0413.825.160 · RPR Brussels	
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619

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

[Nicholas A. Bellinger]

On Mon, 2007-08-06 at 16:19 +0200, Geert Uytterhoeven wrote:
> On Mon, 6 Aug 2007, James Bottomley wrote:
> > On Mon, 2007-08-06 at 15:38 +0200, Geert Uytterhoeven wrote:
> > > On Fri, 3 Aug 2007, Geoff Levand wrote:
> > > > Nicholas A. Bellinger wrote:
> > > > > 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.
> > > > 
> > > > If you get more info on what was happening here, please report it to Geert
> > > > so he can investigate.  He should return next week.
> > > 
> > > Indeed.
> > > 
> > > Perhaps because ps3rom cannot queue more than 1 command?
> > > I'm CCing the SCSI guys, just in case this rings a bell.
> > 
> > Without details, it's really hard to speculate.  The problem description
> > is manifestly strange for two reasons
> > 

My apologies for the delay as things have been busy on late..

On the kernel side, the setup is:

Sector Size:

2048 bytes for TYPE_ROM

Max Sectors:

32 from struct scsi_host->max_sectors.  The iSCSI/HD client software is
requesting single sector READ_10s at various LBAs of the media.

iSCSI TCQ:

Setting ExpCmdSn/MaxCmdSn Window == 1 has had no effect.

ATAPI Transport Level TCQ:

A single TCQ slot is detected from struct scsi_host & struct scsi_device
and the lowest of either is set and enforced.  Both scsi_execute_async()
and legacy scsi-request APIs are working elsewhere (outside of PS3
BD-ROM) with single ATAPI Transport level TCQ for SATA + USB and single
or many iSCSI TCQs value settings.

PS3-Linux BD-ROM support:

Also of interest is that both implementations of
drivers/block/ps3pf_storage.c and drivers/scsi/ps3rom.c using
scsi_execute_async() are able to trigger the exception scenario in
question.

PS3 System Software Revision.

There is no affect on PS3 System Software Revision. 

> >      1. READ_10 should never be issued via scsi_execute_async.  There's
> >         no ULD in the current kernel that does this.  The READ_X/WRITE_X
> >         commands are issued through the filesystem path.

Gotcha.  The filesystem path with scsi_excute_async() for SG_IO Cdbs is
where I will move towards supporting ps3-linux git latest.   Also, as
you mention, TUR expections is what eventually causes the software
player stop.  Only the READ_10s appear to be affected by the scenario in
question.

Thanks for this pointer, I will take another look at the wireshark logs
to verify this is indeed the case.

> Nicholas is using the PS3 as an iSCSI target for watching BD-ROM content on
> other machines. That's probably where the weird command submission comes from.
> 
> He will hopefully fill in the rest...
> 

On my side, the goal has been successful export of Linux-iSCSI Targets
with both formats of commerical HD with win32 iSCSI Initiator(s) and
commerical software decoding the many HD discs I have purchased.  These
iSCSI targets include a Linux/ppc64 with PS3 BD-ROM and a Xbox 360
HD-DVD USB, and Linux/x86 and Linux/Alpha export of Philips SPD7000P BD
Writer over GB/sec Ethernet and IPv4/IPv6.  I have been very pleased the
progress so far, and will be posting more info for an HOWTO in the
upcoming weeks.

> With kind regards,
>  
> Geert Uytterhoeven
> Software Architect
> 

Many thanks for your most valuable of time.

--nab