From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751389AbbDCFTh (ORCPT ); Fri, 3 Apr 2015 01:19:37 -0400 Received: from mx.dave-tech.it ([2.229.21.40]:38033 "EHLO mx.dave-tech.it" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751005AbbDCFTc (ORCPT ); Fri, 3 Apr 2015 01:19:32 -0400 Message-ID: <551E22E2.80200@dave-tech.it> Date: Fri, 03 Apr 2015 07:19:30 +0200 From: Andrea Scian User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: linux-mtd@lists.infradead.org, Richard Weinberger CC: Brian Norris , dwmw2@infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mtd: Add simple read disturb test References: <551D6BDA.6000606@nod.at> In-Reply-To: <551D6BDA.6000606@nod.at> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 150402-2, 02/04/2015), Outbound message X-Antivirus-Status: Clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all, Il 02/04/2015 18:18, Richard Weinberger ha scritto: > Am 02.04.2015 um 18:04 schrieb Brian Norris: >> On Thu, Apr 02, 2015 at 04:13:46PM +0200, Richard Weinberger wrote: >> [1] Although there are some latent issues in these tests that are still >> getting get worked out (e.g., bad handling of 64-bit casting; too large >> of stacks; uninterruptibility). The latter two would not even exist if >> we were in user space. > > uninterruptibility got solved by my "[PATCH] mtd: Make MTD tests cancelable" patch. And this is something I was looking for from years! > But if we want to kill drivers/mtd/tests/ I'll happily help out. > Where shall we move these tests into? mtd-utils? I think so. I'm writing a similar read disturb test on my own, mixing already existing mtd-tools (flash_erase, nandwrite, nanddump) with some naive bash scripting. IMHO, we have a lot of pros running in userspace: * dumping data * better error/status log (which can be easily written on file, for example, while mtdtests error log is mixed with other kernel messages) * running test in parallel (if it make sense ;-) For example on read disturb I already calculate RBER, which is, AFAIK, a nice index on the quality of the NAND cell and of its data. I'm working on writing down data on a separate CSV which can be easily processed later (e.g. to make part to part comparison/statistics). There's already a test directory inside mtd-utils, I think it's better to start creating tests there, as userspace tools, whenever this is possible. Do we have any reason to have MTD tests as kernel module? (performance?) Kind Regards, -- Andrea SCIAN DAVE Embedded Systems