On Sunday 01 October 2006 01:57, Jeff Dike wrote: > On Sun, Oct 01, 2006 at 01:11:37AM +0300, Nikola Ciprich wrote: > > You have an idea where > > could be problem with shutting down? (this Virtual timer expired > > cycling?) > > Oops, missed that in your previous message. > > Where in the shutdown process is this? There have been some previous > reports of hangs during swapoff which I have been unable to reproduce. > I spent part of a day last week pushing UMLs deeply into swap and > shutting them down, always successfully. > > The SIGVTALRM is normal - that's just the timer. That strace you sent > looks like the idle loop, so as far as the kernel is concerned, > everything is fine. > > > and regarding /proc/mm, shouldn't this mm64 file be used? or what's it > > used for? > > /proc/mm64? What would it do that /proc/mm doesn't?
Well, I'll explain everything (even to Jeff, since I never documented anything of this). The SKAS patch V8 supports well i386 host and i386 guest. That's all. SKAS patch V9-preX tries to support x86_64 host, with both 32 and 64 bit guests: * 32 bit guests: a bug prevents using full SKAS3, you must pass noprocmm and you'll get most performance advantages (because faultinfo works). When I worked on the SKAS port to x86_64 I did not discover that something worked, and I never tested support for 64bit guests. I latter discovered the bug is in a different portion of code - Bodo Stroesser unveiled it, and I think this is the same bug that hit even Jeff's 1st attempt to write SKAS4 (all I know can be found in http://user-mode-linux.sourceforge.net/diary.html -> grep skas4 and you'll find what I'm talking about on 23 Sep 2004). * 64bit guests: they do not support SKAS3, but the host patch gives the needed support - to do that, the 1st thing to do would be to use /proc/mm64 as you point out (and it could even suffice, even if I doubt that), but guest kernels still try to use /proc/mm and it does not work. So you must pass skas0 on the cmdline (I do not remember whether noprocmm works for this case). -EINVAL is given on purpose: the request struct UML writes on /proc/mm has a different layout for 32 and 64bit requests, or better a different size since pointers are larger (and there's an explicit check for that - IIRC it has always been there). I chose to have a separate /proc/mm64, I did not think to try autodetection. And frankly my first impression is that I'd still do it this way. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade http://www.user-mode-linux.org/~blaisorblade Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
