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

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

[Isidore Ducasse]

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

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

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

[gentoo-amd64] Re: Gentoo crashing?

[Duncan]

"Peter Davoust" <worldgnat@gmail.com> posted
7c08b4dd0705132304h5eccea49k22513343959aff52@mail.gmail.com, excerpted
below, on  Mon, 14 May 2007 02:04:30 -0400:

> I agree, it could be the heat, and that was the first thing that came to
> my mind, but Vista boots and runs for long periods of time with no
> issues. I'll check it out with the new kernel in the morning and see
> what it does.

Note that Gentoo tends to use hardware to its limits rather more than 
most OSs, MSWormOS and other Linux distributions alike.  Vista is so new, 
and /does/ stress at least the video hardware rather more (if aero is on, 
anyway), so I don't know if anyone can rightly say with it, but certainly 
with older MS platforms, it hasn't been uncommon at /all/ for Gentoo to 
cause problems where MS didn't, and even other Linux distributions didn't.

Part of the reason is that Gentoo tends to be compiled/optimized for the 
specific CPU it's running on, so it makes more efficient use of it, 
including use of functionality distributions (and MS) compiled for use on 
generic hardware simply don't use, plus simply the fact that when the CPU 
is busy, it's often getting more done in the same time, so it IS working 
harder and therefore stressing out the hardware more.

Anyway, just because another OS doesn't have problems on a computer 
doesn't mean Gentoo won't, and there are quite a number of folks on the 
forums and on the gentoo-user list that will tell you the same thing -- 
learned from hard experience.

Meanwhile, you mention specifically that one of the crashes was during a 
bz2 decompress.  As someone who has HAD memory issues in the past, I can 
DEFINITELY tell you that bz2 DOES often trigger memory errors, if 
ANYTHING will!  If the issues with BZ2 turn out to be common, CHECK THAT 
MEMORY, and check it again!  You mentioned you have 2 gigs.  Hopefully 
it's in the form of 2 or more sticks.  If so, you should be able to take 
part of it out and see if the problem persists.  Then test the other 
memory.  If the problem happens with one set but not the other, you have 
your problem.  Do note, however, that just because the problem continues 
to occur with either memory set doesn't necessarily mean it's not the 
memory, particularly if they are the same brand and size, purchased from 
the same place at the same time, so are likely in the same lot.

In my case, I had purchased generic memory that couldn't quite do its 
rated pc3200 (clock at 200 MHz x 2, since it was DDR).  I ran memtest and 
it passed with flying colors, because the memory worked fine, and memtest 
apparently doesn't really stress the memory timings, only testing the 
memory cells.  However, I was crashing in operation, sometimes just the 
app, sometimes the entire kernel would panic.  I turned on the kernel's 
MCE (machine check exception) reporting, and the memory was indeed the 
problem (google MCEs, there's an app available that you can run, feeding 
it the numbers, and it'll spit out the error in English), only wasn't 
quite sure whether it was the memory itself, or the mobo, causing 
perfectly good memory to generate errors upon data delivery because it 
couldn't reliably get the data to the CPU.

While I didn't have the necessary BIOS settings at the time, sometime 
later a BIOS update gave me additional memory settings, and I found that 
reducing the memory timings by a single notch, to 183 MHz (DDR doubled to 
366), effectively PC3000 memory, did the trick.  I was even able to tweak 
some of the individual wait-state settings to get back a bit of the 
performance I lost with the under-clocking.  The memory and entire 
machine was rock-stable at the 183 MHz PC3000 memory setting.

Later I upgraded from my then two 512 MB sticks to four 2 GB sticks, 8 
gigs memory total.  It was indeed the memory, not the board, as the new 
memory was just as stable at PC3200 as the old memory had been at the 
under-clocked PC3000 speed.

Anyway, the way bzip2 works is apparently extremely stressful on memory, 
as more than anything else, that would trigger the errors.  Compiles were 
frustrating too, but sometimes I could compile for quite some time 
without issues.  That's why I didn't think it was the CPUs even before I 
got the program to read the MCE numbers and tell me what they were.  They 
confirmed, it was memory related, the errors were on data as the CPU got 
it.  I just didn't know until I actually changed memory whether it was 
the mobo generating errors on the data in transit, or the memory itself.  
It turned out to be the memory.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] 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

[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

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?

[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

[gentoo-amd64] Re: Gentoo crashing?

[Duncan]

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

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

Thanks. (^_^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Gentoo crashing?

[Duncan]

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

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

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

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] 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] Re: Gentoo crashing?

[Peter Hoff]

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

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


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



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

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

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

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

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

[Bob Sanders]

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

   mobo == motherboard

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

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

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

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

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

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?

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

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

[gentoo-amd64] Re: Gentoo crashing?

[Duncan]

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

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

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

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

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

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

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?

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