From mboxrd@z Thu Jan 1 00:00:00 1970 From: Frank van der Linden Subject: Re: Re: BSOD "A clock interrupt was not recevied onasecondary processor within the allocated time interval" Date: Wed, 07 Jan 2009 13:48:30 -0700 Message-ID: <4965151E.5050209@Sun.COM> References: <49627C6B.7000900@virtualiron.com> <20090106103909.GA23206@weybridge.uk.xensource.com> <4964E970.3090803@Sun.COM> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary_(ID_yoWTvl6yG/YjgrXRN7rLtA)" Return-path: In-reply-to: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Andrew Lyon Cc: "Xen-Devel (E-mail)" , Steve Prochniak , Keir Fraser , Steven Smith , xen-users@lists.xensource.com, Ben Guthro List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format. --Boundary_(ID_yoWTvl6yG/YjgrXRN7rLtA) Content-type: text/plain; format=flowed; charset=windows-1252 Content-transfer-encoding: 7BIT Andrew Lyon wrote: > How do you introduce the delay? I'd like to try xen-unstable with > viridian=1 but I want to be absolutely sure that the issue is fixed so > if you have a patch for qemu-dm I'd appreciate it if you could post > it, the BSOD 101 issue causes serious problems for me because I am > using pci passthrough, I've found if the domain using passthru > crashes, I issue "xm pci-detach", or "xm destroy" a domain that is > using a passthru pci device, will cause the entire machine to lockup , > I've tried Xen 3.2.1/2/3 and 3.3.0/1 with various different kernels > but it always happens, so if my Vista or 2008 domains that are using > pci passthru usb2 cards BSOD at all it takes down the entire box, > usually resulting in data loss :( > > Perhaps that problem might be fixed in unstable too, I will try it > tomorrow but it would really help to have a way to trigger a bsod 101. I use the attached change to qemu. In cpu_handle_ioreq, if send_vcpu != 0,, it checks for the presence of a file called /tmp/qemu_delay. If it exists, it opens it and reads a delay value from it. Then it sleeps for that duration (in microseconds). What I do is boot windows 2008, then open an editor to edit /tmp/qemu_delay. From the editor, I write various values to it. An easy way to trigger the issue is to write a large value (say, 8000000 for 8 seconds), wait a little while, and then write 0 to make the domain come back to life. It should bluescreen at this point. Sometimes the procedure has to be repeated a few times. If you want to do "echo $value > /tmp/qemu_delay", you'll need to change the hack to re-open the file each time, probably. - Frank --Boundary_(ID_yoWTvl6yG/YjgrXRN7rLtA) Content-type: text/plain; name=qemu-delay.patch Content-transfer-encoding: 7BIT Content-disposition: inline; filename=qemu-delay.patch *** target-i386-dm/helper2.c.orig Wed Jan 7 12:37:30 2009 --- target-i386-dm/helper2.c Mon Dec 22 16:09:55 2008 *************** *** 47,52 **** --- 47,54 ---- #include #include + #include + #include #include *************** *** 570,575 **** --- 572,580 ---- extern int shutdown_requested; CPUState *env = opaque; ioreq_t *req = cpu_get_ioreq(); + static int fd = -1; + char buf[16]; + useconds_t udelay; handle_buffered_io(env); if (req) { *************** *** 606,611 **** --- 611,625 ---- } req->state = STATE_IORESP_READY; + if (send_vcpu != 0) { + if (fd == -1) + fd = open("/tmp/qemu_delay", O_RDONLY); + if (fd >= 0) { + pread(fd, buf, sizeof buf, 0L); + udelay = atoi(buf); + usleep(udelay); + } + } xc_evtchn_notify(xce_handle, ioreq_local_port[send_vcpu]); } } --Boundary_(ID_yoWTvl6yG/YjgrXRN7rLtA) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --Boundary_(ID_yoWTvl6yG/YjgrXRN7rLtA)--