Hide Forgot
Cause: Switching system Hibernate Mode(S4) while transferring data over virtio-serial device. Consequence: System fails into BSOD Fix: in virtio-serial driver. Changes in lock acquire/release logic. Result: System can be switched to S4 state without BSOD, after applying this fix.
Description of problem: Version-Release number of selected component (if applicable): 2.6.32-345.el6.x86_64 qemu-kvm-rhev-0.12.1.2-2.337.el6.x86_64 virtio-win-prewhql-49 win7-32bit guest How reproducible: 2/2 Steps to Reproduce: 1.Start Guest with virtio-serial-pci CLI:/usr/libexec/qemu-kvm -M rhel6.4.0 -m 2G -smp 2 -cpu host -usbdevice tablet -drive file=win7-32.qcow2,format=qcow2,if=none,id=drive-ide0-0-0,werror=stop,rerror=stop,cache=none -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,id=hostnet0,script=/etc/qemu-ifup -device e1000,netdev=hostnet0,mac=00:20:51:12:28:10,bus=pci.0,addr=0x4,id=net0 -boot c -uuid 813ef818-efd6-4031-9540-59f8c01d66e6 -rtc-td-hack -no-kvm-pit-reinjection -name win7-32 -vnc :4 -vga std -device virtio-serial-pci,id=virtio-serial0,max_ports=16,vectors=4,bus=pci.0 -chardev socket,path=/tmp/tt,server,nowait,id=channel0 -device virtserialport,chardev=channel0,name=com.redhat.rhevm.vdsm,bus=virtio-serial0.0 -monitor stdio -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=0 -cdrom /home/en_windows_7_ultimate_with_sp1_x86_dvd_619077.iso 2.on the host ,open the receiving side #for((;;)); do python serial-host-receive.py /tmp/tt; done 3.in the guest ,tranferring data via virtserialport #for ((;;)); do python serial-host-receive.py com.redhat.rhevm.vdsm;done 4.doing hibernate in the guest Actual results: guest BSOD Expected results: No BSOD occurs Additional info:
S3 hit the same issue during transferring data from guest to host as well
Hi Gal, Could you please take a look at this. It seems to be regression introduced by e8a1de0760cc95332da52e681303031629015cdb because it reverted some stuff fixed in c93ef0adfb6bd68e6cc730ebe6edf34972ee6bd3 : Bug 806223 - [virtio-win][serial] guest BSOD when doing s3 while virtio-serial in use. Bug 714908 - [virtio-win][serial] virtio-serial is disfunctional after S3 Bug 814896 - [virtio-win][serial] virtio-serial does not work after s4 in win7-32/64 bit guests Bug 823818 - [virtio-win][compatibilty]Guest freeze After terminating the virtserialport receiving side in the host Thank you, Vadim.
seems this is a known issue referring to Bug 806223
also hit this issue when tranferring data from host to guest during s3
(In reply to comment #5) > seems this is a known issue referring to Bug 806223 Hi Mike, what about 806223 and 714908? Hope they are still fine. Best regards, Vadim.
(In reply to comment #7) > (In reply to comment #5) > > seems this is a known issue referring to Bug 806223 > > Hi Mike, > what about 806223 and 714908? Hope they are still fine. > Best regards, > Vadim. I think this bug is dup of Bug 806223 ,and the status of Bug 806223 is post and product flag is rhel6.5.0 ,I never know it has been fixed ever. Re-tried https://bugzilla.redhat.com/show_bug.cgi?id=714908 ,This issue works to me ,no regression found Mike
(In reply to comment #4) > Hi Gal, > Could you please take a look at this. > It seems to be regression introduced by > e8a1de0760cc95332da52e681303031629015cdb > because it reverted some stuff fixed in > c93ef0adfb6bd68e6cc730ebe6edf34972ee6bd3 : > Bug 806223 - [virtio-win][serial] guest BSOD when doing s3 while > virtio-serial in use. Bug 714908 - [virtio-win][serial] virtio-serial is > disfunctional after S3 Bug 814896 - [virtio-win][serial] virtio-serial does > not work after s4 in win7-32/64 bit guests Bug 823818 - > [virtio-win][compatibilty]Guest freeze After terminating the virtserialport > receiving side in the host > > Thank you, > Vadim. The bug occur on function VIOSerialPortCreate. The user open (create) the device after VIOSerialEvtDeviceD0Exit was called and return. The VIOSerialPortCreate function tries to notify the host that the port is open using VIOSerialSendCtrlMsg. But since the device is powered down at this stage pContext->c_ovq is NULL and I believe that the function call vq->vq_ops->add_buf crash the system. The proper solution would be to tell WDF to disable the file handle to device. However, I don't know how to do it yet. The quick solution would be to see if the device is active and if not fail the create request. Vadim? What do you think?
(In reply to comment #9) > (In reply to comment #4) > > Hi Gal, > > Could you please take a look at this. > > It seems to be regression introduced by > > e8a1de0760cc95332da52e681303031629015cdb > > because it reverted some stuff fixed in > > c93ef0adfb6bd68e6cc730ebe6edf34972ee6bd3 : > > Bug 806223 - [virtio-win][serial] guest BSOD when doing s3 while > > virtio-serial in use. Bug 714908 - [virtio-win][serial] virtio-serial is > > disfunctional after S3 Bug 814896 - [virtio-win][serial] virtio-serial does > > not work after s4 in win7-32/64 bit guests Bug 823818 - > > [virtio-win][compatibilty]Guest freeze After terminating the virtserialport > > receiving side in the host > > > > Thank you, > > Vadim. > > The bug occur on function VIOSerialPortCreate. The user open (create) the > device after VIOSerialEvtDeviceD0Exit was called and return. The That's strange. Do you mean that even though device is leaving D0 state and the system is in transition from S0 to S4 we still continue receiving CreateFile requests from user mode application? If it's true, we must be able to hit the same problem during surprise removal. > VIOSerialPortCreate function tries to notify the host that the port is open > using VIOSerialSendCtrlMsg. But since the device is powered down at this > stage pContext->c_ovq is NULL and I believe that the function call > vq->vq_ops->add_buf crash the system. > > The proper solution would be to tell WDF to disable the file handle to > device. However, I don't know how to do it yet. > > The quick solution would be to see if the device is active and if not fail > the create request. > > Vadim? What do you think? Agree, failing a create request in this situation will be a good idea. Best regards, Vadim.
- Not required for WHQL - S3/S4 support is not mandatory for RHEL6.4 Deferring to RHEL6.5
Created attachment 660307 [details] Fix for the bug based on private repository from git.engineering
Fix for this bug based on Vadym's private repository is attached. Please, review it and commit as I don't have corresponding permissions. Also pay attention that the patch doesn't fix all possible problems. See commit message for additional details.
Dmitry's patch seems to solve the crash. Thanks! Although I'm not sure I fully understand this solution. For example, in the VIOSerialPortCreate function only the out and control queues are used. So why do you acquire a lock on the input buffer which is not used?
It could be I missed something because I'm not deeply familiar with serial driver's code yet. I didn't change locks used in this function, I just ordered them in a proper way. Also as I wrote in the commit message locking scheme of the driver needs to be redesigned as it doesn't look proper for me. I believe separate bug needs to be open for this.
Reproduce this bug with virtio-win-prewhql-49 on win7-32,test this bug with virtio-win-prewhql-51 with steps as comment #0 Actually Results: on version virtio-win-prewhql-49,qemu-kvm quit with "Guest move used index from 0 to 256" on version virtio-win-prewhql-51, no BSOD happened, but after guest resume, virtio-serial function fail with error in qemu side :"(qemu) qemu-kvm: virtio-serial-bus: Guest failure in adding port 1 for device virtio-serial0.0". virtio-serial can work well after reboot guest. Based on above, this issue haven't been fixed yet, re-assign this bug. Thanks! Best Regards, Dawn
(In reply to comment #16) > Reproduce this bug with virtio-win-prewhql-49 on win7-32,test this bug with > virtio-win-prewhql-51 with steps as comment #0 > > Actually Results: > on version virtio-win-prewhql-49,qemu-kvm quit with "Guest move used index > from 0 to 256" > on version virtio-win-prewhql-51, no BSOD happened, but after guest resume, > virtio-serial function fail with error in qemu side :"(qemu) qemu-kvm: > virtio-serial-bus: Guest failure in adding port 1 for device > virtio-serial0.0". > virtio-serial can work well after reboot guest. > > Based on above, this issue haven't been fixed yet, re-assign this bug. Don't you think this is another issue which is not related to this one?
(In reply to comment #17) > (In reply to comment #16) > > Reproduce this bug with virtio-win-prewhql-49 on win7-32,test this bug with > > virtio-win-prewhql-51 with steps as comment #0 > > > > Actually Results: > > on version virtio-win-prewhql-49,qemu-kvm quit with "Guest move used index > > from 0 to 256" > > on version virtio-win-prewhql-51, no BSOD happened, but after guest resume, > > virtio-serial function fail with error in qemu side :"(qemu) qemu-kvm: > > virtio-serial-bus: Guest failure in adding port 1 for device > > virtio-serial0.0". > > virtio-serial can work well after reboot guest. > > > > Based on above, this issue haven't been fixed yet, re-assign this bug. > > Don't you think this is another issue which is not related to this one? Since no BOSD occurs ,we can consider the original issue has gone ,Dawu ,pls report a new bug to track your issue you hit . Mike
Report another bug for the new issue, please refer to https://bugzilla.redhat.com/show_bug.cgi?id=902153 Thanks Best Regards, Dawn
Since the Original issue has gone ,Move status to VERIFIED. Need to mention that we decided to ship build49 to customers ,Pls keep product flags to RHEL6.5.0. Mike
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1729.html