Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 2058: regressions -
FAIL"):
> On Wed, 2010-09-01 at 10:01 +0100, xen.org wrote:
> guest debian.guest.osstest 5a:36:0e:0a:00:10 22 link/ip/tcp: wait
> timed out: no entry in statedb::ips.
>
> It would be useful to timestamp this last entry, for a while I was
> unsure if we'd actually waited 100s or not.
I'll look into that.
> The guest log ends with:
> [ 0.678464] Magic number: 1:252:3141
> [ 0.680053] Freeing unused kernel memory: 600k freed
> [ 0.680072] Write protecting the kernel read-only data: 8756k
> Loading, please wait...
> Begin: Loading essential drivers ... done.
> Begin: Running /scripts/init-premount ... done.
> Begin: Mounting root file system ... Begin: Running
> /scripts/local-top ... Volume group "bedbug.cam.xci-test.com" not found
> done.
> Begin: Waiting for root file system ...
>
> I'm not sure if you said something in the past about the LVM thing being
> a benign error due to using the same initrd everywhere (in which case I
> think it would be better to arrange for the test suite to generate a
> proper matching ramdisk for each kernel/VM, since it is quite confusing
> and always sows the seeds of doubt in my mind that a problem might be a
> ramdisk configuration issue)
Hrm. I'll see what I can do. We're using the Debian xen-tools
package which likes to use the dom0's kernel and initramfs directly.
I'm worried that rebuilding the initramfs for the domU is likely to
introduce real problems, rather than harmless warnings.
> > test-amd64-amd64-pv 7 guest-start fail REGR. vs.
> > 2053
>
> Similar pattern to above. Are we confident that the underlying nbd
> infrastructure is not flakey?
This does not have any NBD. I think you may be confused by the fact
that the VG name is the host's domain name. This test is on a single
machine and doesn't do any non-local migration.
> Can we add the output of something like
> ps wwwaxf -eo
> pid,tty,stat,time,nice,psr,pcpu,pmem,nwchan,wchan:25,args
> from dom0 to the captured logs so we can see where processes are hung
> up. In particular it would have been interesting to know where the qemu
> was hung in the windows-install failure below.
Sure. Nice rune btw.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home