While working on another bug I ran head long into an issue with xend.
When running LTP Test Suite (ltp.sf.net) simultaneously on both Dom0 & a
virtual domain.
Not going to get a chance to debug till Tuesday, I wanted to see if
others on the list could easily reproduce this on there machines. It
takes a while to get the machine in this state, because you need to wait
while LTP runs.
Here are some of my notes:
Running with Xen-unstable Feb 24, 2005
Running ltp-full-20050207
on IBM Netvista model# 8305g (Pentium 4 2.GHZ)
Case 1: Dom0 run ltp with NO virtual Domains
REBOOT WORKS FINE
Case 2: Just Dom1 (vitual Domain) run ltp
REBOOT WORKS FINE
Case 3: Dom0 & Dom1 both running LTP simultaneously
First Run:
- console to virtual domain hung, virtual domain still can be
reached via ssh
- xend totally crashed
- can''t restart or get status from it xm
- When I hit a key to got from the virtual console I got the
message:
sleepython:Objects/obmalloc.o:580:PyObject_Malloc: Assertio
''bp != ((void*)0)'' failed.
- run "xm console 1"
(111, ''Console refused'')
ERROR: Error connecting to xend, is xend running?
- On Dom0 shutdown -h or -r does not work.
- On Dom0 only "reboot -f" will work.
--
Jerone Young
Open Virtualization
IBM Linux Technology Center
jyoung5@us.ibm.com
512-838-1157 (T/L: 678-1157)
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
LTP is going to put significant strain on the system it''s being run on. It''s quite likely that under these conditions Xend cannot cope. This sort of testing is probably a bit wishful. It would make sense to start with something a bit more fundamental like unit testing of the libxc interface. Xend marshalls it''s internal state to disk. I''ve not looked into it all that much but I''ve been able to recreate the "Xend totally hosed" problem. It persists even after reinstalling Xend. I''ve got a funny feeling that there''s a directory somewhere that if you just rm -rf Xend will start right up again. Doing a proper reboot or shutdown requires co-operation from the management tools. That''s why you were seeing that problem. Regards, Anthony Liguori ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Mon, 2005-02-28 at 09:58 -0600, Anthony Liguori wrote:> LTP is going to put significant strain on the system it''s being run on. > It''s quite likely that under these conditions Xend cannot cope. This > sort of testing is probably a bit wishful. It would make sense to start > with something a bit more fundamental like unit testing of the libxc > interface.It''s odd since LTP can run fine on them if run individually. But once you do them simultaneously everything goes to hell. I think testing like this is need too, I just happened to be recreating another situation our test team ran into.> > Xend marshalls it''s internal state to disk. I''ve not looked into it all > that much but I''ve been able to recreate the "Xend totally hosed" > problem. It persists even after reinstalling Xend. > > I''ve got a funny feeling that there''s a directory somewhere that if you > just rm -rf Xend will start right up again.Since all LTP test write to /tmp or there own directory I don''t think this is the case.> > Doing a proper reboot or shutdown requires co-operation from the > management tools. That''s why you were seeing that problem.Yeah, only "reboot -f" skipping the traditional shutdown process will let the Dom0 shutdown. I figured that this would also require management tool support, but this does not seem to be the case.> Regards, > Anthony Liguori > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xen-devel >-- Jerone Young Open Virtualization IBM Linux Technology Center jyoung5@us.ibm.com 512-838-1157 (T/L: 678-1157) ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel