Philip Lawatsch wrote:
>>Anyone have any suggestions on how to track this further? It seems
>>fairly clear what circumstances are causing it, but as for figuring out
>>what's at fault..
>
> It seems that mov'ing does not kill my machine while simply using movnti
> does.
Forget about what I
On Wed, 2005-04-06 at 12:59 +0200, Philip Lawatsch wrote:
> Robert Hancock wrote:
> > Alan Cox wrote:
> >
> >> On Sad, 2005-04-02 at 05:50, Robert Hancock wrote:
> >>
> >>> I'm wondering if one does a ton of these cache-bypassing stores
> >>> whether something gets hosed because of that. Not sure
Robert Hancock wrote:
> Alan Cox wrote:
>
>> On Sad, 2005-04-02 at 05:50, Robert Hancock wrote:
>>
>>> I'm wondering if one does a ton of these cache-bypassing stores
>>> whether something gets hosed because of that. Not sure what that
>>> could be though. I don't imagine the chipset is involved
Rafael J. Wysocki wrote:
>>Anyone have any suggestions on how to track this further? It seems
>>fairly clear what circumstances are causing it, but as for figuring out
>>what's at fault..
>
>
> Well, I would start from changing memory modules.
As I wrote earlier, I tried 4 different (but
[disregard my previous mail. I should have read the whole thread first]
On Saturday 02 April 2005 07:50, Robert Hancock wrote:
> As it turns out, the memset in my version of glibc x86_64 is not using
> such a string instruction though - it seems to be using two different
> sets of instructions
Hi,
On Wednesday, 6 of April 2005 06:05, Robert Hancock wrote:
> Alan Cox wrote:
> > On Sad, 2005-04-02 at 05:50, Robert Hancock wrote:
> >
> >>I'm wondering if one does a ton of these cache-bypassing stores whether
> >>something gets hosed because of that. Not sure what that could be
>
Hi,
On Wednesday, 6 of April 2005 06:05, Robert Hancock wrote:
Alan Cox wrote:
On Sad, 2005-04-02 at 05:50, Robert Hancock wrote:
I'm wondering if one does a ton of these cache-bypassing stores whether
something gets hosed because of that. Not sure what that could be
though. I don't
[disregard my previous mail. I should have read the whole thread first]
On Saturday 02 April 2005 07:50, Robert Hancock wrote:
As it turns out, the memset in my version of glibc x86_64 is not using
such a string instruction though - it seems to be using two different
sets of instructions
Rafael J. Wysocki wrote:
Anyone have any suggestions on how to track this further? It seems
fairly clear what circumstances are causing it, but as for figuring out
what's at fault..
Well, I would start from changing memory modules.
As I wrote earlier, I tried 4 different (but same brand)
Robert Hancock wrote:
Alan Cox wrote:
On Sad, 2005-04-02 at 05:50, Robert Hancock wrote:
I'm wondering if one does a ton of these cache-bypassing stores
whether something gets hosed because of that. Not sure what that
could be though. I don't imagine the chipset is involved with any of
On Wed, 2005-04-06 at 12:59 +0200, Philip Lawatsch wrote:
Robert Hancock wrote:
Alan Cox wrote:
On Sad, 2005-04-02 at 05:50, Robert Hancock wrote:
I'm wondering if one does a ton of these cache-bypassing stores
whether something gets hosed because of that. Not sure what that
could
Philip Lawatsch wrote:
Anyone have any suggestions on how to track this further? It seems
fairly clear what circumstances are causing it, but as for figuring out
what's at fault..
It seems that mov'ing does not kill my machine while simply using movnti
does.
Forget about what I just wrote,
Alan Cox wrote:
On Sad, 2005-04-02 at 05:50, Robert Hancock wrote:
I'm wondering if one does a ton of these cache-bypassing stores whether
something gets hosed because of that. Not sure what that could be
though. I don't imagine the chipset is involved with any of that on the
Athlon 64 - either
Alan Cox wrote:
On Sad, 2005-04-02 at 05:50, Robert Hancock wrote:
I'm wondering if one does a ton of these cache-bypassing stores whether
something gets hosed because of that. Not sure what that could be
though. I don't imagine the chipset is involved with any of that on the
Athlon 64 - either
On Sad, 2005-04-02 at 05:50, Robert Hancock wrote:
> I'm wondering if one does a ton of these cache-bypassing stores whether
> something gets hosed because of that. Not sure what that could be
> though. I don't imagine the chipset is involved with any of that on the
> Athlon 64 - either the CPU
On Sad, 2005-04-02 at 05:50, Robert Hancock wrote:
I'm wondering if one does a ton of these cache-bypassing stores whether
something gets hosed because of that. Not sure what that could be
though. I don't imagine the chipset is involved with any of that on the
Athlon 64 - either the CPU or
Paul Jackson wrote:
The x86_64 memset(), both in user space and the kernel, for whatever gcc
I have, and for a current kernel, uses the "repz stos" or "rep stosq"
prefixed instruction for the bulk of the copy. This combination is a
long running, interruptible Intel string instruction that loops
Robert wrote:
> It does run visibly slower
The x86_64 memset(), both in user space and the kernel, for whatever gcc
I have, and for a current kernel, uses the "repz stos" or "rep stosq"
prefixed instruction for the bulk of the copy. This combination is a
long running, interruptible Intel string
Ray Lee wrote:
On Thu, 2005-03-31 at 22:37 -0600, Robert Hancock wrote:
This is getting pretty ridiculous.. I've tried memory timings down to
the slowest possible, ran Memtest86 for 4 passes with no errors, and
it's been stable in Windows for a few months now. Still something is
blowing up in
Ray Lee wrote:
> On Thu, 2005-03-31 at 22:37 -0600, Robert Hancock wrote:
>
>>This is getting pretty ridiculous.. I've tried memory timings down to
>>the slowest possible, ran Memtest86 for 4 passes with no errors, and
>>it's been stable in Windows for a few months now. Still something is
On Thu, 2005-03-31 at 22:37 -0600, Robert Hancock wrote:
> This is getting pretty ridiculous.. I've tried memory timings down to
> the slowest possible, ran Memtest86 for 4 passes with no errors, and
> it's been stable in Windows for a few months now. Still something is
> blowing up in Linux
On Friday 01 April 2005 07:37, Robert Hancock wrote:
> Stelian Pop wrote:
> > Just a thought: does deactivating cpufreq change anything ?
> >
> > I haven't tested yet your program, but on my Asus K8NE-Deluxe very
> > strange things happen if cpufreq/powernow is activated *and*
> > the cpu
On Friday 01 April 2005 07:37, Robert Hancock wrote:
Stelian Pop wrote:
Just a thought: does deactivating cpufreq change anything ?
I haven't tested yet your program, but on my Asus K8NE-Deluxe very
strange things happen if cpufreq/powernow is activated *and*
the cpu frequency is
On Thu, 2005-03-31 at 22:37 -0600, Robert Hancock wrote:
This is getting pretty ridiculous.. I've tried memory timings down to
the slowest possible, ran Memtest86 for 4 passes with no errors, and
it's been stable in Windows for a few months now. Still something is
blowing up in Linux with
Ray Lee wrote:
On Thu, 2005-03-31 at 22:37 -0600, Robert Hancock wrote:
This is getting pretty ridiculous.. I've tried memory timings down to
the slowest possible, ran Memtest86 for 4 passes with no errors, and
it's been stable in Windows for a few months now. Still something is
blowing up
Ray Lee wrote:
On Thu, 2005-03-31 at 22:37 -0600, Robert Hancock wrote:
This is getting pretty ridiculous.. I've tried memory timings down to
the slowest possible, ran Memtest86 for 4 passes with no errors, and
it's been stable in Windows for a few months now. Still something is
blowing up in
Robert wrote:
It does run visibly slower
The x86_64 memset(), both in user space and the kernel, for whatever gcc
I have, and for a current kernel, uses the repz stos or rep stosq
prefixed instruction for the bulk of the copy. This combination is a
long running, interruptible Intel string
Paul Jackson wrote:
The x86_64 memset(), both in user space and the kernel, for whatever gcc
I have, and for a current kernel, uses the repz stos or rep stosq
prefixed instruction for the bulk of the copy. This combination is a
long running, interruptible Intel string instruction that loops on
Stelian Pop wrote:
Just a thought: does deactivating cpufreq change anything ?
I haven't tested yet your program, but on my Asus K8NE-Deluxe very
strange things happen if cpufreq/powernow is activated *and*
the cpu frequency is changed...
Didn't change anything for me, I tried deactivating
Philip Lawatsch wrote:
I've now tried the most conservative settings available. The 32 bit
kernel now hangs after about 15 Iterations (compared to about 16000
before) but the 64 bit kernel still hangs after about 5000.
I'm still seeing this on my system as well, using the most conservative
> your memory timings are out of spec.
I don't know what spec applies here, don't really care.
But when I backed off my Memory Timing from 1T to 2T,
my box became stable running this memset() test.
So I am a happy camper, grateful that someone posted
this nice test, and agree with you that it
On Thu, Mar 31, 2005 at 12:04:59AM +0200, Philip Lawatsch wrote:
> I do have a very strange problem:
>
> If I memset a ~1meg buffer some thousand times (in the userspace) it
> will hardlock my machine.
>
> I've been using 2.6.12-rc1 and also a lot of other kernels (2.6.9,
> 2.6.11). I've tried
Paul Jackson writes:
> Yup - kills my x86_64 too. I can't stay up for half a minute.
...
> My mainboard is an MSI K8N Neo2 Platinum.
I've tested both versions of the test program on two Athlon64 boxes,
and neither has had any problems with them.
My two machines are both VIA K8T800-based (a
Your problem is almost certainly in the hardware area (cpu, bios,
memory, power, northbridge, motherboard, cooling or thereabouts).
> Imo memtest86 should not hang onless something screws up [its] memory area
There is nothing else running when memtest runs. You cannot assume
that your hardware
Paul Jackson wrote:
> Denis wrote:
>
>>This reminds me on VIA northbridge problem when BIOS enabled
>>a feature which was experimental and turned out to be buggy.
>
>
> You were close!
>
> I changed my Memory Timing from 1T to 2T, and now it is as solid as a
> rock. It has been up 7 minutes
Denis wrote:
> This reminds me on VIA northbridge problem when BIOS enabled
> a feature which was experimental and turned out to be buggy.
You were close!
I changed my Memory Timing from 1T to 2T, and now it is as solid as a
rock. It has been up 7 minutes as I type this, without a hiccup.
Denis wrote:
This reminds me on VIA northbridge problem when BIOS enabled
a feature which was experimental and turned out to be buggy.
You were close!
I changed my Memory Timing from 1T to 2T, and now it is as solid as a
rock. It has been up 7 minutes as I type this, without a hiccup.
Notice
Paul Jackson wrote:
Denis wrote:
This reminds me on VIA northbridge problem when BIOS enabled
a feature which was experimental and turned out to be buggy.
You were close!
I changed my Memory Timing from 1T to 2T, and now it is as solid as a
rock. It has been up 7 minutes as I type
Your problem is almost certainly in the hardware area (cpu, bios,
memory, power, northbridge, motherboard, cooling or thereabouts).
Imo memtest86 should not hang onless something screws up [its] memory area
There is nothing else running when memtest runs. You cannot assume
that your hardware
Paul Jackson writes:
Yup - kills my x86_64 too. I can't stay up for half a minute.
...
My mainboard is an MSI K8N Neo2 Platinum.
I've tested both versions of the test program on two Athlon64 boxes,
and neither has had any problems with them.
My two machines are both VIA K8T800-based (a
On Thu, Mar 31, 2005 at 12:04:59AM +0200, Philip Lawatsch wrote:
I do have a very strange problem:
If I memset a ~1meg buffer some thousand times (in the userspace) it
will hardlock my machine.
I've been using 2.6.12-rc1 and also a lot of other kernels (2.6.9,
2.6.11). I've tried it both
your memory timings are out of spec.
I don't know what spec applies here, don't really care.
But when I backed off my Memory Timing from 1T to 2T,
my box became stable running this memset() test.
So I am a happy camper, grateful that someone posted
this nice test, and agree with you that it was
Philip Lawatsch wrote:
I've now tried the most conservative settings available. The 32 bit
kernel now hangs after about 15 Iterations (compared to about 16000
before) but the 64 bit kernel still hangs after about 5000.
I'm still seeing this on my system as well, using the most conservative
Stelian Pop wrote:
Just a thought: does deactivating cpufreq change anything ?
I haven't tested yet your program, but on my Asus K8NE-Deluxe very
strange things happen if cpufreq/powernow is activated *and*
the cpu frequency is changed...
Didn't change anything for me, I tried deactivating
Yup - kills my x86_64 too. I can't stay up for half a minute.
I got a couple of Oops
Unable to handle kernel paging request at 2730 RIP:
Unable to handle kernel paging request at 81773ffc6918 RIP:
The first try ended with a sudden reboot. The second time, I ctrl-C'd
out
On Thursday 31 March 2005 07:38, Robert Hancock wrote:
> Philip Lawatsch wrote:
> > Hi,
> >
> >
> > I do have a very strange problem:
> >
> > If I memset a ~1meg buffer some thousand times (in the userspace) it
> > will hardlock my machine.
>
> I thought that this must be impossible, but I
Philip Lawatsch wrote:
Hi,
I do have a very strange problem:
If I memset a ~1meg buffer some thousand times (in the userspace) it
will hardlock my machine.
I thought that this must be impossible, but I tried it on my machine
which is very similar (Asus A8N-SLI, Athlon 64 3500+, 2GB RAM) and to my
Matthias-Christian Ott wrote:
You want to allocate a lot of memory (16 GB), you don't have that much
space, so the Kernel hangs.
No, this is not what it is doing. The program is simply wiping the same
1MB block of memory over and over. If it was doing what you say it would
not (or should not)
Philip Lawatsch schrieb:
Hi,
I do have a very strange problem:
If I memset a ~1meg buffer some thousand times (in the userspace) it
will hardlock my machine.
I've been using 2.6.12-rc1 and also a lot of other kernels (2.6.9,
2.6.11). I've tried it both using a 32 bit kernel and a 64 bit kernel.
Hi,
I do have a very strange problem:
If I memset a ~1meg buffer some thousand times (in the userspace) it
will hardlock my machine.
I've been using 2.6.12-rc1 and also a lot of other kernels (2.6.9,
2.6.11). I've tried it both using a 32 bit kernel and a 64 bit kernel.
When running on the 32
Hi,
I do have a very strange problem:
If I memset a ~1meg buffer some thousand times (in the userspace) it
will hardlock my machine.
I've been using 2.6.12-rc1 and also a lot of other kernels (2.6.9,
2.6.11). I've tried it both using a 32 bit kernel and a 64 bit kernel.
When running on the 32
Philip Lawatsch schrieb:
Hi,
I do have a very strange problem:
If I memset a ~1meg buffer some thousand times (in the userspace) it
will hardlock my machine.
I've been using 2.6.12-rc1 and also a lot of other kernels (2.6.9,
2.6.11). I've tried it both using a 32 bit kernel and a 64 bit kernel.
Philip Lawatsch wrote:
Hi,
I do have a very strange problem:
If I memset a ~1meg buffer some thousand times (in the userspace) it
will hardlock my machine.
I thought that this must be impossible, but I tried it on my machine
which is very similar (Asus A8N-SLI, Athlon 64 3500+, 2GB RAM) and to my
On Thursday 31 March 2005 07:38, Robert Hancock wrote:
Philip Lawatsch wrote:
Hi,
I do have a very strange problem:
If I memset a ~1meg buffer some thousand times (in the userspace) it
will hardlock my machine.
I thought that this must be impossible, but I tried it on my
Yup - kills my x86_64 too. I can't stay up for half a minute.
I got a couple of Oops
Unable to handle kernel paging request at 2730 RIP:
Unable to handle kernel paging request at 81773ffc6918 RIP:
The first try ended with a sudden reboot. The second time, I ctrl-C'd
out
55 matches
Mail list logo
