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 - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
