linux-um archives
 help / color / mirror / Atom feed
From: Jeff Dike <jdike@addtoit.com>
To: Sven 'Darkman' Michels <sven@darkman.de>
Cc: UML devel list <user-mode-linux-devel@lists.sourceforge.net>,
	user-mode-linux-user@lists.sourceforge.net
Subject: [uml-devel] Re: [uml-user] ubd=mmap problem
Date: Mon, 05 Jan 2004 21:59:16 -0500	[thread overview]
Message-ID: <200401060259.i062xGFI023152@ccure.user-mode-linux.org> (raw)
In-Reply-To: Your message of "Thu, 25 Dec 2003 14:03:31 +0100." <3FEAE023.6040908@darkman.de>

sven@darkman.de said:
> i noticed that the uml can't reboot anymore cause it hangs in an
> endless loop when unmounting the devices. all i saw was: 
> map : /proc/mm map failed, err = 9 

I take it this is reproducable?  ubd-mmap has been stable here, so there's
something about what you're doing that's sending it off the deep end.

The best way I can think to debug it is to stick printks where /proc/mm and
ubd devices get opened and closed showing what file descriptor is involved.
Apparently, the ubd driver is closing a file descriptor that UML thinks is 
a /proc/mm descriptor.

So, could you add printks for the following values in the following places -
    fd in arch/um/kernel/skas/process.c:get_mm() after the os_open_file
    mm->context.skas.mm_fd in arch/um/kernel/skas/mmu.c:destroy_context_skas()
    
    fd in arch/um/drivers/ubd_user.c:open_ubd_file() before the os_lock_file
    dev->fd and dev->cow.fd in arch/um/drivers/ubd_kern.c:ubd_close() before
their respective calls to os_close_file

Make sure that logging is set up so that printks show up in the messages file
or on the console so that you don't lose any of it.

What I think you're looking for is ubd_close closing a /proc/mm descriptor.
This would explain things going to hell when devices are being unmounted.

I'm a little suspicious of the fact that ubd_close doesn't set the descriptors
to -1 after closing them, but I don't see a bug there offhand.

				Jeff


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

      parent reply	other threads:[~2004-01-06  2:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-25 13:03 [uml-devel] ubd=mmap problem Sven 'Darkman' Michels
2003-12-26 18:36 ` BlaisorBlade
2003-12-27  2:46   ` Jeff Chua
2004-01-06  2:59 ` Jeff Dike [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200401060259.i062xGFI023152@ccure.user-mode-linux.org \
    --to=jdike@addtoit.com \
    --cc=sven@darkman.de \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    --cc=user-mode-linux-user@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox