> -----Original Message----- > From: James Bottomley [mailto:James.Bottomley@xxxxxxxxxxxxxxxxxxxxx] > Sent: Sunday, March 04, 2012 9:49 AM > To: KY Srinivasan > Cc: Christoph Hellwig; gregkh@xxxxxxxxxxxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx; devel@xxxxxxxxxxxxxxxxxxxxxx; > virtualization@xxxxxxxxxxxxxx; ohering@xxxxxxxx; linux-scsi@xxxxxxxxxxxxxxx; > Haiyang Zhang > Subject: RE: [PATCH 1/1] Drivers: scsi: storvsc: Don't pass ATA_16 command to > the host > > On Sun, 2012-03-04 at 14:23 +0000, KY Srinivasan wrote: > > > > > -----Original Message----- > > > From: Christoph Hellwig [mailto:hch@xxxxxxxxxxxxx] > > > Sent: Sunday, March 04, 2012 4:12 AM > > > To: KY Srinivasan > > > Cc: gregkh@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > > > devel@xxxxxxxxxxxxxxxxxxxxxx; virtualization@xxxxxxxxxxxxxx; > ohering@xxxxxxxx; > > > jbottomley@xxxxxxxxxxxxx; hch@xxxxxxxxxxxxx; linux-scsi@xxxxxxxxxxxxxxx; > > > Haiyang Zhang > > > Subject: Re: [PATCH 1/1] Drivers: scsi: storvsc: Don't pass ATA_16 command to > > > the host > > > > > > On Fri, Mar 02, 2012 at 12:49:07PM -0800, K. Y. Srinivasan wrote: > > > > Windows hosts don't handle the ATA_16 command; don't pass it to the > host. > > > > > > Most devices don't handle it, and answer with and unsupported opcode > > > sense reason. If hyperv iis buggy enough to crap out on it please add > > > a comment explaining that. > > > > The host does not "crap out", it does return an error code but it is not > "unsupported opcode". > > The sense reason that comes back is a generic error SRB_STATUS code. It is > easier for me to filter the > > command on the outgoing side as opposed to dealing with a generic error code > that is coming back from > > the host. > > That's the wrong thing to do ... you need to unwrap the error code. > The reason being I presume it's not impossible for Windows to host a > device supporting ATA_16 and there are signs that this is going to be > necessary to prevent data corruption on some USB devices ... if you just > filter the command without checking if the host supports it, you're > going to end up perpetuating the corruption problem. James, Currently, the Windows host does not provide me with granular error codes to distinguish between the case where the operation failed and the case where it is an illegal or unsupported operation. I have asked the windows team to return more appropriate error codes and they may do that sometime soon. In the interim, filtering the command on the outgoing path is the best way I can deal with this issue. Currently, even on the host side they are filtering this command, except they are returning a failure to the guest instead of a more appropriate error code. While my proposal has been accepted for windows 8, I don't know when this change will ship. Also, it is not clear when prior versions of Windows hosts that we care about will pick up this change. This patch is the only way I know how to deal with this problems within my current constraints. Regards, K. Y > > The general rule of thumb for avoiding this is to let the lower layers > handle as much as possible, and only begin behaviour alterations in the > upper layers if the lower layers have a provable and usually fatal > failure. > > James > > ��.n��������+%������w��{.n�����{������ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
