From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-we0-x232.google.com ([2a00:1450:400c:c03::232]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1UkFpX-0007Ya-1G for linux-mtd@lists.infradead.org; Wed, 05 Jun 2013 15:40:56 +0000 Received: by mail-we0-f178.google.com with SMTP id u53so1465031wes.9 for ; Wed, 05 Jun 2013 08:40:32 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1370445867.2938.1.camel@sauron.fi.intel.com> References: <1370445867.2938.1.camel@sauron.fi.intel.com> Date: Wed, 5 Jun 2013 10:40:32 -0500 Message-ID: Subject: Re: UBIFS: Orphaned inode 1 From: Brent Taylor To: Artem Bityutskiy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "linux-mtd@lists.infradead.org" , =?ISO-8859-1?Q?Mats_K=E4rrman?= List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Artem, I've seen the same issue with 3.6.9. I can get it to occur by following these steps: 1. Flash an image generated by ubinize. 2. Boot the system to run first time initialization scripts (UBI and UBIFS successfully mount the root filesystem). 3. Once initialization is complete, the system invokes 'sync' then causes a kernel panic to reboot the system. 4. On the second (and subsequent boots) the problem is observed. I've used 3.5.1 in the past without any issues so maybe something was introduced between those versions. -- Brent Taylor On Wed, Jun 5, 2013 at 10:24 AM, Artem Bityutskiy wro= te: > On Mon, 2013-06-03 at 13:03 +0000, Mats K=E4rrman wrote: >> Hi, >> >> I'm facing a problem involving systems running in the field that suddenl= y cannot >> boot anymore because the root UBIFS file system residing in a NOR flash >> cannot be mounted. Error msg in kernel log is: >> >> UBIFS error (pid 1): ubifs_iget: failed to read inode 1, error -2 >> >> I have managed to copy a failing FLASH image into a file on my PC, uploa= ded it >> to an mtdram device and tried to mount it with all debug info turned on = and >> "general" checks enabled. The final error is the same: >> >> < snip > >> [ 5513.523872] UBIFS: mounted UBI device 0, volume 0, name "debug-rootfs= " >> [ 5513.523878] UBIFS: file system size: 57877248 bytes (56520 KiB, 55 = MiB, 442 LEBs) >> [ 5513.523882] UBIFS: journal size: 8773248 bytes (8567 KiB, 8 MiB= , 67 LEBs) >> [ 5513.523885] UBIFS: media format: w4/r0 (latest is w4/r0) >> [ 5513.523887] UBIFS: default compressor: lzo >> [ 5513.523893] UBIFS: reserved for root: 261902 bytes (255 KiB) >> [ 5513.523896] UBIFS DBG (pid 4659): mount_ubifs: compiled on: M= ay 31 2013 at 13:31:25 >> [ 5513.523900] UBIFS DBG (pid 4659): mount_ubifs: min. I/O unit size: 8= bytes >> [ 5513.523903] UBIFS DBG (pid 4659): mount_ubifs: max. write size: 6= 4 bytes >> [ 5513.523905] UBIFS DBG (pid 4659): mount_ubifs: LEB size: 1= 30944 bytes (127 KiB) >> [ 5513.523908] UBIFS DBG (pid 4659): mount_ubifs: data journal heads: 1 >> [ 5513.523911] UBIFS DBG (pid 4659): mount_ubifs: UUID: B= 43E1323-1747-41FB-9C11-F4C0E59C24B8 >> [ 5513.523914] UBIFS DBG (pid 4659): mount_ubifs: big_lpt 0 >> [ 5513.523916] UBIFS DBG (pid 4659): mount_ubifs: log LEBs: 4= (3 - 6) >> [ 5513.523919] UBIFS DBG (pid 4659): mount_ubifs: LPT area LEBs: 2= (7 - 8) >> [ 5513.523921] UBIFS DBG (pid 4659): mount_ubifs: orphan area LEBs: 1= (9 - 9) >> [ 5513.523924] UBIFS DBG (pid 4659): mount_ubifs: main area LEBs: 4= 42 (10 - 451) >> [ 5513.523926] UBIFS DBG (pid 4659): mount_ubifs: index LEBs: 3= 2 >> [ 5513.523935] UBIFS DBG (pid 4659): mount_ubifs: total index bytes: 6= 22720 (608 KiB, 0 MiB) >> [ 5513.523940] UBIFS DBG (pid 4659): mount_ubifs: key hash type: 0 >> [ 5513.523944] UBIFS DBG (pid 4659): mount_ubifs: tree fanout: 8 >> [ 5513.523949] UBIFS DBG (pid 4659): mount_ubifs: reserved GC LEB: 4= 43 >> [ 5513.523953] UBIFS DBG (pid 4659): mount_ubifs: first main LEB: 1= 0 >> [ 5513.523958] UBIFS DBG (pid 4659): mount_ubifs: max. znode size 3= 20 >> [ 5513.523964] UBIFS DBG (pid 4659): mount_ubifs: max. index node size 1= 92 >> [ 5513.523967] UBIFS DBG (pid 4659): mount_ubifs: node sizes: d= ata 48, inode 160, dentry 56 >> [ 5513.523970] UBIFS DBG (pid 4659): mount_ubifs: node sizes: t= run 56, sb 4096, master 512 >> [ 5513.523973] UBIFS DBG (pid 4659): mount_ubifs: node sizes: r= ef 64, cmt. start 32, orph 32 >> [ 5513.523977] UBIFS DBG (pid 4659): mount_ubifs: max. node sizes: d= ata 4144, inode 4256 dentry 312, idx 188 >> [ 5513.523979] UBIFS DBG (pid 4659): mount_ubifs: dead watermark: 5= 6 >> [ 5513.523982] UBIFS DBG (pid 4659): mount_ubifs: dark watermark: 4= 256 >> [ 5513.523984] UBIFS DBG (pid 4659): mount_ubifs: LEB overhead: 2= 480 >> [ 5513.523987] UBIFS DBG (pid 4659): mount_ubifs: max. dark space: 1= 881152 (1837 KiB, 1 MiB) >> [ 5513.523989] UBIFS DBG (pid 4659): mount_ubifs: maximum bud bytes: 8= 249472 (8056 KiB, 7 MiB) >> [ 5513.523992] UBIFS DBG (pid 4659): mount_ubifs: BG commit bud bytes: 6= 702696 (6545 KiB, 6 MiB) >> [ 5513.523995] UBIFS DBG (pid 4659): mount_ubifs: current bud bytes 9= 0112 (88 KiB, 0 MiB) >> [ 5513.523998] UBIFS DBG (pid 4659): mount_ubifs: max. seq. number: 2= 3851433 >> [ 5513.524000] UBIFS DBG (pid 4659): mount_ubifs: commit number: 1= 769 >> [ 5513.524003] ubifs_iget: UBIFS DBG gen: inode 1 >> [ 5513.524011] ubifs_lookup_level0: UBIFS DBG tnc: search key (1, inode) >> [ 5513.524015] ubifs_lookup_level0: UBIFS DBG tnc: found 0, lvl 0, n -1 >> [ 5513.524018] UBIFS error (pid 4659): ubifs_iget: failed to read inode = 1, error -2 >> [ 5513.524022] ubifs_evict_inode: UBIFS DBG gen: inode 1, mode 0x8000 >> [ 5513.524026] ubifs_umount: UBIFS DBG gen: un-mounting UBI device 0, vo= lume 0 >> [ 5513.524049] UBIFS DBG (pid 4660): ubifs_bg_thread: background thread = "ubifs_bgt0_0" stops >> >> If i grep the log for recovery messages I get: >> >> [ 5513.520324] UBIFS: recovery needed >> [ 5513.520327] ubifs_recover_inl_heads: UBIFS DBG rcvry: checking index = head at 449:109136 >> [ 5513.520343] ubifs_recover_inl_heads: UBIFS DBG rcvry: checking LPT he= ad at 7:123208 >> [ 5513.520983] ubifs_recover_leb: UBIFS DBG rcvry: 219:93032, jhead 0, g= rouped 0 >> [ 5513.521039] ubifs_recover_leb: UBIFS DBG rcvry: found corruption - -1 >> [ 5513.521073] clean_buf: UBIFS DBG rcvry: cleaning corruption at 219:93= 032 >> [ 5513.521079] fix_unclean_leb: UBIFS DBG rcvry: fixing LEB 219 start 93= 032 endpt 93032 >> [ 5513.521396] ubifs_recover_leb: UBIFS DBG rcvry: 369:83568, jhead 1, g= rouped 1 >> [ 5513.521474] ubifs_recover_leb: UBIFS DBG rcvry: found corruption - -1 >> [ 5513.521548] clean_buf: UBIFS DBG rcvry: cleaning corruption at 369:83= 568 >> [ 5513.521557] fix_unclean_leb: UBIFS DBG rcvry: fixing LEB 369 start 83= 568 endpt 83568 >> [ 5513.521853] ubifs_recover_leb: UBIFS DBG rcvry: 444:126120, jhead 2, = grouped 1 >> [ 5513.521919] ubifs_recover_leb: UBIFS DBG rcvry: found corruption - -1 >> [ 5513.521952] clean_buf: UBIFS DBG rcvry: cleaning corruption at 444:12= 6120 >> [ 5513.521968] fix_unclean_leb: UBIFS DBG rcvry: fixing LEB 444 start 12= 6120 endpt 126120 >> [ 5513.522770] kill_orphans: UBIFS DBG rcvry: LEB 9 >> [ 5513.522885] do_kill_orphans: UBIFS DBG rcvry: deleting orphaned inode= 1208852 >> [ 5513.523313] do_kill_orphans: UBIFS DBG rcvry: deleting orphaned inode= 1 >> [ 5513.523489] do_kill_orphans: UBIFS DBG rcvry: last orph node for comm= it 1700 at 9:0 >> [ 5513.523494] ubifs_rcvry_gc_commit: UBIFS DBG rcvry: GC head LEB 219, = offs 93032 >> [ 5513.523512] ubifs_rcvry_gc_commit: UBIFS DBG rcvry: committing >> [ 5513.523768] ubifs_rcvry_gc_commit: UBIFS DBG rcvry: GC'ing LEB 443 >> [ 5513.523840] ubifs_rcvry_gc_commit: UBIFS DBG rcvry: allocated LEB 443= for GC >> [ 5513.523843] UBIFS: recovery completed >> >> The message that caught my attention: >> >> [ 5513.523313] do_kill_orphans: UBIFS DBG rcvry: deleting orphaned inode= 1 >> >> How can inode 1 be an orphan, or rather shouldn't it be? >> Is it possible for a user-space application to cause this error? >> Should I also look in UBI and MTD layers for the cause? >> I'm not sure where to go on from here, any suggestions are welcome!! >> >> My target system runs a Freescale MPC5125 (PPC e300c4) with a Linux 2.6.= 35.14 >> kernel patched with all UBFS patches from Artem's 2.6.35 maintenance tre= e and >> additional ones from later kernel versions. >> My PC runs the latest LMDE (3.2.32) recompiled with dynamic debug turned= on. > > You are the second person reporting this for 2.6.35. Probably I > introduced a bug while back-porting stuff. > > Can you reproduce this or try to find a way to reproduce? > > Can you share your image? > > > -- > Best Regards, > Artem Bityutskiy > > > ______________________________________________________ > Linux MTD discussion mailing list > http://lists.infradead.org/mailman/listinfo/linux-mtd/