Playstation 3 BD-ROM access and LV1_DENIED_BY_POLICY

Cbe-oss-dev Geert Uytterhoeven 3 participants 4 messages Aug 6, 2007 – Aug 7, 2007 5 messages not in the archive SCSI

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Geert Uytterhoeven

author

2007-08-06 13:38 UTC #5 lore raw

Quoted 11 lines · Geoff Levand

Quoted 7 lines · Nicholas A. Bellinger
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:   [email protected]	
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

James Bottomley

2007-08-06 14:09 UTC #6 lore raw

Quoted 10 lines · Geert Uytterhoeven

Quoted 9 lines · Geoff Levand
Quoted 7 lines · Nicholas A. Bellinger
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.

Quoted 7 lines

Quoted 2 lines
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

Geert Uytterhoeven

author

2007-08-06 14:19 UTC #7 lore raw

Quoted 22 lines · James Bottomley

Quoted 10 lines · Geert Uytterhoeven
Quoted 9 lines · Geoff Levand
Quoted 7 lines · Nicholas A. Bellinger
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.
Quoted 7 lines
Quoted 2 lines
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

Quoted 8 lines

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:   [email protected]	
Internet: http://www.sony-europe.com/

Nicholas A. Bellinger

2007-08-07 08:55 UTC #8 lore raw

Quoted 15 lines · Geert Uytterhoeven

Quoted 14 lines · James Bottomley
Quoted 13 lines · Geert Uytterhoeven
Quoted 11 lines · Geoff Levand
Quoted 7 lines · Nicholas A. Bellinger
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.

Quoted 8 lines

Quoted 8 lines
Quoted 4 lines
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.

Quoted 3 lines

Quoted 3 lines
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.

Quoted 5 lines

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.

Quoted 5 lines

With kind regards,
Geert Uytterhoeven
Software Architect

Many thanks for your most valuable of time.

--nab