> > Here's another solution ;)
> > http://www.crucial.com/store/mpartspecs.aspx?mtbpoid=09E2BA19A5CA7304
Yeah, it really can help!
...until golang guys multiply the compilation memory needs again. ;)
Pavel
On Fri Nov 2 13:08:27 EDT 2012, skip.tavakkol...@gmail.com wrote:
> Here's another solution ;)
>
> http://www.crucial.com/store/mpartspecs.aspx?mtbpoid=09E2BA19A5CA7304
>
addressing the actual problem FTW!
- erik
Here's another solution ;)
http://www.crucial.com/store/mpartspecs.aspx?mtbpoid=09E2BA19A5CA7304
On Fri, Nov 2, 2012 at 9:03 AM, Pavel Klinkovsky
wrote:
>> Just 'rm -rf' the exp/locale/collate directory and
>> run you should be good.
>
> Thank you for the hint.
> I confirm such work-around helps
i believe 8l uses its own storage allocator, but coul easily be tweeked to use
malloc and free
by hacking the sources a little (global search and replace), if memory serves
me well this
trades memory use for speed, and by going back to traditional malloc in go's 8l
you could
reduce the ram use b
9front kernel extracts and uses all the cpu and apic and interrupt
routing info from acpi tables if you boot it with *acpi=1. theres
no mixing of mptable and acpi tables.
--
cinap
> Just 'rm -rf' the exp/locale/collate directory and
> run you should be good.
Thank you for the hint.
I confirm such work-around helps. ;)
Pavel
> i might give the 9front kernel a go. i think that cinap spent
> some time trying to make swap work a little bit.
Well, actually I prefer to follow the main trunk (bell-labs) version.
Pavel
> i found in nix that when mixing acpi and mp i had to defend against
> double-entries for i/o apics since the numbering can be different. but
> it will be interesting to see what happened to start 2 cpu1s.
Looks like the same thing: MP table says 2 cpus with apic ids 0 and 1,
ACPI table says 2 c
> Just 'rm -rf' the exp/locale/collate directory and
> run you should be good.
it would be sad to see go sucked into the locale debacale.
- erik
erik quanstrom once said:
> On Fri Nov 2 09:44:43 EDT 2012, pavel.klinkov...@gmail.com wrote:
> > > How much memory does your system have?
> >
> > - 512 MB RAM
> > - 512 MB swap
> >
> > > Changeset 14739 grew the Unicode collation tables
> > > in the exp/locale/collate package by a considerable
> > I am running the Plan 9 on the single CPU only (old IBM T30).
>
> Sorry, that means we are looking at two different panics.
Yes.
My panic occurs inside 'fault' (search for 'faultarm' string) function of
/sys/src/9/port/fault.c.
It seems as an unfixable page fault.
I thought I have a problem
On Fri Nov 2 09:44:43 EDT 2012, pavel.klinkov...@gmail.com wrote:
> > How much memory does your system have?
>
> - 512 MB RAM
> - 512 MB swap
>
> > Changeset 14739 grew the Unicode collation tables
> > in the exp/locale/collate package by a considerable
> > amount. The compiler's memory usage no
On Fri Nov 2 09:52:22 EDT 2012, 9f...@hamnavoe.com wrote:
> > I am running the Plan 9 on the single CPU only (old IBM T30).
>
> Sorry, that means we are looking at two different panics.
> Mine seems to be a side effect of mpacpi.c trying to enable
> the same cpu twice:
>
> cpu0: 1599MHz Genuine
> I am running the Plan 9 on the single CPU only (old IBM T30).
Sorry, that means we are looking at two different panics.
Mine seems to be a side effect of mpacpi.c trying to enable
the same cpu twice:
cpu0: 1599MHz GenuineIntel Atom (cpuid: AX 0x106C2 DX 0xBFE9FBFF)
...
mpinit: mp table describ
> Are you running a recent (since 24 August) kernel on a multiprocessor?
I am running the latest kernel (pulled from the bell-labs repository).
I am running the Plan 9 on the single CPU only (old IBM T30).
> If so, try booting with *nomp=1 in plan9.ini and see if running on
> just one cpu prevent
> How much memory does your system have?
- 512 MB RAM
- 512 MB swap
> Changeset 14739 grew the Unicode collation tables
> in the exp/locale/collate package by a considerable
> amount. The compiler's memory usage now goes above
> 400 MB when building that package, almost 2.5x the
> amount used to
On Fri Nov 2 08:00:29 EDT 2012, 9f...@hamnavoe.com wrote:
> Are you running a recent (since 24 August) kernel on a multiprocessor?
>
> If so, try booting with *nomp=1 in plan9.ini and see if running on
> just one cpu prevents the panic.
>
> I've just updated my kernel, and I'm getting a panic on
Pavel Klinkovsky once said:
> I made another test.
> I compared compilation of exp/locale/collate of the Go build 14738 and
> 14739 (and later).
>
> Compilation of 14738 does not consume RAM a lot.
> Compilation of 14739 (and later) consume a huge amount of RAM
> (involving swap).
>
> So it seem
Are you running a recent (since 24 August) kernel on a multiprocessor?
If so, try booting with *nomp=1 in plan9.ini and see if running on
just one cpu prevents the panic.
I've just updated my kernel, and I'm getting a panic on opening
a particular email message in acme. Just debugging it now.
I made another test.
I compared compilation of exp/locale/collate of the Go build 14738 and
14739 (and later).
Compilation of 14738 does not consume RAM a lot.
Compilation of 14739 (and later) consume a huge amount of RAM
(involving swap).
So it seems the Plan 9 has a problem with the virtual mem
20 matches
Mail list logo
