This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-users] Release 0.9.2 of GPL PV Drivers for Windows

To: <xen-users@xxxxxxxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-users] Release 0.9.2 of GPL PV Drivers for Windows
From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
Date: Mon, 26 May 2008 12:09:28 +1000
Delivery-date: Sun, 25 May 2008 19:10:00 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Aci+1Ycc2Bd7eBoFSgKifdwzZClpDg==
Thread-topic: Release 0.9.2 of GPL PV Drivers for Windows
Another update. This one should fix the problems people were having with
chkdsk on boot failing. Chkdsk never aligns its buffers to a 512 byte
boundary, so I've put in some code which will handle this case when the
transfer size is > PAGE_SIZE. This might fix some other random crashes

A word of warning though, on my system a windows bug check (eg BSoD)
will hang my Dom0 hard for upwards of 5 minutes, and when it finally
comes back it reports:

BUG: soft lockup detected on CPU#0!

Call Trace:
 <IRQ> [<ffffffff8029fb2c>] softlockup_tick+0xdb/0xed
 [<ffffffff80267dba>] timer_interrupt+0x38d/0x3db
 [<ffffffff80211154>] handle_IRQ_event+0x2d/0x60
 [<ffffffff8029fe6b>] __do_IRQ+0xa4/0x105
 [<ffffffff8028364e>] _local_bh_enable+0x59/0xb3
 [<ffffffff802665a8>] do_IRQ+0x65/0x73
 [<ffffffff80360feb>] evtchn_do_upcall+0x86/0xe0
 [<ffffffff8025c616>] do_hypervisor_callback+0x1e/0x2c
 <EOI> [<ffffffff8020622a>] hypercall_page+0x22a/0x1000
 [<ffffffff8020622a>] hypercall_page+0x22a/0x1000
 [<ffffffff803607c4>] force_evtchn_callback+0xa/0xb
 [<ffffffff8036a7a3>] make_response+0xeb/0x131
 [<ffffffff8036b020>] blkif_schedule+0x24f/0x328
 [<ffffffff8028fa70>] autoremove_wake_function+0x0/0x2e
 [<ffffffff8028f8ad>] keventd_create_kthread+0x0/0x61
 [<ffffffff8036add1>] blkif_schedule+0x0/0x328
 [<ffffffff8028f8ad>] keventd_create_kthread+0x0/0x61
 [<ffffffff8023352b>] kthread+0xd4/0x107
 [<ffffffff8025c86c>] child_rip+0xa/0x12
 [<ffffffff8028f8ad>] keventd_create_kthread+0x0/0x61
 [<ffffffff80233457>] kthread+0x0/0x107
 [<ffffffff8025c862>] child_rip+0x0/0x12

Dom0 just plods along fine again after that though. Not sure what to
make of it at this point. This probably also happened on 0.9.1 too, and
maybe 0.9.0. It's to do with a crash in xenvbd when Windows calls it in
'dump mode'.

You can trigger this behaviour manually on 0.9.2 with a 'xm sysrq
<domain> B' if you want to see it for yourself, and maybe give me a clue
as to why it's happening :)

Have a look at the wiki page for more details:

Download from:
(there is a link to the download site from the wiki entry).


Xen-users mailing list