1 |
On 10/28/07, Dan Farrell <dan@×××××××××.cx> wrote: |
2 |
> |
3 |
> On Sun, 28 Oct 2007 19:40:01 +0200 |
4 |
> "Yoav Luft" <yoav.luft@×××××.com> wrote: |
5 |
> |
6 |
> > On 10/28/07, Dan Farrell <dan@×××××××××.cx> wrote: |
7 |
> > > |
8 |
> > > On Sun, 28 Oct 2007 06:04:43 +0200 |
9 |
> > > "Yoav Luft" <yoav.luft@×××××.com> wrote: |
10 |
> > > |
11 |
> > > > hello, |
12 |
> > > > during an emerge -uDN process, the compilation for gcc-4.2.1 |
13 |
> > > > failed, as well as for glibc, with same errors. |
14 |
> > > > I have run revdep-rebuilt, and found out about a broken |
15 |
> > > > libexpat.so.0thingy, which I solved following the instruction of |
16 |
> > > > the gentoo irc bot. |
17 |
> > > > after that, compiling gcc still fails. |
18 |
> > > > |
19 |
> > > > insn-emit.c: In function 'gen_leave': |
20 |
> > > > insn-emit.c:1123: internal compiler error: Segmentation fault |
21 |
> > > > . . . |
22 |
> > > > I'm clueless about it, but do feel that not being able to updaate |
23 |
> > > > gcc or glibc is bad, and will probably mean that I will not be |
24 |
> > > > able to update other things as well. |
25 |
> > > |
26 |
> > > Have you done a memtest-86, and waited for a few days, or at least a |
27 |
> > > few error-free complete passes? |
28 |
> > > -- |
29 |
> > > gentoo-user@g.o mailing list |
30 |
> > > |
31 |
> > > |
32 |
> > |
33 |
> > I have waited for a few days, and tried different versions of gcc and |
34 |
> > glibc, all failed. |
35 |
> |
36 |
> did you remember to emerge --sync, maybe even emerge --metadata ? |
37 |
> frankly, I am not sure what the last one does, but I believe it could |
38 |
> update data concerning the ebuilds themselves, which could be a |
39 |
> potential source of problems. |
40 |
> |
41 |
> > I did had an overheating problem a couple of months ago, right around |
42 |
> > the time the problem started. So, it could be that the CPU is |
43 |
> > semi-toasted? How do I run memtest-86? |
44 |
> |
45 |
> there are 2 ways I know of: |
46 |
> 1) simply reboot on a gentoo boot cd and type 'memtest' or some such |
47 |
> at the boot: line. (Refer to the on-disc documentation for help |
48 |
> concerning what exactly to type) |
49 |
> 2) a)emerge memtest86+; |
50 |
> b) find memtest.bin and move it to /boot/memtest86plus |
51 |
> c)add a grub line that looks like this: |
52 |
> title=Memtest86Plus |
53 |
> root (hd0,1) # this refers to my boot partition. you may have |
54 |
> # to change this setting. |
55 |
> kernel /boot/memtest86plus/memtest.bin |
56 |
> d) reboot and use memtest from the hard drive. |
57 |
> |
58 |
> If, when you emerge memtest86+, you have /boot mounted, the emerge will |
59 |
> plop the .bin file down right where it needs to be. If not, the output |
60 |
> from the emerge should giveyou the info you need. |
61 |
> |
62 |
> Of course, memtest.bin doesn't have to be on your boot partition, if |
63 |
> grub can read the root partition. In fact, you might not even have |
64 |
> a /boot partition. Just make sure the root line for memtest in grub is |
65 |
> proper. |
66 |
> |
67 |
> |
68 |
> > Is there anything else that's |
69 |
> > worth checking? |
70 |
> |
71 |
> You could try a CPU stress test. If the cpu isn't working properly, |
72 |
> using it at 100% capacity for a little while ought to make that |
73 |
> apparent. But your results may vary. A rudimentary query on google |
74 |
> points me in the direction of: |
75 |
> |
76 |
> http://users.bigpond.net.au/cpuburn/ |
77 |
> |
78 |
> However, i don't know if it's source and if not, there's always a valid |
79 |
> security concern when running others' binaries. something to keep in |
80 |
> mind... |
81 |
> -- |
82 |
> gentoo-user@g.o mailing list |
83 |
> |
84 |
> |
85 |
I had run memtest, and returned no errors. In all occurrences of this |
86 |
problem I had emerge --sync before I updated, as I was about the update |
87 |
the whole system, and eventually emerge -UD world. I would try a cpu stress, |
88 |
but that would have to wait for next week. Thanks fo rthe help so far. |