On Mon, Dec 3, 2012 at 5:35 AM, Michael Schmitz
wrote:
>> The machines are 060s. What does Aranym emulate? 040? 030?
>
> 030 IIRC. Stock Falcon - that's 030 (with 68881 so Linux will run).
Nope, 68040:
cat /proc/cpuinfo
CPU:68040
MMU:68040
FPU:68040
Clocking:
On 2012-12-03 05:06, Finn Thain wrote:
On three different machines the same symptom? Unlikely, I guess...
;-)
If these three crashing machines are all using the same filesystem
then
it's possible that an intermittent hardware fault caused both the
non-reproducible ICE and earlier corrupted a b
Hi,
The machines are 060s. What does Aranym emulate? 040? 030?
030 IIRC. Stock Falcon - that's 030 (with 68881 so Linux will run).
Looks like you could run the command again with no trouble - so this
might be something related to schroot or kernel.
Cheers,
Michael
Another guess, i
On Sun, 2 Dec 2012, Brad Boyer wrote:
> I did find a place online selling the 16M 30 pin SIMMs that would be
> required for that total.
I bought some from macsales.com last year. They were cheap but I don't
know whether they are still available.
Finn
--
To UNSUBSCRIBE, email to debian-68k-
On Sun, 2 Dec 2012, Ingo J?rgensmann wrote:
>
> On three different machines the same symptom? Unlikely, I guess... ;-)
If these three crashing machines are all using the same filesystem then
it's possible that an intermittent hardware fault caused both the
non-reproducible ICE and earlier co
On Sun, Dec 02, 2012 at 11:22:33AM +0100, Ingo Jürgensmann wrote:
> On 2012-12-02 09:19, Wouter Verhelst wrote:
>
> >>You mean the compiler command? You mean I should rerun
> >>gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall
> >>-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-pro
On Sun, Dec 02, 2012 at 04:53:33PM +0100, Ingo Jürgensmann wrote:
> Well, gcc-4.3 just built fine with that amount of RAM. Anyway,
> there's no possibility to extend that. All Amigas are maxed out at
> 128M. In the past that was never an issue. I built much larger
> packages that came near to 1 GB
Ingo Jürgensmann dixit:
> Well, gcc-4.3 just built fine with that amount of RAM. Anyway, there's no
> possibility to extend that. All Amigas are maxed out at 128M. In the past that
> was never an issue.
Well, in the past, we didn’t have aggressively broken/over-optimising
compilers and standards
On 2012-12-02 16:34, Thorsten Glaser wrote:
The machines are 060s. What does Aranym emulate? 040? 030?
Something in between, I think.
In between? Sounds strange... ;)
http://aranym.org/features.html states that it's emulating an 040. So,
it *may* be an 060 issue, perhaps.
Another guess, i
Ingo Jürgensmann dixit:
> The machines are 060s. What does Aranym emulate? 040? 030?
Something in between, I think.
>> Another guess, is there enough RAM?
>
> 128M memory and >400M swap.
This is probably not enough real RAM to build GCC without
any major pain. Should be enough for most smaller
Ingo Jürgensmann dixit:
> Hmmm... dunno if that's right...
>
> elgar:/media/gcc-4.6-4.6.3/build/gcc# gcc -c -g -fkeep-inline-functions
> -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
> -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long
> -Wno-variadic-
Am 02.12.2012 um 11:59 schrieb Ingo Jürgensmann:
> Am 02.12.2012 um 01:37 schrieb Thorsten Glaser:
>
>>> Well, as I said: I can run some memory testing tomorrow. This, of
>>> course, doesn't guarantee that the memory is without any faults, if
>>> nothing pops up. Only if something is found, then
Am 02.12.2012 um 01:37 schrieb Thorsten Glaser:
>> Well, as I said: I can run some memory testing tomorrow. This, of
>> course, doesn't guarantee that the memory is without any faults, if
>> nothing pops up. Only if something is found, then it's sure that the
>> memory is faulty. But what if the t
On 2012-12-02 09:19, Wouter Verhelst wrote:
You mean the compiler command? You mean I should rerun
gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros
Ingo Jürgensmann writes:
> The bug is not reproducible, so it is likely a hardware or OS problem.
Do you have enough memory?
> elgar.debian.net
ssh: Could not resolve hostname elgar.debian.net: Name or service not known
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint =
On 2012-12-02 09:39, Andreas Schwab wrote:
The bug is not reproducible, so it is likely a hardware or OS
problem.
Do you have enough memory?
128 MB RAM + >400 MB swap.
elgar.debian.net
ssh: Could not resolve hostname elgar.debian.net: Name or service not
known
Yeah, usually it's located
On Sun, Dec 02, 2012 at 09:07:58AM +0100, Ingo Jürgensmann wrote:
> On 2012-12-02 01:37, Thorsten Glaser wrote:
> >Also, what happens if you run the segfaulting command repeatedly?
>
> You mean the compiler command? You mean I should rerun
>
> gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wa
On 2012-12-02 04:55, Michael Schmitz wrote:
I surely hope not╜ this looks more like a hardware issue,
possibly faulty RAM, to me. (Never saw the ╲The bug is not
reproducible╡ blurb beforeâ•œ)
I've seen that one before - it's been there pretty much since the
stone ages. gcc does exercise
On 2012-12-02 01:37, Thorsten Glaser wrote:
Well, as I said: I can run some memory testing tomorrow. This, of
course, doesn't guarantee that the memory is without any faults, if
nothing pops up. Only if something is found, then it's sure that the
memory is faulty. But what if the test won't show
Thorsten,
I surely hope not╜ this looks more like a hardware issue,
possibly faulty RAM, to me. (Never saw the ╲The bug is not
reproducible╡ blurb beforeâ•œ)
I've seen that one before - it's been there pretty much since the stone
ages. gcc does exercise memory more thoroughly than anyt
Ingo J�rgensmann dixit:
>Well, as I said: I can run some memory testing tomorrow. This, of
>course, doesn't guarantee that the memory is without any faults, if
>nothing pops up. Only if something is found, then it's sure that the
>memory is faulty. But what if the test won't show memory issues? I'
Am 02.12.2012 um 00:48 schrieb Thorsten Glaser:
> I surely hope not╜ this looks more like a hardware issue,
> possibly faulty RAM, to me. (Never saw the ╲The bug is not
> reproducible╡ blurb beforeâ•œ)
Well, as I said: I can run some memory testing tomorrow. This, of course,
doesn't guara
Ingo J�rgensmann dixit:
>For me, it seems as if we have a toolchain problem, maybe caused by
>building the toolchain on emulated CPUs for a long term. But that's
>only a quick and simplified guess.
>../../src/gcc/basic-block.h:927:1: internal compiler error: Segmentation fault
>Please submit a fu
Hi all!
For me, it seems as if we have a toolchain problem, maybe caused by building
the toolchain on emulated CPUs for a long term. But that's only a quick and
simplified guess.
I experienced in Unstable some glibc double free problems, like when running
schroot or apt-transport-https. So I
24 matches
Mail list logo
