FWIW, i just noticed this in subr_extent.c. gross, but what you want :-)
.mrg.
#include
#define KMEM_IS_RUNNING (kmem_map != NULL)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
On May 7, 2010, at 5:31 PM, Eduardo Horvath wrote:
On Fri, 7 May 2010, Michael wrote:
In fact I did describe it in another mail.
And the problem is that macppc sets up its console extremely early.
If I move
consinit() after uvm_init() th
On Fri, 7 May 2010, Michael wrote:
> In fact I did describe it in another mail.
> And the problem is that macppc sets up its console extremely early. If I move
> consinit() after uvm_init() then debugging uvm_init() problems becomes a lot
> harder and as I said before, the parts that need uvm to b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
On May 7, 2010, at 4:26 PM, Martin Husemann wrote:
On Fri, May 07, 2010 at 04:05:30PM -0400, Michael wrote:
kernel output anyway. All it needs is a sane way to decide wether it
can allocate memory or not.
So split init in a minimal (optio
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
On May 7, 2010, at 3:39 PM, Mindaugas Rasiukevicius wrote:
Michael wrote:
Any chance to just have kmem_alloc() immediately return NULL if it
isn't ready yet so we can fail gracefully instead of hanging?
Such handling, i.e. in kmem(9), se
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
On May 7, 2010, at 4:19 PM, Joerg Sonnenberger wrote:
On Fri, May 07, 2010 at 03:11:32PM -0400, Michael wrote:
It's rasops_reconfig(). It may want to autogenerate box drawing
characters, which needs to allocate memory, but it can happily li
> > kernel output anyway. All it needs is a sane way to decide wether it
> > can allocate memory or not.
>
> So split init in a minimal (optional) version called from the consinit
> functions, and a full grown init called at driver attach time (and have the
> latter skip the parts already done b
On Fri, May 07, 2010 at 04:05:30PM -0400, Michael wrote:
> kernel output anyway. All it needs is a sane way to decide wether it
> can allocate memory or not.
So split init in a minimal (optional) version called from the consinit
functions, and a full grown init called at driver attach time (and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
On May 7, 2010, at 3:21 PM, Martin Husemann wrote:
On Fri, May 07, 2010 at 03:15:55PM -0400, Michael wrote:
We get out of cold WAY later than that. In fact kmem is ready before
autoconfig starts and cold is only cleared after that.
Realis
On Fri, May 07, 2010 at 03:11:32PM -0400, Michael wrote:
> It's rasops_reconfig(). It may want to autogenerate box drawing
> characters, which needs to allocate memory, but it can happily live
> without them and some ports ( macppc for example ) setup a rasops-
> based console very early in the boo
macal...@netbsd.org said:
> the parts that need uvm are strictly optional - not needed at all
> for basic kernel output. We only need to know if we can use them or
> not.
So as Martin said: if called from consinit(), static memory should
be used. At autoconf time and later, *alloc is OK. If w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
On May 7, 2010, at 3:45 PM, Martin Husemann wrote:
On Fri, May 07, 2010 at 08:39:51PM +0100, Mindaugas Rasiukevicius
wrote:
Well, kmem(9) is initialised very early, just after pool(9), in
uvm_init(),
where I moved it couple years ago. Ye
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
On May 7, 2010, at 4:01 PM, Mindaugas Rasiukevicius wrote:
Martin Husemann wrote:
Well, kmem(9) is initialised very early, just after pool(9), in
uvm_init
(), where I moved it couple years ago. Yes, 'cold' is unset very
late.
Since all
Martin Husemann wrote:
> > Well, kmem(9) is initialised very early, just after pool(9), in uvm_init
> > (), where I moved it couple years ago. Yes, 'cold' is unset very late.
> > Since allocation gets postponed anyway, is that a problem? You did not
> > describe your use case. :)
>
> consinit()
On Fri, May 07, 2010 at 08:39:51PM +0100, Mindaugas Rasiukevicius wrote:
> Well, kmem(9) is initialised very early, just after pool(9), in uvm_init(),
> where I moved it couple years ago. Yes, 'cold' is unset very late. Since
> allocation gets postponed anyway, is that a problem? You did not des
Michael wrote:
> >> Any chance to just have kmem_alloc() immediately return NULL if it
> >> isn't ready yet so we can fail gracefully instead of hanging?
> >
> > Such handling, i.e. in kmem(9), seems like a wrong approach to me.
> >
> > Caller can check the 'cold' variable, which is unset in confi
On Fri, May 07, 2010 at 03:15:55PM -0400, Michael wrote:
> We get out of cold WAY later than that. In fact kmem is ready before
> autoconfig starts and cold is only cleared after that.
Realistically, besides all the problems we already solved by rearranging
intializiation order, it is only consi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
On May 6, 2010, at 10:19 PM, Masao Uebayashi wrote:
On Thu, May 06, 2010 at 02:32:57PM -0400, Michael wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
I recently ran into this problem - there is no easy way to determine
wether
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
On May 7, 2010, at 10:37 AM, Mindaugas Rasiukevicius wrote:
Hello,
Michael wrote:
I recently ran into this problem - there is no easy way to determine
wether it is safe to call kmem_alloc() yet ( as in, are we far enough
through startup )
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
On May 7, 2010, at 5:54 AM, Izumi Tsutsui wrote:
Right, on the face of it I don't see why this is something to be
handled at
runtime.
Move consinit() past uvm_init() ;-}
Probably we should classify console devices and split consinit()?
Hello,
Michael wrote:
> I recently ran into this problem - there is no easy way to determine
> wether it is safe to call kmem_alloc() yet ( as in, are we far enough
> through startup ) and when we call it too early the whole thing just
> hangs.
> Any chance to just have kmem_alloc() immedia
> > Right, on the face of it I don't see why this is something to be handled at
> > runtime.
>
> Move consinit() past uvm_init() ;-}
Probably we should classify console devices and split consinit()?
- dumb device working without VM
(though we still have to consider about bus_space(9))
- comp
On Fri, May 07, 2010 at 09:28:31AM +, Andrew Doran wrote:
> Right, on the face of it I don't see why this is something to be handled at
> runtime.
Move consinit() past uvm_init() ;-}
Martin
On Fri, May 07, 2010 at 11:19:58AM +0900, Masao Uebayashi wrote:
> On Thu, May 06, 2010 at 02:32:57PM -0400, Michael wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > Hello,
> >
> > I recently ran into this problem - there is no easy way to determine
> > wether it is safe to ca
> I recently ran into this problem - there is no easy way to determine
> wether it is safe to call kmem_alloc() yet ( as in, are we far enough
> through startup ) and when we call it too early the whole thing just
> hangs.
> Any chance to just have kmem_alloc() immediately return NULL if it
On Thu, May 06, 2010 at 02:32:57PM -0400, Michael wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello,
>
> I recently ran into this problem - there is no easy way to determine
> wether it is safe to call kmem_alloc() yet ( as in, are we far
> enough through startup ) and when we ca
26 matches
Mail list logo
