Bug 1003158
| Summary: | vioscsi.sys doesn't return scsi status codes correctly to guest OS | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Corinna Vinschen <vinschen> | ||||||||
| Component: | virtio-win | Assignee: | Vadim Rozenfeld <vrozenfe> | ||||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Virtualization Bugs <virt-bugs> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 7.0 | CC: | bcao, bsarathy, dfleytma, ghammer, hhuang, juzhang, lersek, lijin, mdeng, michen, pbonzini, qzhang, rbalakri, rhod, sluo, vinschen, virt-bugs, virt-maint, vrozenfe, yvugenfi | ||||||||
| Target Milestone: | rc | ||||||||||
| Target Release: | 7.0 | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Windows | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2014-11-09 10:43:22 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
Try to reproduce this issue with following steps: 1.Connect to an iscsi disk:/dev/sdf 2.Boot win7-32 guest with: /usr/libexec/qemu-kvm -drive file=/dev/sdf,if=none,cache=none,media=disk,format=raw,id=drive-ide0-0-1 -device virtio-scsi-pci,id=scsi0 -device scsi-hd,drive=drive-ide0-0-1,bus=scsi0.0,id=scsi1,bootindex=0 -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -usb -device usb-tablet -vnc :22 -netdev tap,id=hostnet0,script=/etc/qemu-ifup -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:7f:f9:F6,bus=pci.0 -monitor stdio -chardev file,path=/root/console.log,id=serial1 -device isa-serial,chardev=serial1,id=s1 -cpu Penryn,hv_relaxed,family=0xe -M rhel6.4.0 -smp 2,maxcpus=2,cores=2,threads=1,sockets=1 -m 2G -enable-kvm -chardev socket,id=111a,path=/tmp/test,server,nowait -mon chardev=111a,mode=readline 3.Update the scsi driver to build 68 4.Run get_tape.exe in windows cmd Actual result: after step4: it always display in cmd "CreateFile:2" Corinna,Dmitry,could you tell me how to reproduce this issue. (In reply to lijin from comment #6) > Try to reproduce this issue with following steps: > 1.Connect to an iscsi disk:/dev/sdf > 2.Boot win7-32 guest with: > /usr/libexec/qemu-kvm -drive > file=/dev/sdf,if=none,cache=none,media=disk,format=raw,id=drive-ide0-0-1 > -device virtio-scsi-pci,id=scsi0 -device > scsi-hd,drive=drive-ide0-0-1,bus=scsi0.0,id=scsi1,bootindex=0 -global > PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -usb -device usb-tablet > -vnc :22 -netdev tap,id=hostnet0,script=/etc/qemu-ifup -device > e1000,netdev=hostnet0,id=net0,mac=52:54:00:7f:f9:F6,bus=pci.0 -monitor stdio > -chardev file,path=/root/console.log,id=serial1 -device > isa-serial,chardev=serial1,id=s1 -cpu Penryn,hv_relaxed,family=0xe -M > rhel6.4.0 -smp 2,maxcpus=2,cores=2,threads=1,sockets=1 -m 2G -enable-kvm > -chardev socket,id=111a,path=/tmp/test,server,nowait -mon > chardev=111a,mode=readline > 3.Update the scsi driver to build 68 > 4.Run get_tape.exe in windows cmd > > Actual result: > after step4: it always display in cmd "CreateFile:2" > > Corinna,Dmitry,could you tell me how to reproduce this issue. It can be tricky. I have no idea what get_tape does, if it sends READ POSITION - it should be fine to use it as a quick test tool. For more comprehensive testing I would probably try running HCK against SCSI tape device. Even running HCK against an emulated SCSI disk device should fail some tests. Vadim, perhaps you can run the SCSI test from the command-line and find a test that fails? There are many tests there that are not part of the logo program. (In reply to Paolo Bonzini from comment #8) > Even running HCK against an emulated SCSI disk device should fail some > tests. Vadim, perhaps you can run the SCSI test from the command-line and > find a test that fails? There are many tests there that are not part of the > logo program. Yes, we can run scsi complains test manually. The problem is that it didn't reveal any problem during WHQL'ing 6.4 drivers. Maybe HCK 8.0/8.1 have more comprehensive set of tests. (In reply to Vadim Rozenfeld from comment #9) > (In reply to Paolo Bonzini from comment #8) > > Even running HCK against an emulated SCSI disk device should fail some > > tests. Vadim, perhaps you can run the SCSI test from the command-line and > > find a test that fails? There are many tests there that are not part of the > > logo program. > > Yes, we can run scsi complains test manually. The problem is that it didn't > reveal any problem during WHQL'ing 6.4 drivers. Maybe HCK 8.0/8.1 have more > comprehensive set of tests. Do you mean HCK2.1 ? the matrix of certification test should be same Mike I was using this one with Xen: http://msdn.microsoft.com/en-us/library/gg607509%28v=vs.85%29.aspx This test could detect the bug: Title: ASSERTION: INQUIRY Test for error when PAGE CODE field is nonzero and EVPD=0 Description: Checking that an error is returned when PAGE CODE field is nonzero and EVPD=0. Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) specification Section 6.4.2. http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf Expectation: ScsiStatus == 0x2, CHECK CONDITION But IIRC this test is only done as part of the disk logo program, not the controller logo program. That's why WHQL'ing the driver didn't detect the problem. The SCSI compliance test executable has to be run manually to pick the appropriate testcase. Mike, could you please share or check cpk file from the latest virtio-scsi submission. I might be wrong, but it definitely should have "StorHDD" logoprogram SCSI compliance tests. Thanks, Vadim. (In reply to Vadim Rozenfeld from comment #13) > Mike, could you please share or check cpk file from the latest virtio-scsi > submission. I might be wrong, but it definitely should have "StorHDD" > logoprogram SCSI compliance tests. > > Thanks, > Vadim. Do you mean PCI Hardware Compliance Test For a Single Device (PCIHCT) ? you can find previous testing results from https://docspace.corp.redhat.com/docs/DOC-107342 . Attention that we run virtio-scsi certification as "Stroage Controller "product type instead of "StroHDD" product type or "Optioncal Drive" product type. Best Regards, Mike (In reply to Paolo Bonzini from comment #12) > I was using this one with Xen: > > http://msdn.microsoft.com/en-us/library/gg607509%28v=vs.85%29.aspx > > This test could detect the bug: > > Title: ASSERTION: INQUIRY Test for error when PAGE CODE field is nonzero and > EVPD=0 > Description: Checking that an error is returned when PAGE CODE field is > nonzero and EVPD=0. > Reference: SCSI Primary Commands - 3 (SPC-3) Revision 23 (or published) > specification Section 6.4.2. > http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf > Expectation: ScsiStatus == 0x2, CHECK CONDITION > > But IIRC this test is only done as part of the disk logo program, not the > controller logo program. That's why WHQL'ing the driver didn't detect the > problem. The SCSI compliance test executable has to be run manually to pick > the appropriate testcase. No. Actually I think QE hit this issue. The reason we did not detect it due to https://sysdev.microsoft.com/en-US/Hardware/EC/FilterDetail.aspx?id=2225 that MSFT would like us to workaound it Mike Created attachment 811556 [details]
HCKX log file
Sorry ,ignore my last comment QE tried it on virtio-win-prewhql-71 SCSI Compliance Test Failed Re-assigned this issue Probably fixed on build 74 with virtio-win-1.6.8-4.el7.noarch,run "SCSI Compliance Test (LOGO)" and "SCSI Compliance Test 2.0" on win2k8-R2 && win8-64 guests,both jobs failed. I will upload the hck log later. Created attachment 866898 [details]
win2k8-R2-scsi-hck-log
re-assigned according to comment #19 QE, Probably fixed. Can you check? I suggest to close this bug as fixed. Let's create a new one for the problem mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1003158#c19. Thanks, Vadim. (In reply to Vadim Rozenfeld from comment #26) > I suggest to close this bug as fixed. > Let's create a new one for the problem > mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1003158#c19. OK from QE's side But Is it worthy to report a new bug as HCK did not detect SCSI compliance tests automately ? Mike > > Thanks, > Vadim. (In reply to Mike Cao from comment #27) > (In reply to Vadim Rozenfeld from comment #26) > > I suggest to close this bug as fixed. > > Let's create a new one for the problem > > mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1003158#c19. > > OK from QE's side > But Is it worthy to report a new bug as HCK did not detect SCSI compliance > tests automately ? I think yes. 8 out of 107 tests failed last time. Can re-run it again on the most recent rhel 7.1 host? Cheers, Vadim. > > Mike > > > > Thanks, > > Vadim. (In reply to Vadim Rozenfeld from comment #28) > (In reply to Mike Cao from comment #27) > > (In reply to Vadim Rozenfeld from comment #26) > > > I suggest to close this bug as fixed. > > > Let's create a new one for the problem > > > mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1003158#c19. > > > > OK from QE's side > > But Is it worthy to report a new bug as HCK did not detect SCSI compliance > > tests automately ? > > I think yes. > 8 out of 107 tests failed last time. Can re-run it again on the most recent > rhel 7.1 host? > Sure dengmin ,pls retest SCSI Compliance Test with win2k8-R2 and Win8-64 bit guest on virtio-win-prewhql-93 on RHEL7.1 host ,feel free to report a new bug w/ the log attached if the test still failed Mike (In reply to Mike Cao from comment #29) > (In reply to Vadim Rozenfeld from comment #28) > > (In reply to Mike Cao from comment #27) > > > (In reply to Vadim Rozenfeld from comment #26) > > > > I suggest to close this bug as fixed. > > > > Let's create a new one for the problem > > > > mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1003158#c19. > > > > > > OK from QE's side > > > But Is it worthy to report a new bug as HCK did not detect SCSI compliance > > > tests automately ? > > > > I think yes. > > 8 out of 107 tests failed last time. Can re-run it again on the most recent > > rhel 7.1 host? > > > Sure > > dengmin ,pls retest SCSI Compliance Test with win2k8-R2 and Win8-64 bit > guest on virtio-win-prewhql-93 on RHEL7.1 host ,feel free to report a new > bug w/ the log attached if the test still failed > > Mike According to Mike's comments QE tried the bug with build 93,fortunately the job (SCSI Compliance Test) still failed on win2008R2 and win8-64 Platform. Notes,the job isn't included in "Certification" category by default but need me to add additional features and then it could be selected and executed.I will report a new bug about these failures,thanks. Build info, kernel-3.10.0-186.el7.x86_64 qemu-kvm-rhev-2.1.2-1.el7.x86_64u (In reply to dengmin from comment #30) > (In reply to Mike Cao from comment #29) > > (In reply to Vadim Rozenfeld from comment #28) > > > (In reply to Mike Cao from comment #27) > > > > (In reply to Vadim Rozenfeld from comment #26) > > > > > I suggest to close this bug as fixed. > > > > > Let's create a new one for the problem > > > > > mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1003158#c19. > > > > > > > > OK from QE's side > > > > But Is it worthy to report a new bug as HCK did not detect SCSI compliance > > > > tests automately ? > > > > > > I think yes. > > > 8 out of 107 tests failed last time. Can re-run it again on the most recent > > > rhel 7.1 host? > > > > > Sure > > > > dengmin ,pls retest SCSI Compliance Test with win2k8-R2 and Win8-64 bit > > guest on virtio-win-prewhql-93 on RHEL7.1 host ,feel free to report a new > > bug w/ the log attached if the test still failed > > > > Mike > > According to Mike's comments QE tried the bug with build 93,fortunately > the job (SCSI Compliance Test) still failed on win2008R2 and win8-64 > Platform. > Notes,the job isn't included in "Certification" category by default but > need me to add additional features and then it could be selected and > executed.I will report a new bug about these failures,thanks. > Build info, > kernel-3.10.0-186.el7.x86_64 > qemu-kvm-rhev-2.1.2-1.el7.x86_64u Pls report a new bug for it according to comment #28 Mike (In reply to dengmin from comment #30) > (In reply to Mike Cao from comment #29) > > (In reply to Vadim Rozenfeld from comment #28) > > > (In reply to Mike Cao from comment #27) > > > > (In reply to Vadim Rozenfeld from comment #26) > > > > > I suggest to close this bug as fixed. > > > > > Let's create a new one for the problem > > > > > mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1003158#c19. > > > > > > > > OK from QE's side > > > > But Is it worthy to report a new bug as HCK did not detect SCSI compliance > > > > tests automately ? > > > > > > I think yes. > > > 8 out of 107 tests failed last time. Can re-run it again on the most recent > > > rhel 7.1 host? > > > > > Sure > > > > dengmin ,pls retest SCSI Compliance Test with win2k8-R2 and Win8-64 bit > > guest on virtio-win-prewhql-93 on RHEL7.1 host ,feel free to report a new > > bug w/ the log attached if the test still failed > > > > Mike > > According to Mike's comments QE tried the bug with build 93,fortunately > the job (SCSI Compliance Test) still failed on win2008R2 and win8-64 > Platform. > Notes,the job isn't included in "Certification" category by default but > need me to add additional features and then it could be selected and > executed.I will report a new bug about these failures,thanks. > Build info, > kernel-3.10.0-186.el7.x86_64 > qemu-kvm-rhev-2.1.2-1.el7.x86_64u New bug,Bug 1161453 - [whql][vioscsi]Job named by SCSI Compliance Test (LOGO) failed on win2k8-R2 and win8-64 guest |
Created attachment 792398 [details] WIndows test case for READ POSITION LONG Description of problem: Consider using a host SCSI tape drive from a Windows guest, which doesn't understand the READ POSITION LONG command. When checking the current tape position (Win32 API call GetTapePosition), the guest tape driver tries to use this command. If it works (the returned SCSI status is 0) it uses the information. Otherwise it falls back to READ POSITION without the LONG flag and uses that information. This works fine when using the SCSI controller emulation "lsisas1078" aka "megasas.sys" in Windows, but it fails when using the "virtio-scsi" emulation aka "vioscsi.sys" in Windows. The problem is, that for some reason the vioscsi driver returns an SCSI status of 0, even if READ POSITION LONG failed, and thus the tape driver accidentally uses the sense information as if it is position information. A Windows test application (attached) using SCSI passthrough commands shows that the SCSI status after calling READ POSITION LONG is, in fact, 2. So the SCSI status gets lost at some point, and the only component which is between the tape drive and the tape driver is the SCSI controller driver. Version-Release number of selected component (if applicable): virtio-win-1.6.6-1.el6.noarch How reproducible: Connect a tape drive which doesn't understand READ POSITION LONG to the host, add virtio-scsi controller and hostdev entry matching the tape drive to the guest. Install vioscsi.sys. Fetch position information from the drive. Observe strange values. Actual results: Wrong position information returned by Win32 API call GetTapePosition. Expected results: Correct position information returned by Win32 API call GetTapePosition. Additional info: The attached testcase can be compiled with Cygwin or Mingw-w64 gcc. It prints the info given by GetTapePosition and it tries to read the position info using READ POSITION LONG. With a tape drive not supporting READ POSITION LONG, the GetTapePosition should still return the correct information. The SCSI passthrough attempt should result in sense informatioṅ. This works with the megasas driver. With the vioscsi driver, the information returned by GetTapePosition is broken, and it also prints the broken position information from the SCSI passthrough command, because the SCSI status code is 0.