Re: MTD : Kernel oops when remounting ubifs as read/write

2013-03-14 Thread Artem Bityutskiy 
On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote:
 Sorry ... this just locks up the unit.

OK, I've reproduced the issue with 3.9-rc2 in nandsim, see the details
below. The patch I proposed did not get the error path correctly, but it
does fix the issue.

I think what you treat as lockup is the fixup process. UBIFS basically
reads the entire UBI volume and writes it back. And it uses the atomic
change UBI service, which means it also calculates CRC of everything it
writes. And this all just takes a lot of time. This has to be done only
once on the first mount.

I've attached the following:

1. The patch which fixes the issue when I use nandsim. It is also
   inlined in the end. Please, give it a try and be more patient -
   wait longer. Please, do report your results back.
2. 'reproduce.sh' - a quick and dirty shell script which reproduces the
problem
3. ubinize.cfg - is needed for 'reproduce.sh'.


Thanks!

From a173f8e9296562e5ece3dd2936d799001897d6c6 Mon Sep 17 00:00:00 2001
From: Artem Bityutskiy artem.bityuts...@linux.intel.com
Date: Thu, 14 Mar 2013 10:49:23 +0200
Subject: [PATCH] UBIFS: make space fixup work in the remount case

The UBIFS space fixup is a useful feature which allows to fixup the broken
flash space at the time of the first mount. The broken space is usually the
result of using a dumb industrial flasher which is not able to skip empty
NAND pages and just writes all 0xFFs to the empty space, which has grave
side-effects for UBIFS when UBIFS trise to write useful data to those empty
pages.

The fix-up feature works roughly like this:
1. mkfs.ubifs sets the fixup flag in UBIFS superblock when creating the image
   (see -F option)
2. when the file-system is mounted for the first time, UBIFS notices the fixup
   flag and re-writes the entire media atomically, which may take really a lot
   of time.
3. UBIFS clears the fixup flag in the superblock.

This works fine when the file system is mounted R/W for the very first time.
But it did not really work in the case when we first mount the file-system R/O,
and then re-mount R/W. The reason was that we started the fixup procedure too
late, which we cannot really do because we have to fixup the space before it
starts being used.

Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com
Reported-by: Mark Jackson mpfj-l...@mimc.co.uk
Cc: sta...@vger.kernel.org # 3.0+
---
 fs/ubifs/super.c |   13 +++--
 1 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index ac838b8..fa4aec6 100644
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -1568,10 +1568,17 @@ static int ubifs_remount_rw(struct ubifs_info *c)
c-remounting_rw = 1;
c-ro_mount = 0;
 
+   if (c-space_fixup) {
+   err = ubifs_fixup_free_space(c);
+   if (err)
+   return err;
+   }
+
err = check_free_space(c);
if (err)
goto out;
 
+
if (c-old_leb_cnt != c-leb_cnt) {
struct ubifs_sb_node *sup;
 
@@ -1684,12 +1691,6 @@ static int ubifs_remount_rw(struct ubifs_info *c)
err = dbg_check_space_info(c);
}
 
-   if (c-space_fixup) {
-   err = ubifs_fixup_free_space(c);
-   if (err)
-   goto out;
-   }
-
mutex_unlock(c-umount_mutex);
return err;
 
-- 
1.7.7.6

-- 
Best Regards,
Artem Bityutskiy
From a173f8e9296562e5ece3dd2936d799001897d6c6 Mon Sep 17 00:00:00 2001
From: Artem Bityutskiy artem.bityuts...@linux.intel.com
Date: Thu, 14 Mar 2013 10:49:23 +0200
Subject: [PATCH] UBIFS: make space fixup work in the remount case

The UBIFS space fixup is a useful feature which allows to fixup the broken
flash space at the time of the first mount. The broken space is usually the
result of using a dumb industrial flasher which is not able to skip empty
NAND pages and just writes all 0xFFs to the empty space, which has grave
side-effects for UBIFS when UBIFS trise to write useful data to those empty
pages.

The fix-up feature works roughly like this:
1. mkfs.ubifs sets the fixup flag in UBIFS superblock when creating the image
   (see -F option)
2. when the file-system is mounted for the first time, UBIFS notices the fixup
   flag and re-writes the entire media atomically, which may take really a lot
   of time.
3. UBIFS clears the fixup flag in the superblock.

This works fine when the file system is mounted R/W for the very first time.
But it did not really work in the case when we first mount the file-system R/O,
and then re-mount R/W. The reason was that we started the fixup procedure too
late, which we cannot really do because we have to fixup the space before it
starts being used.

Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com
Cc: sta...@vger.kernel.org # 3.0+
---
 fs/ubifs/super.c |   13 +++--
 1 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index

Re: MTD : Kernel oops when remounting ubifs as read/write

2013-03-14 Thread Mark Jackson 
On 14/03/13 09:13, Artem Bityutskiy wrote:
 On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote:
 Sorry ... this just locks up the unit.
 
 OK, I've reproduced the issue with 3.9-rc2 in nandsim, see the details
 below. The patch I proposed did not get the error path correctly, but it
 does fix the issue.
 
 I think what you treat as lockup is the fixup process. UBIFS basically
 reads the entire UBI volume and writes it back. And it uses the atomic
 change UBI service, which means it also calculates CRC of everything it
 writes. And this all just takes a lot of time. This has to be done only
 once on the first mount.

Okay ... I've retried, but how long is a lot of time ?

I've waited 15 minutes and still nothing.

And I can see that there's no activity on the NAND chip select !?!

I'll put some debug info into the fixup routines to see if I can trace what's 
going on.

Regards
Mark J.

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MTD : Kernel oops when remounting ubifs as read/write

2013-03-14 Thread Artem Bityutskiy 
On Thu, 2013-03-14 at 09:54 +, Mark Jackson wrote:
 On 14/03/13 09:13, Artem Bityutskiy wrote:
  On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote:
  Sorry ... this just locks up the unit.
  
  OK, I've reproduced the issue with 3.9-rc2 in nandsim, see the details
  below. The patch I proposed did not get the error path correctly, but it
  does fix the issue.
  
  I think what you treat as lockup is the fixup process. UBIFS basically
  reads the entire UBI volume and writes it back. And it uses the atomic
  change UBI service, which means it also calculates CRC of everything it
  writes. And this all just takes a lot of time. This has to be done only
  once on the first mount.
 
 Okay ... I've retried, but how long is a lot of time ?
 
 I've waited 15 minutes and still nothing.
 
 And I can see that there's no activity on the NAND chip select !?!
 
 I'll put some debug info into the fixup routines to see if I can trace what's 
 going on.

Just to make sure - try this last patch I sent. I did test it with
nandsim at least, and I am sure it works. I did not test at all the
first one.

And yes, debug messages would be useful, just do not forget to add the
'ignore_loglevel' kernel boot option, otherwise you won't see the
messages on your console, since they are of KERN_DEBUG level.

You may have other issues which cause lockup, e.g., in driver level. It
makes sense to validate your flash with MTD test modules.

-- 
Best Regards,
Artem Bityutskiy

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MTD : Kernel oops when remounting ubifs as read/write

2013-03-14 Thread Mark Jackson 
On 14/03/13 10:30, Artem Bityutskiy wrote:
 On Thu, 2013-03-14 at 09:54 +, Mark Jackson wrote:
 On 14/03/13 09:13, Artem Bityutskiy wrote:
 On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote:
 Sorry ... this just locks up the unit.

 OK, I've reproduced the issue with 3.9-rc2 in nandsim, see the details
 below. The patch I proposed did not get the error path correctly, but it
 does fix the issue.

 I think what you treat as lockup is the fixup process. UBIFS basically
 reads the entire UBI volume and writes it back. And it uses the atomic
 change UBI service, which means it also calculates CRC of everything it
 writes. And this all just takes a lot of time. This has to be done only
 once on the first mount.

 Okay ... I've retried, but how long is a lot of time ?

 I've waited 15 minutes and still nothing.

 And I can see that there's no activity on the NAND chip select !?!

 I'll put some debug info into the fixup routines to see if I can trace 
 what's going on.
 
 Just to make sure - try this last patch I sent. I did test it with
 nandsim at least, and I am sure it works. I did not test at all the
 first one.
 
 And yes, debug messages would be useful, just do not forget to add the
 'ignore_loglevel' kernel boot option, otherwise you won't see the
 messages on your console, since they are of KERN_DEBUG level.
 
 You may have other issues which cause lockup, e.g., in driver level. It
 makes sense to validate your flash with MTD test modules.

My first initial findings ...

I added some simple printk(KERN_INFO) lines to fixup_free_space(), and when
I remount, it gets as far as:-

printk(KERN_INFO ffs 7\n);
/* Fixup LEBs in the main area */
for (lnum = c-main_first; lnum  c-leb_cnt; lnum++) {
lprops = ubifs_lpt_lookup(c, lnum);
if (IS_ERR(lprops)) {
err = PTR_ERR(lprops);
goto out;
}

if (lprops-free  0) {
err = fixup_leb(c, lnum, c-leb_size - lprops-free);
if (err)
goto out;
}
}

out:
printk(KERN_INFO ffs x\n);
ubifs_release_lprops(c);
return err;
}

... before we get an oops with crc32_le().  See the full log below.

I'll keep digging ...

Regards
Mark J.
---
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.8.0-next-20130225-2-g678576f-dirty 
(mpfj@mpfj-nanobone) (gcc version 4.5.4 (Buildroot 2012.11) ) #40 Thu Mar 14 
10:58:28 GMT 2013
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI 
AM335x BeagleBone
[0.00] debug: ignoring loglevel setting.
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] On node 0 totalpages: 65280
[0.00] free_area_init_node: node 0, pgdat c059c7b0, node_mem_map 
c0ac6000
[0.00]   Normal zone: 512 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 65280 pages, LIFO batch:15
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] AM335X ES1.0 (neon )
[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[0.00] pcpu-alloc: [0] 0
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 64768
[0.00] Kernel command line: console=ttyO0,115200n8 noinitrd ip=off 
mem=256M rootwait=1 ubi.mtd=6,2048 rootfstype=ubifs root=ubi0:rootfs 
ignore_loglevel
[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] __ex_table already sorted, skipping sort
[0.00] Memory: 255MB = 255MB total
[0.00] Memory: 247768k/247768k available, 14376k reserved, 0K highmem
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
[0.00] vmalloc : 0xd080 - 0xff00   ( 744 MB)
[0.00] lowmem  : 0xc000 - 0xd000   ( 256 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00]   .text : 0xc0008000 - 0xc05194ac   (5190 kB)
[0.00]   .init : 0xc051a000 - 0xc054bfbc   ( 200 kB)
[0.00]   .data : 0xc054c000 - 0xc059d360   ( 325 kB)
[0.00].bss : 0xc059d360 - 0xc0ac21a0   (5268 kB)
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128 
interrupts
[0.00] Total of 128 interrupts on 1 active controller
[0.00] OMAP clockevent source: GPTIMER1 at 2600 Hz
[0.00] sched_clock: 32 bits at 26MHz,

Re: MTD : Kernel oops when remounting ubifs as read/write

2013-03-14 Thread Artem Bityutskiy 
On Thu, 2013-03-14 at 11:15 +, Mark Jackson wrote:
 [   28.538525] [d08ea004] *pgd=8f045811, *pte=, *ppte=
 [   28.545173] Internal error: Oops: 7 [#1] ARM
 [   28.549685] CPU: 0Not tainted  
 (3.8.0-next-20130225-2-g678576f-dirty #40)
 [   28.557595] PC is at crc32_le+0x50/0x168
 [   28.561735] LR is at ubi_eba_atomic_leb_change+0x1b4/0x410
 [   28.567523] pc : [c01e7244]lr : [c026dd9c]psr: 2013
 [   28.567523] sp : cf385de0  ip : 180a985a  fp : c054f840
 [   28.579632] r10: c054f040  r9 : c054fc40  r8 : 158a1232
 [   28.585141] r7 : 4d506705  r6 : 9324fd72  r5 : 4dc8a10b  r4 : 4c162691
 [   28.592025] r3 : c054e040  r2 : c054f440  r1 : d08ea000  r0 : 4c8ee09f
 [   28.598912] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
 user
 [   28.606439] Control: 10c5387d  Table: 8f3b8019  DAC: 0015
 [   28.612501] Process mount (pid: 659, stack limit = 0xcf384238)
 [   28.618652] Stack: (0xcf385de0 to 0xcf386000)
 [   28.623254] 5de0: cf2f8554  d08e6e8c 180a9e88 5a257c4f 58399ee9 
 c8d98a08 bb0ee864
 [   28.631886] 5e00: eae10678 c054fc40 c054f040 c054f840 cf2f8000  
 d08caffc 3c00
 [   28.640517] 5e20: cf2f8000 cf357c00  000c cf2ec000  
 000c cf2f8554
 [   28.649148] 5e40: d08cb000 0001e000  d08cb000 8000  
  0001e000
 [   28.657779] 5e60:  000c d08cb000 0080 000c 000c 
  0020
 [   28.666409] 5e80: 8000 c026c41c 0001e000 cf33 cf33 d08cb000 
 0001e000 c0179b14
 [   28.675042] 5ea0: 000d c0177a68 0001e000 cf33  cf330b20 
 000d c0179698
 [   28.683672] 5ec0: cf33  cf330a9c  cf385f48 c0175170 
 0001 6013
 [   28.692303] 5ee0: cf32c800    cf385f48  
 0020 c00c9e24
 [   28.700934] 5f00: 00100100 00200200 cf3a6c80 8000 cf384000 00208020 
  cf01a200
 [   28.709564] 5f20: cf32c800 c00e3d6c  000c cf32c840  
 c0013968 cf31fb80
 [   28.718195] 5f40: 000c  cf01a210 ce828858 000c cf3ac000 
 000a18b4 
 [   28.726827] 5f60: 00208020 c0013968 cf384000  0003 c00e3e40 
  c0071e24
 [   28.735459] 5f80:   cf31fb80 cf31fbc0 a010  
 bed87b68 b6ff148c
 [   28.744091] 5fa0: 0015 c00137c0  bed87b68 000a18b4 000a18c0 
 000a18c2 00208020
 [   28.752720] 5fc0:  bed87b68 b6ff148c 0015   
  0003
 [   28.761350] 5fe0: b6fa3f48 bed87a64 00042994 b6fa3f58 a010 000a18b4 
  
 [   28.769989] [c01e7244] (crc32_le+0x50/0x168) from [cf2f8000] 
 (0xcf2f8000)
 [   28.777522] Code: e58d8008 0a26 e1a0c005 e58d2004 (e5916004)
 [   28.784029] ---[ end trace f50f53afffe647f1 ]---

OK, this is an independent problem which, as I think, has nothing to do
with the first one.

I do not know why crc32 oopses on your system. You need to investigate
this. I believe this is not UBI/UBIFS's fault.

One theory could be that UBI uses vmalloc'ed buffers for the atomic
update operation, and submits the buffer to the MTD layer for the I/O.
If your NAND driver is trying to DMA this memory, you may be in trouble,
because vmalloced memory is often not DMA-able on many systems,
especially ARM systems which do not have coherent cache support.

-- 
Best Regards,
Artem Bityutskiy

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MTD : Kernel oops when remounting ubifs as read/write

2013-03-14 Thread Artem Bityutskiy 
On Thu, 2013-03-14 at 12:02 +, Mark Jackson wrote:
 But there's also a call to crc with a size of 122880 bytes, and that's
 when the oops occurs.
 
This is when we do the atomic LEB change.

 Is this size larger than the allocated buffer ?

I believe so.

-- 
Best Regards,
Artem Bityutskiy

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MTD : Kernel oops when remounting ubifs as read/write

2013-03-14 Thread Mark Jackson 
On 14/03/13 12:23, Artem Bityutskiy wrote:
 On Thu, 2013-03-14 at 14:18 +0200, Artem Bityutskiy wrote:
 Is this size larger than the allocated buffer ?

 I believe so.
 
 Err, I mean, the buffer is large enough. I do not believe there is a
 stupid bug like too small buffer. This code has worked for years and I
 do not think it was changes much.
 
 The oops may be cause by memory corruption - some of your drivers may
 corrupt memory. You need to spend more time debugging this carefully.

It can handle 64k, but not 122880 bytes ...

# mount -o remount,rw /
[   19.208302] UBIFS: start fixing up free space
[   19.235881] uealc crc32 : d08cb000 2048
[   19.240015] uealc crc32 : d08cb000 4096
[   19.244091] uealc crc32 : d08cb000 8192
[   19.248184] uealc crc32 : d08cb000 16384
[   19.252448] uealc crc32 : d08cb000 32768
[   19.256772] uealc crc32 : d08cb000 65536
[   19.260133] uealc crc32 : d08cb000 122880
[   19.261117] Unable to handle kernel paging request at virtual address 
e79381bc
[   19.268741] pgd = cf40c000
[   19.271598] [e79381bc] *pgd=
[   19.275387] Internal error: Oops: 5 [#1] ARM
[   19.279902] CPU: 0Not tainted  (3.8.0-next-20130225-2-g678576f-dirty 
#47)
[   19.287819] PC is at crc32_le+0xf8/0x168
[   19.291965] LR is at ubi_eba_atomic_leb_change+0x3ac/0x4f8
[   19.297760] pc : [c01e724c]lr : [c026def4]psr: 2013
[   19.297760] sp : cf3bbe08  ip : 0e4e  fp : c054f840
[   19.309882] r10: e7938104  r9 : c054fc40  r8 : 65e95c1c
[   19.315396] r7 : 322e315f  r6 : 352e332e  r5 : 002e  r4 : 0035
[   19.322288] r3 : c054e040  r2 : 0033  r1 : d08d3d90  r0 : 63c3884e
[   19.329180] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   19.336713] Control: 10c5387d  Table: 8f40c019  DAC: 0015
[   19.342781] Process mount (pid: 659, stack limit = 0xcf3ba238)
[   19.348939] Stack: (0xcf3bbe08 to 0xcf3bc000)
[   19.353542] be00:   cf2f8554  d08caffc 2000 
cf2f8000 cf357a00
[   19.362183] be20:  000c cf2ec000  000c cf2f8554 
 
[   19.370823] be40: d08cb000 d08cb000  0700 8000 c026c168 
 0001e000
[   19.379463] be60:  000c d08cb000 0080 000c cf3bbf48 
 0020
[   19.388101] be80: 8000 c026c37c 0001e000 cf33 cf33 d08cb000 
0001e000 c0179a78
[   19.396738] bea0: 000d c0177a68 0001e000 cf33  cf330b20 
000d c01794b4
[   19.405376] bec0:  cf33  cf330a9c  c0175170 
0001 6013
[   19.414012] bee0: cf32c800    cf3bbf48  
0020 c00c9e24
[   19.422648] bf00: 00100100 00200200 cf390300 8000 cf3ba000 00208020 
 cf01a200
[   19.431284] bf20: cf32c800 c00e3d6c  000c cf32c840  
c0013968 cf325800
[   19.439921] bf40: 000c  cf01a210 ce828858 000c cf053000 
000a18b4 
[   19.448559] bf60: 00208020 c0013968 cf3ba000  0003 c00e3e40 
 c0071e24
[   19.457197] bf80:   cf325800 cf328380 a010  
beb83b68 b6f8348c
[   19.465838] bfa0: 0015 c00137c0  beb83b68 000a18b4 000a18c0 
000a18c2 00208020
[   19.474475] bfc0:  beb83b68 b6f8348c 0015   
 0003
[   19.483108] bfe0: b6f35f48 beb83a64 00042994 b6f35f58 a010 000a18b4 
 
[   19.491758] [c01e724c] (crc32_le+0xf8/0x168) from [] (  (null))
[   19.499115] Code: 0a08 e59da008 e28a1003 e5f1c001 (e2522001)
[   19.50] ---[ end trace 84a04423f0bc8388 ]---

 Do you have fastmap UBI feature enabled?

No ...

#
# LPDDR flash memory drivers
#
# CONFIG_MTD_LPDDR is not set
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_LIMIT=20
# CONFIG_MTD_UBI_FASTMAP is not set
# CONFIG_MTD_UBI_GLUEBI is not set
CONFIG_DTC=y
CONFIG_OF=y

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MTD : Kernel oops when remounting ubifs as read/write

2013-03-13 Thread Mark Jackson 
On 12/03/13 11:25, Artem Bityutskiy wrote:
 On Mon, 2013-03-04 at 16:42 +, Mark Jackson wrote:
 I'm encountering an oops when remounting my ubifs volume as read/write.

 # mount -o remount,rw /
 [   89.434974] UBIFS assert failed in ubifs_write_node at 869 (pid 628)
 [   89.442122] [c001b124] (unwind_backtrace+0x0/0xf0) from [c01ad7d4] 
 (ubifs_write_node+0x180/0x1c4)
 [   89.451896] [c01ad7d4] (ubifs_write_node+0x180/0x1c4) from [c01b3878] 
 (ubifs_write_master+0x9c/0x134)
 [   89.462018] [c01b3878] (ubifs_write_master+0x9c/0x134) from 
 [c01a79a4] (ubifs_remount_fs+0x5d4/0x7f8)
 [   89.472133] [c01a79a4] (ubifs_remount_fs+0x5d4/0x7f8) from [c010dbf4] 
 (do_remount_sb+0x98/0x16c)
 [   89.481790] [c010dbf4] (do_remount_sb+0x98/0x16c) from [c0128268] 
 (do_mount+0x830/0x888)
 [   89.490708] [c0128268] (do_mount+0x830/0x888) from [c0128344] 
 (sys_mount+0x84/0xb8)
 [   89.499178] [c0128344] (sys_mount+0x84/0xb8) from [c0013800] 
 (ret_fast_syscall+0x0/0x3c)
 [   89.510997] UBIFS assert failed in ubifs_write_node at 869 (pid 628)
 [   89.517884] [c001b124] (unwind_backtrace+0x0/0xf0) from [c01ad7d4] 
 (ubifs_write_node+0x180/0x1c4)
 [   89.527641] [c01ad7d4] (ubifs_write_node+0x180/0x1c4) from [c01b38b4] 
 (ubifs_write_master+0xd8/0x134)
 [   89.537760] [c01b38b4] (ubifs_write_master+0xd8/0x134) from 
 [c01a79a4] (ubifs_remount_fs+0x5d4/0x7f8)
 [   89.547869] [c01a79a4] (ubifs_remount_fs+0x5d4/0x7f8) from [c010dbf4] 
 (do_remount_sb+0x98/0x16c)
 [   89.557526] [c010dbf4] (do_remount_sb+0x98/0x16c) from [c0128268] 
 (do_mount+0x830/0x888)
 [   89.566435] [c0128268] (do_mount+0x830/0x888) from [c0128344] 
 (sys_mount+0x84/0xb8)
 [   89.574905] [c0128344] (sys_mount+0x84/0xb8) from [c0013800] 
 (ret_fast_syscall+0x0/0x3c)
 [   89.585939] UBIFS: start fixing up free space
 [   89.592237] UBIFS: background thread ubifs_bgt0_0 started, PID 629
 [   91.419951] UBIFS: free space fixup complete
 #

 If it's any help, if the remount is put into my inittab, I don't get any 
 oops.
 
 Would you please try this patch (also attached):
 
 diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
 index ac838b8..9791b3c 100644
 --- a/fs/ubifs/super.c
 +++ b/fs/ubifs/super.c
 @@ -1568,6 +1568,12 @@ static int ubifs_remount_rw(struct ubifs_info *c)
   c-remounting_rw = 1;
   c-ro_mount = 0;
  
 + if (c-space_fixup) {
 + err = ubifs_fixup_free_space(c);
 + if (err)
 + goto out;
 + }
 +
   err = check_free_space(c);
   if (err)
   goto out;
 @@ -1684,12 +1690,6 @@ static int ubifs_remount_rw(struct ubifs_info *c)
   err = dbg_check_space_info(c);
   }
  
 - if (c-space_fixup) {
 - err = ubifs_fixup_free_space(c);
 - if (err)
 - goto out;
 - }
 -
   mutex_unlock(c-umount_mutex);
   return err;
 

Sorry ... this just locks up the unit.

Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MTD : Kernel oops when remounting ubifs as read/write

2013-03-13 Thread Artem Bityutskiy 
On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote:
  -   if (c-space_fixup) {
  -   err = ubifs_fixup_free_space(c);
  -   if (err)
  -   goto out;
  -   }
  -
  mutex_unlock(c-umount_mutex);
  return err;
  
 
 Sorry ... this just locks up the unit.

Am I right that to reproduce it I need any image with the 'fixup' flag
set, then I should put it on the flash, mount it R/O and then remount
R/W. Right?

-- 
Best Regards,
Artem Bityutskiy

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MTD : Kernel oops when remounting ubifs as read/write

2013-03-13 Thread Mark Jackson 
On 13/03/13 11:20, Artem Bityutskiy wrote:
 On Wed, 2013-03-13 at 11:12 +, Mark Jackson wrote:
 -   if (c-space_fixup) {
 -   err = ubifs_fixup_free_space(c);
 -   if (err)
 -   goto out;
 -   }
 -
 mutex_unlock(c-umount_mutex);
 return err;


 Sorry ... this just locks up the unit.
 
 Am I right that to reproduce it I need any image with the 'fixup' flag
 set, then I should put it on the flash, mount it R/O and then remount
 R/W. Right?
 

Yes ... this is on a custom AM335x board, where the ubi image must be created
with the -F flag.

Cheers
Mark J.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MTD : Kernel oops when remounting ubifs as read/write

2013-03-12 Thread Artem Bityutskiy 
On Mon, 2013-03-04 at 16:42 +, Mark Jackson wrote:
 I'm encountering an oops when remounting my ubifs volume as read/write.
 
 # mount -o remount,rw /
 [   89.434974] UBIFS assert failed in ubifs_write_node at 869 (pid 628)
 [   89.442122] [c001b124] (unwind_backtrace+0x0/0xf0) from [c01ad7d4] 
 (ubifs_write_node+0x180/0x1c4)
 [   89.451896] [c01ad7d4] (ubifs_write_node+0x180/0x1c4) from [c01b3878] 
 (ubifs_write_master+0x9c/0x134)
 [   89.462018] [c01b3878] (ubifs_write_master+0x9c/0x134) from [c01a79a4] 
 (ubifs_remount_fs+0x5d4/0x7f8)
 [   89.472133] [c01a79a4] (ubifs_remount_fs+0x5d4/0x7f8) from [c010dbf4] 
 (do_remount_sb+0x98/0x16c)
 [   89.481790] [c010dbf4] (do_remount_sb+0x98/0x16c) from [c0128268] 
 (do_mount+0x830/0x888)
 [   89.490708] [c0128268] (do_mount+0x830/0x888) from [c0128344] 
 (sys_mount+0x84/0xb8)
 [   89.499178] [c0128344] (sys_mount+0x84/0xb8) from [c0013800] 
 (ret_fast_syscall+0x0/0x3c)
 [   89.510997] UBIFS assert failed in ubifs_write_node at 869 (pid 628)
 [   89.517884] [c001b124] (unwind_backtrace+0x0/0xf0) from [c01ad7d4] 
 (ubifs_write_node+0x180/0x1c4)
 [   89.527641] [c01ad7d4] (ubifs_write_node+0x180/0x1c4) from [c01b38b4] 
 (ubifs_write_master+0xd8/0x134)
 [   89.537760] [c01b38b4] (ubifs_write_master+0xd8/0x134) from [c01a79a4] 
 (ubifs_remount_fs+0x5d4/0x7f8)
 [   89.547869] [c01a79a4] (ubifs_remount_fs+0x5d4/0x7f8) from [c010dbf4] 
 (do_remount_sb+0x98/0x16c)
 [   89.557526] [c010dbf4] (do_remount_sb+0x98/0x16c) from [c0128268] 
 (do_mount+0x830/0x888)
 [   89.566435] [c0128268] (do_mount+0x830/0x888) from [c0128344] 
 (sys_mount+0x84/0xb8)
 [   89.574905] [c0128344] (sys_mount+0x84/0xb8) from [c0013800] 
 (ret_fast_syscall+0x0/0x3c)
 [   89.585939] UBIFS: start fixing up free space
 [   89.592237] UBIFS: background thread ubifs_bgt0_0 started, PID 629
 [   91.419951] UBIFS: free space fixup complete
 #
 
 If it's any help, if the remount is put into my inittab, I don't get any oops.

Would you please try this patch (also attached):

diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index ac838b8..9791b3c 100644
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -1568,6 +1568,12 @@ static int ubifs_remount_rw(struct ubifs_info *c)
c-remounting_rw = 1;
c-ro_mount = 0;
 
+   if (c-space_fixup) {
+   err = ubifs_fixup_free_space(c);
+   if (err)
+   goto out;
+   }
+
err = check_free_space(c);
if (err)
goto out;
@@ -1684,12 +1690,6 @@ static int ubifs_remount_rw(struct ubifs_info *c)
err = dbg_check_space_info(c);
}
 
-   if (c-space_fixup) {
-   err = ubifs_fixup_free_space(c);
-   if (err)
-   goto out;
-   }
-
mutex_unlock(c-umount_mutex);
return err;

-- 
Best Regards,
Artem Bityutskiy
diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index ac838b8..9791b3c 100644
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -1568,6 +1568,12 @@ static int ubifs_remount_rw(struct ubifs_info *c)
 	c-remounting_rw = 1;
 	c-ro_mount = 0;
 
+	if (c-space_fixup) {
+		err = ubifs_fixup_free_space(c);
+		if (err)
+			goto out;
+	}
+
 	err = check_free_space(c);
 	if (err)
 		goto out;
@@ -1684,12 +1690,6 @@ static int ubifs_remount_rw(struct ubifs_info *c)
 		err = dbg_check_space_info(c);
 	}
 
-	if (c-space_fixup) {
-		err = ubifs_fixup_free_space(c);
-		if (err)
-			goto out;
-	}
-
 	mutex_unlock(c-umount_mutex);
 	return err;

MTD : Kernel oops when remounting ubifs as read/write

2013-03-04 Thread Mark Jackson 
I'm encountering an oops when remounting my ubifs volume as read/write.

# mount -o remount,rw /
[   89.434974] UBIFS assert failed in ubifs_write_node at 869 (pid 628)
[   89.442122] [c001b124] (unwind_backtrace+0x0/0xf0) from [c01ad7d4] 
(ubifs_write_node+0x180/0x1c4)
[   89.451896] [c01ad7d4] (ubifs_write_node+0x180/0x1c4) from [c01b3878] 
(ubifs_write_master+0x9c/0x134)
[   89.462018] [c01b3878] (ubifs_write_master+0x9c/0x134) from [c01a79a4] 
(ubifs_remount_fs+0x5d4/0x7f8)
[   89.472133] [c01a79a4] (ubifs_remount_fs+0x5d4/0x7f8) from [c010dbf4] 
(do_remount_sb+0x98/0x16c)
[   89.481790] [c010dbf4] (do_remount_sb+0x98/0x16c) from [c0128268] 
(do_mount+0x830/0x888)
[   89.490708] [c0128268] (do_mount+0x830/0x888) from [c0128344] 
(sys_mount+0x84/0xb8)
[   89.499178] [c0128344] (sys_mount+0x84/0xb8) from [c0013800] 
(ret_fast_syscall+0x0/0x3c)
[   89.510997] UBIFS assert failed in ubifs_write_node at 869 (pid 628)
[   89.517884] [c001b124] (unwind_backtrace+0x0/0xf0) from [c01ad7d4] 
(ubifs_write_node+0x180/0x1c4)
[   89.527641] [c01ad7d4] (ubifs_write_node+0x180/0x1c4) from [c01b38b4] 
(ubifs_write_master+0xd8/0x134)
[   89.537760] [c01b38b4] (ubifs_write_master+0xd8/0x134) from [c01a79a4] 
(ubifs_remount_fs+0x5d4/0x7f8)
[   89.547869] [c01a79a4] (ubifs_remount_fs+0x5d4/0x7f8) from [c010dbf4] 
(do_remount_sb+0x98/0x16c)
[   89.557526] [c010dbf4] (do_remount_sb+0x98/0x16c) from [c0128268] 
(do_mount+0x830/0x888)
[   89.566435] [c0128268] (do_mount+0x830/0x888) from [c0128344] 
(sys_mount+0x84/0xb8)
[   89.574905] [c0128344] (sys_mount+0x84/0xb8) from [c0013800] 
(ret_fast_syscall+0x0/0x3c)
[   89.585939] UBIFS: start fixing up free space
[   89.592237] UBIFS: background thread ubifs_bgt0_0 started, PID 629
[   91.419951] UBIFS: free space fixup complete
#

If it's any help, if the remount is put into my inittab, I don't get any oops.

I've attached my full dmesg log below.

Regards
Mark J.
---
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.8.0-next-20130225-dirty (mpfj@mpfj-nanobone) 
(gcc version 4.5.4 (Buildroot 2012.11) ) #24 SMP Mon Mar 4 16:34:01 GMT 2013
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI 
AM335x BeagleBone
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] On node 0 totalpages: 65280
[0.00] free_area_init_node: node 0, pgdat c062cd40, node_mem_map 
c0b7f000
[0.00]   Normal zone: 512 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 65280 pages, LIFO batch:15
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] AM335X ES1.0 (neon )
[0.00] PERCPU: Embedded 9 pages/cpu @c0d89000 s13696 r8192 d14976 u36864
[0.00] pcpu-alloc: s13696 r8192 d14976 u36864 alloc=9*4096
[0.00] pcpu-alloc: [0] 0
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 64768
[0.00] Kernel command line: console=ttyO0,115200n8 noinitrd ip=off 
mem=256M rootwait=1 ubi.mtd=6,2048 rootfstype=ubifs root=ubi0:rootfs
[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] __ex_table already sorted, skipping sort
[0.00] Memory: 255MB = 255MB total
[0.00] Memory: 247020k/247020k available, 15124k reserved, 0K highmem
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
[0.00] vmalloc : 0xd080 - 0xff00   ( 744 MB)
[0.00] lowmem  : 0xc000 - 0xd000   ( 256 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
[0.00]   .text : 0xc0008000 - 0xc0570d40   (5540 kB)
[0.00]   .init : 0xc0571000 - 0xc05b7580   ( 282 kB)
[0.00]   .data : 0xc05b8000 - 0xc062ee20   ( 476 kB)
[0.00].bss : 0xc062ee20 - 0xc0b7b0ac   (5425 kB)
[0.00] Hierarchical RCU implementation.
[0.00]  RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1.
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128 
interrupts
[0.00] Total of 128 interrupts on 1 active controller
[0.00] OMAP clockevent source: GPTIMER1 at 2600 Hz
[0.00] sched_clock: 32 bits at 26MHz, resolution 38ns, wraps every 
165191ms
[0.00] OMAP clocksource: GPTIMER2 at 2600 Hz
[0.00] Console: colour dummy device 80x30
[0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., 
Ingo Molnar
[