From mboxrd@z Thu Jan 1 00:00:00 1970 From: Edward Shishkin Subject: Re: Reiser4 for 3.16.2 problem: mount: mount /dev/md125 on /mnt/backup failed: Cannot allocate memory Date: Mon, 08 Dec 2014 20:27:00 +0100 Message-ID: <5485FB84.5010001@gmail.com> References: <5458CB45.2050303@gmail.com> <545965C7.5010304@gmail.com> <54665EFD.7030304@gmail.com> <547BACC8.6090805@gmail.com> <547BAF3D.1000605@gmail.com> <54843175.7010503@gmai l.com> <54858A06.1000504@gmail.com> Mime-Version: 1.0 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=bPLViOW8gT4Y5DyA3m83WPLs5wjm17gwYwoyfukwhjs=; b=aRWuZ/uQS0eOq9j8ddQTRTRGrM1clKy8TI6oMv/2TIh7U3zOn1ez80h6soCQF0+7AL 07Tdh96baZdhHE+qd6Y0yaakLzVoXf4Jhxt7B7JbhrtZKkg3LIIVTFDVr1Iu1vCKe0Si BEGlTG2QEJu7MbEMt9PcKNCI9ZEQ8GrnPET1jhjAh1GfnycvNy7gz02zU9M9b8lQWW2M Ppg1iOBZL9nARIdSnZmDW2GhyD/v+XnYKz5ruMiaK77NhSgluSQhrka38gTA0JJDzRfs HNLRFR2OzcmWWSQ7p3LbXkAfrkiPodB5gXqCPf7DS/sDnNclk67Ji/04DkhvsPfufQCf C9Gw== In-Reply-To: Sender: reiserfs-devel-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="utf-8"; format="flowed" To: =?UTF-8?B?RHXFoWFuIMSMb2xpxIc=?= Cc: reiserfs-devel , Ivan Shapovalov So in 3.16 when we ask for some memory, we get ENOMEM plus a corrupted root partition.. I would also check the stuff for 3.17 before doing anything. Thanks, Edward. On 12/08/2014 12:54 PM, Du=C5=A1an =C4=8Coli=C4=87 wrote: > On Mon, Dec 8, 2014 at 12:22 PM, Edward Shishkin > wrote: >> Is .config the same as in the stuff for 3.10? >> >> Thanks, >> Edward. >> > Only thing that jumps out that we haven't mentioned yet is optimize f= or size.... > I used same config for 3.16.2.patch and for 3.16ported-from3.11.patch > > http://marc.info/?l=3Dreiserfs-devel&m=3D141503126615043&w=3D2 > > " > > Last time I enabled page migration in kernel so I tried to find what'= s > the difference between kernel config that worked and that fails: > > krshina3 linux-3.16.5-gentoo # diff -du ./.config configBAD |grep > "+"|grep -v "#"|grep -v "@@" > --- ./.config 2014-11-03 17:09:03.895249969 +0100 > +++ configBAD 2014-10-24 01:27:07.677613236 +0200 > +CONFIG_CGROUPS=3Dy > +CONFIG_CGROUP_SCHED=3Dy > +CONFIG_FAIR_GROUP_SCHED=3Dy > +CONFIG_SCHED_AUTOGROUP=3Dy > +CONFIG_SCHED_MC=3Dy > +CONFIG_KSM=3Dy > +CONFIG_X86_INTEL_PSTATE=3Dy > +CONFIG_EDAC=3Dy > +CONFIG_EDAC_LEGACY_SYSFS=3Dy > +CONFIG_DEBUG_INFO=3Dy > +CONFIG_DEBUG_INFO_REDUCED=3Dy > +CONFIG_FRAME_POINTER=3Dy > > > krshina3 linux-3.16.5-gentoo # diff -du ./.config configBAD |grep > "-"|grep -v "#"|grep -v "@@" > --- ./.config 2014-11-03 17:09:03.895249969 +0100 > +++ configBAD 2014-10-24 01:27:07.677613236 +0200 > -CONFIG_USELIB=3Dy > -CONFIG_AUDIT=3Dy > -CONFIG_AUDITSYSCALL=3Dy > -CONFIG_AUDIT_WATCH=3Dy > -CONFIG_AUDIT_TREE=3Dy > -CONFIG_CC_OPTIMIZE_FOR_SIZE=3Dy > -CONFIG_GART_IOMMU=3Dy > -CONFIG_LCD_CLASS_DEVICE=3Dy > " > > >> >> On 12/08/2014 12:45 AM, Du=C5=A1an =C4=8Coli=C4=87 wrote: >>> On Sun, Dec 7, 2014 at 11:52 AM, Edward Shishkin >>> wrote: >>>> And the root partition became corrupted, or...? >>>> >>> Yes, just managed to fsck it now. >>> >>> fsck: >>> >>> CHECKING THE STORAGE TREE >>> $ >>> [=3D=3D\ ] 4% >>> $ >>> Nodes left in the tree 3678479 >>> Leaves of them 3626831, Twigs of them 50438 >>> Time interval: Sun Dec 7 23:22:35 2014 - Sun Dec 7 23:2= 5:26 >>> 2014 >>> CHECKING EXTENT REGIONS. >>> Read twigs 50438 >>> Time interval: Sun Dec 7 23:25:26 2014 - Sun Dec 7 23:2= 5:35 >>> 2014 >>> CHECKING THE SEMANTIC TREE >>> FSCK: >>> >>> /mkdeb/build/reiser4progs/reiser4progs/plugin/object/ccreg40/ccreg4= 0_repair.c: >>> 167: ccreg40_check_cluster: The file [1b529a6:134623831303736:1d80a= 73] >>> (ccreg40): the cluster at [0] offset 65536 bytes long is orphan. >>> Found 543127 objects (some could be encountered more then= once). >>> Time interval: Sun Dec 7 23:25:35 2014 - Sun Dec 7 23:2= 8:50 >>> 2014 >>> FSCK: /mkdeb/build/reiser4progs/reiser4progs/librepair/repair.c: 55= 0: >>> repair_sem_fini: On-disk used block bitmap and really used block bi= tmap >>> differ. >>> ***** fsck.reiser4 finished at Sun Dec 7 23:28:50 2014 >>> Closing fs...done >>> >>> >>> build-fs: >>> >>> FSCK: /mkdeb/build/reiser4progs/reiser4progs/librepair/node.c: 108: >>> repair_node_items_check: Node (4078203), items (60) and (61): Wrong= order >>> of >>> keys. >>> FSCK: /mkdeb/build/reiser4progs/reiser4progs/librepair/node.c: 108: >>> repair_node_items_check: Node (4078899), items (6) and (7): Wrong o= rder of >>> keys. >>> FSCK: /mkdeb/build/reiser4progs/reiser4progs/librepair/node.c: 108: >>> repair_node_items_check: Node (4079383), items (0) and (1): Wrong o= rder of >>> keys. >>> FSCK: /mkdeb/build/reiser4progs/reiser4progs/librepair/node.c: 108: >>> repair_node_items_check: Node (4079488), items (0) and (1): Wrong o= rder of >>> keys. >>> FSCK: /mkdeb/build/reiser4progs/reiser4progs/librepair/node.c: 108: >>> repair_node_items_check: Node (4079546), items (0) and (1): Wrong o= rder of >>> keys. >>> FSCK: /mkdeb/build/reiser4progs/reiser4progs/librepair/node.c: 108: >>> repair_node_items_check: Node (4080447), items (0) and (1): Wrong o= rder of >>> keys. >>> FSCK: /mkdeb/build/reiser4progs/reiser4progs/librepair/node.c: 108: >>> repair_node_items_check: Node (4080571), items (0) and (1): Wrong o= rder of >>> keys. >>> FSCK: /mkdeb/build/reiser4progs/reiser4progs/librepair/node.c: 108: >>> repair_node_items_check: Node (4081137), items (1) and (2): Wrong o= rder of >>> keys. >>> FSCK: /mkdeb/build/reiser4progs/reiser4progs/librepair/node.c: 108: >>> repair_node_items_check: Node (4090871), items (0) and (1): Wrong o= rder of >>> keys. >>> FSCK: /mkdeb/build/reiser4progs/reiser4progs/librepair/node.c: 108: >>> repair_node_items_check: Node (4091337), items (0) and (1): Wrong o= rder of >>> keys. >>> FSCK: /mkdeb/build/reiser4progs/reiser4progs/librepair/node.c: 108: >>> repair_node_items_check: Node (4091990), items (0) and (1): Wrong o= rder of >>> keys. >>> FSCK: /mkdeb/build/reiser4progs/reiser4progs/librepair/node.c: 108: >>> repair_node_items_check: Node (4092423), items (1) and (2): Wrong o= rder of >>> keys. >>> FSCK: /mkdeb/build/reiser4progs/reiser4progs/librepair/node.c: 108: >>> repair_node_items_check: Node (4093016), items (0) and (1): Wrong o= rder of >>> keys. >>> FSCK: /mkdeb/build/reiser4progs/reiser4progs/librepair/node.c: 108: >>> repair_node_items_check: Node (4093690), items (27) and (28): Wrong= order >>> of >>> keys. >>> FSCK: /mkdeb/build/reiser4progs/reiser4progs/librepair/node.c: 108: >>> repair_node_items_check: Node (4094525), items (0) and (1): Wrong o= rder of >>> keys. >>> FSCK: /mkdeb/build/reiser4progs/reiser4progs/librepair/node.c: 108: >>> repair_node_items_check: Node (4096175), items (0) and (1): Wrong o= rder of >>> keys. >>> FSCK: /mkdeb/build/reiser4progs/reiser4progs/librepair/node.c: 108: >>> repair_node_items_check: Node (4099659), items (12) and (13): Wrong= order >>> of >>> keys. >>> FSCK: /mkdeb/build/reiser4progs/reiser4progs/librepair/node.c: 108: >>> repair_node_items_check: Node (4099663), items (21) and (22): Wrong= order >>> of >>> keys. >>> FSCK: /mkdeb/build/reiser4progs/reiser4progs/librepair/node.c: 108: >>> repair_node_items_check: Node (4113492), items (0) and (1): Wrong o= rder of >>> keys. >>> >>>> Thanks, >>>> Edward. >>>> >>>> >>>> >>>> On 12/07/2014 09:07 AM, Du=C5=A1an =C4=8Coli=C4=87 wrote: >>>>> And on the 4th day: >>>>> >>>>> ### RSNAPSHOT DAILY ### >>>>> fsck.reiser4 /dev/md125 >>>>> mount: mount /dev/md125 on /mnt/backup failed: Cannot allocate me= mory >>>>> Backup failure >>>>> umount: /mnt/backup: not mounted >>>>> >>>>> >>>>> krshina3 ~ # cat /proc/meminfo >>>>> MemTotal: 7867900 kB >>>>> MemFree: 1553044 kB >>>>> MemAvailable: 4853752 kB >>>>> Buffers: 0 kB >>>>> Cached: 2975880 kB >>>>> SwapCached: 4944 kB >>>>> Active: 3780968 kB >>>>> Inactive: 2003640 kB >>>>> Active(anon): 2336740 kB >>>>> Inactive(anon): 498120 kB >>>>> Active(file): 1444228 kB >>>>> Inactive(file): 1505520 kB >>>>> Unevictable: 0 kB >>>>> Mlocked: 0 kB >>>>> SwapTotal: 594300 kB >>>>> SwapFree: 180008 kB >>>>> Dirty: 3064 kB >>>>> Writeback: 0 kB >>>>> AnonPages: 2804424 kB >>>>> Mapped: 180772 kB >>>>> Shmem: 26132 kB >>>>> Slab: 427632 kB >>>>> SReclaimable: 392984 kB >>>>> SUnreclaim: 34648 kB >>>>> KernelStack: 7536 kB >>>>> PageTables: 38328 kB >>>>> NFS_Unstable: 0 kB >>>>> Bounce: 0 kB >>>>> WritebackTmp: 0 kB >>>>> CommitLimit: 4528248 kB >>>>> Committed_AS: 5352472 kB >>>>> VmallocTotal: 34359738367 kB >>>>> VmallocUsed: 352244 kB >>>>> VmallocChunk: 34359293283 kB >>>>> HugePages_Total: 0 >>>>> HugePages_Free: 0 >>>>> HugePages_Rsvd: 0 >>>>> HugePages_Surp: 0 >>>>> Hugepagesize: 2048 kB >>>>> DirectMap4k: 12224 kB >>>>> DirectMap2M: 8056832 kB >>>>> >>>>> >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.958316] reiser4: md125: = found >>>>> disk format 4.0.0. >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.958998] mount: page >>>>> allocation failure: order:4, mode:0x2040d0 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959000] CPU: 2 PID: 7078 >>>>> Comm: mount Not tainted 3.16.5-gentoo #1 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959001] Hardware name: >>>>> Gigabyte Technology Co., Ltd. To be filled by O.E.M./B75-D3V, BIO= S F5 >>>>> 07/04/2012 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959003] 000000000000000= 6 >>>>> ffffffff8152bdfb 0000000000000001 ffffffff810b0bc3 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959005] ffffffff81818df= 8 >>>>> 0000000000000000 00000002fffffff0 0000000000000010 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959006] ffff8801007b27a= 0 >>>>> 0000000000000000 0000000000000010 0000204081818240 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959008] Call Trace: >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959011] [] >>>>> ? dump_stack+0x41/0x51 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959014] [] >>>>> ? warn_alloc_failed+0x10c/0x120 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959016] [] >>>>> ? __alloc_pages_nodemask+0x581/0x69d >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959019] [] >>>>> ? cache_alloc_refill+0x261/0x48c >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959022] [] >>>>> ? reiser4_mount+0xc/0xc >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959024] [] >>>>> ? kmem_cache_alloc+0x6d/0xa1 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959026] [] >>>>> ? znodes_tree_init+0xb9/0xe6 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959028] [] >>>>> ? reiser4_init_tree+0x3f/0xb2 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959031] [] >>>>> ? init_format_format40+0x357/0x4e4 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959033] [] >>>>> ? wake_up_bit+0xc/0x1b >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959035] [] >>>>> ? fill_super+0xcb/0x1ad >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959037] [] >>>>> ? mount_bdev+0x133/0x186 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959039] [] >>>>> ? mount_fs+0xc/0x9e >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959041] [] >>>>> ? vfs_kern_mount+0x5e/0xef >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959042] [] >>>>> ? do_mount+0x80b/0x904 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959044] [] >>>>> ? SyS_mount+0x7e/0xb7 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959046] [] >>>>> ? system_call_fastpath+0x16/0x1b >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959047] Mem-Info: >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959048] DMA per-cpu: >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959049] CPU 0: hi: = 0, >>>>> btch: 1 usd: 0 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959050] CPU 1: hi: = 0, >>>>> btch: 1 usd: 0 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959051] CPU 2: hi: = 0, >>>>> btch: 1 usd: 0 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959052] CPU 3: hi: = 0, >>>>> btch: 1 usd: 0 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959052] DMA32 per-cpu: >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959053] CPU 0: hi: 1= 86, >>>>> btch: 31 usd: 0 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959054] CPU 1: hi: 1= 86, >>>>> btch: 31 usd: 0 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959055] CPU 2: hi: 1= 86, >>>>> btch: 31 usd: 0 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959056] CPU 3: hi: 1= 86, >>>>> btch: 31 usd: 0 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959057] Normal per-cpu: >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959057] CPU 0: hi: 1= 86, >>>>> btch: 31 usd: 0 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959058] CPU 1: hi: 1= 86, >>>>> btch: 31 usd: 0 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959059] CPU 2: hi: 1= 86, >>>>> btch: 31 usd: 0 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959060] CPU 3: hi: 1= 86, >>>>> btch: 31 usd: 0 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959062] active_anon:5930= 69 >>>>> inactive_anon:120226 isolated_anon:0 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959062] active_file:503= 137 >>>>> inactive_file:503029 isolated_file:0 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959062] unevictable:0 >>>>> dirty:333 writeback:0 unstable:0 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959062] free:104532 >>>>> slab_reclaimable:109978 slab_unreclaimable:8402 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959062] mapped:51579 >>>>> shmem:5928 pagetables:9488 bounce:0 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959062] free_cma:0 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959068] DMA free:15900kB >>>>> min:20kB low:24kB high:28kB active_anon:0kB inactive_anon:0kB >>>>> active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon= ):0kB >>>>> isolated(file):0kB present:15984kB managed:15900kB mlocked:0kB >>>>> dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB >>>>> slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0= kB >>>>> bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 >>>>> all_unreclaimable? yes >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959069] lowmem_reserve[]= : 0 >>>>> 2952 7667 7667 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959074] DMA32 free:16802= 8kB >>>>> min:4308kB low:5384kB high:6460kB active_anon:837216kB >>>>> inactive_anon:214776kB active_file:790440kB inactive_file:790440= kB >>>>> unevictable:0kB isolated(anon):0kB isolated(file):0kB >>>>> present:3098560kB managed:3023876kB mlocked:0kB dirty:316kB >>>>> writeback:0kB mapped:78860kB shmem:8760kB slab_reclaimable:171284= kB >>>>> slab_unreclaimable:11888kB kernel_stack:2240kB pagetables:16348kB >>>>> unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scan= ned:0 >>>>> all_unreclaimable? no >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959075] lowmem_reserve[]= : 0 0 >>>>> 4714 4714 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959079] Normal free:2342= 00kB >>>>> min:6880kB low:8600kB high:10320kB active_anon:1535060kB >>>>> inactive_anon:266128kB active_file:1222108kB inactive_file:12216= 76kB >>>>> unevictable:0kB isolated(anon):0kB isolated(file):0kB >>>>> present:4954112kB managed:4828124kB mlocked:0kB dirty:1016kB >>>>> writeback:0kB mapped:127456kB shmem:14952kB slab_reclaimable:2686= 28kB >>>>> slab_unreclaimable:21720kB kernel_stack:4976kB pagetables:21604kB >>>>> unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scan= ned:0 >>>>> all_unreclaimable? no >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959080] lowmem_reserve[]= : 0 0 0 >>>>> 0 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959081] DMA: 1*4kB (U) 1= *8kB >>>>> (U) 1*16kB (U) 0*32kB 2*64kB (U) 1*128kB (U) 1*256kB (U) 0*512kB >>>>> 1*1024kB (U) 1*2048kB (R) 3*4096kB (M) =3D 15900kB >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959088] DMA32: 36545*4kB >>>>> (UEM) 2543*8kB (UEM) 70*16kB (UMR) 0*32kB 0*64kB 1*128kB (R) 0*25= 6kB >>>>> 1*512kB (R) 0*1024kB 0*2048kB 0*4096kB =3D 168284kB >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959093] Normal: 50408*4k= B >>>>> (UEM) 3913*8kB (UEM) 36*16kB (UMR) 0*32kB 1*64kB (R) 1*128kB (R) >>>>> 1*256kB (R) 1*512kB (R) 0*1024kB 0*2048kB 0*4096kB =3D 234472kB >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959099] Node 0 >>>>> hugepages_total=3D0 hugepages_free=3D0 hugepages_surp=3D0 >>>>> hugepages_size=3D2048kB >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959100] 1013453 total pa= gecache >>>>> pages >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959101] 1228 pages in sw= ap >>>>> cache >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959102] Swap cache stats= : add >>>>> 133257, delete 132029, find 57308/68141 >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959103] Free swap =3D 1= 84632kB >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959103] Total swap =3D 5= 94300kB >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959104] 2017164 pages RA= M >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959105] 0 pages >>>>> HighMem/MovableOnly >>>>> Dec 7 03:30:01 krshina3 kernel: [281555.959106] 31497 pages rese= rved >>>>> >>>>> On Wed, Dec 3, 2014 at 9:16 PM, Du=C5=A1an =C4=8Coli=C4=87 wrote: >>>>>> On Mon, Dec 1, 2014 at 12:58 AM, Edward Shishkin >>>>>> wrote: >>>>>>> On 12/01/2014 12:53 AM, Du=C5=A1an =C4=8Coli=C4=87 wrote: >>>>>>> >>>>>>> >>>>>>> On Dec 1, 2014 12:47 AM, "Edward Shishkin" >>>>>>> wrote: >>>>>>>> On 12/01/2014 12:04 AM, Du=C5=A1an =C4=8Coli=C4=87 wrote: >>>>>>>>> On Fri, Nov 14, 2014 at 9:09 PM, Du=C5=A1an =C4=8Coli=C4=87 >>>>>>>>> wrote: >>>>>>>>>> As I had no time to make a full backup I went back to 3.10 k= ernel >>>>>>>>>> and >>>>>>>>>> had no >>>>>>>>>> problem since. >>>>>>>>>> >>>>>>>>>> Could this issue be connected with those firefox cache files= that >>>>>>>>>> were >>>>>>>>>> bad >>>>>>>>>> (see other mail thread) so I deleted them but for some reaso= n they >>>>>>>>>> continued >>>>>>>>>> making problems or problem wasn't really solved by deletion?= I ask >>>>>>>>>> this >>>>>>>>>> as >>>>>>>>>> after long time of stable r4 I got 2 problems in same week s= o >>>>>>>>>> they're >>>>>>>>>> probably related. >>>>>>>>>> >>>>>>>>>> On Nov 14, 2014 8:58 PM, "Edward Shishkin" >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>> On 11/05/2014 12:04 PM, Du=C5=A1an =C4=8Coli=C4=87 wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Nov 5, 2014 12:48 AM, "Edward Shishkin" >>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>>> On 11/04/2014 02:16 PM, Du=C5=A1an =C4=8Coli=C4=87 wrote: >>>>>>>>>>>>> Did a fsck of source partition. >>>>>>>>>>>>> Btw. why is there a reason this corruption appeared when = I >>>>>>>>>>>>> started >>>>>>>>>>>>> using 3.16.2 instead 3.10? >>>>>>>>>>>>> >>>>>>>>>>>> I would also suspect this failed mount. >>>>>>>>>>>> It could have fatal consequences for the system, and, in >>>>>>>>>>>> particular >>>>>>>>>>>> for >>>>>>>>>>>> your ''/". >>>>>>>>>>>> >>>>>>>>>>> Failed mount happened on the partition that I was copying >>>>>>>>>>> to,/mnt/backup, >>>>>>>>>>> and it fscked ok. >>>>>>>>>>> / was partition I was copying from and it had errors. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi Du=C5=A1an, >>>>>>>>>>> >>>>>>>>>>> So, how is your / ? >>>>>>>>> So I was feeling brave so I put 3.16.2 back 4 days ago and I = got >>>>>>>>> this: >>>>>>>>> >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.436017] ------------= [ cut >>>>>>>>> here ]------------ >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.436320] kernel BUG a= t >>>>>>>>> fs/reiser4/plugin/item/ctail.c:669! >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.436652] invalid opco= de: >>>>>>>>> 0000 >>>>>>>>> [#1] SMP >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.436899] CPU: 3 PID: = 30235 >>>>>>>>> Comm: rsync Not tainted 3.16.5-gentoo #2 >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.437275] Hardware nam= e: >>>>>>>>> Gigabyte Technology Co., Ltd. To be filled by O.E.M./B75-D3V,= BIOS >>>>>>>>> F5 >>>>>>>>> 07/04/2012 >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.437834] task: >>>>>>>>> ffff8801333d4010 ti: ffff880118218000 task.ti: ffff8801182180= 00 >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.438264] RIP: >>>>>>>>> 0010:[] [] >>>>>>>>> do_readpage_ctail+0x2c5/0x3c4 >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.438768] RSP: >>>>>>>>> 0018:ffff88011821baa8 EFLAGS: 00010246 >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.439073] RAX: >>>>>>>>> 0000000000000000 >>>>>>>>> RBX: ffff88011821bb78 RCX: 000000000002f35d >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.439484] RDX: >>>>>>>>> 000000000000002f >>>>>>>>> RSI: 0000000000000000 RDI: ffff8800b953b000 >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.439894] RBP: >>>>>>>>> ffff880169d231a0 >>>>>>>>> R08: 0000000000000000 R09: 0000000000000000 >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.440304] R10: >>>>>>>>> ffffffff8114eb84 >>>>>>>>> R11: 0000000000012368 R12: 0000000000000002 >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.440713] R13: >>>>>>>>> 0000000000001000 >>>>>>>>> R14: ffffea00052f5158 R15: 0000000000000000 >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.441124] FS: >>>>>>>>> 00007f3d4d434700(0000) GS:ffff88022e380000(0000) >>>>>>>>> knlGS:0000000000000000 >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.441589] CS: 0010 DS= : 0000 >>>>>>>>> ES: 0000 CR0: 0000000080050033 >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.441918] CR2: >>>>>>>>> 0000000000980000 >>>>>>>>> CR3: 00000001a0c03000 CR4: 00000000001427e0 >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.442327] Stack: >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.442443] 00000000000= 00000 >>>>>>>>> ffff88011821bb78 0000000000000000 ffff880169d231a0 >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.442890] 00000000000= 00000 >>>>>>>>> ffffea00052f5158 0000000000000000 ffffffff8115ad7b >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.443336] 00000000000= aa1a1 >>>>>>>>> ffff88011821bca0 ffffea00052f5158 ffff880169d232e0 >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.443784] Call Trace: >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.443926] >>>>>>>>> [] >>>>>>>>> ? ctail_readpages_filler+0x188/0x1c9 >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.444302] >>>>>>>>> [] >>>>>>>>> ? do_readpage_ctail+0x3c4/0x3c4 >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.444655] >>>>>>>>> [] >>>>>>>>> ? read_cache_pages+0x91/0xfc >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.444990] >>>>>>>>> [] >>>>>>>>> ? readpages_ctail+0x2c8/0x2e5 >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.445332] >>>>>>>>> [] >>>>>>>>> ? readpages_cryptcompress+0x39/0x5f >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.445704] >>>>>>>>> [] >>>>>>>>> ? __do_page_cache_readahead+0x136/0x1d0 >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.446094] >>>>>>>>> [] >>>>>>>>> ? ondemand_readahead+0x1f5/0x203 >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.446450] >>>>>>>>> [] >>>>>>>>> ? generic_file_read_iter+0x191/0x539 >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.446827] >>>>>>>>> [] >>>>>>>>> ? path_openat+0x24b/0x5ce >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.447147] >>>>>>>>> [] >>>>>>>>> ? new_sync_read+0x6b/0x8f >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.447469] >>>>>>>>> [] >>>>>>>>> ? read_cryptcompress+0x6f/0x97 >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.447815] >>>>>>>>> [] >>>>>>>>> ? reiser4_read_dispatch+0xc7/0x11e >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.448181] >>>>>>>>> [] >>>>>>>>> ? vfs_read+0x84/0x13e >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.448483] >>>>>>>>> [] >>>>>>>>> ? SyS_read+0x41/0x84 >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.448780] >>>>>>>>> [] >>>>>>>>> ? system_call_fastpath+0x16/0x1b >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.449135] Code: 01 00 = 00 e9 >>>>>>>>> 00 >>>>>>>>> ff ff ff 8b 43 58 41 0f b7 4d 04 48 8d 04 48 48 89 54 c3 28 e= 9 ea fe >>>>>>>>> ff ff 44 8b a3 88 00 00 00 41 83 fc 02 75 02 <0f> 0b 0f 87 87= 00 00 >>>>>>>>> 00 >>>>>>>>> 41 83 fc 01 0f 85 de 00 00 00 49 8b 56 >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.450567] RIP >>>>>>>>> [] do_readpage_ctail+0x2c5/0x3c4 >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.450934] RSP >>>>>>>>> >>>>>>>>> Nov 30 03:30:36 krshina3 kernel: [293446.562843] ---[ end tra= ce >>>>>>>>> 45473ce04b35219f ]--- >>>>>>>>> >>>>>>>>> Looks like same error like last time I used 3.16. Kernel 3.10= lasted >>>>>>>>> with 20 days uptime without problems this month and 3.16 had = this >>>>>>>>> oops >>>>>>>>> after 3 days. >>>>>>>> >>>>>>>> Unfortunately, there is no any ideas... >>>>>>>> I can port reiser4-for-3.10 stuff to 3.16. Will you test this = port? >>>>>>>> >>>>>>> Ofcourse! >> -- To unsubscribe from this list: send the line "unsubscribe reiserfs-deve= l" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html