Hi all,
I have troubles to compile Go on my native Plan 9 - Go revision 14739
and later.
I do have a kernel panic when compiling exp/locale/collate.
Does anyone else have the same problem?
Thank you.
Pavel
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
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.
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
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
> 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
> 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
> 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
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
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
> > 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
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
Hi.
For those interested in participating in the International Workshop on Plan 9,
please BOOK
HOTEL asap.
Please also register for participation, again, see details at iwp9.org.
IMPORTANT: if you want to stay at the main hotel, the Maldron, they are
filling fast, so
please book your room asa
> 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
> 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
> 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
> 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 prepared the very simple program sequentially allocating 1 MB blocks of
memory.
When it reached the end of RAM, the kernel panic occured.
It really seems as a problem with swap. :(
Pavel
On Fri Nov 2 12:24:44 EDT 2012, pavel.klinkov...@gmail.com wrote:
> I prepared the very simple program sequentially allocating 1 MB blocks of
> memory.
> When it reached the end of RAM, the kernel panic occured.
>
> It really seems as a problem with swap. :(
this is well known, and solutions ar
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
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
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
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
Yeah, it really can help!
...until golang guys multiply the compilation memory needs again. ;)
Pavel
>> It really seems as a problem with swap. :(
>
> this is well known, and solutions are available
> even if you don't care to use them.
Oh, does it mean the official Plan 9 distribution contains non-working swap? :O
It is clear I missed something...
Sorry for the noise.
Pavel
On Fri, Nov 2, 2012 at 10:36 AM, Pavel Klinkovsky
wrote:
>>> It really seems as a problem with swap. :(
>>
>> this is well known, and solutions are available
>> even if you don't care to use them.
>
> Oh, does it mean the official Plan 9 distribution contains non-working swap?
> :O
> It is clear
> Swap has been broken since at least 2005 (my first experiments with
> Plan 9). Once I stopped trying to compile ghostscript on a 32 MB
> laptop, I never really had problems with the lack... hell, I did my
> master's work and most of my personal computing on a laptop with only
> 1 GB of RAM and no
it's by design:
http://9fans.net/archive/2006/07/229
-Skip
On Fri, Nov 2, 2012 at 10:36 AM, Pavel Klinkovsky
wrote:
>>> It really seems as a problem with swap. :(
>>
>> this is well known, and solutions are available
>> even if you don't care to use them.
>
> Oh, does it mean the official Plan 9
On Fri Nov 2 15:10:00 EDT 2012, skip.tavakkol...@gmail.com wrote:
> it's by design:
> http://9fans.net/archive/2006/07/229
>
> -Skip
>
> On Fri, Nov 2, 2012 at 10:36 AM, Pavel Klinkovsky
> wrote:
> >>> It really seems as a problem with swap. :(
> >>
> >> this is well known, and solutions are av
There's a non-trivial chance that what now goes wrong with paging
(which did once work, even if it isn't great) is a symptom of a bug
that afflicts the virtual memory code itself. (For instance, a page unlocked
during a critical period, a race, and so on.)
On 2 November 2012 19:18, erik quanstro
To be clear, is the swap partition completely useless in Plan9?
pmarin.
On Fri, Nov 2, 2012 at 9:28 PM, Charles Forsyth
wrote:
> There's a non-trivial chance that what now goes wrong with paging
> (which did once work, even if it isn't great) is a symptom of a bug
> that afflicts the virtual mem
if you use the 9front distribution swap works,
if you use the either 9atom or the labs distribution it does not.
the labs or erik may take the fixes from 9front but there are good reasons
for dropping swap all together - it is very slow, rarely used,
and ram is cheap these days.
i think this is a
On Sat Nov 3 02:54:52 EDT 2012, st...@quintile.net wrote:
> if you use the 9front distribution swap works,
> if you use the either 9atom or the labs distribution it does not.
>
> the labs or erik may take the fixes from 9front but there are good reasons
> for dropping swap all together - it is ve
33 matches
Mail list logo
