Red Hat Bugzilla – Bug 806223
[virtio-win][serial] guest BSOD when doing s3 while virtio-serial in use
Last modified: 2013-11-21 18:56:02 EST
Description of problem: Version-Release number of selected component (if applicable): 2.6.32-252.el6 qemu-kvm-0.12.1.2.2.248.el6rhev How reproducible: Steps to Reproduce: 1.Start Guest with virtio serial 2.write a scripts to transfer data from guest to host via virtio-serial-port 3.during step2 ,sleep guest Actual results: guest BSOD Probably caused by : vioser.sys ( vioser!VIOSerialSendCtrlMsg+9b ) Expected results: Additional info: steps simiar with Bug804923 ,Report a new once since the dmp said it might related to virtio serial .
Loading Dump File [I:\bcao\serial\MEMORY.DMP] Kernel Summary Dump File: Only kernel address space is available Symbol search path is: C:\testsymbols\;SRV*c:\symbols*http://msdl.microsoft.com/download/symbols Executable search path is: Windows XP Kernel Version 2600 (Service Pack 3) MP (2 procs) Free x86 compatible Product: WinNt, suite: TerminalServer SingleUserTS Built by: 2600.xpsp_sp3_gdr.111025-1629 Machine Name: Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055d720 Debug session time: Fri Mar 23 08:56:15.609 2012 (GMT+8) System Uptime: 0 days 0:05:45.734 Loading Kernel Symbols ............................................................... ........................... Loading User Symbols PEB is paged out (Peb.Ldr = 7ffdb00c). Type ".hh dbgerr001" for details Loading unloaded module list ........ ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 8E, {c0000005, ba15ab17, b59b4904, 0} PEB is paged out (Peb.Ldr = 7ffdb00c). Type ".hh dbgerr001" for details PEB is paged out (Peb.Ldr = 7ffdb00c). Type ".hh dbgerr001" for details Probably caused by : vioser.sys ( vioser!VIOSerialSendCtrlMsg+9b ) Followup: MachineOwner --------- 0: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e) This is a very common bugcheck. Usually the exception address pinpoints the driver/function that caused the problem. Always note this address as well as the link date of the driver/image that contains this address. Some common problems are exception code 0x80000003. This means a hard coded breakpoint or assertion was hit, but this system was booted /NODEBUG. This is not supposed to happen as developers should never have hardcoded breakpoints in retail code, but ... If this happens, make sure a debugger gets connected, and the system is booted /DEBUG. This will let us see why this breakpoint is happening. Arguments: Arg1: c0000005, The exception code that was not handled Arg2: ba15ab17, The address that the exception occurred at Arg3: b59b4904, Trap Frame Arg4: 00000000 Debugging Details: ------------------ PEB is paged out (Peb.Ldr = 7ffdb00c). Type ".hh dbgerr001" for details PEB is paged out (Peb.Ldr = 7ffdb00c). Type ".hh dbgerr001" for details EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. FAULTING_IP: vioser!VIOSerialSendCtrlMsg+9b [c:\cygwin\tmp\build\source\internal-kvm-guest-drivers-windows\vioserial\sys\control.c @ 46] ba15ab17 8b4604 mov eax,dword ptr [esi+4] TRAP_FRAME: b59b4904 -- (.trap 0xffffffffb59b4904) ErrCode = 00000000 eax=bdad69b0 ebx=00000000 ecx=b59b49a0 edx=00000000 esi=00000000 edi=ba15d7fa eip=ba15ab17 esp=b59b4978 ebp=b59b49bc iopl=0 nv up ei ng nz na po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00210282 vioser!VIOSerialSendCtrlMsg+0x9b: ba15ab17 8b4604 mov eax,dword ptr [esi+4] ds:0023:00000004=???????? Resetting default scope DEFAULT_BUCKET_ID: DRIVER_FAULT BUGCHECK_STR: 0x8E PROCESS_NAME: python.exe LAST_CONTROL_TRANSFER: from 804fe827 to 804f9f43 STACK_TEXT: b59b44cc 804fe827 0000008e c0000005 ba15ab17 nt!KeBugCheckEx+0x1b b59b4894 805420e5 b59b48b0 00000000 b59b4904 nt!KiDispatchException+0x3b1 b59b48fc 80542096 b59b49bc ba15ab17 badb0d00 nt!CommonDispatchException+0x4d b59b4910 8054bd24 00000068 8a5894c0 00001000 nt!KiExceptionExit+0x18a b59b49bc ba159a38 00000000 00000001 00000006 nt!ExAllocatePoolWithTag+0x3bc b59b49dc b9d3c02a 75db8fe8 75a390d0 75aa8d70 vioser!VIOSerialPortCreate+0xfc [c:\cygwin\tmp\build\source\internal-kvm-guest-drivers-windows\vioserial\sys\port.c @ 1126] b59b49f8 b9d3b10e 75db8fe8 75a390d0 75aa8d70 wdf01000!FxIoQueueIoRead::Invoke+0x2a b59b4a34 b9d3b1f0 8a517f68 8a517f78 8a59f7b0 wdf01000!FxPkgGeneral::OnCreate+0x2dd b59b4a50 b9d31a3f 8a517f68 b59b4b4c 804ef19f wdf01000!FxPkgGeneral::Dispatch+0xc3 b59b4a5c 804ef19f 8a247ab8 8a517f68 8a517f68 wdf01000!FxDevice::Dispatch+0x7f b59b4a6c 80583220 8a247aa0 8a4e0fd4 b59b4c04 nt!IopfCallDriver+0x31 b59b4b4c 805bf488 8a247ab8 00000000 8a4e0f30 nt!IopParseDevice+0xa12 b59b4bc4 805bba14 00000000 b59b4c04 00000042 nt!ObpLookupObjectName+0x53c b59b4c18 80576057 00000000 00000000 50995801 nt!ObOpenObjectByName+0xea b59b4c94 805769ce 0021f3b8 c0100080 0021f358 nt!IopCreateFile+0x407 b59b4cf0 805790d8 0021f3b8 c0100080 0021f358 nt!IoCreateFile+0x8e b59b4d30 8054167c 0021f3b8 c0100080 0021f358 nt!NtCreateFile+0x30 b59b4d30 7c90e526 0021f3b8 c0100080 0021f358 nt!KiFastCallEntry+0xfc WARNING: Frame IP not in any known module. Following frames may be wrong. 0021f3b0 00000000 00000000 00000000 00000000 0x7c90e526 STACK_COMMAND: kb FOLLOWUP_IP: vioser!VIOSerialSendCtrlMsg+9b [c:\cygwin\tmp\build\source\internal-kvm-guest-drivers-windows\vioserial\sys\control.c @ 46] ba15ab17 8b4604 mov eax,dword ptr [esi+4] FAULTING_SOURCE_CODE: 42: 43: sg.physAddr = MmGetPhysicalAddress(&cpkt); 44: sg.ulSize = sizeof(cpkt); 45: > 46: if(0 <= vq->vq_ops->add_buf(vq, &sg, 1, 0, &cpkt, NULL, 0)) 47: { 48: vq->vq_ops->kick(vq); 49: while(!vq->vq_ops->get_buf(vq, &len)) 50: { 51: KeStallExecutionProcessor(100); SYMBOL_STACK_INDEX: 0 SYMBOL_NAME: vioser!VIOSerialSendCtrlMsg+9b FOLLOWUP_NAME: MachineOwner MODULE_NAME: vioser IMAGE_NAME: vioser.sys DEBUG_FLR_IMAGE_TIMESTAMP: 4f66615d FAILURE_BUCKET_ID: 0x8E_vioser!VIOSerialSendCtrlMsg+9b BUCKET_ID: 0x8E_vioser!VIOSerialSendCtrlMsg+9b Followup: MachineOwner ---------
please check with the latest build http://download.devel.redhat.com/brewroot/packages/virtio-win-prewhql/0.1/25/win/virtio-win-prewhql-0.1.zip
Tested on virtio-win-prewhql-25 w/ win2k8R2 guests steps: 1.Start guest with vioserial CLI:/usr/libexec/qemu-kvm -M rhel6.3.0 -enable-kvm -m 1024 -smp 4,sockets=4,cores=1,threads=1 -name win2k8-R2 -uuid e2eaca3e-e764-f57b-22f0-74f4ab8c4965 -monitor stdio -rtc base=localtime,driftfix=slew -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/test/win2k8r2,if=none,id=drive-ide0-0-0,format=raw,cache=writeback -device ide-drive,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,script=/etc/qemu-ifup,downscript=no,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:15:af:6a,bus=pci.0,addr=0x4 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -spice port=5910,disable-ticketing -vga qxl -device intel-hda,id=sound0,bus=pci.0,addr=0x5 -device virtio-serial-pci,id=virtioserial0 -chardev socket,path=/tmp/serialport0,id=serialport0,server,nowait -device virtserialport,bus=virtioserial0.0,id=virtioserialport0,chardev=serialport0,name=com.redhat.rhevm.vdsm 2.transfer date via vioserial in a loop 3.during step2 ,s3 guests Actual Restults: Guest still BSOD Based on above ,this issue hasn't been fixed yet ,re-assign this bug .
Moving to RHEL6.4 Since S3 support in RHEL6.3 is not the default, and since the fix involves an infrastructure change from work-items to working thread. Ronen.
In work, need to re-test in 2-3 weeks.
This look like a duplicate of a bug 882795. Mike, can you please confirm? Thanks.
(In reply to comment #13) > This look like a duplicate of a bug 882795. Mike, can you please confirm? > Thanks. Sure ,I remeber you said there is a bug in seabios component will costs guest BSOD .Could you send me the seabios w/ the bug fixed first ,I will try to verify it on this issue Thanks, Mike
(In reply to comment #14) > (In reply to comment #13) > > This look like a duplicate of a bug 882795. Mike, can you please confirm? > > Thanks. > > Sure ,I remeber you said there is a bug in seabios component will costs > guest BSOD .Could you send me the seabios w/ the bug fixed first ,I will try > to verify it on this issue The bug that is related to the BIOS is a virtio-scsi driver's bug. This one (and probably the duplicated bug 882795) is a virtio-serial driver's bug :-). You should be able to verify this one with a latest driver and the current BIOS. > Thanks, > Mike
Re-assigned According to comment #17
*** Bug 916437 has been marked as a duplicate of this bug. ***
(In reply to comment #19) > Re-assigned According to comment #17 A commit was posted (230ec9af49d7d9affab273ec4d826bb0ca3ce813) and is waiting for a build.
*** Bug 917969 has been marked as a duplicate of this bug. ***
Reproduced this issue on virtio-win-prewhql-0.1-54 version Verified this issue on virtio-win-prewhql-0.1-55&virtio-win-prewhql-0.1-58 verion steps same as comment#0 Actual Results: on virtio-win-prewhql-0.1-54 verion ,guest BSOD when doing s3 while virtio-serial in use; on virtio-win-prewhql-0.1-55&virtio-win-prewhql-0.1-58 verion ,guest can sleep&wakeup normally Based on above ,this issue has been fixed already.
Based on Comment #28 ,Move status to Verified
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