From: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
To: Blaisorblade <blaisorblade_spam@yahoo.it>
Cc: user-mode-linux-devel@lists.sourceforge.net
Subject: [uml-devel] Re: Fwd: [PATCH] UML - close host file descriptors properly
Date: Thu, 25 Nov 2004 14:58:34 +0100 [thread overview]
Message-ID: <41A5E50A.1080804@fujitsu-siemens.com> (raw)
In-Reply-To: <200411251349.54865.blaisorblade_spam@yahoo.it>
Blaisorblade wrote:
> On Thursday 25 November 2004 12:44, Bodo Stroesser wrote:
>
>>Blaisorblade wrote:
>>
>>>This patch was sent by Jeff for merging in mainline - since you
>>>complained on an earlier version, have you still something to correct in
>>>it?
>
>
>>AFAICS, it's the same patch as you have in bb3 with the name
>>"uml-close-all-fds". So, it's OK. To have reboot on SKAS working,
>>fix-reboot-skas is required also.
>
> Yes, that is in -bb3.
>
>>>Btw, the reboot problem is not fixed for me - even in -bb3, with your
>>>last patch tarball excluding SYSEMU_SINGLESTEP, rebooting does not always
>>>work.
>
>
>>That's bad. On my system, since the patches are applied, I never saw a
>>reboot failing.
>
> I got the same randomical failure before. And what's more, with the use-va_end
> cleanup, it *always* crashed (not retested, but going to do this now).
>
> Without va_end, sometimes (1 on 3 on average, I'd say) I get:
>
> "Remounting root filesystem read-only.
> Rebooting.
> Restarting system.
>
> deactivate_all_fds failed, errno = 9
> Segmentation fault"
OK. Let's read the code: if deactivate_all_fds fails, the handler for SIGIO isn't
set to SIG_IGN, since it does return(err) without calling set_handler() (maybe
you call this a bug, but *normally* deactivate_all_fds must not fail). Thus, if
there is a SIGIO in the queue, UML *must* segfault when calling unblock_signals().
The question here is, which fd is in the list active_fds and is invalid?
Could you please change the error output to contain the fd-number?
And before doing the reboot, please get a list of the open fds. This could help to
find out, which driver is having a bug.
>
>
>>I have an idea to find out, what happens on your machine.
>
> Ok, going to test ASAP.
>
>>First let me
-------------------------------------------------------
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://productguide.itmanagersjournal.com/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
prev parent reply other threads:[~2004-11-25 13:58 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200411250456.33779.blaisorblade_spam@yahoo.it>
[not found] ` <41A5C5A9.7040902@fujitsu-siemens.com>
2004-11-25 12:49 ` [uml-devel] Re: Fwd: [PATCH] UML - close host file descriptors properly Blaisorblade
2004-11-25 13:58 ` Bodo Stroesser [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=41A5E50A.1080804@fujitsu-siemens.com \
--to=bstroesser@fujitsu-siemens.com \
--cc=blaisorblade_spam@yahoo.it \
--cc=user-mode-linux-devel@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