marcin.krzeminski | 27 Jun 12:20 2016
Picon

[RFC 0/3] mtd: spi-nor: DUAL/QUAD I/O read modes implementation

From: Marcin Krzeminski <marcin.krzeminski <at> nokia.com>

This small series adds support for new spi-nor Cypress(Spansion) FS-S
family based on s25fs512s device. This family stopped to support
QUAD/DUAL read modes, so fastest supported read is FAST_READ
in current framework. Series implements DUAL/QUAD I/O
read modes, as well as continuous read mode configuration byte.

Chnages are under KConfig entry because it is easier for me
to merge them between kernel version.

RFC since you are working on new framework, this might help to define
some requirememnts.

Marcin Krzeminski (3):
  mtd: spi-nor: DUAL I/O and QUAD I/O modes support
  mtd: spi-nor: Read Mode byte implementation
  mtd: spi-nor: Support for s25fs512s

 drivers/mtd/spi-nor/Kconfig   |  8 ++++
 drivers/mtd/spi-nor/spi-nor.c | 91 ++++++++++++++++++++++++++++++++++++++++++-
 include/linux/mtd/spi-nor.h   | 21 ++++++++++
 3 files changed, 118 insertions(+), 2 deletions(-)

--

-- 
2.7.4

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
(Continue reading)

marcin.krzeminski | 27 Jun 12:19 2016
Picon

[RFC 0/3] mtd: spi-nor: DUAL/QUAD I/O read modes implementation

From: Marcin Krzeminski <marcin.krzeminski <at> nokia.com>

This small series adds support for new spi-nor Cypress(Spansion) FS-S
family based on s25fs512s device. This family stopped to support
QUAD/DUAL read modes, so fastest supported read is FAST_READ
in current framework. Series implements DUAL/QUAD I/O
read modes, as well as continuous read mode configuration byte.

Chnages are under KConfig entry because it is easier for me
to merge them between kernel version.

RFC since you are working on new framework, this might help to define
some requirememnts.

Marcin Krzeminski (3):
  mtd: spi-nor: DUAL I/O and QUAD I/O modes support
  mtd: spi-nor: Read Mode byte implementation
  mtd: spi-nor: Support for s25fs512s

 drivers/mtd/spi-nor/Kconfig   |  8 ++++
 drivers/mtd/spi-nor/spi-nor.c | 91 ++++++++++++++++++++++++++++++++++++++++++-
 include/linux/mtd/spi-nor.h   | 21 ++++++++++
 3 files changed, 118 insertions(+), 2 deletions(-)

--

-- 
2.7.4

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
(Continue reading)

ubifs issue about ubifs_tnc_remove_ino when replay journal

hi mtd-list

I've seen a problem on embedded board with UBIFS/UBI.
My environment is as follows:

kernel version : 3.10.49
flash : 512MB nand, 128KB PEB

If a power cut occurs when the system is operating
a problem occur in a journal replay at reboot.

ubifs_jnl_delete_inode or ubifs_jnl_delete_xattr remove 
all nodes belonging to the extended attribute inode from TNC.
And it makes the journal to delete the information in flash. 
The journal is applied to flash on reboot.
However, the GC delete the region before applying journal,
I guess that the problem occurs.

------------------ kernel log -------------------------
[    3.637490]   No soundcard[    3.644631] UBIFS-0: background thread "ubifs_bgt0_0" started, PID 108
[    3.675468] UBIFS-0: recovery needed
[    4.323462] UBIFS-0 error (pid 1): ubifs_read_node: bad node type (192 but expected 3)
[    4.330341] UBIFS-0 error (pid 1): ubifs_read_node: bad node at LEB 635:58544, LEB mapping status 1
[    4.339388] Not a node, first 24 bytes:
[    4.343030] 00000000: 47 5f 49 44 45 4e 54 49 46 49 45 52 3d 6e 65 74 6d 67 72 64 c0 05 fd 04                          G_IDENTIFIER=netmgrd....
[    4.356051] CPU: 0 PID: 1 Comm: swapper Tainted: G        W    3.10.49+ #1
[    4.362923] [<c00143b8>] (unwind_backtrace+0x0/0xe0) from [<c00118a8>] (show_stack+0x10/0x14)
[    4.371419] [<c00118a8>] (show_stack+0x10/0x14) from [<c01ba514>] (ubifs_read_node+0x240/0x27c)
[    4.380089] [<c01ba514>] (ubifs_read_node+0x240/0x27c) from [<c01d41a4>] (ubifs_tnc_read_node+0x48/0x130)
[    4.389651] [<c01d41a4>] (ubifs_tnc_read_node+0x48/0x130) from [<c01bb2d4>] (tnc_read_node_nm+0xb4/0x1b8)
(Continue reading)

Brian Norris | 24 Jun 19:38 2016
Picon

[PATCH] mtd: spi-nor: fix wrong "fully unlocked" test

In stm_unlock(), the test to determine whether we've fully unlocked the
flash checks for the lock length to be equal to the flash size. That is
a typo/think-o -- the condition actually means the flash is completely
*locked.* We should be using the inverse condition -- that the lock
length is 0 (i.e., no protection).

The result of this bug is that we never actually turn off the Status
Register Write Disable bit, even if the flash is completely unlocked.
Now we can.

Fixes: 47b8edbf0d43 ("mtd: spi-nor: disallow further writes to SR if WP# is low")
Reported-by: Giorgio <giorgio.nicole <at> arcor.de>
Signed-off-by: Brian Norris <computersforpeace <at> gmail.com>
Cc: Ezequiel Garcia <ezequiel <at> vanguardiasur.com.ar>
---
 drivers/mtd/spi-nor/spi-nor.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index a63922ed6385..14cf6ac8c0a5 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
 <at>  <at>  -661,7 +661,7  <at>  <at>  static int stm_unlock(struct spi_nor *nor, loff_t ofs, uint64_t len)
 	status_new = (status_old & ~mask & ~SR_TB) | val;

 	/* Don't protect status register if we're fully unlocked */
-	if (lock_len == mtd->size)
+	if (lock_len == 0)
 		status_new &= ~SR_SRWD;

(Continue reading)

Anatolij Gustschin | 24 Jun 15:33 2016
Picon
Picon

Is UBI volume update broken?

Hi,

after UBI volume update the UBIFS file system in the volume cannot be
mounted any more. I'm testing it with kernel 4.7.0-rc4 and mtd-utils
version 1.5.2 from git tree. The UBI volume is on SPI-NOR flash in
15.4 MiB big MTD partition. UBI debugging is enabled with

echo 'format "UBI DBG" +pf' > /sys/kernel/debug/dynamic_debug/control
echo 'format "UBIFS DBG" +pf' > /sys/kernel/debug/dynamic_debug/control

Mounting with "mount -t ubifs ubi0:data /mnt" fails with -EINVAL, but
I can't see any obvious error message in the generated debug log:
...
[   60.046082] ubifs_mount: UBIFS DBG gen (pid 353): name ubi0:data, flags 0x8000
[   60.046122] ubi_open_volume_path: UBI DBG gen (pid 353): open volume ubi0:data, mode 1
[   60.046184] ubi_open_volume_nm: UBI DBG gen (pid 353): open device 0, volume data, mode 1
[   60.046508] ubi_open_volume: UBI DBG gen (pid 353): open device 0, volume 0, mode 1
[   60.046764] ubifs_mount: UBIFS DBG gen (pid 353): opened ubi0_0
[   60.047210] ubi_open_volume: UBI DBG gen (pid 353): open device 0, volume 0, mode 2
[   60.049054] ubi_is_mapped: UBI DBG gen (pid 353): test LEB 0:0
[   60.049250] ubifs_read_node: UBIFS DBG io (pid 353): LEB 0:0, superblock node, length 4096
[   60.049287] ubi_leb_read: UBI DBG gen (pid 353): read 4096 bytes from LEB 0:0:0
[   60.049729] ubi_eba_read_leb: UBI DBG eba (pid 353): read 4096 bytes from offset 0 of LEB 0:0, PEB 216
[   60.049766] ubi_io_read: UBI DBG io (pid 353): read 4096 bytes from PEB 216:128
[   60.058205] ubi_close_volume: UBI DBG gen (pid 353): close device 0, volume 0, mode 2
[   60.058281] ubi_close_volume: UBI DBG gen (pid 353): close device 0, volume 0, mode 1

With a patched kernel (used debug patch is attached) the debug log finally
looks more meaningful:
...
(Continue reading)

Richard Weinberger | 23 Jun 21:18 2016
Picon

Re: 回复:ubifs:Questions About Garbage Collection

Am 23.06.2016 um 19:55 schrieb Michal Suchanek:
> On 23 June 2016 at 19:34, Richard Weinberger <richard <at> nod.at> wrote:
>> Am 23.06.2016 um 19:20 schrieb Michal Suchanek:
>>> Hello,
>>>
>>> On 19 June 2016 at 19:05, Richard Weinberger <richard <at> nod.at> wrote:
>>>> Am 19.06.2016 um 18:14 schrieb 辉少:
>>>>> Thanks for your kind reply!Do you mean that in synchronous/asynchronous mode GC is also finished
in synchronous
>>>>> /asynchronous way as writting is? A more question is,are all dirty spaces collected in the same
time in synchronous mode(at this point the caller will be blocked for a long time) while in asynchronous
mode dirty spaces will be collected little by little in asynchronous mode when i do not  notice?Thank you!
>>>>
>>>> Hmm, I don't fully understand your first question, can you elaborate?
>>>> As for dirty space, GC will not collect all dirty space. UBIFS tells GC how much free space an operation
>>>> will take. UBIFS calls this budget. The GC will try to produce as much free space as needed.
>>>>
>>>
>>> I guess the issue here is that UBIFS appears to do this
>>>
>>>  1) write files while there is space
>>>  2) when space is 0 perform a GC run as part of write operation
>>>
>>> when writes are synchronous the GC run is timed as part of the write.
>>
>> Exactly. :-)
>>
>>> If GC was asynchronous it would not appear as part of the synchronous
>>> write operation and would not cause as much write time jitter. When
>>> mounting a filesystem synchronous having GC synchronous is likely not
(Continue reading)

Richard Weinberger | 23 Jun 19:34 2016
Picon

Re: 回复:ubifs:Questions About Garbage Collection

Am 23.06.2016 um 19:20 schrieb Michal Suchanek:
> Hello,
> 
> On 19 June 2016 at 19:05, Richard Weinberger <richard <at> nod.at> wrote:
>> Am 19.06.2016 um 18:14 schrieb 辉少:
>>> Thanks for your kind reply!Do you mean that in synchronous/asynchronous mode GC is also finished in synchronous
>>> /asynchronous way as writting is? A more question is,are all dirty spaces collected in the same time
in synchronous mode(at this point the caller will be blocked for a long time) while in asynchronous mode
dirty spaces will be collected little by little in asynchronous mode when i do not  notice?Thank you!
>>
>> Hmm, I don't fully understand your first question, can you elaborate?
>> As for dirty space, GC will not collect all dirty space. UBIFS tells GC how much free space an operation
>> will take. UBIFS calls this budget. The GC will try to produce as much free space as needed.
>>
> 
> I guess the issue here is that UBIFS appears to do this
> 
>  1) write files while there is space
>  2) when space is 0 perform a GC run as part of write operation
> 
> when writes are synchronous the GC run is timed as part of the write.

Exactly. :-)

> If GC was asynchronous it would not appear as part of the synchronous
> write operation and would not cause as much write time jitter. When
> mounting a filesystem synchronous having GC synchronous is likely not
> what the user asked for. It's part of the internal fs bookkeeping and
> not part of the operation the user wants to perform synchronously.
> 
(Continue reading)

辉少 | 23 Jun 16:10 2016

回复:ubifs:Questions About Garbage Collection

Thank you for reply.
You said"the caller (where you measure the time) will be blocked
until GC produce some space", my question is that since GC thread has default priority, how can the caller be
blocked without context switch when another thread is working in my embedded system? Does block happen as
sychronizing function is always tring to synchronize data to flash until GC thread frees enough space in
synchronised mode?
Many Thanks,
Andy

---原始邮件---
发件人: "Richard Weinberger"<richard.weinberger <at> gmail.com>
发送时间: 2016年6月19日 22:50:59
收件人: "辉少"<wang502742203 <at> qq.com>;
抄送: "linux-mtd"<linux-mtd <at> lists.infradead.org>;
主题: Re: ubifs:Questions About Garbage Collection

Hi!

On Sun, Jun 19, 2016 at 3:56 PM, 辉少 <wang502742203 <at> qq.com> wrote:
> Hi,MTD  lists
> I meet some problems while using UBI file system recently.I make an experiment in which I write 2 files(1KB
each) to UBI frequently.Normally it takes only several millseconds to finish writting 2 files every
time,but what puzzles me is that it takes about 4 minutes to write once nearly every 20 to 30 minutes.I am
wondering how can this problem happen?Does Garbage Collection lead to this? I mount UBIFS to a 33MiB MTD
partion with "o -sync" option.By the way,if UBI is mounted in asynchronous mode, this problem never
happens. Does GC(Garbage Collecton) differ in synchronous mode andasynchronous mode?  What I've leared
from some documents is that GC thread is sleeping while writting files without interval until UBIFS is
full in synchronous mode and at that point writing will become very slow, but in asynchronous mode, before
data is  moved into flash media, GC thread will work when there is not enough free space, am I right?

(Continue reading)

Sascha Hauer | 23 Jun 15:29 2016
Picon

[PATCH] UBI: only read UBI_VID_HDR_SIZE when reading the vid_hdr

When reading the vid hdr from the device UBI always reads a whole
page. Instead, read only the data we actually need and speed up
attachment of UBI devices by potentially making use of reading
subpages.

Signed-off-by: Sascha Hauer <s.hauer <at> pengutronix.de>
---

Please review carefully. It obviously works and speeds up UBI attachment
from 3s to 2s here in one case and I have not found places where this patch
makes problems, but there might be a reason I haven't seen why in case of
the ec header only the header is read while in case of the vid header the
whole page is read.

 drivers/mtd/ubi/io.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c
index 10cf3b5..31918a0 100644
--- a/drivers/mtd/ubi/io.c
+++ b/drivers/mtd/ubi/io.c
 <at>  <at>  -1019,7 +1019,7  <at>  <at>  int ubi_io_read_vid_hdr(struct ubi_device *ubi, int pnum,

 	p = (char *)vid_hdr - ubi->vid_hdr_shift;
 	read_err = ubi_io_read(ubi, p, pnum, ubi->vid_hdr_aloffset,
-			  ubi->vid_hdr_alsize);
+			  UBI_VID_HDR_SIZE);
 	if (read_err && read_err != UBI_IO_BITFLIPS && !mtd_is_eccerr(read_err))
 		return read_err;

(Continue reading)

Sylvain Etienne | 23 Jun 07:53 2016
Picon

[PATCH] ubifs: switch_gc_head: remove redondant sync of wbuf

The wbuf is already sync-ed before ubifs_leb_unmap()

Signed-off-by: Sylvain Etienne <seti <at> dadboo.eu>
---

Notes:
    This is my first patch on this mailing list. Please let me know if I missed
    something.

 fs/ubifs/gc.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/fs/ubifs/gc.c b/fs/ubifs/gc.c
index 9718da8..821b348 100644
--- a/fs/ubifs/gc.c
+++ b/fs/ubifs/gc.c
 <at>  <at>  -100,10 +100,6  <at>  <at>  static int switch_gc_head(struct ubifs_info *c)
 	if (err)
 		return err;

-	err = ubifs_wbuf_sync_nolock(wbuf);
-	if (err)
-		return err;
-
 	err = ubifs_add_bud_to_log(c, GCHD, gc_lnum, 0);
 	if (err)
 		return err;
--

-- 
2.7.4

(Continue reading)

辉少 | 22 Jun 17:26 2016

回复:ubifs:questions about this filesystem

Thank you for kind reply.

1. As you said just now"there is only a background thread to do many things",  dose "many things" include both
GC and synchronizing data?
2. If I write a file(1 KB) to ubifs mounted in 34MiB mtd, can i write 34,000 times or 34000/4 times(the real
disk usage of a 1KB file is 4KB)?

Many Thanks,
Andy
---原始邮件---
发件人: "Richard Weinberger"<richard <at> nod.at>
发送时间: 2016年6月22日 22:46:07
收件人: "linux-mtd <at> lists.infradead.org"<linux-mtd <at> lists.infradead.org>;"辉少"<wang502742203 <at> qq.com>;
主题: Re: 回复:ubifs:questions about this filesystem

Am 22.06.2016 um 16:43 schrieb 辉少:
> As for the second question, I mean if ubifs background is collecting garbage,meanwhile my embeded system
is doing another thing, will GC thread affect the performance of "doing another thing"?

Please start unsing reply-all.
Sure will it as every thread on a multithreaded OS does...

Thanks,
//richard

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
______________________________________________________
Linux MTD discussion mailing list
(Continue reading)


Gmane