On Wed, Sep 28, 2005 at 01:46:15PM +0200, Blaisorblade wrote:
> Also, there are some calls to kmalloc in the shutdown path - and they work.
> I know this because I saw a problem with one of them: it gave "might_sleep
> while atomic", and it was kmalloc in the shutdown, or rather, in panic() -
>
On Wed, Sep 28, 2005 at 01:46:15PM +0200, Blaisorblade wrote:
> And I am wondering about whether the recent "eactivate_all_fds failed, errno
> =
> 9"
I found this one, although I didn't notice the missing 'd'. It turns out that
close_chan closes file descriptors, but never freed the associated
hi,
On 9/28/05, Jeff Dike <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 28, 2005 at 09:47:41AM -0400, Young Koh wrote:
> > yes, i think memory can go bad if 1) it cannot be allocated because of
> > filesystem full or similar reasons as Jeff described, or 2) it was
> > allocated once but could have been
On Wed, Sep 28, 2005 at 07:26:43PM +0200, Blaisorblade wrote:
> I'm not sure that would help anyway - if the host memory is full, it's full.
> It's just matter of waiting and retrying.
This isn't a matter of waiting and retrying. We use pages that are already
known to be good, and the rest go on
On Wednesday 28 September 2005 18:09, Jeff Dike wrote:
> On Wed, Sep 28, 2005 at 01:59:48PM +0200, Blaisorblade wrote:
> > That wasn't the original reason - this is fine too, but as I explained in
> > the other mail, cat /dev/kmem will cause a copy_to_user() with invalid
> > kernel ("from") addres
On Wed, Sep 28, 2005 at 01:59:48PM +0200, Blaisorblade wrote:
> That wasn't the original reason - this is fine too, but as I explained in the
> other mail, cat /dev/kmem will cause a copy_to_user() with invalid kernel
> ("from") address. I remember because I discussed this with you at length.
Oh
On Wednesday 28 September 2005 17:54, Jeff Dike wrote:
> On Wed, Sep 28, 2005 at 02:14:32PM +0200, Blaisorblade wrote:
> > Very, very nice.
> > Let's hope for the better, but next time the debug should be done
> > *before* merging, ok? Even because, for instance, if (say) the patch was
> > ready f
On Wednesday 28 September 2005 16:22, Young Koh wrote:
> so, as my understanding, sigsetjmp() is used for returning an error
> when there is a userspace and/or kernelspace address faulting in both
> skas and tt modes. and i386 implementation works the same way, i
> guess.
> my one quick question i
On Wednesday 28 September 2005 16:52, Jeff Dike wrote:
> On Wed, Sep 28, 2005 at 02:15:18PM +0200, Blaisorblade wrote:
> > Do you know when this was introduced, and the last working UML version?
> It's always been broken, I think.
Ah, but you're talking of SKAS0.
In this case (which seems strange
On Wed, Sep 28, 2005 at 02:14:32PM +0200, Blaisorblade wrote:
> Very, very nice.
>
> What about the early removal of the request from the queue, before being sure
> we can complete it (sorry for not reading carefully everything below, I'm
> going to have lunch and afterwards back to study).
I t
On Wed, Sep 28, 2005 at 09:47:41AM -0400, Young Koh wrote:
> yes, i think memory can go bad if 1) it cannot be allocated because of
> filesystem full or similar reasons as Jeff described, or 2) it was
> allocated once but could have been swapped.
>
> in case of 1) it should be more like kernel pan
On Wed, Sep 28, 2005 at 02:15:18PM +0200, Blaisorblade wrote:
> Do you know when this was introduced, and the last working UML version?
It's always been broken, I think. It results from the stub having to
sigreturn by hand because it has no access to the libc restorer, and thus
needing to restor
so, as my understanding, sigsetjmp() is used for returning an error
when there is a userspace and/or kernelspace address faulting in both
skas and tt modes. and i386 implementation works the same way, i
guess.
my one quick question is (it could sound stupid, but) that why there
may be a kernelspac
Thank you for your reply, but still have one more.
(i think i forgot to reply to the mailing list with the previous
email, so, i'm attaching the text)
On 9/28/05, Jeff Dike <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 27, 2005 at 08:56:51PM -0400, Young Koh wrote:
> > 1) if the address is fine, shoul
On Tuesday 27 September 2005 21:30, Jeff Dike wrote:
> On Tue, Sep 27, 2005 at 06:46:50PM +0200, Blaisorblade wrote:
> > Jeff, have you any further notes to add?
>
> Agree.
>
> I have one more to add - that UML/x86_64 doesn't run with
> CONFIG_FRAME_POINTER disabled.
Do you know when this was intro
On Tuesday 27 September 2005 20:12, Jeff Dike wrote:
> Attached is my current set of I/O patches. It's significantly different,
> and simpler, than my previous set.
> Now, there is no sleeping while running the queue, so the spinlock is never
> dropped, and all of the extra synchronization is gon
On Tuesday 27 September 2005 19:28, Jeff Dike wrote:
> On Tue, Sep 27, 2005 at 10:06:53AM -0400, Young Koh wrote:
> > my question is, if so, shouldn't the error be caught when UML kernel
> > translates the user space address to the kernel space address? i mean,
> > UML kernel must know the valid me
On Tuesday 27 September 2005 15:21, Muhammad Sajjad wrote:
> Hi,
> I am not able to run an application which is useing wxGTK-2.6.2 libaray.
> when tls is enable (/lib/tls exist) then segmentation fault occured.
Known..
> If tls is disable (/lib/tls.disable) then following error occure while
> call
I've recently realized how potentially misguided that thing is.
And I am wondering about whether the recent "eactivate_all_fds failed, errno =
9" (no, the initial "d" never comes out) may be due to this. Even if, now I
see that was done even before... but first only on TT mode, then also in SKAS
On Tuesday 27 September 2005 16:06, Young Koh wrote:
> Hi,
> i have a question about copy_from/to_user() implementation in skas mode.
Ok, and here I'll explain also about TT mode, since they're reasonably
similar, and TT mode is more similar to i386.
> as my understanding,
> when copy_from/to_us
20 matches
Mail list logo
