[gentoo-amd64] Gentoo crashing?

[gentoo-amd64] Gentoo crashing?

[Peter Davoust]

[-- Attachment #1: Type: text/plain, Size: 1072 bytes --]

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?

-Peter

[-- Attachment #2: Type: text/html, Size: 1159 bytes --]

Re: [gentoo-amd64] Gentoo crashing?

[Dustin C. Hatch]

[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]

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.

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! 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?
>
> -Peter

-- 
Dustin C. Hatch
http://www.dchweb.com


[-- Attachment #2: Type: text/html, Size: 1911 bytes --]

Re: [gentoo-amd64] Gentoo crashing?

[Barry.SCHWARTZ]

> 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" <admiralnemo@dchweb.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/20051219-2.html)
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Gentoo crashing?

[Naga]

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-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Gentoo crashing?

[Peter Davoust]

[-- Attachment #1: Type: text/plain, Size: 1423 bytes --]

Ok, I'll just unzip it on another partition and compile as quickly as
possible I guess. It's pretty much a pain. Just hope it let's me compile
before it crashes again.

On 5/14/07, Barry.SCHWARTZ@chemoelectric.org <
Barry.SCHWARTZ@chemoelectric.org> wrote:
>
> > 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" <admiralnemo@dchweb.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/20051219-2.html)
> --
> gentoo-amd64@gentoo.org mailing list
>
>

[-- Attachment #2: Type: text/html, Size: 2247 bytes --]

Re: [gentoo-amd64] Gentoo crashing?

[Wil Reichert]

On 5/13/07, Peter Davoust <worldgnat@gmail.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-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Gentoo crashing?

[Peter Davoust]

[-- Attachment #1: Type: text/plain, Size: 579 bytes --]

I have Vista on this machine too, and I'm pretty sure that it would wig out
if it detected memory errors, and it hasn't been freezing... any more than
usual, that is. Actually, come to think of it, I would wig out if I found
memory errors in my laptop, so we're going to hope it's not that.

On 5/14/07, Naga <nagatoro@gmail.com> wrote:
>
> 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-amd64@gentoo.org mailing list
>
>

[-- Attachment #2: Type: text/html, Size: 931 bytes --]

Re: [gentoo-amd64] Gentoo crashing?

[Peter Davoust]

[-- Attachment #1: Type: text/plain, Size: 2279 bytes --]

Ok, first, while I appreciate your advice, this is a brand new laptop and
there's no way I'm running bonnie++ (that's prime95, right?), or anything
with the words "cpu" and "burn" in the same sentence on this thing.
Memtest86 might be an option as long as it has no potential to kill
anything. 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.

On 5/14/07, Wil Reichert <wil.reichert@gmail.com> wrote:
>
> On 5/13/07, Peter Davoust <worldgnat@gmail.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-amd64@gentoo.org mailing list
>
>

[-- Attachment #2: Type: text/html, Size: 2866 bytes --]

Re: [gentoo-amd64] Re: Gentoo crashing?

[Isidore Ducasse]

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.duncan@cox.net> wrote:

> "Peter Davoust" <worldgnat@gmail.com> posted
> 7c08b4dd0705132304h5eccea49k22513343959aff52@mail.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-amd64@gentoo.org mailing list
> 
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Gentoo crashing?

[Duncan]

"Peter Davoust" <worldgnat@gmail.com> posted
7c08b4dd0705132304h5eccea49k22513343959aff52@mail.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-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Gentoo crashing?

[Florian D.]

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-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Gentoo crashing?

[Sebastian Redl]

Isidore Ducasse wrote:
> Could you explain what "mobo" means?
>   

Motherboard, also known as mainboard. The component where CPU, RAM and
PCI cards get stuck on.

Sebastian Redl
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Gentoo crashing?

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 1060 bytes --]

Am Montag 14 Mai 2007 11:36 schrieb Isidore Ducasse:
> 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?

Well, it is not the worst advise he could give you.

If you plan to use "dual channel" you should use two identical sticks.
However, for sticks that are not connected to each other with dual channel  
there is no need for this. For example you could have two sticks called "abc" 
in dual channel and two sticks called "def" in dual channel.
But keep in mind that all sticks will use the same speed setting.

And yes, Peter's problem definitly sounds like a RAM issue of some kind.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] Re: Gentoo crashing?

[Wil Reichert]

mobo == motherboard

I always use matched ram.  I also stick to well known name brands
(corsair, kingston, OCZ, etc).  With todays dual channel RAM
controllers you _really_ want your RAM to have identical timings,
voltages, etc.  If all your sticks are following JEDEC standards it
shouldn't matter, but I've been building my own & other peoples
machines long enough to be superstitious.

Wil

On 5/14/07, Isidore Ducasse <ducasse.isidore@gmail.com> wrote:
> 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.duncan@cox.net> wrote:
>
> > "Peter Davoust" <worldgnat@gmail.com> posted
> > 7c08b4dd0705132304h5eccea49k22513343959aff52@mail.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-amd64@gentoo.org mailing list
> >
> --
> gentoo-amd64@gentoo.org mailing list
>
>
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Gentoo crashing?

[Duncan]

Isidore Ducasse <ducasse.isidore@gmail.com> posted
20070514113637.3a4ba97d@Bazaar, excerpted below, on  Mon, 14 May 2007
11:36:37 +0200:

> Very interesting post!
> Could you explain what "mobo" means?

The other answers are correct, mo(ther)bo(ard).  Sorry for the 
unexplained confusing shorthand.

> 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?

I agree with the others here, especially Florian, too.  Same 
manufacturer's lot is a good idea when the memory is interleaved (should 
be a BIOS setting controlling that).  Common interleaving is dual-
channel, but with dual Opterons as here, quad channel is an option, 
interleaving the nodes as well as the sticks on the same node.  However I 
stick with dual-channel and independent nodes, as I prefer NUMA mode 
(each CPU/core gets its own memory space to work with, on its physically 
local memory, if possible) with its independent memory access, the apps 
on each CPU interfering less with the other's memory, over the additional 
bandwidth.  If it's not interleaved, it doesn't matter (or shouldn't, 
anyway), tho as Florian mentioned, the lower clock rate is used if the 
differ.

The same thing applies to capacity.  If one is interleaving, same 
capacity is required across the interleaf but not necessarily between two 
separate interleaves.

The problem could indeed be unmatched timing related (such unmatched 
timing being the reason different lots, even of the same manufacturer, 
often causes problems when interleaving), especially if interleaving is 
turned on.  Again, however, trying it with a stick at a time would of 
course eliminate such interleaving timing issues, altho if that's the 
issue, the memory sticks would test out fine individually.

-- 
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-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Gentoo crashing?

[dustin]

On Mon, May 14, 2007 at 02:04:30AM -0400, Peter Davoust wrote:
>    Ok, first, while I appreciate your advice, this is a brand new laptop
>    and there's no way I'm running bonnie++ (that's prime95, right?), or
>    anything with the words "cpu" and "burn" in the same sentence on this
>    thing. Memtest86 might be an option as long as it has no potential to
>    kill anything. 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.

Any new laptop should have the hardware smarts not to smoke itself, or
something really is broken.  It may shut down "unexpectedly" (which I
also consider a design bug), but actually causing damage is unlikely.

That said, this really sounds like a RAM problem, so I would run
memtest86 first.  Memtest86 has zero chance of smoking any system that
has passed a factory QA check.

I had a Gentoo system (a server) that pretty much ran (to be honest, it
was a heavily used database server that stayed up for a good 3 months in
this state).  However, its clock was skewed something like 10m/hour (I
now think this was due to lost ticks during processing of memory
faults).

I tried all the various kernel flags, largemem, etc., only to find out
that the problem was (as others on this thread have posted) incompatible
RAM.  I point this out only to say that bad RAM can cause *very* unusual
problems (not just the segfaults you'd expect), and to say that lots of
complex operations (like Vista, for example) can continue to run just
fine in such a broken environment.

Dustin
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Gentoo crashing?

[Peter Davoust]

[-- Attachment #1: Type: text/plain, Size: 2382 bytes --]

Ok, so I compiled a new kernel, and it seemed to work. I booted the new
kernel, I was able to unzip and install dhcpcd, ndiswrapper, wireless-tools,
and cab extract. Then, once the wireless was working, I tried emerge
--search dhcpcd, because gentoo apparently doesn't like my manually
configured dhcpcd.... CRASH! I ran memtest86+, as suggested, and it got to
at least 30% without a failure. I'll try it again, but at least 30% of my
memory is in tact. I'll try to emerge some other things, and see how it
goes.

-Peter

On 5/14/07, dustin@v.igoro.us <dustin@v.igoro.us> wrote:
>
> On Mon, May 14, 2007 at 02:04:30AM -0400, Peter Davoust wrote:
> >    Ok, first, while I appreciate your advice, this is a brand new laptop
> >    and there's no way I'm running bonnie++ (that's prime95, right?), or
> >    anything with the words "cpu" and "burn" in the same sentence on this
> >    thing. Memtest86 might be an option as long as it has no potential to
> >    kill anything. 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.
>
> Any new laptop should have the hardware smarts not to smoke itself, or
> something really is broken.  It may shut down "unexpectedly" (which I
> also consider a design bug), but actually causing damage is unlikely.
>
> That said, this really sounds like a RAM problem, so I would run
> memtest86 first.  Memtest86 has zero chance of smoking any system that
> has passed a factory QA check.
>
> I had a Gentoo system (a server) that pretty much ran (to be honest, it
> was a heavily used database server that stayed up for a good 3 months in
> this state).  However, its clock was skewed something like 10m/hour (I
> now think this was due to lost ticks during processing of memory
> faults).
>
> I tried all the various kernel flags, largemem, etc., only to find out
> that the problem was (as others on this thread have posted) incompatible
> RAM.  I point this out only to say that bad RAM can cause *very* unusual
> problems (not just the segfaults you'd expect), and to say that lots of
> complex operations (like Vista, for example) can continue to run just
> fine in such a broken environment.
>
> Dustin
> --
> gentoo-amd64@gentoo.org mailing list
>
>

[-- Attachment #2: Type: text/html, Size: 3079 bytes --]

Re: [gentoo-amd64] Gentoo crashing?

[Antoine Martin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Peter Davoust wrote:
> Ok, so I compiled a new kernel, and it seemed to work. I booted the new
> kernel, I was able to unzip and install dhcpcd, ndiswrapper,
> wireless-tools, and cab extract. Then, once the wireless was working, I
> tried emerge --search dhcpcd, because gentoo apparently doesn't like my
> manually configured dhcpcd.... CRASH!
What exactly do you mean by crash?
complete system lockup? oops on screen?
Does it happen with X turned off?

> I ran memtest86+, as suggested,
> and it got to at least 30% without a failure. I'll try it again, but at
> least 30% of my memory is in tact.
You are mis-reading memtest, it means 30% of all the tests, but each
test does go through all the ram at least once, so your ram is probably
ok as far as memtest is concerned. Note that this may not be enough to
trigger your kind of problems - which may have something to do with
system load or disk, etc.

> I'll try to emerge some other things,
> and see how it goes.
Really sounds like a hardware problem.

Antoine
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGSQ/LGK2zHPGK1rsRCqBhAJwL+OB6v+2l2CzqRFPhhdn4WaYlmQCfafop
Kw6H0JNEBfbSo+WTCYoLcCA=
=iilp
-----END PGP SIGNATURE-----
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Gentoo crashing?

[Antoine Martin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Peter Davoust wrote:
> Ok, first, while I appreciate your advice, this is a brand new laptop
> and there's no way I'm running bonnie++ (that's prime95, right?)
http://www.coker.com.au/bonnie++/
>, or
> anything with the words "cpu" and "burn" in the same sentence on this
> thing.
Well, if you want to get to the bottom of things, you may have to.
And in fact, if the laptop is under warranty, you are better off finding
out if it is broken now rather than later.
Note: cpuburn doesn't burn your cpu (unless your laptop's design is
flawed) and it is quite likely to cause a crash if there is a problem
with your system.

> Memtest86 might be an option as long as it has no potential to
> kill anything. 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGSRC1GK2zHPGK1rsRCsflAJ0bF0EmeIzDdPkxtokXzfRn6tGgYQCfZsTj
y8Hb2SNLxD6caVPOUP2M39c=
=Uo6k
-----END PGP SIGNATURE-----
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Gentoo crashing?

[Peter Davoust]

[-- Attachment #1: Type: text/plain, Size: 2416 bytes --]

I know it doesn't actually burn the cpu, but I'd rather not cook any
components if I don't have to. From what I know of torture tests, they run
the cpu so hot it starts making computational errors, am I right? It still
makes me nervous. I was hoping to be able to fix the issue just by
recompiling my kernel, but no such luck. I'll mess with it some more and see
what I can do. Can you give me any advice as to what I should to to a) not
violate my warrantee and b) avoid killing my computer as much as possible?
Could it just be something with my Gentoo install? I guess that's a stupid
question; I've had this problem on an older computer, but it was a Desktop
and it was much easier to swap components without messing up my warrantee.
So if it were a hardware problem, wouldn't you think that suse 10.2 would
have run into it as well? I used to run 10.2 (used to as in 3 days ago) for
hours on end without any problems at all. I agree that Gentoo can run the
computer harder, but that doesn't quite click.

-Peter

On 5/14/07, Antoine Martin <antoine@nagafix.co.uk> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Peter Davoust wrote:
> > Ok, first, while I appreciate your advice, this is a brand new laptop
> > and there's no way I'm running bonnie++ (that's prime95, right?)
> http://www.coker.com.au/bonnie++/
> >, or
> > anything with the words "cpu" and "burn" in the same sentence on this
> > thing.
> Well, if you want to get to the bottom of things, you may have to.
> And in fact, if the laptop is under warranty, you are better off finding
> out if it is broken now rather than later.
> Note: cpuburn doesn't burn your cpu (unless your laptop's design is
> flawed) and it is quite likely to cause a crash if there is a problem
> with your system.
>
> > Memtest86 might be an option as long as it has no potential to
> > kill anything. 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.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.4 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFGSRC1GK2zHPGK1rsRCsflAJ0bF0EmeIzDdPkxtokXzfRn6tGgYQCfZsTj
> y8Hb2SNLxD6caVPOUP2M39c=
> =Uo6k
> -----END PGP SIGNATURE-----
> --
> gentoo-amd64@gentoo.org mailing list
>
>

[-- Attachment #2: Type: text/html, Size: 2982 bytes --]

Re: [gentoo-amd64] Gentoo crashing?

[Peter Davoust]

[-- Attachment #1: Type: text/plain, Size: 3242 bytes --]

Actually, one thing I probably should mention is that it hasn't locked up
while running anything GUI yet. Maybe that's just luck of the draw, but it
may be important. Who knows. And to answer your previous question, by crash
I mean it locks up completely. The mouse driver operates for a few seconds,
but after that it's frozen entirely. Not even ctrl+atl+del does it. You
know, the other thing that makes me curious about it being a hardware glitch
is that it does this with gdm, I think (see previous thread: "GDM hates
me"). Well, the last time it locked up was while running emerge --sync,
which I'm running now with no apparent problems... yet.

-Peter

On 5/14/07, Peter Davoust <worldgnat@gmail.com> wrote:
>
> I know it doesn't actually burn the cpu, but I'd rather not cook any
> components if I don't have to. From what I know of torture tests, they run
> the cpu so hot it starts making computational errors, am I right? It still
> makes me nervous. I was hoping to be able to fix the issue just by
> recompiling my kernel, but no such luck. I'll mess with it some more and see
> what I can do. Can you give me any advice as to what I should to to a) not
> violate my warrantee and b) avoid killing my computer as much as possible?
> Could it just be something with my Gentoo install? I guess that's a stupid
> question; I've had this problem on an older computer, but it was a Desktop
> and it was much easier to swap components without messing up my warrantee.
> So if it were a hardware problem, wouldn't you think that suse 10.2 would
> have run into it as well? I used to run 10.2 (used to as in 3 days ago)
> for hours on end without any problems at all. I agree that Gentoo can run
> the computer harder, but that doesn't quite click.
>
> -Peter
>
> On 5/14/07, Antoine Martin <antoine@nagafix.co.uk> wrote:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> >
> > Peter Davoust wrote:
> > > Ok, first, while I appreciate your advice, this is a brand new laptop
> > > and there's no way I'm running bonnie++ (that's prime95, right?)
> > http://www.coker.com.au/bonnie++/
> > >, or
> > > anything with the words "cpu" and "burn" in the same sentence on this
> > > thing.
> > Well, if you want to get to the bottom of things, you may have to.
> > And in fact, if the laptop is under warranty, you are better off finding
> > out if it is broken now rather than later.
> > Note: cpuburn doesn't burn your cpu (unless your laptop's design is
> > flawed) and it is quite likely to cause a crash if there is a problem
> > with your system.
> >
> > > Memtest86 might be an option as long as it has no potential to
> > > kill anything. 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.
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v2.0.4 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> > iD8DBQFGSRC1GK2zHPGK1rsRCsflAJ0bF0EmeIzDdPkxtokXzfRn6tGgYQCfZsTj
> > y8Hb2SNLxD6caVPOUP2M39c=
> > =Uo6k
> > -----END PGP SIGNATURE-----
> > --
> > gentoo-amd64@gentoo.org mailing list
> >
> >
>

[-- Attachment #2: Type: text/html, Size: 4378 bytes --]

Re: [gentoo-amd64] Gentoo crashing?

[Barry.SCHWARTZ]

[-- Attachment #1: Type: text/plain, Size: 690 bytes --]

Peter Davoust <worldgnat@gmail.com> skribis:
> Well, the last time it locked up was while running emerge --sync,
> which I'm running now with no apparent problems... yet.

I'm no expert, but locking up during syncing seems to me the sort of
thing a screwball kernel might do. I can't explain bzip troubles as
easily that way, but is it just that the system has frozen up while a
bzip was going on?


-- 
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/20051219-2.html)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] Gentoo crashing?

[Peter Davoust]

[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]

Well, I suppose it might have been because it was bzipping the second time
(I'm not to familiar with the way portage syncs, I assume it as un-bzipping
an archive of files). I've been running it for a few hours how, non stop,
emerging things left and right plus an emerge --sync, and it hasn't locked
up, now this, as I described before, is running in Gnome. I don't know. It's
weird.

On 5/14/07, Barry.SCHWARTZ@chemoelectric.org <
Barry.SCHWARTZ@chemoelectric.org> wrote:
>
> Peter Davoust <worldgnat@gmail.com> skribis:
> > Well, the last time it locked up was while running emerge --sync,
> > which I'm running now with no apparent problems... yet.
>
> I'm no expert, but locking up during syncing seems to me the sort of
> thing a screwball kernel might do. I can't explain bzip troubles as
> easily that way, but is it just that the system has frozen up while a
> bzip was going on?
>
>
> --
> 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/20051219-2.html)
>
>

[-- Attachment #2: Type: text/html, Size: 1885 bytes --]

Re: [gentoo-amd64] Gentoo crashing?

[Barry.SCHWARTZ]

[-- Attachment #1: Type: text/plain, Size: 630 bytes --]

Peter Davoust <worldgnat@gmail.com> wrote:
>  Well, I suppose it might have been because it was bzipping the second time
>  (I'm not to familiar with the way portage syncs, I assume it as un-bzipping
>  an archive of files).

I'm thinking of all the networking that is involved in syncing, and
thus all the kernel code that gets run then.


-- 
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/20051219-2.html)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-amd64] Re: Gentoo crashing?

[Duncan]

"Peter Davoust" <worldgnat@gmail.com> posted
7c08b4dd0705141408occ29970ueaf4ea6699cdc81@mail.gmail.com, excerpted
below, on  Mon, 14 May 2007 17:08:42 -0400:

> things, and see how it goes. <br><br>-Peter<br><br><div><span
> class="gmail_quote">On 5/14/07, <b class="gmail_sendername"><a
> href="mailto:dustin@v.igoro.us">dustin@v.igoro.us</a></b> &lt;<a

FWIW, I was trying to ignore this, but after multiple posts, it's 
becoming difficult to do so.  Please kill the HTML.  While your at it, 
top posting isn't so great either, but it's not the security issue that 
HTML posting can be, so killing the HTML is the big thing.

-- 
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-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Gentoo crashing?

[Antoine Martin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Barry.SCHWARTZ@chemoelectric.org wrote:
> Peter Davoust <worldgnat@gmail.com> skribis:
>> Well, the last time it locked up was while running emerge --sync,
>> which I'm running now with no apparent problems... yet.
> 
> I'm no expert, but locking up during syncing seems to me the sort of
> thing a screwball kernel might do. I can't explain bzip troubles as
> easily that way, but is it just that the system has frozen up while a
> bzip was going on?
I've had bzip2 problems with overheating laptop cpus before.
Also gcc would mis-compile and tell you about it.

Antoine

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGSZv5GK2zHPGK1rsRCrAYAJwOCrIzc0meIQaEbfXHSWwhUHq5ewCfaldE
CjxZd0keXxhf9vnkd/bG2HA=
=dFq/
-----END PGP SIGNATURE-----
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Gentoo crashing?

[Antoine Martin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Peter Davoust wrote:
> Actually, one thing I probably should mention is that it hasn't locked
> up while running anything GUI yet. Maybe that's just luck of the draw,
> but it may be important. Who knows. And to answer your previous
> question, by crash I mean it locks up completely. The mouse driver
> operates for a few seconds, but after that it's frozen entirely.
Quite odd. Could be interrupt related, have you tried booting with
"noapic" and/or "acpi=off"?

> Not
> even ctrl+atl+del does it. You know, the other thing that makes me
> curious about it being a hardware glitch is that it does this with gdm,
> I think (see previous thread: "GDM hates me"). Well, the last time it
> locked up was while running emerge --sync, which I'm running now with no
> apparent problems... yet.
> 
> -Peter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGSZx4GK2zHPGK1rsRCkv3AJ9fD8TWd0qzNOl36xtNhjHtWWSRYwCfdIOg
q6n4iUvbxwNAYxOddALMUxQ=
=mH8T
-----END PGP SIGNATURE-----
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Gentoo crashing?

[Isidore Ducasse]

le Tue, 15 May 2007 08:57:01 -0400
"Peter Davoust" <worldgnat@gmail.com> a écrit:

> Ok, I thought I had turned it to plain text, but gmail is obsessive
> about these things. Ok, so I haven't tried with acpi off. 

My brother's computer (intel dual core, as far as I remember) used to hang up randomly when used with acpi. He also had a problem with the preemption option inkernel, leading to hang-ups. But those issues had nothing to do with loading X.

I'll have a glance at gmail's options next time I use the web interface; sorry for the inconvenience if the [ originally text ] message gets blown as html.
--
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Gentoo crashing?

[Isidore Ducasse]

le Tue, 15 May 2007 11:06:23 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> a écrit:

> "Peter Davoust" <worldgnat@gmail.com> posted
> 7c08b4dd0705141408occ29970ueaf4ea6699cdc81@mail.gmail.com, excerpted
> below, on  Mon, 14 May 2007 17:08:42 -0400:
> 
> > things, and see how it goes. <br><br>-Peter<br><br><div><span
> > class="gmail_quote">On 5/14/07, <b class="gmail_sendername"><a
> > href="mailto:dustin@v.igoro.us">dustin@v.igoro.us</a></b> &lt;<a
> 
> FWIW, I was trying to ignore this, but after multiple posts, it's 
> becoming difficult to do so.  Please kill the HTML.  While your at it, 
> top posting isn't so great either, but it's not the security issue that 
> HTML posting can be, so killing the HTML is the big thing.
> 

It seems my messages get transformed to have both text/plain and text/html bodies. Is this what you receive from me? Does it bother?
--
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Gentoo crashing?

[Peter Davoust]

Ok, I thought I had turned it to plain text, but gmail is obsessive
about these things. Ok, so I haven't tried with acpi off. One
interesting development is that I've been trying to get my nvidia
graphics card working (no luck, by the way), and when I logon, startx
(doesn't work), then kill x, edit the config and try to start it
again, it crashes, sure thing. So if nothing else that establishes a
point where it will definately crash and I can reproduce the error.
Other than that I'm clueless.

On 5/15/07, Antoine Martin <antoine@nagafix.co.uk> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Peter Davoust wrote:
> > Actually, one thing I probably should mention is that it hasn't locked
> > up while running anything GUI yet. Maybe that's just luck of the draw,
> > but it may be important. Who knows. And to answer your previous
> > question, by crash I mean it locks up completely. The mouse driver
> > operates for a few seconds, but after that it's frozen entirely.
> Quite odd. Could be interrupt related, have you tried booting with
> "noapic" and/or "acpi=off"?
>
> > Not
> > even ctrl+atl+del does it. You know, the other thing that makes me
> > curious about it being a hardware glitch is that it does this with gdm,
> > I think (see previous thread: "GDM hates me"). Well, the last time it
> > locked up was while running emerge --sync, which I'm running now with no
> > apparent problems... yet.
> >
> > -Peter
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.4 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFGSZx4GK2zHPGK1rsRCkv3AJ9fD8TWd0qzNOl36xtNhjHtWWSRYwCfdIOg
> q6n4iUvbxwNAYxOddALMUxQ=
> =mH8T
> -----END PGP SIGNATURE-----
> --
> gentoo-amd64@gentoo.org mailing list
>
>
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Gentoo crashing?

[Duncan]

"Peter Davoust" <worldgnat@gmail.com> posted
7c08b4dd0705150848v7736297p2499585046f2772d@mail.gmail.com, excerpted
below, on  Tue, 15 May 2007 11:48:41 -0400:

> I just clicked the "<<plain text" button and the setting has held for
> this entire thread. Come to think of it, I may have actually converted
> it back to Rich Text a few weeks back.

Thanks. (^_^)

-- 
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-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Gentoo crashing?

[Duncan]

Isidore Ducasse <ducasse.isidore@gmail.com> posted
20070515145141.512b9186@Bazaar, excerpted below, on  Tue, 15 May 2007
14:51:41 +0200:

> It seems my messages get transformed to have both text/plain and
> text/html bodies. Is this what you receive from me? Does it bother?

This one was just text.  Thanks. (^_^)

-- 
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-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Gentoo crashing?

[Peter Hoff]

[-- Attachment #1: Type: text/plain, Size: 1483 bytes --]

----- Original Message ----
From: Isidore Ducasse ducasse.isidore@gmail.com


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?



For the most part RAM sticks are identical. I have seen some issues in the past where this was not the case, but this was back in the bad old days of SIMMs. The issue I saw was where a manufacturer streamlined their design and were able to start manufacturing  sticks with 4 layer circuit boards instead of the usual 6 layers. The slightly thinner board result in occasional problems with flakey connections in RAM slots that were designed for the thicker ones.

I've also heard of some long term corrosion problems in RAM slots when the slot pins were of a different metal than the pins on the stick, but I've never actually seen it myself.

Really, the main problems you'll run into are due to different quality levels from different manufacturers. As someone else in this thread mentioned, not all manufacturers can be reliedd upon to give accurate representations of the timing settings their RAM can handle.

[-- Attachment #2: Type: text/html, Size: 2015 bytes --]

Re: [gentoo-amd64] Gentoo crashing?

[Barry.SCHWARTZ]

[-- Attachment #1: Type: text/plain, Size: 787 bytes --]

Peter Davoust <worldgnat@gmail.com> wrote:
>  Other than that I'm clueless.

Have you tried vanilla-sources? After all, anything in gentoo-sources
that isn't in vanilla-sources is by definition unaccepted code. :)

Also with the nvidia, it's easier to keep the nv driver running than
the nvidia driver, as long as you remove anything to do with the
nvidia driver; plus with nv you don't need to patch a big,
suspicious-looking black box into your kernel, the way you do with the
nvidia driver.

-- 
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/20051219-2.html)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] Re: Gentoo crashing?

[Bob Sanders]

Peter Hoff, mused, then expounded:
> ----- Original Message ----
> From: Isidore Ducasse ducasse.isidore@gmail.com
> 
> 
> Very interesting post!
> Could you explain what "mobo" means?

   mobo == motherboard

> 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?
>

I've seen a case, my own laptop - IBM X31, where it was impossible to re-install winXP or to compile
certain programs on Gentoo because the DDR DIMMs were unmatched.  Either ran fine by itself, but
the memory controller didn't work properly with DIMMs of different capacities.  And there were
no bit errors reported by memtest86.

Replaced both with a matched pair, and no more problems.
 
> 
> 
> 
> I've also heard of some long term corrosion problems in RAM slots when the slot pins were of a different metal than the pins on the stick, but I've never actually seen it myself.
>

This is repaired by simply removing and re-installing the DIMMs.  The process will break up the
oxidation on the connector pins and on the fingers of the DIMMs via the wiping action.

Bob 
-  
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Gentoo crashing?

[Duncan]

"Boyd Stephen Smith Jr." <bss03@volumehost.net> posted
200705190231.33752.bss03@volumehost.net, excerpted below, on  Sat, 19 May
2007 02:31:27 -0500:

> On Friday 18 May 2007 23:45:42 Peter Davoust wrote:
>> Actually, I wanted to ask a some what unrelated question as well: I've
>> heard it's possible to update kernel without rebooting, and while I'm
>> not sure of the advisability, I'm getting things to work here and I'd
>> like to not have to reboot my computer so many times. Besides, it just
>> sounds cool. Could someone tell me how to do it?
> 
> I've done it before via kexec, but I don't remember exactly how.  Google
> for: linux kexec how-to
> and you should get some useful links.

I'm going to go out on a limb here (but not so far, I think), and say 
most folks shouldn't be worried about kexec at this point.  There are a 
lot of unpredictables in terms of hardware state once the new kernel is 
started, many of which the kernel isn't yet expecting (it expects to 
start with everything in a known or just initialized state) or prepared 
to deal with, and most folks won't be prepared to deal with the potential 
crashes and even possible data loss, if things don't go quite right.

kexec is coming along (just with kernel 2.6.22-rc1 a critical piece was 
placed for x86_64/amd64 users, an x86_64 kernel can now be compiled as 
relocatable, according to the changelog), but I don't believe any 
involved kernel hacker would tell you it's ready for ordinary prime-time 
use, yet.  I'd say another six months to a year, anyway, maybe more if 
development focuses on other areas more and less on kexec.

Without kexec, in general, no, one has to reboot to make use of a new 
kernel or its features.  However, it IS possible to build modules and 
insert them into a running kernel.  Of course, that works best if it's 
modules for the same kernel and using the same CFLAGS. I'm sufficiently 
cautious not to even consider otherwise, but it does sometimes work (and 
in fact, with proprietary closed source modules, /must/ work, to /some/ 
extent, but I don't run those, either).  So yes, even without kexec, if 
all you are doing is building additional modules, particularly if it's 
the same kernel sources and cflags, you should be able to load those 
modules in the running kernel without damage or indeed undue risk.  The 
kernel is in fact designed for such module loading.  (The big risk is in 
unloading modules, particularly in /force/ unloading, because it can 
create serious race and unknown state conditions.  There's still an 
option for forced unload, however, with the caveat that it's discouraged, 
and only for use where the alternative would be reboot anyway, and the 
risk of kernel instability is considered less of a loss than the reboot 
might be.)

-- 
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-amd64@gentoo.org mailing list