:
:I'll remove (or change) the assertion later this evening
:unless I hear protests to the contrary.
:
:Alan
:
Sounds like a plan. When you get it committed I'll bring it
up on one of my test boxes and run it through the gauntlet.
-Matt
I'll remove (or change) the assertion later this evening
unless I hear protests to the contrary.
Alan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
:
:This patch introduces a new bug. While it does guarantee that
:the assertion in vm_object_shadow isn't tripped over, it doesn't
:clear the OBJ_ONEMAPPING flag on the newly created shadow object.
:(New objects are created with OBJ_ONEMAPPING set.) Consequently,
:we'll have two overlapping map
This patch introduces a new bug. While it does guarantee that
the assertion in vm_object_shadow isn't tripped over, it doesn't
clear the OBJ_ONEMAPPING flag on the newly created shadow object.
(New objects are created with OBJ_ONEMAPPING set.) Consequently,
we'll have two overlapping mappings to
Has Brian or Michael or anyone been able to verify whether my patch
below fixes the reported vm_object_shadow panics yet? I'd like to get
it committed (or scrapped).
-Matt
Index: vm_map.c
=
:> I don't think this is an issue. The only double-mapped pages we care
:> about are those at the top-level (vm_object's connected directly to a
:> vm_map_entry). This is because these are the only pages effected by
:> write-faults and copy-on-write issues.
:>
:
:I disagre
On Sat, Apr 15, 2000 at 08:18:01PM -0700, Matthew Dillon wrote:
> :Is there a good reason for not having the vm_object_clear_flag() in
> :vm_object_reference()?
>
> Well, yes... vm_object's are referenced for all sorts of things
> temporarily. Everything from a process looking one up te
On Sat, Apr 15, 2000 at 08:13:20PM -0700, Matthew Dillon wrote:
>
> :Here's what I worry about: We only clear OBJ_ONEMAPPING on the top-level
> :object, and none of its backing objects. Nothing guarantees that these
> :backing objects have OBJ_ONEMAPPING cleared. The page that we're "double"
>
:Is there a good reason for not having the vm_object_clear_flag() in
:vm_object_reference()?
Well, yes... vm_object's are referenced for all sorts of things
temporarily. Everything from a process looking one up temporarily
to the swap code issuing I/O. None of these references have
:Here's what I worry about: We only clear OBJ_ONEMAPPING on the top-level
:object, and none of its backing objects. Nothing guarantees that these
:backing objects have OBJ_ONEMAPPING cleared. The page that we're "double"
:mapping may, however, reside in one of its backing objects. This is
:bad
On Sat, Apr 15, 2000 at 06:09:56PM -0400, Brian Fundakowski Feldman wrote:
>
> I'm still trying to understand this: if you know that the object may
> have pages mapped elsewhere, the backing objects recursively inherit
> the assumption that it may have parts mapped elsewhere?
Umm, just to be
On Sat, Apr 15, 2000 at 06:12:22PM -0400, Brian Fundakowski Feldman wrote:
> On Sat, 15 Apr 2000, Matthew Dillon wrote:
>
> > Note that the ref_count == 1 test in the vm_object_shadow optimization
> > should be left intact. This optimization requires a much stricter set
> > of tests
On Sat, 15 Apr 2000, Matthew Dillon wrote:
> Note that the ref_count == 1 test in the vm_object_shadow optimization
> should be left intact. This optimization requires a much stricter set
> of tests because we do not want to assume sharability of an object
> if someone else (the
On Sat, 15 Apr 2000, Alan Cox wrote:
> > It is totally legal for OBJ_ONEMAPPING to be set even if the ref_count
> > is greater then 1.
>
> Agreed. OBJ_ONEMAPPING actually means that *each page* within the object
> is mapped at most once. The object itself may be mapped many times,
> as
On Sat, 15 Apr 2000, Matthew Dillon wrote:
> [explanation]
>
> Here is a new patch. Please try it (and get rid of any prior patches
> to vm_object.c before applying this one).
>
Thanks for the reply :) What you say makes sense, so I'll try out this
patch as soon as I work out a way t
On Sat, Apr 15, 2000 at 11:23:11AM -0700, Matthew Dillon wrote:
> :Well, first the question must be answered, in an absolute yes or no:
> :is it wrong in the first place to have OBJ_ONEMAPPING set with a ref_count
> :of more than 1? I'd accept an authoritative answer about this from
> :alc, dillo
* Matthew Dillon <[EMAIL PROTECTED]> [000415 11:32] wrote:
>
> :On Thu, 13 Apr 2000, Michael Reifenberger wrote:
> :
> :> Hi,
> :> when using a linux java app (SAP PlatinGUI 46Cb2) I get the above panic.
> :> FreeBSD -current. Kernel+mods in sync.
> :> Linux from ports. Linux-Java-JDK 1.2.2 from
:Well, first the question must be answered, in an absolute yes or no:
:is it wrong in the first place to have OBJ_ONEMAPPING set with a ref_count
:of more than 1? I'd accept an authoritative answer about this from
:alc, dillon, dyson, or luoqi, who are all very familiar with the new
:VM.
:--
: Br
:Further elaboration:
:
:there is an assumption that it is wrong for OBJ_ONEMAPPING to be set but
:not when ref_count > 1. This assumption is defeated in the multiple test
:cases we can find. It seems that in the test cases, the common problem
:is with (I think mmap()d) memory across multiple p
:On Thu, 13 Apr 2000, Michael Reifenberger wrote:
:
:> Hi,
:> when using a linux java app (SAP PlatinGUI 46Cb2) I get the above panic.
:> FreeBSD -current. Kernel+mods in sync.
:> Linux from ports. Linux-Java-JDK 1.2.2 from blackdown as of yesterday.
:> Backtrace see crash.txt. Kernelconfig see n
On Sat, 15 Apr 2000, Alfred Perlstein wrote:
> Yes, find all places where source->ref_count is incremented and check
> for OBJ_ONEMAPPING as well as where OBJ_ONEMAPPING is set.
>
> Then add some printfs to find the snippet that's incrementing it
> to complain when the OBJ_ONEMAPPING bit is set,
On Sat, 15 Apr 2000, Alfred Perlstein wrote:
> Yes, find all places where source->ref_count is incremented and check
> for OBJ_ONEMAPPING as well as where OBJ_ONEMAPPING is set.
>
> Then add some printfs to find the snippet that's incrementing it
> to complain when the OBJ_ONEMAPPING bit is set,
* Brian Fundakowski Feldman <[EMAIL PROTECTED]> [000415 07:07] wrote:
> On Thu, 13 Apr 2000, Michael Reifenberger wrote:
>
> > Hi,
> > when using a linux java app (SAP PlatinGUI 46Cb2) I get the above panic.
> > FreeBSD -current. Kernel+mods in sync.
> > Linux from ports. Linux-Java-JDK 1.2.2 fro
On Sat, 15 Apr 2000, Brian Fundakowski Feldman wrote:
...
> Do you think you can find a specific set of steps for Alan to reproduce
> it?
Not without this SAP-GUI in conjuntion with a SAP-System to connect to :-(
But then it's easyly reproducable.
BTW: with your patch I get on the console during
On Thu, 13 Apr 2000, Michael Reifenberger wrote:
> Hi,
> when using a linux java app (SAP PlatinGUI 46Cb2) I get the above panic.
> FreeBSD -current. Kernel+mods in sync.
> Linux from ports. Linux-Java-JDK 1.2.2 from blackdown as of yesterday.
> Backtrace see crash.txt. Kernelconfig see nihil.
>
Hi,
when using a linux java app (SAP PlatinGUI 46Cb2) I get the above panic.
FreeBSD -current. Kernel+mods in sync.
Linux from ports. Linux-Java-JDK 1.2.2 from blackdown as of yesterday.
Backtrace see crash.txt. Kernelconfig see nihil.
Any thoughts anyone?
Bye!
Michael Reifenberger
^.*Plaut.
26 matches
Mail list logo
