Prev: [git pull] device-mapper patches for 2.6.34
Next: please don't apply : bootmem: avoid DMA32 zone by default
From: Martin Guy on 7 Mar 2010 06:10
On 3/7/10, dave b <db.pub.mail(a)gmail.com> wrote:
> Ok... however how should one test the memory of an arm machine? ...
> memtest is only for x86. *I am referring to the kernel memtest and not
> memtest86.

Well, there's a userspace one: follow the link from
http://www.arm.linux.org.uk/developer/stresstests.php

M
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Uwe Kleine-König on 8 Mar 2010 05:00
On Sun, Mar 07, 2010 at 12:05:21PM +1100, dave b wrote:
> Ok... however how should one test the memory of an arm machine? ...
> memtest is only for x86. *I am referring to the kernel memtest and not
> memtest86.
The easiest is: rerun make and check if it fails at exactly the same
place.

Best regards
Uwe

--
Pengutronix e.K. | Uwe Kleine-K�nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Daniel Mack on 8 Mar 2010 05:40
On Mon, Mar 08, 2010 at 10:53:37AM +0100, Uwe Kleine-K�nig wrote:
> On Sun, Mar 07, 2010 at 12:05:21PM +1100, dave b wrote:
> > Ok... however how should one test the memory of an arm machine? ...
> > memtest is only for x86. *I am referring to the kernel memtest and not
> > memtest86.
> The easiest is: rerun make and check if it fails at exactly the same
> place.

Hmm, I wonder whether this is in any way related to what Pavel and Cyril
reported in the 'bit error' thread.

Dave, does your bootloader have any memory test built-in? Do you see the
same issues with any older kernel?

FWIW, we're currently hunting a strange bug with hanging tasks, which
only seems to affect systems with Wifi enabled. That might be totally
unrelated to both of these issues though.

Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: dave b on 11 Mar 2010 08:20
2010/3/8 Daniel Mack <daniel(a)caiaq.de>:
> On Mon, Mar 08, 2010 at 10:53:37AM +0100, Uwe Kleine-König wrote:
>> On Sun, Mar 07, 2010 at 12:05:21PM +1100, dave b wrote:
>> > Ok... however how should one test the memory of an arm machine? ...
>> > memtest is only for x86. *I am referring to the kernel memtest and not
>> > memtest86.
>> The easiest is:  rerun make and check if it fails at exactly the same
>> place.
>
> Hmm, I wonder whether this is in any way related to what Pavel and Cyril
> reported in the 'bit error' thread.
>
> Dave, does your bootloader have any memory test built-in? Do you see the
> same issues with any older kernel?
>
> FWIW, we're currently hunting a strange bug with hanging tasks, which
> only seems to affect systems with Wifi enabled. That might be totally
> unrelated to both of these issues though.
>
> Daniel
>

U-boot apparently has a very simple memory checker, this doesn't help
me as I don't have serial access. I have now re-compiled the 2.6.33
kernel whilst the device has been on the 2.6.33 kernel 4 times now
*without* an *error*. I also ran memtester for a while using most of
the memory on the device, without invoking the oom killer.

I will re-run these tests on the 2.6.32.7 kernel soon.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Russell King - ARM Linux on 11 Mar 2010 08:40
On Sat, Mar 06, 2010 at 09:24:49PM +1100, dave b wrote:
> I had already reported it to debian -
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572653
>
> I have cc'ed linux-arm-kernel into this email.

I think most of the points have already been convered, but just for
completeness,

What is the history of the hardware you're running these builds on?
Has it proven itself on previous kernel versions running much the same
tests?

Another point to consider: how are you running the compiler - is it
over NFS from a PC?

The reason I ask is that you can suffer from very weird corruption
issues - I have a nice illustration of one which takes a copy of 1GB
worth of data each day, and every once in a while, bytes 8-15 of a
naturally aligned 16 byte block in the data become corrupted somewhere
between the network and disk. The probability of corruption happening
is around 0.0000001%, but it still happens... and that makes it
extremely difficult to track down.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: [git pull] device-mapper patches for 2.6.34
Next: please don't apply : bootmem: avoid DMA32 zone by default