> -----Original Message----- > From: James Bottomley [mailto:jbottomley@xxxxxxxxxxxxx] > Sent: Monday, July 28, 2014 1:03 PM > To: KY Srinivasan > Cc: linux-kernel@xxxxxxxxxxxxxxx; hch@xxxxxxxxxxxxx; sitsofe@xxxxxxxxx; > devel@xxxxxxxxxxxxxxxxxxxxxx; apw@xxxxxxxxxxxxx; > martin.petersen@xxxxxxxxxx; linux-scsi@xxxxxxxxxxxxxxx; > ohering@xxxxxxxx; gregkh@xxxxxxxxxxxxxxxxxxx; jasowang@xxxxxxxxxx > Subject: Re: [PATCH v2 3/3] [SCSI] Make LBP quirk skip lbpme checks tests > > On Mon, 2014-07-28 at 19:05 +0000, KY Srinivasan wrote: > > > > > -----Original Message----- > > > From: Martin K. Petersen [mailto:martin.petersen@xxxxxxxxxx] > > > Sent: Monday, July 28, 2014 12:03 PM > > > To: KY Srinivasan > > > Cc: Martin K. Petersen; Sitsofe Wheeler; Christoph Hellwig; > > > gregkh@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > > > devel@xxxxxxxxxxxxxxxxxxxxxx; ohering@xxxxxxxx; apw@xxxxxxxxxxxxx; > > > jasowang@xxxxxxxxxx; jbottomley@xxxxxxxxxxxxx; linux- > > > scsi@xxxxxxxxxxxxxxx > > > Subject: Re: [PATCH v2 3/3] [SCSI] Make LBP quirk skip lbpme checks > > > tests > > > > > > >>>>> "KY" == KY Srinivasan <kys@xxxxxxxxxxxxx> writes: > > > > > > KY, > > > > > > KY> "At the time thin-provisioning was defined, the discovery > > > KY> information was first proposed in READ CAPACITY 16 command. And > > > then > > > KY> moved into the new dedicated VPD page - B2h. You can see the > > > KY> information reported in this VPD page is richer than READ > > > KY> CAPACITY > > > KY> 16 command. As this transition happened during we added the > > > KY> feature, Windows uses the newer method that based on VPD page > > > KY> B2h. It looks Linux tries to use both new and old method which is > weird to me." > > > > > > The READ CAPACITY(16) response is not optional. > > > > Ok; that settles the issue then. I will attempt to get it fixed on Windows. > > Like Martin says, this isn't optional either/or; it's mandatory to support the RC > 16 bits. If you don't want to get into playing the messenger between us and > the windows guys on SCSI standards, we'd be happy to communicate > directly, either by email or a phone meeting. Thanks James. I will take up your offer if needed. Regards, K. Y _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
