Brian Norris | 20 Dec 03:38 2014
Picon

[PATCH mtd-www 1/4] footer: drop 'Last updated' and other buggy footer notices

These "last updated" messages are often wrong, and are rarely useful. We
could also drop the VAR_CVSID definitions from all the other source
files, but there's no need at the moment.

Signed-off-by: Brian Norris <computersforpeace <at> gmail.com>
---
 inc/footer.tmpl | 1 -
 1 file changed, 1 deletion(-)

diff --git a/inc/footer.tmpl b/inc/footer.tmpl
index 9ba350f55f56..aaa58a1950bf 100644
--- a/inc/footer.tmpl
+++ b/inc/footer.tmpl
 <at>  <at>  -2,7 +2,6  <at>  <at> 
    </div>
    <div align="right">
    	<p>
-	VAR_CVSID
       	<a href="http://validator.w3.org/check?uri=referer">
 		<img src="http://www.w3.org/Icons/valid-xhtml10"
 		 alt="Valid XHTML 1.0!" height="31" width="88" />
--

-- 
1.9.1

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

Dan Ehrenberg | 19 Dec 20:27 2014

[PATCH v5] UBI: block: Continue creating ubiblocks after an initialization error

If one ubi volume is corrupted but another is not, it should be
possible to initialize that ubiblock from a kernel commandline which
includes both of them. This patch changes the error handling behavior
in initializing ubiblock to ensure that all parameters are attempted
even if one fails. If there is a failure, it is logged on dmesg.
It also makes error messages more descriptive by including the
name of the UBI volume that failed.

Tested: Formatted ubi volume /dev/ubi5_0 in a corrupt way and
dev/ubi3_0 properly and included "ubi.block=5,0 ubi.block=3,0" on
the kernel command line. At boot, I see the following in the console:
[   21.082420] UBI error: ubiblock_create_from_param: block: can't open volume on ubi5_0, err=-19
[   21.084268] UBI: ubiblock3_0 created from ubi3:0(rootfs)

Signed-off-by: Dan Ehrenberg <dehrenberg <at> chromium.org>
---
Changes in v5:
- Rebased on current UBI sources and changed ubi_err to pr_err
Changes in v4:
- Removed Change-Id line
Changes in v3:
- Tried to fix the wraparound in sending the email
- Moved the 'changes' section to below the ---
Changes in v2:
- Added comments in the code explaning the intent of the error
  handling strategy.
- Fixed the code surrounding ubiblock initialization to not
  shut down the block devices after starting them up. In my
  test case, the initialization happened to not get called
  because the return value happened to be overwritten by the
(Continue reading)

t kevin | 19 Dec 13:24 2014
Picon

Get error -74 (ECC error) during ubiattach

Hi all,

I get below error message everytime when my box boots up.
It appears there is a ECC error. But such errors should be taken care
by UBI/UBIFS itself, right?
Is it because the background thread "ubi_bgt2d" has not started yet so
no one could do the data scrubbing during ubiattach stage?
Is it possible to do something like a fsck.ubifs to fix this issue?

The system can boot up correctly but this message is kind of terrifying.

Thanks a lot
Kevin

UBI: attaching mtd10 to ubi2
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    126976 bytes
UBI: smallest flash I/O unit:    2048
UBI: sub-page size:              512
UBI: VID header offset:          2048 (aligned 2048)
UBI: data offset:                4096
UBI warning: ubi_io_read: error -74 (ECC error) while reading 512
bytes from PEB 404:2048, read only 512 bytes, retry
UBI warning: ubi_io_read: error -74 (ECC error) while reading 512
bytes from PEB 404:2048, read only 512 bytes, retry
UBI warning: ubi_io_read: error -74 (ECC error) while reading 512
bytes from PEB 404:2048, read only 512 bytes, retry
UBI error: ubi_io_read: error -74 (ECC error) while reading 512 bytes
from PEB 404:2048, read 512 bytes
[<c0138160>] (unwind_backtrace+0x0/0xf4) from [<c02f43dc>]
(Continue reading)

Dan Ehrenberg | 19 Dec 00:33 2014

[PATCH v4] UBI: block: Continue creating ubiblocks after an initialization error

If one ubi volume is corrupted but another is not, it should be
possible to initialize that ubiblock from a kernel commandline which
includes both of them. This patch changes the error handling behavior
in initializing ubiblock to ensure that all parameters are attempted
even if one fails. If there is a failure, it is logged on dmesg.
It also makes error messages more descriptive by including the
name of the UBI volume that failed.

Tested: Formatted ubi volume /dev/ubi5_0 in a corrupt way and
dev/ubi3_0 properly and included "ubi.block=5,0 ubi.block=3,0" on
the kernel command line. At boot, I see the following in the console:
[   21.082420] UBI error: ubiblock_create_from_param: block: can't open volume on ubi5_0, err=-19
[   21.084268] UBI: ubiblock3_0 created from ubi3:0(rootfs)

Signed-off-by: Dan Ehrenberg <dehrenberg <at> chromium.org>
---
Changes in v4:
- Removed Change-Id line
Changes in v3:
- Tried to fix the wraparound in sending the email
- Moved the 'changes' section to below the ---
Changes in v2:
- Added comments in the code explaning the intent of the error
  handling strategy.
- Fixed the code surrounding ubiblock initialization to not
  shut down the block devices after starting them up. In my
  test case, the initialization happened to not get called
  because the return value happened to be overwritten by the
  second successful case, but if the cases were reversed it
  would be removed. In the new code, ubiblock_create_from_param
(Continue reading)

Dan Ehrenberg | 18 Dec 23:39 2014

[PATCH v3] UBI: block: Continue creating ubiblocks after an initialization error

If one ubi volume is corrupted but another is not, it should be
possible to initialize that ubiblock from a kernel commandline which
includes both of them. This patch changes the error handling behavior
in initializing ubiblock to ensure that all parameters are attempted
even if one fails. If there is a failure, it is logged on dmesg.
It also makes error messages more descriptive by including the
name of the UBI volume that failed.

Tested: Formatted ubi volume /dev/ubi5_0 in a corrupt way and
dev/ubi3_0 properly and included "ubi.block=5,0 ubi.block=3,0" on
the kernel command line. At boot, I see the following in the console:
[   21.082420] UBI error: ubiblock_create_from_param: block: can't open volume on ubi5_0, err=-19
[   21.084268] UBI: ubiblock3_0 created from ubi3:0(rootfs)

Change-Id: I85a5e756429314f317174efe4beee2f2532e8b73
Signed-off-by: Dan Ehrenberg <dehrenberg <at> chromium.org>
---
Changes in v2:
- Added comments in the code explaning the intent of the error
  handling strategy.
- Fixed the code surrounding ubiblock initialization to not
  shut down the block devices after starting them up. In my
  test case, the initialization happened to not get called
  because the return value happened to be overwritten by the
  second successful case, but if the cases were reversed it
  would be removed. In the new code, ubiblock_create_from_param
  is simply a void function because no caller cares if one of
  the blocks failed to initialize.
Changes in v3:
- Tried to fix the wraparound in sending the email
(Continue reading)

Daniel Ehrenberg | 18 Dec 23:17 2014

[PATCH v2] UBI: block: Continue creating ubiblocks after an initialization error

If one ubi volume is corrupted but another is not, it should be
possible to initialize that ubiblock from a kernel commandline which
includes both of them. This patch changes the error handling behavior
in initializing ubiblock to ensure that all parameters are attempted
even if one fails. If there is a failure, it is logged on dmesg.
It also makes error messages more descriptive by including the
name of the UBI volume that failed.

Tested: Formatted ubi volume /dev/ubi5_0 in a corrupt way and
dev/ubi3_0 properly and included "ubi.block=5,0 ubi.block=3,0" on
the kernel command line. At boot, I see the following in the console:
[   21.082420] UBI error: ubiblock_create_from_param: block: can't
open volume on ubi5_0, err=-19
[   21.084268] UBI: ubiblock3_0 created from ubi3:0(rootfs)

Changes in v2:
- Added comments in the code explaning the intent of the error
  handling strategy.
- Fixed the code surrounding ubiblock initialization to not
  shut down the block devices after starting them up. In my
  test case, the initialization happened to not get called
  because the return value happened to be overwritten by the
  second successful case, but if the cases were reversed it
  would be removed. In the new code, ubiblock_create_from_param
  is simply a void function because no caller cares if one of
  the blocks failed to initialize.

Signed-off-by: Dan Ehrenberg <dehrenberg <at> chromium.org>
---
 drivers/mtd/ubi/block.c | 37 ++++++++++++++++++++++---------------
(Continue reading)

nick | 18 Dec 19:00 2014
Picon

Help Out

Greetings Mtd Developers,
I am looking to help out in this subsystem. Please note I am no longer acting immature 
and sending out shitty patches. Further more I hope to help out where you guys need the
help. Please send me a TODO list for this subsystem or a project, either way I want to
learn more about this area and help out.
Regards Nick 

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

Tanya Brokhman | 18 Dec 09:34 2014

Synchronization in UBIFS (zero length files)

Hi Artem/Richard

I've been looking into the "zero length files" issue in UBIFS and came 
across "Synchronization exceptions for buggy applications"  <at>  
http://www.linux-mtd.infradead.org/doc/ubifs.html#L_sync_semantics. This 
section concludes with:

"We have plans to implement these features in UBIFS, but this has not 
been done yet. The problem is that UBI/MTD are fully synchronous and we 
cannot initiate asynchronous write-out, so we'd have to synchronously 
write files on close/rename, which is slow. So implementing these 
features would require implementing asynchronous I/O in UBI, which is a 
big job. But feel free to do this :-)."

So two questions:
1. was anything done in ubifs to handle file truncation and rename 
similar to ext4? Didn't find anything but afraid I might be missing 
something
2. Not sure I understand why "implementing these features would require 
implementing asynchronous I/O in UBI". Could you please elaborate on this?

Thanks,
Tanya Brokhman
--

-- 
Qualcomm Israel, on behalf of Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum, a Linux Foundation Collaborative Project

______________________________________________________
Linux MTD discussion mailing list
(Continue reading)

vndao | 18 Dec 09:23 2014

[PATCH mtd] mtd:devices: Add Altera EPCQ Driver

From: Viet Nga Dao <vndao <at> altera.com>

Altera EPCQ Controller is a soft IP which enables access to Altera EPCQ and
EPCS flash chips. This patch adds driver for these devices.

Signed-off-by: Viet Nga Dao <vndao <at> altera.com>
---
 .../devicetree/bindings/mtd/altera_epcq.txt        |   45 ++
 drivers/mtd/devices/Kconfig                        |   12 +
 drivers/mtd/devices/Makefile                       |    2 +-
 drivers/mtd/devices/altera_epcq.c                  |  804 ++++++++++++++++++++
 drivers/mtd/devices/altera_epcq.h                  |  130 ++++
 5 files changed, 992 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mtd/altera_epcq.txt
 create mode 100644 drivers/mtd/devices/altera_epcq.c
 create mode 100644 drivers/mtd/devices/altera_epcq.h

diff --git a/Documentation/devicetree/bindings/mtd/altera_epcq.txt b/Documentation/devicetree/bindings/mtd/altera_epcq.txt
new file mode 100644
index 0000000..d14f50e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/altera_epcq.txt
 <at>  <at>  -0,0 +1,45  <at>  <at> 
+* MTD Altera EPCQ driver
+
+Required properties:
+- compatible: Should be "altr,epcq-1.0"
+- reg: Address and length of the register set  for the device. It contains
+  the information of registers in the same order as described by reg-names
+- reg-names: Should contain the reg names
(Continue reading)

chenjie6 | 18 Dec 12:04 2014

[PATCH] [RESEND] jffs2: bugfix of summary length

From: Chen Jie <chenjie6 <at> huawei.com>

sm->offset maybe wrong but magic maybe right, the offset 
do not have CRC.

------------[ cut here ]------------
Badness at c00c7580 [verbose debug info unavailable]
NIP: c00c7580 LR: c00c718c CTR: 00000014
REGS: df07bb40 TRAP: 0700   Not tainted  (2.6.34.13-WR4.3.0.0_standard)
MSR: 00029000 <EE,ME,CE>  CR: 22084f84  XER: 00000000
TASK = df84d6e0[908] 'mount' THREAD: df07a000
GPR00: 00000001 df07bbf0 df84d6e0 00000000 00000001 00000000 df07bb58 00000041
GPR08: 00000041 c0638860 00000000 00000010 22084f88 100636c8 df814ff8 00000000
GPR16: df84d6e0 dfa558cc c05adb90 00000048 c0452d30 00000000 000240d0 000040d0
GPR24: 00000014 c05ae734 c05be2e0 00000000 00000001 00000000 00000000 c05ae730
NIP [c00c7580] __alloc_pages_nodemask+0x4d0/0x638
LR [c00c718c] __alloc_pages_nodemask+0xdc/0x638
Call Trace:
[df07bbf0] [c00c718c] __alloc_pages_nodemask+0xdc/0x638 (unreliable)
[df07bc90] [c00c7708] __get_free_pages+0x20/0x48
[df07bca0] [c00f4a40] __kmalloc+0x15c/0x1ec
[df07bcd0] [c01fc880] jffs2_scan_medium+0xa58/0x14d0
[df07bd70] [c01ff38c] jffs2_do_mount_fs+0x1f4/0x6b4
[df07bdb0] [c020144c] jffs2_do_fill_super+0xa8/0x260
[df07bdd0] [c020230c] jffs2_fill_super+0x104/0x184
[df07be00] [c0335814] get_sb_mtd_aux+0x9c/0xec
[df07be20] [c033596c] get_sb_mtd+0x84/0x1e8
[df07be60] [c0201ed0] jffs2_get_sb+0x1c/0x2c
[df07be70] [c0103898] vfs_kern_mount+0x78/0x1e8
[df07bea0] [c0103a58] do_kern_mount+0x40/0x100
(Continue reading)

Daniel Ehrenberg | 18 Dec 00:16 2014

[PATCH] UBI: block: Continue creating ubiblocks after an initialization error

If one ubi volume is corrupted but another is not, it should be
possible to initialize that ubiblock from a kernel commandline which
includes both of them. This patch changes the error handling behavior
in initializing ubiblock to ensure that all parameters are attempted
even if one fails. If there is a failure, it returns one of the
error status codes. It also makes error messages more descriptive
by including the name of the UBI volume that failed.

Tested: Formatted ubi volume /dev/ubi5_0 in a corrupt way and
dev/ubi3_0 properly and included "ubi.block=5,0 ubi.block=3,0" on
the kernel command line. At boot, I see the following in the console:
[   21.082420] UBI error: ubiblock_create_from_param: block: can't
open volume on ubi5_0, err=-19
[   21.084268] UBI: ubiblock3_0 created from ubi3:0(rootfs)

Signed-off-by: Dan Ehrenberg <dehrenberg <at> chromium.org>
---
 drivers/mtd/ubi/block.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/ubi/block.c b/drivers/mtd/ubi/block.c
index 8876c7d..32eeeee 100644
--- a/drivers/mtd/ubi/block.c
+++ b/drivers/mtd/ubi/block.c
 <at>  <at>  -596,10 +596,11  <at>  <at>  static int __init ubiblock_create_from_param(void)

                desc = open_volume_desc(p->name, p->ubi_num, p->vol_id);
                if (IS_ERR(desc)) {
-                       ubi_err("block: can't open volume, err=%ld\n",
-                               PTR_ERR(desc));
(Continue reading)


Gmane