WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] 09 Feb 1.2 hangs on partition check

To: stevegt@xxxxxxxxxxxxx
Subject: Re: [Xen-devel] 09 Feb 1.2 hangs on partition check
From: Steven Hand <Steven.Hand@xxxxxxxxxxxx>
Date: Wed, 11 Feb 2004 08:38:24 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx, Steven.Hand@xxxxxxxxxxxx
Delivery-date: Wed, 11 Feb 2004 08:38:24 +0000
Envelope-to: Steven.Hand@xxxxxxxxxxxx
In-reply-to: Message from stevegt@xxxxxxxxxxxxx of "Tue, 10 Feb 2004 22:52:54 PST." <20040211065254.GC3272@pathfinder>
>I built xen and xenolinux from this morning's 1.2 pull and attempted to
>boot it on the same hardware where I've been running the 02 Feb 1.2
>build.  It hangs in partition check.  Compiler for both builds is gcc
>3.0.4.  BIOS settings etc. are the same -- this node reboots back into
>the 02 Feb build just fine.

This is odd - at least in the sense that there's been no changes to 
the block device stuff (either in xenolinux or xen) in that interval
of time. Only even plausible candidates are the gdt fix and the memory
fix, but neither of these 'should'  cause problems...

>Xen is running well enough that help etc. works -- here're the boot
>messages, followed by the output of several dump queries.  Let me know
>what else you need.  

So dumps show that domain 0 is running - presumably waiting for the 
response to its block requests - although it's tricky to see exactly
since the block prod/cons values aren't shown. 

>'q' pressed -> dumping task queues
>Xen: DOM -1, CPU 0 [has=F], state = Runnable, hyp_events = 00000000
>Xen: DOM 0, CPU 0 [has=T], state = Runnable, hyp_events = 00000000
>Guest: events = 00000000, events_mask = 8000017f
>rx_prod=0 ,rx_cons=0, tx_prod=0, tx_cons=0
>rx_req_cons=0, rx_resp_prod=0, tx_req_cons=0, tx_resp_prod=0
>Notifying guest...

Two things to try (in addition to Keir's suggestion of trying 
another gcc) 

  - press 'q' twice in succession so that we can see if the 
    guest event handlings is really broken (which it seems
    to be) 

  - press 'b' to dump the block queues so we can see the 
    event count values


cheers, 

S.