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

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

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

[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: 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 --]

[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] 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

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

[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] 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

[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] 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 --]

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?

[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

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] 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] 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] Gentoo crashing?

[Peter Hoff]

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

I can't even get 2.6.21 to compile. I was getting unhappy about that, but perhaps I've been looking at it the wrong way?


----- Original Message ----
From: Dustin C. Hatch <admiralnemo@dchweb.com>
To: gentoo-amd64@lists.gentoo.org
Sent: Sunday, May 13, 2007 10:25:46 PM
Subject: Re: [gentoo-amd64] Gentoo crashing?




  
  

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: 2366 bytes --]

Re: [gentoo-amd64] Gentoo crashing?

[Peter Davoust]

Cool, so it isn't hardware (hopefully). How to I downgrade my kernel?

-Peter

On 5/15/07, Peter Hoff <petehoff@pacbell.net> wrote:
>
> I can't even get 2.6.21 to compile. I was getting unhappy about that, but
> perhaps I've been looking at it the wrong way?
>
>
> ----- Original Message ----
> From: Dustin C. Hatch <admiralnemo@dchweb.com>
> To: gentoo-amd64@lists.gentoo.org
> Sent: Sunday, May 13, 2007 10:25:46 PM
> Subject: Re: [gentoo-amd64] Gentoo crashing?
>
>  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
>
>
>
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Gentoo crashing?

[Bernhard Auzinger]

Am Dienstag 15 Mai 2007 schrieb Peter Hoff:
> I can't even get 2.6.21 to compile. I was getting unhappy about that, but
> perhaps I've been looking at it the wrong way?

My suggestion is to boot without X, without loading the graphic driver module 
(nvidia, ati) and without any other driver that is not needed for basic 
functionality (dvb, bttv, alsa, usb . . .). Maybe you should try not to load 
the network driver too. If it is not the heat, you could have some interrupt 
issues. A while ago, with my old P3, I had a similar problem. My problem was 
that my network-controller and my soundcard didn't like to share an interrupt 
together :) and the system hung up very often. For me it was unreproduceable, 
what caused my problems, but finally I got behind it by testing each 
component step by step.

So don't become desperate. Try everything you have in your mind. Sometimes the 
least promising possibility solves the problem

rgds
Bernhard
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Gentoo crashing?

[Peter Hoff]

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

Just because Memtest86 went 30% without failure does not mean your RAM is 30% OK. It should run for at least a full loop, and I typically run it for at least 2 loops (though only once have I seen a system suddenly start spewing errors it didn't have during the first loop, and I've run it on a lot of systems). It does take a while, so you probably don't want to sit around watching it. I usually let it run overnight while I sleep.


----- Original Message ----
From: Peter Davoust <worldgnat@gmail.com>
To: gentoo-amd64@lists.gentoo.org
Sent: Monday, May 14, 2007 2:08:42 PM
Subject: Re: [gentoo-amd64] Gentoo crashing?

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: 4127 bytes --]

Re: [gentoo-amd64] Gentoo crashing?

[Peter Hoff]

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



----- Original Message ----
From: Peter Davoust <worldgnat@gmail.com>
To: gentoo-amd64@lists.gentoo.org
Sent: Monday, May 14, 2007 7:11:20 PM
Subject: Re: [gentoo-amd64] Gentoo crashing?

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




You're being silly. Software torture tests are not going to kill your hardware. Just run them and see what you get. Memtest will give you the address where the error occured, and I've always been able to determine which stick was bad from that, using a little deductive reasoning (I usually verify by testing the sticks alone, but so far I've not been wrong).

As for voiding your warranty, memory and the hard drive are typically considered user-servicable parts. In fact, most of the time if either of those are the problem they'll just send you the parts and you'll have to replace them yourself anyway.

More on torturing hardware: really, the only component that's at all vulnerable to this is the hard drive, simply because it's a mechanical device, but it will take an absurdly long time to do any actual damage. I used to test hard drives for video servers (think Tivo, but starting at $100k). We tried a wide variety of drive testing suites, but it turned out none of them ran the drives harder than our normal application. A surprising number of the oldest version of our product are still running, on the original drives, after over 10 years, in situations that are very demanding (like serving multiple channels for DirecTV). So, really, stop being so paranoid about software torture tests. It is a complete myth that you can ruin your hardware by running them.







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

Re: [gentoo-amd64] Gentoo crashing?

[Peter Davoust]

Now wait a minute, not everyone has $100k to spend on a brand new
laptop. I'm a student, and I have a single computer to last me through
two years of highschool and and at least a few years of college, and
there's no way I'm going to screw up my computer without some
insurance, ok? Before I run anything on this machine, I'm going to
make sure that I'm still under warrantee, whether the parts are user
servicable or not. Now if you call that being silly, then that's your
choice, but it's my choice if I want to be cautious, even overly so.

On that note, I did buck up and run memtest86+ from a Ubuntu livecd,
and after several loops (about 1h 30 min of straight testing) I didn't
get a single error. It was on Test #6 when I stopped, so I think the
memory's chill. Besides, as I said before, when I run anything GUI
(enlightement, right now), it's fine. I just have to jump in and out
of terminal really quickly. The fact that it likes to crash after
starting x server twice makes me think I might have a few damaged
portions on my harddrive. Does that sound about right? Of course, that
sounds like it could be a kernel issue too. If I can figure out how to
"downgrade" my kernel, maybe that will solve it.

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.

-Peter

On 5/15/07, Peter Hoff <petehoff@pacbell.net> wrote:
>
>
>
> ----- Original Message ----
> From: Peter Davoust <worldgnat@gmail.com>
> To: gentoo-amd64@lists.gentoo.org
> Sent: Monday, May 14, 2007 7:11:20 PM
> Subject: Re: [gentoo-amd64] Gentoo crashing?
>
> 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
>
>
>
> You're being silly. Software torture tests are not going to kill your
> hardware. Just run them and see what you get. Memtest will give you the
> address where the error occured, and I've always been able to determine
> which stick was bad from that, using a little deductive reasoning (I usually
> verify by testing the sticks alone, but so far I've not been wrong).
>
> As for voiding your warranty, memory and the hard drive are typically
> considered user-servicable parts. In fact, most of the time if either of
> those are the problem they'll just send you the parts and you'll have to
> replace them yourself anyway.
>
> More on torturing hardware: really, the only component that's at all
> vulnerable to this is the hard drive, simply because it's a mechanical
> device, but it will take an absurdly long time to do any actual damage. I
> used to test hard drives for video servers (think Tivo, but starting at
> $100k). We tried a wide variety of drive testing suites, but it turned out
> none of them ran the drives harder than our normal application. A surprising
> number of the oldest version of our product are still running, on the
> original drives, after over 10 years, in situations that are very demanding
> (like serving multiple channels for DirecTV). So, really, stop being so
> paranoid about software torture tests. It is a complete myth that you can
> ruin your hardware by running them.
>
>
>
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Gentoo crashing?

[Bob Sanders]

Peter Davoust, mused, then expounded:
> Now if you call that being silly, then that's your
> choice, but it's my choice if I want to be cautious, even overly so.
>

Computers are routinely tested at the design stage to run full load 
from a temperature range of 0F to 120F.  If you're concerned about heat,
insure there is at least 1" of air space between the bottom of the
case and the surface it's on - prop it up.  It'll be fine.
 
> On that note, I did buck up and run memtest86+ from a Ubuntu livecd,
> and after several loops (about 1h 30 min of straight testing) I didn't
> get a single error. It was on Test #6 when I stopped, so I think the
> memory's chill. 

Memtest will only find bit errors.  It's not able to test much other
than that.  It's pretty poor at finding memory problems that exist at
the bonderies of the dimm.  The easist way to do that is, if it's
possible on your laptop, is to swap the dimms.  If the problem moves
or occurs much, much sooner, then it's a dimm issue.  If it doesn't
change, then run only one dimm at a time and try again.  That would
eliminate the memory as the cause of the problem.

> Besides, as I said before, when I run anything GUI
> (enlightement, right now), it's fine. I just have to jump in and out
> of terminal really quickly. The fact that it likes to crash after
> starting x server twice makes me think I might have a few damaged
> portions on my harddrive. Does that sound about right? Of course, that
> sounds like it could be a kernel issue too. If I can figure out how to
> "downgrade" my kernel, maybe that will solve it.
>

No it sounds like a flakey Gfx driver.  Try running a later or earlier
driver, if it's an nvidia or ati.  If it's not then you'll need to try
a different version of Xorg.

And if it is a third party driver, try running just the 2D Xorg variant
and see if the issue still occurs.

Also, it would help us a bit if the specs of your laptop - chipset, etc.
were given. 

And FWIW - our corp spam filter thinks your email may be spam.  So there
still seems to be a formatting issue.

Thanks,

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

Re: [gentoo-amd64] Gentoo crashing?

[Antoine Martin]

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

>> Besides, as I said before, when I run anything GUI
>> (enlightement, right now), it's fine. I just have to jump in and out
>> of terminal really quickly. The fact that it likes to crash after
>> starting x server twice makes me think I might have a few damaged
>> portions on my harddrive. Does that sound about right? Of course, that
>> sounds like it could be a kernel issue too. If I can figure out how to
>> "downgrade" my kernel, maybe that will solve it.
>>
> 
> No it sounds like a flakey Gfx driver.
I second that.

>  Try running a later or earlier
> driver, if it's an nvidia or ati.  If it's not then you'll need to try
> a different version of Xorg.
IIRC, there are issues with nvidia and framebuffer modes.
Try booting with vga=normal on the kernel command line.

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

iD8DBQFGSgLgGK2zHPGK1rsRCvvbAJ9uXgyr978B5jDPDNeMq4V+yK8guQCePT0b
EnYVOaU1WkS5VIDjng+OJXc=
=yv5/
-----END PGP SIGNATURE-----
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Gentoo crashing?

[Isidore Ducasse]

le Tue, 15 May 2007 19:58:40 +0100
Antoine Martin <antoine@nagafix.co.uk> a écrit:

> >  Try running a later or earlier
> > driver, if it's an nvidia or ati.  If it's not then you'll need to try
> > a different version of Xorg.
> IIRC, there are issues with nvidia and framebuffer modes.
> Try booting with vga=normal on the kernel command line.
> 
> Antoine

Yes, I use nvidia-drivers and udev keeps loading the nvidiafb LKM, which doesn't work since we've been presented. I even tried to update udev rules, moving the "nvidia*" rule to "nvidia", so that it would only load the private firmware, but in vain.

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

Re: [gentoo-amd64] Gentoo crashing?

[Hemmann, Volker Armin]

On Mittwoch, 16. Mai 2007, Isidore Ducasse wrote:
> le Tue, 15 May 2007 19:58:40 +0100

> >
> > IIRC, there are issues with nvidia and framebuffer modes.
> > Try booting with vga=normal on the kernel command line.

>
> Yes, I use nvidia-drivers and udev keeps loading the nvidiafb LKM, 

why are you building the nvidiafb crap in the first place?


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Gentoo crashing?

[Isidore Ducasse]

le Wed, 16 May 2007 01:03:42 +0200
"Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> a écrit:
> >
> > Yes, I use nvidia-drivers and udev keeps loading the nvidiafb LKM, 
> 
> why are you building the nvidiafb crap in the first place?
> 
> 

As far as I remember, I used the default genkernel. Now in fact, and though stated differently on NVIDIA_HOWTO , nvidia LKM works fine here even with nvidiafb loaded. It's just that I have no framebuffer functionality.


To stick to the subject: (Why was his gentoo crashing all of a sudden?) this "Kernel hacking" option seems to be enabled by default by genkernel. It caused my brother's dual core machine to turn into a black screen under X:

 Linux Kernel v2.6.20-gentoo-r8 Configuration
 ──────────────────────────────────────────────────────────────────────────────
  ┌────────────────────────── Detect Soft Lockups
──────────────────────────┐ │
CONFIG_DETECT_SOFTLOCKUP:
Say Y here to enable the kernel to detect "soft lockups",
which are bugs that cause the kernel to loop in kernel
mode for more than 10 seconds, without giving other tasks a
chance to run.                                                          │

When a soft-lockup is detected, the kernel will print the current stack trace (which you should report), but the system will stay locked up. This feature has negligible overhead.


(Note that "hard lockups" are separate type of bugs that can be detected via the NMI-watchdog, on platforms that support it.)
--
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Gentoo crashing?

[Peter Davoust]

I'll try that. Actually, I haven't had any problems with locking up
recently. I've got kde running and I can emerge all I want. Thank you
all for the help.

-Peter

On 5/19/07, Isidore Ducasse <ducasse.isidore@gmail.com> wrote:
> le Wed, 16 May 2007 01:03:42 +0200
> "Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> a écrit:
> > >
> > > Yes, I use nvidia-drivers and udev keeps loading the nvidiafb LKM,
> >
> > why are you building the nvidiafb crap in the first place?
> >
> >
>
> As far as I remember, I used the default genkernel. Now in fact, and though stated differently on NVIDIA_HOWTO , nvidia LKM works fine here even with nvidiafb loaded. It's just that I have no framebuffer functionality.
>
>
> To stick to the subject: (Why was his gentoo crashing all of a sudden?) this "Kernel hacking" option seems to be enabled by default by genkernel. It caused my brother's dual core machine to turn into a black screen under X:
>
>  Linux Kernel v2.6.20-gentoo-r8 Configuration
>  ──────────────────────────────────────────────────────────────────────────────
>   ┌────────────────────────── Detect Soft Lockups
> ──────────────────────────┐ │
> CONFIG_DETECT_SOFTLOCKUP:
> Say Y here to enable the kernel to detect "soft lockups",
> which are bugs that cause the kernel to loop in kernel
> mode for more than 10 seconds, without giving other tasks a
> chance to run.                                                          │
>
> When a soft-lockup is detected, the kernel will print the current stack trace (which you should report), but the system will stay locked up. This feature has negligible overhead.
>
>
> (Note that "hard lockups" are separate type of bugs that can be detected via the NMI-watchdog, on platforms that support it.)
> --
> gentoo-amd64@gentoo.org mailing list
>
>

Re: [gentoo-amd64] Gentoo crashing?

[david]

Isidore Ducasse wrote:
> le Tue, 15 May 2007 19:58:40 +0100
> Antoine Martin <antoine@nagafix.co.uk> a écrit:
>
>   
>>>  Try running a later or earlier
>>> driver, if it's an nvidia or ati.  If it's not then you'll need to try
>>> a different version of Xorg.
>>>       
>> IIRC, there are issues with nvidia and framebuffer modes.
>> Try booting with vga=normal on the kernel command line.
>>
>> Antoine
>>     
>
> Yes, I use nvidia-drivers and udev keeps loading the nvidiafb LKM, which doesn't work since we've been presented. I even tried to update udev rules, moving the "nvidia*" rule to "nvidia", so that it would only load the private firmware, but in vain.
>
> Florent
>   
>From the guide;

*Important: * For x86 and AMD64 processors, the in-kernel driver
conflicts with the binary driver provided by nVidia. If you will be
compiling your kernel for these CPUs, you must completely remove support
for the in-kernel driver as shown:

http://www.gentoo.org/doc/en/nvidia-guide.xml

-- 
Powered by Gentoo/Linux

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Gentoo crashing?

[Peter Davoust]

Ok, so I just did a fresh install of 2007.0. I used the same method as
before (networkless install and then configured sources from
kernel.org), to get my system running again. It crashes far less
often, but still has a little trouble with compiling linux sources
(that was while using the livecd kernel). However, I'm writing you
from the machine in question, so that's a good sign. I'll mess with it
and emerge some stuff, try 2.6.20 vanilla-sources and let you know how
it goes. I'm also going to try the Linux drivers from the nvidia
website. While I trust Gentoo, I'm sure NVidia is more up to date. I
don't think I enabled the in-kernel nvidia drivers, so I should be
fine.

-Peter

On 5/15/07, david <abbottdavid@bellsouth.net> wrote:
> Isidore Ducasse wrote:
> > le Tue, 15 May 2007 19:58:40 +0100
> > Antoine Martin <antoine@nagafix.co.uk> a écrit:
> >
> >
> >>>  Try running a later or earlier
> >>> driver, if it's an nvidia or ati.  If it's not then you'll need to try
> >>> a different version of Xorg.
> >>>
> >> IIRC, there are issues with nvidia and framebuffer modes.
> >> Try booting with vga=normal on the kernel command line.
> >>
> >> Antoine
> >>
> >
> > Yes, I use nvidia-drivers and udev keeps loading the nvidiafb LKM, which doesn't work since we've been presented. I even tried to update udev rules, moving the "nvidia*" rule to "nvidia", so that it would only load the private firmware, but in vain.
> >
> > Florent
> >
> From the guide;
>
> *Important: * For x86 and AMD64 processors, the in-kernel driver
> conflicts with the binary driver provided by nVidia. If you will be
> compiling your kernel for these CPUs, you must completely remove support
> for the in-kernel driver as shown:
>
> http://www.gentoo.org/doc/en/nvidia-guide.xml
>
> --
> Powered by Gentoo/Linux
>
> --
> gentoo-amd64@gentoo.org mailing list
>
>

Re: [gentoo-amd64] Gentoo crashing?

[Peter Davoust]

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?

-Peter

On 5/19/07, Peter Davoust <worldgnat@gmail.com> wrote:
> Ok, so I just did a fresh install of 2007.0. I used the same method as
> before (networkless install and then configured sources from
> kernel.org), to get my system running again. It crashes far less
> often, but still has a little trouble with compiling linux sources
> (that was while using the livecd kernel). However, I'm writing you
> from the machine in question, so that's a good sign. I'll mess with it
> and emerge some stuff, try 2.6.20 vanilla-sources and let you know how
> it goes. I'm also going to try the Linux drivers from the nvidia
> website. While I trust Gentoo, I'm sure NVidia is more up to date. I
> don't think I enabled the in-kernel nvidia drivers, so I should be
> fine.
>
> -Peter
>
> On 5/15/07, david <abbottdavid@bellsouth.net> wrote:
> > Isidore Ducasse wrote:
> > > le Tue, 15 May 2007 19:58:40 +0100
> > > Antoine Martin <antoine@nagafix.co.uk> a écrit:
> > >
> > >
> > >>>  Try running a later or earlier
> > >>> driver, if it's an nvidia or ati.  If it's not then you'll need to try
> > >>> a different version of Xorg.
> > >>>
> > >> IIRC, there are issues with nvidia and framebuffer modes.
> > >> Try booting with vga=normal on the kernel command line.
> > >>
> > >> Antoine
> > >>
> > >
> > > Yes, I use nvidia-drivers and udev keeps loading the nvidiafb LKM, which doesn't work since we've been presented. I even tried to update udev rules, moving the "nvidia*" rule to "nvidia", so that it would only load the private firmware, but in vain.
> > >
> > > Florent
> > >
> > From the guide;
> >
> > *Important: * For x86 and AMD64 processors, the in-kernel driver
> > conflicts with the binary driver provided by nVidia. If you will be
> > compiling your kernel for these CPUs, you must completely remove support
> > for the in-kernel driver as shown:
> >
> > http://www.gentoo.org/doc/en/nvidia-guide.xml
> >
> > --
> > Powered by Gentoo/Linux
> >
> > --
> > gentoo-amd64@gentoo.org mailing list
> >
> >
>

Re: [gentoo-amd64] Gentoo crashing?

[Boyd Stephen Smith Jr.]

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

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 really should try and convince my computer to kexec again.  It takes forever 
to initialize my hw RAID card and the BIOS felt slow even before that card 
was added.

There's also the older and more flakey method of modifying a running kernel by 
writing to /proc/kcore, but I've not actually seen code to load a new kernel 
that way, only code to hide a (GPL'd) rootkit in a running kerenl.

-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss03@volumehost.net                      ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.org/                      \_/     

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

Re: [gentoo-amd64] Gentoo crashing?

[Hemmann, Volker Armin]

On Samstag, 19. Mai 2007, Peter Davoust wrote:
>I'm also going to try the Linux drivers from the nvidia
> website. While I trust Gentoo, I'm sure NVidia is more up to date. I
> don't think I enabled the in-kernel nvidia drivers, so I should be
> fine.

YOU ARE WRONG!

DO NOT DO THIS!

The latest nvidia-drivers in portage are also the latest stable drivers from 
nvidia PLUS some patches that are needed! If you want to play with the beta 
drivers, get the ebuild from the gentoo bugzilla.

NEVER INSTALL THE NVIDIA-DRIVERS WITHOUT USING THE EBUILD!

NEVER!

You will hurt yourself, believe me, been there, got hurt badly, had lots of 
trouble.

JUST SAY NO.

And about changing kernel without rebooting:

you have enough trouble at the moment without it. It can only get worse.
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Gentoo crashing?

[Wil Reichert]

> Now wait a minute, not everyone has $100k to spend on a brand new
> laptop. I'm a student, and I have a single computer to last me through
> two years of highschool and and at least a few years of college, and
> there's no way I'm going to screw up my computer without some
> insurance, ok? Before I run anything on this machine, I'm going to
> make sure that I'm still under warrantee, whether the parts are user
> servicable or not. Now if you call that being silly, then that's your
> choice, but it's my choice if I want to be cautious, even overly so.
Keep in mind the programs mentioned are not supposed to break your
hardware but to discover if its already got problems.  Yes, they do
put stress on various components, but thats the entire point - a lot
of issues don't show themselves under 'normal' usage.

> On that note, I did buck up and run memtest86+ from a Ubuntu livecd,
> and after several loops (about 1h 30 min of straight testing) I didn't
> get a single error. It was on Test #6 when I stopped, so I think the
> memory's chill. Besides, as I said before, when I run anything GUI
> (enlightement, right now), it's fine. I just have to jump in and out
> of terminal really quickly. The fact that it likes to crash after
> starting x server twice makes me think I might have a few damaged
> portions on my harddrive. Does that sound about right? Of course, that
> sounds like it could be a kernel issue too. If I can figure out how to
> "downgrade" my kernel, maybe that will solve it.
Try 'badblocks' from a livecd.  Its got a read-only mode which will
not harm your existing data.  This is sounding more and more like a
kernel issue.  You haven't mentioned the specs on your laptop, but its
a recent core 2 model, you'll find its devices are poorly supported in
anything less that 2.6.19 / 2.6.20.

Wil

>
> 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.
>
> -Peter
>
> On 5/15/07, Peter Hoff <petehoff@pacbell.net> wrote:
> >
> >
> >
> > ----- Original Message ----
> > From: Peter Davoust <worldgnat@gmail.com>
> > To: gentoo-amd64@lists.gentoo.org
> > Sent: Monday, May 14, 2007 7:11:20 PM
> > Subject: Re: [gentoo-amd64] Gentoo crashing?
> >
> > 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
> >
> >
> >
> > You're being silly. Software torture tests are not going to kill your
> > hardware. Just run them and see what you get. Memtest will give you the
> > address where the error occured, and I've always been able to determine
> > which stick was bad from that, using a little deductive reasoning (I usually
> > verify by testing the sticks alone, but so far I've not been wrong).
> >
> > As for voiding your warranty, memory and the hard drive are typically
> > considered user-servicable parts. In fact, most of the time if either of
> > those are the problem they'll just send you the parts and you'll have to
> > replace them yourself anyway.
> >
> > More on torturing hardware: really, the only component that's at all
> > vulnerable to this is the hard drive, simply because it's a mechanical
> > device, but it will take an absurdly long time to do any actual damage. I
> > used to test hard drives for video servers (think Tivo, but starting at
> > $100k). We tried a wide variety of drive testing suites, but it turned out
> > none of them ran the drives harder than our normal application. A surprising
> > number of the oldest version of our product are still running, on the
> > original drives, after over 10 years, in situations that are very demanding
> > (like serving multiple channels for DirecTV). So, really, stop being so
> > paranoid about software torture tests. It is a complete myth that you can
> > ruin your hardware by running them.
> >
> >
> >
> --
> gentoo-amd64@gentoo.org mailing list
>
>
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Gentoo crashing?

[Peter Davoust]

Ok, so I may try a stress test if I get a chance, but I'd much rather
try an older kernel version first. As far as specs, Turion64 dual
core, nvidia GeForce go 6150, 2gb ram (of some kind, not sure, I know,
it's deplorable), 120 gb hard disk, other than that I'm not sure,
unless you're looking for asthetics, which I assume you aren't. Can
anyone tell me how to emerge an older kernel? I'm not that good with
portage, and I'm not sure how to emerge older versions. I think I knew
at one point, but that was a while ago. Thanks.

-Peter

On 5/15/07, Wil Reichert <wil.reichert@gmail.com> wrote:
> > Now wait a minute, not everyone has $100k to spend on a brand new
> > laptop. I'm a student, and I have a single computer to last me through
> > two years of highschool and and at least a few years of college, and
> > there's no way I'm going to screw up my computer without some
> > insurance, ok? Before I run anything on this machine, I'm going to
> > make sure that I'm still under warrantee, whether the parts are user
> > servicable or not. Now if you call that being silly, then that's your
> > choice, but it's my choice if I want to be cautious, even overly so.
> Keep in mind the programs mentioned are not supposed to break your
> hardware but to discover if its already got problems.  Yes, they do
> put stress on various components, but thats the entire point - a lot
> of issues don't show themselves under 'normal' usage.
>
> > On that note, I did buck up and run memtest86+ from a Ubuntu livecd,
> > and after several loops (about 1h 30 min of straight testing) I didn't
> > get a single error. It was on Test #6 when I stopped, so I think the
> > memory's chill. Besides, as I said before, when I run anything GUI
> > (enlightement, right now), it's fine. I just have to jump in and out
> > of terminal really quickly. The fact that it likes to crash after
> > starting x server twice makes me think I might have a few damaged
> > portions on my harddrive. Does that sound about right? Of course, that
> > sounds like it could be a kernel issue too. If I can figure out how to
> > "downgrade" my kernel, maybe that will solve it.
> Try 'badblocks' from a livecd.  Its got a read-only mode which will
> not harm your existing data.  This is sounding more and more like a
> kernel issue.  You haven't mentioned the specs on your laptop, but its
> a recent core 2 model, you'll find its devices are poorly supported in
> anything less that 2.6.19 / 2.6.20.
>
> Wil
>
> >
> > 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.
> >
> > -Peter
> >
> > On 5/15/07, Peter Hoff <petehoff@pacbell.net> wrote:
> > >
> > >
> > >
> > > ----- Original Message ----
> > > From: Peter Davoust <worldgnat@gmail.com>
> > > To: gentoo-amd64@lists.gentoo.org
> > > Sent: Monday, May 14, 2007 7:11:20 PM
> > > Subject: Re: [gentoo-amd64] Gentoo crashing?
> > >
> > > 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
> > >
> > >
> > >
> > > You're being silly. Software torture tests are not going to kill your
> > > hardware. Just run them and see what you get. Memtest will give you the
> > > address where the error occured, and I've always been able to determine
> > > which stick was bad from that, using a little deductive reasoning (I usually
> > > verify by testing the sticks alone, but so far I've not been wrong).
> > >
> > > As for voiding your warranty, memory and the hard drive are typically
> > > considered user-servicable parts. In fact, most of the time if either of
> > > those are the problem they'll just send you the parts and you'll have to
> > > replace them yourself anyway.
> > >
> > > More on torturing hardware: really, the only component that's at all
> > > vulnerable to this is the hard drive, simply because it's a mechanical
> > > device, but it will take an absurdly long time to do any actual damage. I
> > > used to test hard drives for video servers (think Tivo, but starting at
> > > $100k). We tried a wide variety of drive testing suites, but it turned out
> > > none of them ran the drives harder than our normal application. A surprising
> > > number of the oldest version of our product are still running, on the
> > > original drives, after over 10 years, in situations that are very demanding
> > > (like serving multiple channels for DirecTV). So, really, stop being so
> > > paranoid about software torture tests. It is a complete myth that you can
> > > ruin your hardware by running them.
> > >
> > >
> > >
> > --
> > gentoo-amd64@gentoo.org mailing list
> >
> >
> --
> gentoo-amd64@gentoo.org mailing list
>
>
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Gentoo crashing?

[Bob Sanders]

Peter Davoust, mused, then expounded:
> Ok, so I may try a stress test if I get a chance, but I'd much rather
> try an older kernel version first. As far as specs, Turion64 dual
> core, nvidia GeForce go 6150, 2gb ram (of some kind, not sure, I know,
> it's deplorable), 120 gb hard disk, other than that I'm not sure,
> unless you're looking for asthetics, which I assume you aren't. Can
> anyone tell me how to emerge an older kernel? I'm not that good with
> portage, and I'm not sure how to emerge older versions. I think I knew
> at one point, but that was a while ago. Thanks.
>

emerge -av =gentoo-sources-2.6.18-r7  (something like that)


But, as yu have an nvidia card, I suggest doing the following

vim /etc/portage/package.keywords
i
#
x11-drivers/nvidia-drivers ~amd64
<ESC>
:wq
emerge -uDNav nvidia-drivers

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

Re: [gentoo-amd64] Gentoo crashing?

[Peter Hoff]

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

Yes, thinking that running a software based test is going to damage your hardware is silly. Maybe 20 years ago that was possible, but on modern hardware the very idea is absurd. You really should run all of the tests recommended earlier in this thread.

I don't think you understand what I mean by a "loop" in Memtest. Unless you have run all of the tests at least once, you have not done a loop (there are 8, IIRC). The amount of time you ran it for is irrelevant, as that's totally system dependent. I've had systems with 32M take 3 hours to complete a loop, and I've had systems with 1G do it in less than 45 minutes. Processor type and speed, RAM type and speed, memory controller, system bus... all of these are factors in how long it takes to complete a Memtest loop. BTW, Memtest tells you how many loops it has completed, and it automatically starts over on the first test once it completes the last one.

As for not wanting to put your fingers on the hardware, that's justifiable, especially if you aren't prepared to protect your equipment from electrostatic discharge. But, warranty questions can't be answered here, you'd have to talk to the vendor you got it from. I'm just telling you what my experience has been. Dell, for example, really doesn't want to pay someone to swap parts for you, and will do everything they can to get you to do it yourself. If you're really that worried about it, though, you could take it to the local computer repair shop. Most of the good ones can handle Linux these days.

I am also a student, and I have never had $100k to spend on a system, I was just trying to give you an idea of the level of experience I have with hardware testing. Those are systems that I used to test and repair, not systems that I owned.


----- Original Message ----
From: Peter Davoust <worldgnat@gmail.com>
To: gentoo-amd64@lists.gentoo.org
Sent: Tuesday, May 15, 2007 8:48:41 AM
Subject: Re: [gentoo-amd64] Gentoo crashing?


Now wait a minute, not everyone has $100k to spend on a brand new
laptop. I'm a student, and I have a single computer to last me through
two years of highschool and and at least a few years of college, and
there's no way I'm going to screw up my computer without some
insurance, ok? Before I run anything on this machine, I'm going to
make sure that I'm still under warrantee, whether the parts are user
servicable or not. Now if you call that being silly, then that's your
choice, but it's my choice if I want to be cautious, even overly so.

On that note, I did buck up and run memtest86+ from a Ubuntu livecd,
and after several loops (about 1h 30 min of straight testing) I didn't
get a single error. It was on Test #6 when I stopped, so I think the
memory's chill. Besides, as I said before, when I run anything GUI
(enlightement, right now), it's fine. I just have to jump in and out
of terminal really quickly. The fact that it likes to crash after
starting x server twice makes me think I might have a few damaged
portions on my harddrive. Does that sound about right? Of course, that
sounds like it could be a kernel issue too. If I can figure out how to
"downgrade" my kernel, maybe that will solve it.

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.

-Peter

On 5/15/07, Peter Hoff <petehoff@pacbell.net> wrote:
>
>
>
> ----- Original Message ----
> From: Peter Davoust <worldgnat@gmail.com>
> To: gentoo-amd64@lists.gentoo.org
> Sent: Monday, May 14, 2007 7:11:20 PM
> Subject: Re: [gentoo-amd64] Gentoo crashing?
>
> 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
>
>
>
> You're being silly. Software torture tests are not going to kill your
> hardware. Just run them and see what you get. Memtest will give you the
> address where the error occured, and I've always been able to determine
> which stick was bad from that, using a little deductive reasoning (I usually
> verify by testing the sticks alone, but so far I've not been wrong).
>
> As for voiding your warranty, memory and the hard drive are typically
> considered user-servicable parts. In fact, most of the time if either of
> those are the problem they'll just send you the parts and you'll have to
> replace them yourself anyway.
>
> More on torturing hardware: really, the only component that's at all
> vulnerable to this is the hard drive, simply because it's a mechanical
> device, but it will take an absurdly long time to do any actual damage. I
> used to test hard drives for video servers (think Tivo, but starting at
> $100k). We tried a wide variety of drive testing suites, but it turned out
> none of them ran the drives harder than our normal application. A surprising
> number of the oldest version of our product are still running, on the
> original drives, after over 10 years, in situations that are very demanding
> (like serving multiple channels for DirecTV). So, really, stop being so
> paranoid about software torture tests. It is a complete myth that you can
> ruin your hardware by running them.
>
>
>
-- 
gentoo-amd64@gentoo.org mailing list

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