Gentoo crashing?

> Peter Davoust wrote:
> Ok, I just conquered my gdm issues in a previous
thread, and now I'm
> finding that gentoo is crashing on me! ...


"Dustin C. Hatch" <admiralnemodchweb.com> skribis:
> I have been having that problem for quite some time
now.  It was really
> bad when I upgraded to 2.6.21.  I downgraded back to
2.6.20-r4 and I
> haven't had near the problems.  I am not sure what it
is, but you aren't
> the only one with that problem.

I quit using Gentoo kernels on my AMD64 some while ago,
after
determining that with Gentoo kernels bad things happened
with some
kernels, while with vanilla kernels those bad things
happened with
none of the kernels. I don't know if my situation is related
to this
latest.

I use the Gentoo kernel on x86 (my wife's computer) without
any
problems.

-- 
Barry.SCHWARTZ ĉe chemoelectric punkto org  http://chemoelectric.org

              Free stuff / Senpagaj varoj:  http://crudfactory.com
'Democracies don't war; democracies are peaceful countries.'
- Bush
(http://www.whitehouse.gov/news/releases/2005/12/2
0051219-2.html)
-- 
gentoo-amd64gentoo.org mailing list

On Monday 14 May 2007 07.25.46 Dustin C. Hatch wrote:
> Peter Davoust wrote:

I would check my memory, only time I've had this kind
problem has been with 
faulty memory.
-- 
Naga
-- 
gentoo-amd64gentoo.org mailing list

On 5/13/07, Peter Davoust <worldgnatgmail.com> wrote:
> Ok, I just conquered my gdm issues in a previous
thread, and now I'm finding
> that gentoo is crashing on me! Twice so far, gentoo has
crashed at fairly
> inappropriate times. I've used gentoo before, and not
once has it crashed
> meaninglessly. First, I think I was listing a
directory, and it totally
> froze, and then the second time I was unzipping a
bzipped archive of the
> latest kernel sources and it came to a dead halt. I had
to hard reboot the
> machine, it wasn't fun. I'm starting to get worried,
especially since if it
> can't handle a little tar.bz2 file, then it certainly
can't emerge anything.
> I'm sure you'll be wanting some logs, and I'll get them
to you next time I
> boot gentoo. I've got 2 gig of RAM, and a dual core
processor, so those
> aren't the problem, and my hard drive has plenty of
free space (talking gigs
> here), so that's not it either. It sounds like it's
something really obvious
> that I'm overlooking, but I don't understand how it
could just stop. Even
> the normal clicking associated with the processor
"thinking" just halts.
> Isn't that weird?

Did this just start when you loaded Gentoo?  For the sake
of
troubleshooting I'd start with taking Gentoo out of the loop
and
verifying your hardware is not the problem.  Memtest86,
cpuburn, and
bonnie++ from a live cd should give you a decent sanity
test.  From
there look at your kernel then compiler flags.  You also may
want to
consider heat as well since the weather in most places is
starting to
warm up this time of year.

Wil
-- 
gentoo-amd64gentoo.org mailing list

Very interesting post!
Could you explain what "mobo" means?
And BTW (_almost_ off-topic...) I've heard that RAM sticks
should be identical when plugged on the same motherboard,
but it was some "good vendor advice" so I'd rather
rely on some experienced user's answer.
So is there an issue if two RAM sticks of different brands
are plugged on the same motherboard? What if, whilst of the
same brand, they don't have the same capacity? Could Peter's
issue be related to this kind of problem?

On Mon, 14 May 2007 10:50:31 +0000 (UTC)
Duncan <1i5t5.duncancox.net> wrote:

> "Peter Davoust" <worldgnatgmail.com> posted
> 7c08b4dd0705132304h5eccea49k22513343959aff52mail.gmail.com, excerpted
> below, on  Mon, 14 May 2007 02:04:30 -0400:
> 
> > I agree, it could be the heat, and that was the
first thing that came to
> > my mind, but Vista boots and runs for long periods
of time with no
> > issues. I'll check it out with the new kernel in
the morning and see
> > what it does.
> 
> Note that Gentoo tends to use hardware to its limits
rather more than 
> most OSs, MSWormOS and other Linux distributions alike.
 Vista is so new, 
> and /does/ stress at least the video hardware rather
more (if aero is on, 
> anyway), so I don't know if anyone can rightly say with
it, but certainly 
> with older MS platforms, it hasn't been uncommon at
/all/ for Gentoo to 
> cause problems where MS didn't, and even other Linux
distributions didn't.
> 
> Part of the reason is that Gentoo tends to be
compiled/optimized for the 
> specific CPU it's running on, so it makes more
efficient use of it, 
> including use of functionality distributions (and MS)
compiled for use on 
> generic hardware simply don't use, plus simply the fact
that when the CPU 
> is busy, it's often getting more done in the same time,
so it IS working 
> harder and therefore stressing out the hardware more.
> 
> Anyway, just because another OS doesn't have problems
on a computer 
> doesn't mean Gentoo won't, and there are quite a number
of folks on the 
> forums and on the gentoo-user list that will tell you
the same thing -- 
> learned from hard experience.
> 
> Meanwhile, you mention specifically that one of the
crashes was during a 
> bz2 decompress.  As someone who has HAD memory issues
in the past, I can 
> DEFINITELY tell you that bz2 DOES often trigger memory
errors, if 
> ANYTHING will!  If the issues with BZ2 turn out to be
common, CHECK THAT 
> MEMORY, and check it again!  You mentioned you have 2
gigs.  Hopefully 
> it's in the form of 2 or more sticks.  If so, you
should be able to take 
> part of it out and see if the problem persists.  Then
test the other 
> memory.  If the problem happens with one set but not
the other, you have 
> your problem.  Do note, however, that just because the
problem continues 
> to occur with either memory set doesn't necessarily
mean it's not the 
> memory, particularly if they are the same brand and
size, purchased from 
> the same place at the same time, so are likely in the
same lot.
> 
> In my case, I had purchased generic memory that
couldn't quite do its 
> rated pc3200 (clock at 200 MHz x 2, since it was DDR). 
I ran memtest and 
> it passed with flying colors, because the memory worked
fine, and memtest 
> apparently doesn't really stress the memory timings,
only testing the 
> memory cells.  However, I was crashing in operation,
sometimes just the 
> app, sometimes the entire kernel would panic.  I turned
on the kernel's 
> MCE (machine check exception) reporting, and the memory
was indeed the 
> problem (google MCEs, there's an app available that you
can run, feeding 
> it the numbers, and it'll spit out the error in
English), only wasn't 
> quite sure whether it was the memory itself, or the
mobo, causing 
> perfectly good memory to generate errors upon data
delivery because it 
> couldn't reliably get the data to the CPU.
> 
> While I didn't have the necessary BIOS settings at the
time, sometime 
> later a BIOS update gave me additional memory settings,
and I found that 
> reducing the memory timings by a single notch, to 183
MHz (DDR doubled to 
> 366), effectively PC3000 memory, did the trick.  I was
even able to tweak 
> some of the individual wait-state settings to get back
a bit of the 
> performance I lost with the under-clocking.  The memory
and entire 
> machine was rock-stable at the 183 MHz PC3000 memory
setting.
> 
> Later I upgraded from my then two 512 MB sticks to four
2 GB sticks, 8 
> gigs memory total.  It was indeed the memory, not the
board, as the new 
> memory was just as stable at PC3200 as the old memory
had been at the 
> under-clocked PC3000 speed.
> 
> Anyway, the way bzip2 works is apparently extremely
stressful on memory, 
> as more than anything else, that would trigger the
errors.  Compiles were 
> frustrating too, but sometimes I could compile for
quite some time 
> without issues.  That's why I didn't think it was the
CPUs even before I 
> got the program to read the MCE numbers and tell me
what they were.  They 
> confirmed, it was memory related, the errors were on
data as the CPU got 
> it.  I just didn't know until I actually changed memory
whether it was 
> the mobo generating errors on the data in transit, or
the memory itself.  
> It turned out to be the memory.
> 
> -- 
> Duncan - List replies preferred.   No HTML msgs.
> "Every nonfree program has a lord, a master --
> and if you use the program, he is your master." 
Richard Stallman
> 
> -- 
> gentoo-amd64gentoo.org mailing list
> 
-- 
gentoo-amd64gentoo.org mailing list

Hello,
from your bug report, it is unclear if your are running
kde/gnome or whatever under X-server or not.
If the latter is the case, try to boot without X (press i
during boot and omit xdm) and try your
unzip commands in a console. If that works, you know your
X-config is faulty. Then try to turn off
all hardware acceleration options and disable dri and drm
modules in /etc/X11/xorg.conf
If you have also crashes in a normal console without X, I
think your hardware is broken. I know that
your notebook is new, but also new notebooks can be faulty.
-- 
gentoo-amd64gentoo.org mailing list