RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 693993 - BSOD sometimes happened when run whql NIC jobs
Summary: BSOD sometimes happened when run whql NIC jobs
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.1
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Virtualization Maintenance
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-04-06 08:14 UTC by Chao Yang
Modified: 2013-01-09 23:45 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-04-11 14:21:17 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
BSOD-nic.png (19.20 KB, image/png)
2011-04-06 08:14 UTC, Chao Yang 		no flags Details
View All

Comment 2 RHEL Program Management 2011-04-06 08:23:54 UTC 
Since RHEL 6.1 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.
Comment 3 dawu 2011-04-06 08:42:23 UTC 
Since forgetting to log into bz with my account, use other account to report this bug, actually this bug is reported by dawu,sorry for my mistake.
Comment 4 dawu 2011-04-06 08:46:47 UTC 
Please refer to the crash dump analysis according to comment #9 in bug 684082,(https://bugzilla.redhat.com/show_bug.cgi?id=684082#c9)

Crash dump analysis:
0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

THREAD_STUCK_IN_DEVICE_DRIVER (ea)
The device driver is spinning in an infinite loop, most likely waiting for
hardware to become idle. This usually indicates problem with the hardware
itself or with the device driver programming the hardware incorrectly.
If the kernel debugger is connected and running when watchdog detects a
timeout condition then DbgBreakPoint() will be called instead of KeBugCheckEx()
and detailed message including bugcheck arguments will be printed to the
debugger. This way we can identify an offending thread, set breakpoints in it,
and hit go to return to the spinning code to debug it further. Because
KeBugCheckEx() is not called the .bugcheck directive will not return bugcheck
information in this case. The arguments are already printed out to the kernel
debugger. You can also retrieve them from a global variable via
"dd watchdog!g_WdBugCheckData l5" (use dq on NT64).
On MP machines (OS builds <= 3790) it is possible to hit a timeout when the
spinning thread is
interrupted by hardware interrupt and ISR or DPC routine is running at the time
of the bugcheck (this is because the timeout's work item can be delivered and
handled on the second CPU and the same time). If this is the case you will have
to look deeper at the offending thread's stack (e.g. using dds) to determine
spinning code which caused the timeout to occur.
Arguments:
Arg1: fffffa800348ba80, Pointer to a stuck thread object.  Do .thread then kb
on it to find
 the hung location.
Arg2: fffffa80034c7990, Pointer to a DEFERRED_WATCHDOG object.
Arg3: fffffa80034bf850, Pointer to offending driver name.
Arg4: 0000000000000001, Number of times this error occurred.  If a debugger is
attached,
 this error is not always fatal -- see DESCRIPTION below.  On the
 blue screen, this will always equal 1.

Debugging Details:
------------------

Page 2170e not present in the dump file. Type ".hh dbgerr004" for details
Page 23162 not present in the dump file. Type ".hh dbgerr004" for details
ERROR - could not read driver name for bugcheck parameter 3

Page 23162 not present in the dump file. Type ".hh dbgerr004" for details
Page 23162 not present in the dump file. Type ".hh dbgerr004" for details
PEB is paged out (Peb.Ldr = 000007ff`fffdf018).  Type ".hh dbgerr001" for
details
PEB is paged out (Peb.Ldr = 000007ff`fffdf018).  Type ".hh dbgerr001" for
details

FAULTING_THREAD:  fffffa800348ba80

FAULTING_IP: 
framebuf!bInitSURF+47
fffff960`009d22e3 3bc5            cmp     eax,ebp

IMAGE_NAME:  framebuf.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  4a5bc587

MODULE_NAME: framebuf

FAULTING_MODULE: fffff960009d0000 framebuf

DEFAULT_BUCKET_ID:  GRAPHICS_DRIVER_FAULT

BUGCHECK_STR:  0xEA

PROCESS_NAME:  csrss.exe

CURRENT_IRQL:  1

LAST_CONTROL_TRANSFER:  from fffff88001995c54 to fffff800026cd740

STACK_TEXT:  
fffff880`040684f8 fffff880`01995c54 : 00000000`000000ea fffffa80`0348ba80
fffffa80`034c7990 fffffa80`034bf850 : nt!KeBugCheckEx
fffff880`04068500 fffff800`026aa0b7 : fffffa80`0348ba80 fffffa80`0348bad0
00000000`00000001 fffff800`02615939 : VIDEOPRT!WdpKernelApc+0x2e8
fffff880`04068a30 fffff800`026aa477 : 00000000`00000001 00000000`00000000
00000000`00000000 00000000`00000000 : nt!KiDeliverApc+0x1d7
fffff880`04068ab0 fffff800`0262b9d6 : 00000000`00000010 00000000`00000001
fffff800`02614000 fffff800`0262de3e : nt!KiApcInterrupt+0xd7
fffff880`04068c40 fffff800`0262c03f : fffff800`0263bf60 00000000`00000001
00000000`00000000 fffff800`02614000 : hal!x86BiosWriteIoSpace+0x15e
fffff880`04068c90 fffff800`0262be30 : fffff800`0263bf60 fffff880`04068d60
00000000`00000000 fffff880`04068d60 : hal!XmEmulateStream+0x10f
fffff880`04068cc0 fffff800`026251c5 : 00000000`00000000 00000000`00004115
fffffa80`034c8fc0 fffff880`04068db0 : hal!x86BiosExecuteInterruptShadowed+0xfc
fffff880`04068cf0 fffff880`0199f0a7 : 00000000`00000000 00000000`00000000
fffffa80`0278c300 00000000`00000000 : hal!x86BiosCall+0x45
fffff880`04068d30 fffff880`03c6830d : 00000000`00000007 fffffa80`029fe618
00000000`00000000 fffff800`0285c880 : VIDEOPRT!VideoPortInt10+0x9f
fffff880`04068d90 fffff880`03c68d81 : fffffa80`0278c380 00000000`00000000
00000000`00000000 fffff880`00e1d9ac : vgapnp!VgaSetMode+0x115
fffff880`04068df0 fffff880`019aaeb3 : fffffa80`0278c500 fffff880`00000000
00000000`00000000 00000000`00000000 : vgapnp!VgaStartIO+0x2e5
fffff880`04068e90 fffff960`00084abe : 00000000`00000004 fffffa80`0278c350
fffff900`c0083de8 fffffa80`029fe618 : VIDEOPRT!pVideoPortDispatch+0x3af
fffff880`04068f40 fffff960`001f83a8 : fffff900`c0083db0 00000000`00000000
fffff900`c00d8010 00000000`00000001 : win32k!GreDeviceIoControlEx+0xd6
fffff880`04068fe0 fffff960`009d22e3 : fffff900`c00c4000 00000000`00000000
00000009`0000000c 00000000`00000000 : win32k!EngDeviceIoControl+0x3c
fffff880`04069030 fffff960`009d1867 : 00000000`00000000 fffff900`c0083db0
fffff900`c0083db0 fffff960`0008ff9e : framebuf!bInitSURF+0x47
fffff880`040690b0 fffff960`00079cb6 : fffffa80`034b3d60 fffff900`c00d8920
fffff800`02847e80 fffff800`026d9de0 : framebuf!DrvEnableSurface+0x1f
fffff880`04069100 fffff960`002e3de2 : fffffa80`034b3d60 fffff900`c00d8920
00000000`40210088 fffff900`64776447 : win32k!WatchdogDrvEnableSurface+0x36
fffff880`04069140 fffff960`000882f2 : fffff900`c00c4000 fffff880`040692b8
fffff900`c00c4000 fffff900`c00bdec0 : win32k!PanEnableSurface+0x5a
fffff880`04069210 fffff960`00080fae : fffff900`c00c4000 00000000`00000001
00000000`00000000 fffffa80`029fe070 : win32k!PDEVOBJ::bMakeSurface+0x4a
fffff880`04069240 fffff960`0007c1ea : fffff900`c00be420 fffff900`c00be420
00000000`00000001 00000000`00000000 : win32k!hCreateHDEV+0xb8e
fffff880`040693a0 fffff960`00234b83 : 00000000`00000000 00000000`ffffffff
00000000`00000000 00000000`00000000 : win32k!DrvCreateMDEV+0x7d6
fffff880`04069640 fffff960`0007a9dd : fffff880`00000000 ffffffff`00000000
00000000`00000000 00000000`00000000 :
win32k!DrvInternalChangeDisplaySettings+0x7a3
fffff880`04069880 fffff960`0007a200 : 00000000`00000128 00000000`00000000
00000000`00000000 00000000`00000000 : win32k!DrvChangeDisplaySettings+0x62d
fffff880`04069a60 fffff960`000815da : 00000000`00000000 00000000`ffffaecc
00000000`00000000 00000000`00000000 : win32k!InitVideo+0x1f8
fffff880`04069b60 fffff960`00075841 : fffff900`c0600000 fffff8a0`0166ec60
fffffa80`0348ab30 00000000`0000004c : win32k!UserInitialize+0x28a
fffff880`04069be0 fffff800`026cc993 : fffffa80`0348ba80 00000000`001f0003
00000000`00000007 fffff880`04069c01 : win32k!NtUserInitialize+0xc1
fffff880`04069c20 000007fe`fd7233da : 00000000`00000000 00000000`00000000
00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`001bf4f8 00000000`00000000 : 00000000`00000000 00000000`00000000
00000000`00000000 00000000`00000000 : 0x7fe`fd7233da
Comment 5 Vadim Rozenfeld 2011-04-06 09:10:38 UTC 
(In reply to comment #4)
> Please refer to the crash dump analysis according to comment #9 in bug
> 684082,(https://bugzilla.redhat.com/show_bug.cgi?id=684082#c9)
> 
> Crash dump analysis:
> 0: kd> !analyze -v
> 

Hi Dawn,

Not sure whether or not it can help, but could you completely 
disable the display hardware acceleration, including write
combining feature 
(Start->Control Panel->Display->Settings->Troubleshoot)? 
Best regards,
Vadim.
Comment 6 dawu 2011-04-06 09:17:04 UTC 
Hi Vadim,

I will have a try for run whql job of "NDIS Test 6.0" with disable the display hardware acceleration and update this result later.

Thanks
Best Regards,
Dawn
Comment 7 Vadim Rozenfeld 2011-04-06 12:53:36 UTC 
Please try disabling watchdog
http://msdn.microsoft.com/en-us/library/ff553890%28v=vs.85%29.aspx
(Just wonder how did I miss it)

Cheers,
Vadim.
Comment 8 dawu 2011-04-07 10:29:42 UTC 
(In reply to comment #5)
> (In reply to comment #4)
> > Please refer to the crash dump analysis according to comment #9 in bug
> > 684082,(https://bugzilla.redhat.com/show_bug.cgi?id=684082#c9)
> > 
> > Crash dump analysis:
> > 0: kd> !analyze -v
> > 
> 
> Hi Dawn,
> 
> Not sure whether or not it can help, but could you completely 
> disable the display hardware acceleration, including write
> combining feature 
> (Start->Control Panel->Display->Settings->Troubleshoot)? 
> Best regards,
> Vadim.

Hi Vadim,

We have tried this method, unfortunately, this issue still reproduced.

Best Regards,
Dawn
Comment 9 dawu 2011-04-07 10:33:42 UTC 
(In reply to comment #7)
> Please try disabling watchdog
> http://msdn.microsoft.com/en-us/library/ff553890%28v=vs.85%29.aspx
> (Just wonder how did I miss it)
> 
> Cheers,
> Vadim.

Hi Vadim,

There is no watchdog under regist path of"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\" on win2k8/win7,but can find it on winxp/win2k3,seems like it's not support by win7/win2k8,but I didn't find related information on microsoft website.

Best Regards,
Dawn
Comment 10 Vadim Rozenfeld 2011-04-07 11:30:36 UTC 
(In reply to comment #9)
> (In reply to comment #7)
> > Please try disabling watchdog
> > http://msdn.microsoft.com/en-us/library/ff553890%28v=vs.85%29.aspx
> > (Just wonder how did I miss it)
> > 
> > Cheers,
> > Vadim.
> 
> Hi Vadim,
> 
> There is no watchdog under regist path
> of"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\" on win2k8/win7,but can
> find it on winxp/win2k3,seems like it's not support by win7/win2k8,but I didn't
> find related information on microsoft website.
> 
> Best Regards,
> Dawn

(In reply to comment #9)
> (In reply to comment #7)
> > Please try disabling watchdog
> > http://msdn.microsoft.com/en-us/library/ff553890%28v=vs.85%29.aspx
> > (Just wonder how did I miss it)
> > 
> > Cheers,
> > Vadim.
> 
> Hi Vadim,
> 
> There is no watchdog under regist path
> of"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\" on win2k8/win7,but can
> find it on winxp/win2k3,seems like it's not support by win7/win2k8,but I didn't
> find related information on microsoft website.
> 
> Best Regards,
> Dawn

It must be under Tdr category on Vista and higher.

Try changing TdrDebugMode to 1
http://msdn.microsoft.com/en-us/library/ff569918%28v=vs.85%29.aspx

Best regards,
Vadim.
Comment 11 dawu 2011-04-08 07:26:14 UTC 
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #7)
> > > Please try disabling watchdog
> > > http://msdn.microsoft.com/en-us/library/ff553890%28v=vs.85%29.aspx
> > > (Just wonder how did I miss it)
> > > 
> > > Cheers,
> > > Vadim.
> > 
> > Hi Vadim,
> > 
> > There is no watchdog under regist path
> > of"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\" on win2k8/win7,but can
> > find it on winxp/win2k3,seems like it's not support by win7/win2k8,but I didn't
> > find related information on microsoft website.
> > 
> > Best Regards,
> > Dawn
> 
> (In reply to comment #9)
> > (In reply to comment #7)
> > > Please try disabling watchdog
> > > http://msdn.microsoft.com/en-us/library/ff553890%28v=vs.85%29.aspx
> > > (Just wonder how did I miss it)
> > > 
> > > Cheers,
> > > Vadim.
> > 
> > Hi Vadim,
> > 
> > There is no watchdog under regist path
> > of"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\" on win2k8/win7,but can
> > find it on winxp/win2k3,seems like it's not support by win7/win2k8,but I didn't
> > find related information on microsoft website.
> > 
> > Best Regards,
> > Dawn
> 
> It must be under Tdr category on Vista and higher.
> 
> Try changing TdrDebugMode to 1
> http://msdn.microsoft.com/en-us/library/ff569918%28v=vs.85%29.aspx
> 
> Best regards,
> Vadim.

Hi Vadim,

1.According to http://msdn.microsoft.com/en-us/library/ff569918%28v=vs.85%29.aspx,
we can not find TdrDebugMode under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\GraphicsDrivers, so we manually created "TdrDebugMode" with REG_DWORD
type,and set it's value to 1, but still failed with the same BSOD happened when ran NIC related job such as "Sleep Stress with IO","Common Scenario" or "NDISTest 6.5(MPE)". 

2.Guest reboot very slowly and need long time to start,almost use 100% cpu resource, but when changed to other NIC such as e1000 instead of virtio-NIC,guest can be reboot soon.

Best Regards,
Dawn
Comment 12 Qunfang Zhang 2011-04-08 08:04:42 UTC 
Hi, Vadim

I found when boot guest with vhost=on, guest will always hit this problem
especially for win2k832 and 64. Guest boot up slowly and got BSOD as bug
description.
Without vhost, guest boot up normally (using the same image). Now the job
"NDISTest 6.5 MPE" is running, I will check if it will suffer the BSOD (error
code 0xEA) or not.
Comment 14 Arkady Frenkel 2011-04-11 06:29:28 UTC 
Hi, dears!
I received the exactly same BSOD without NetKvm installed at all on my WinDbg host VM machine. Check http://cleo.tlv.redhat.com/qumrawiki/BSOD%20info

Regards
Arkady
Comment 15 Qunfang Zhang 2011-04-11 06:34:14 UTC 
Hi, Arkady

And after I use the build in Comment 13, do not meet this problem any more.

Best Regards,
Qunfang
Note You need to log in before you can comment on or make changes to this bug.