Re: [gentoo-amd64] Incipient hardware failure?

Re: [gentoo-amd64] Incipient hardware failure?

[Kyle Liddell]

Here's just an idea:  You took out half your RAM, and then more recently
you tested the other half of the RAM that you left in the computer?  How
about you swap the RAM around and run memtest86+ or some such.  Perhaps
some of the RAM you took out of your system is bad, and you've got a
corrupted file or something lying around?  I had this happen on my old
server...had very occasional weird errors, but worked enough to compile
a stage1 install, then when the RAM completely died and things went nuts
I checked it with memtest86 and found that a stick was bad, dumped it,
but still had strange crashes every once in a while.  Completely
reinstalling (switching to debian actually) stopped the problems.

On Tue, 2005-07-05 at 10:48 +0100, Peter Humphrey wrote:
> Recently I've been seeing some strange events. First was random hangs of
> the whole system; this began as summer approached, and I fixed it by
> taking out half the RAM pro tem.
> 
> Then, in the last week or so I've been getting random compilation
> errors, so I ran memtest86 for a few hours with no errors. Today I got a


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Incipient hardware failure?

[Peter Humphrey]

Kyle Liddell wrote:

>Here's just an idea:  You took out half your RAM, and then more recently
>you tested the other half of the RAM that you left in the computer?  How
>about you swap the RAM around and run memtest86+ or some such.  Perhaps
>some of the RAM you took out of your system is bad, and you've got a
>corrupted file or something lying around?  I had this happen on my old
>server...had very occasional weird errors, but worked enough to compile
>a stage1 install, then when the RAM completely died and things went nuts
>I checked it with memtest86 and found that a stick was bad, dumped it,
>but still had strange crashes every once in a while.  Completely
>reinstalling (switching to debian actually) stopped the problems.
>

Interesting idea, that. The other day in my clumsiness I managed to
knock the spare sticks onto the tiled floor, so now I can't trust them
not to have PCB cracks. Secondly, I'm still getting segmentation faults
and that one bus error I mentioned, and in the meantime I've zapped the
root partition of my Xfce system and rebuilt it from scratch. So on
balance I think I won't pursue your suggestion, thanks all the same. I
did enjoy reading about your experience though.

-- 
Rgds
Peter Humphrey
Linux Counter 5290, Aug 93.

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Incipient hardware failure?

[Peter Humphrey]

I wrote:

>So on balance I think I won't pursue your suggestion, thanks all the same.
>
On the other hand, I've been playing with the script that Jani Averbach recommended in article 20050705155357.GA12533@jaa.iki.fi in this thread. First I tried it from the console, with no X, but it showed up no errors. Then I tried it from an x-term and got the same null result. Then I remembered I'd compiled swap out of the kernel and recompiled with it included. Still no errors.

I have my Linux partitions on the second disk, with a swap partition on the first to reduce latency. Running in /tmp in /dev/hdb9 (after expanding it to make space for all those copies of the kernel - 17 in my case with 2GB RAM) I watched the disk activity in gkrellm. I saw lots of activity on hdb but none at all on hda. so nothing is being swapped out. I'll try it soon with parallel instances to see if that will flush out some swap (while running in serial the disk activity is in flushing and re-reading file buffers), but in the meantime I get either segmentation or bus errors every time I compile anything. Well, actually, I kept trying to emerge --resume part-way through emerge -e world, which was failing on xorg-x11.

That makes me think again of your bad file left lying around, and wondering if my compiler is similarly affected, so I'm doing another emerge -e world at the moment to see if I can build a good tool chain. I fear it won't work, but it's got to 7 of 274 binutils so far.

Watch this space...

-- 

Rgds
Peter Humphrey
Linux Counter 5290, Aug 93.

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Incipient hardware failure?

[Duncan]

Peter Humphrey posted <42CEA2DC.70205@gotadsl.co.uk>, excerpted below,  on
Fri, 08 Jul 2005 16:59:24 +0100:

> I'll try it soon with parallel instances to see if that will flush out
> some swap (while running in serial the disk activity is in flushing and
> re-reading file buffers)

Note that there's a kernel command line parameter, something like mem=512M
or some such (from memory), that will manually tell the kernel how much
physical memory to use.  It was designed for systems that had more memory
than the kernel could detect, some years ago, but it also works well for
telling the kernel to use less memory than you actually have, if you want
to do some experimentation or something, perfect for forcing more swapping
activity than you'd normally get (zero swapping <g>), or for watching the
kernel OOM (out of memory) killer in action, if you don't have enough
memory including swap.

I'd know how to add it to my LILO kernel command line, but couldn't tell
you how to add it to GRUB, tho it shouldn't be difficult.

-- 
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Incipient hardware failure?

[Peter Humphrey]

Duncan wrote:

>Note that there's a kernel command line parameter, something like mem=512M
>  
>

So there is - I'd forgotten about that. Of course it would restrict the
amount of RAM that's being tested, but it may be worth trying; thanks
for the idea. Meanwhile I think I don't need to get swapping as I've got
two instances of the script operating in competition, one on each
physical disk. What with the BOINC clients, some routine emerging and
ordinary X user activity, if this doesn't break the system I don't know
what will!

-- 
Rgds
Peter Humphrey
Linux Counter 5290, Aug 93.

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Incipient hardware failure?

[Peter Humphrey]

Peter Humphrey wrote:

>I think I don't need to get swapping as I've got
>two instances of the script operating in competition, one on each
>physical disk. What with the BOINC clients, some routine emerging and
>ordinary X user activity, if this doesn't break the system I don't know
>what will!
>  
>

I should have added that my disks are showing 39 and 49 C in gkrellm.
Hda is being used for reading at present, while the 20 copies of the
code are being compared in parallel, whereas hdb is writing 20 copies in
parallel. 49 C makes me nervous  :-(

-- 
Rgds
Peter Humphrey
Linux Counter 5290, Aug 93.

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Re: Incipient hardware failure?

[Peter Humphrey]

Barry.SCHWARTZ@chemoelectric.org wrote:

>My point was that I had trouble with one of the Gentoo kernels, which
>I don't have with a non-Gentoo kernel, even though my non-Gentoo
>kernel is hardened.  Taking out the Gentoo-ness is what works for me,
>and I don't know that the same Gentoo-ness isn't in the gentoo-sources
>kernel.
>
Hmm. I see what you mean. Time to ponder...

-- 
Rgds
Peter Humphrey
Linux Counter 5290, Aug 93.

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] PCI Wireless Cards with 64bit support and drivers

[Terry Ellis]

Are there any?  After playing around with one and ndiswrapper this 
afternoon, I found the logs complaining about the windoze driver not being 
64bit.  Doh! :(

-----
Terry

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] PCI Wireless Cards with 64bit support and drivers

[Benny Pedersen]

On Wed, July 6, 2005 04:19, Terry Ellis wrote:
> Are there any?  After playing around with one and ndiswrapper this
> afternoon, I found the logs complaining about the windoze driver not being
>  64bit.  Doh! :(

i have succes with rt2500 on both p4 and opteron, i count my self lucky :-)

try one of the kernel drivers, it might work, so select a card that is
supported in the kernel or there exists userland drivers for, is
ndiswrapper realy needed ?

for rt2500 it ain't
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] PCI Wireless Cards with 64bit support and drivers

[Terry Ellis]

Ndiswrapper only works with drivers that are compatible with the kernel.
Therefore 32 bit drivers won't work with a 64-bit kernel.

My only mistake was getting a D-Link DLW-G510 without researching
it. :( 

If I can't find a good card, I'll be quite content with my functioning
ethernet port.

On Wed, 2005-07-06 at 05:40 +0200, Benny Pedersen wrote:
> On Wed, July 6, 2005 04:19, Terry Ellis wrote:
> > Are there any?  After playing around with one and ndiswrapper this
> > afternoon, I found the logs complaining about the windoze driver not being
> >  64bit.  Doh! :(
> 
> i have succes with rt2500 on both p4 and opteron, i count my self lucky :-)
> 
> try one of the kernel drivers, it might work, so select a card that is
> supported in the kernel or there exists userland drivers for, is
> ndiswrapper realy needed ?
> 
> for rt2500 it ain't

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] PCI Wireless Cards with 64bit support and drivers

[Peter Humphrey]

Terry Ellis wrote:

> Are there any?  After playing around with one and ndiswrapper this
> afternoon, I found the logs complaining about the windoze driver not
> being 64bit.  Doh! :(


Please don't hijack threads.

-- 
Rgds
Peter Humphrey
Linux Counter 5290, Aug 93.

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: PCI Wireless Cards with 64bit support and drivers

[Duncan]

Peter Humphrey posted <42CB869B.4050508@gotadsl.co.uk>, excerpted below, 
on Wed, 06 Jul 2005 08:22:03 +0100:

> Terry Ellis wrote:
> 
>> Are there any?  After playing around with one and ndiswrapper this
>> afternoon, I found the logs complaining about the windoze driver not
>> being 64bit.  Doh! :(
> 
> 
> Please don't hijack threads.

Agreed, but it might help if you mentioned exactly what that means, as
those doing it likely don't understand the issue, or they'd /not/ be doing
it...

Thread hijacking occurs when you hit reply to an existing thread, then
simply change the subject, and post a question entirely different than the
existing thread.  Because you hit reply, the post's references header will
still say it belongs in the old thread, and a decent client will thread it
as such, regardless of whether it has a different subject or not (altho
some clients make threading new subjects as new threads an option).

The better alternative is to create a NEW post (as opposed to a reply to
an existing post), starting a new thread, rather than hijacking an old one.

-- 
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] PCI Wireless Cards with 64bit support and drivers

[Terry Ellis]

How can I hijack my own thread. :(

Using pine I put gentoo-amd64 in the To:  and the subject in a blank 
Subject:

I must be missing a nuance somewhere.
-----
Terry

On Wed, 6 Jul 2005, Peter Humphrey wrote:

> Terry Ellis wrote:
>
>> Are there any?  After playing around with one and ndiswrapper this
>> afternoon, I found the logs complaining about the windoze driver not
>> being 64bit.  Doh! :(
>
>
> Please don't hijack threads.
>
> -- 
> Rgds
> Peter Humphrey
> Linux Counter 5290, Aug 93.
>
> -- 
> gentoo-amd64@gentoo.org mailing list
>
>
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: PCI Wireless Cards with 64bit support and drivers

[Duncan]

Terry Ellis posted <Pine.LNX.4.63.0507060844200.12301@wuzzerd.site>,
excerpted below,  on Wed, 06 Jul 2005 08:47:04 -0600:


> How can I hijack my own thread. :(
> 
> Using pine I put gentoo-amd64 in the To:  and the subject in a blank
> Subject:
> 
> I must be missing a nuance somewhere.

References:         <42CA5774.9060907@gotadsl.co.uk>
<42CA5930.7010508@tiscali.fr> <42CA667E.7060701@gotadsl.co.uk>
<pan.2005.07.05.13.21.52.33248@cox.net> <42CA9646.5060200@gotadsl.co.uk>
<42CA9F34.1030305@gotadsl.co.uk> <20050705155357.GA12533@jaa.iki.fi>

That's the references header from your original post, still listing the
upline of the thread (Incipient hardware failure?) your post was
supposedly a reply to.  Start with a /new/ post, not a reply to an
/existing/ post, if you want to start a new thread.  Otherwise, you hijack
the old one, because the references still point to it, and most decent
clients thread based on those references.

-- 
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Incipient hardware failure?

[Peter Humphrey]

Jani Averbach wrote:

>Another good way to test your memory is this little script:
>http://people.redhat.com/dledford/memtest.html
>  
>

Well, what a week! I ran two copies of this useful script, one on each
physical disk [1], while simultaneously running BOINC clients at nice=19
to fill in the CPU gaps. Sometimes I would try an emerge -e world
instead of one of the memtest scripts; I did that because I wasn't sure
I'd cleaned up the tool-chain since installing, so I emerged
linux-headers, glibc, binutils and gcc and then -e world.

I still kept getting segmentation faults, and other compilation errors
occurred in a few packages such as xorg-x11. Each segmentation fault
disappeared on running emerge --resume, as expected. Eventually I
remembered revdep-rebuild; running that cured the xorg-x11 problem (I
forget which library was rebuilt). The memtest script passed every time
- and the disk temperatures rose anything up to 20 C to over 50 C, which
illustrates the amount of extra work they were doing.

So I have a box that passes all tests except one: compiling programs.
Looks like I'll just have to wait for a harder fault to appear. Thanks
to all who've offered suggestions.

-- 
Rgds
Peter Humphrey
Linux Counter 5290, Aug 93.


[1] I did notice one minor wrinkle. The two copies started in series, so
one was always following the other with its requests for disk transfers,
at least at first, and so fell steadily behind. But by specifying, say,
40 passes, I saw that the two instances eventually drifted well out of
sync; I deduce therefore that the occurrence of interrupts will have
been random for all practical purposes. Secondly, I used a kernel
without swap because I thought it would make no difference; the disks
were being stressed equally anyway. Thirdly, I ran some tests from
xterms, and others from the console without X running.

-- 
gentoo-amd64@gentoo.org mailing list