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
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 w
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
[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 d
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
> >>thoug
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
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
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 i
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 Li
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
>>blo
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 wit
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 frequen
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 cpufreq
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
tim
> 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
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 i
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 des
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 i
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
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.
Notic
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 whi
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 trie
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) lo
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.
Whe
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 b
28 matches
Mail list logo
