Oops on 2.6.31 with udev and root using ubifs
Hello,
I have just compiled a UBIFS enable 2.6.31 kernel and when I use it to boot with a NAND ubifs root partition, as soon as the udev daemon starts to populate the nodes, I get a Oops:
[ 59.261166] Unable to handle kernel paging request at virtual address fffffff0 [ 59.283061] pgd = c0004000 [ 59.291211] [fffffff0] *pgd=a0906021, *pte=00000000, *ppte=00000000 [ 59.317151] Internal error: Oops: 17 [#1] PREEMPT [ 59.331114] Modules linked in: [ 59.340167] CPU: 0 Not tainted (2.6.31-cmx0sc #20) [ 59.355456] PC is at ubi_leb_read+0x14/0x190 [ 59.368136] LR is at gluebi_read+0xdc/0x114 [ 59.380566] pc : [<c021c070>] lr : [<c0223ef0>] psr: 60000013 [ 59.380581] sp : e39b1eb8 ip : e39b1ef8 fp : e39b1ef4 [ 59.414702] r10: e3cbe4c0 r9 : 00000200 r8 : 00000000 [ 59.430237] r7 : e393e000 r6 : e3c5b000 r5 : 00000200 r4 : 00000200 [ 59.449648] r3 : 00000000 r2 : e3c5b000 r1 : 00000000 r0 : fffffff0 [ 59.469060] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 59.490795] Control: 0000397f Table: c3d74018 DAC: 00000035 [ 59.507880] Process mtdblockd (pid: 293, stack limit = 0xe39b0278) [ 59.526255] Stack: (0xe39b1eb8 to 0xe39b2000) [ 59.539200] 1ea0: c019effc e39b61c0 [ 59.563754] 1ec0: e3be1640 00000000 00000000 00000200 00000200 e3c5b000 e393e000 00000000 [ 59.588306] 1ee0: 00000200 e3cbe4c0 e39b1f34 e39b1ef8 c0223ef0 c021c068 00000200 00000000 [ 59.612861] 1f00: 00000000 00000000 e3be1640 00000000 e39b1f4c 00000200 00000000 00000000 [ 59.637415] 1f20: 0001f000 e3c5b000 e39b1f84 e39b1f38 c020d0dc c0223e20 00000200 e39b1f54 [ 59.661968] 1f40: e3c5b000 e3be1640 e39b1f6c e393e000 c0190cb0 c019b0c0 00000008 00000008 [ 59.686522] 1f60: e3be1640 00000000 c03fc1dc e3c5b000 00000000 e39ab900 e39b1fc4 e39b1f88 [ 59.711076] 1f80: c020c8a0 c020d08c c02d8350 e39b0000 e39ab910 e39b61c0 e39b1fc4 e3823f08 [ 59.735629] 1fa0: c03fc1dc c020c690 00000000 00000000 00000000 00000000 e39b1ff4 e39b1fc8 [ 59.760183] 1fc0: c005ff28 c020c69c 00000000 00000000 e39b1fd0 e39b1fd0 00000000 00000000 [ 59.784738] 1fe0: 00000000 00000000 00000000 e39b1ff8 c0025fe8 c005feac 2064656c 72642600 [ 59.809306] [<c021c070>] (ubi_leb_read+0x14/0x190) from [<c0223ef0>] (gluebi_read+0xdc/0x114) [ 59.834650] [<c0223ef0>] (gluebi_read+0xdc/0x114) from [<c020d0dc>] (mtdblock_readsect+0x5c/0x134) [ 59.861298] [<c020d0dc>] (mtdblock_readsect+0x5c/0x134) from [<c020c8a0>] (mtd_blktrans_thread+0x210/0x32c) [ 59.890244] [<c020c8a0>] (mtd_blktrans_thread+0x210/0x32c) from [<c005ff28>] (kthread+0x88/0x90) [ 59.916376] [<c005ff28>] (kthread+0x88/0x90) from [<c0025fe8>] (kernel_thread_exit+0x0/0x8) [ 59.941211] Code: e92ddff0 e24cb004 e24dd014 ebf823de (e5904000)
I think that the problem may be ralated to the fact that /dev/mtd6, which is emulated from ubi0_0 is "double-accessed" without proper lock or something else. Can someone give me a hint?
Best Regards,
P.S.: I'm not subscribed on the list
--
Raphael Derosso Pereira
DATAPROM®
Departamento de Engenharia
Tel.: +55 41 3014-1325
Fax.: +55 41 3014-1201
www.dataprom.com
Hi,
I think it's not ubifs bug. Instead it's related with mtd_blkdev.
Before read the ubi glue layer it should be call the get_device first.
Please see the following patch
http://git.infradead.org/mtd-2.6.git/commitdiff/8022c13c27b822cf22f13df10b42aae89cd56bf0
Thank you,
Kyungmin Park
Quoted 89 lines · Raphael Derosso Pereira
Hello,
I have just compiled a UBIFS enable 2.6.31 kernel and when I use it to boot with a NAND ubifs root partition, as soon as the udev daemon starts to populate the nodes, I get a Oops:
[ 59.261166] Unable to handle kernel paging request at virtual address
fffffff0
[ 59.283061] pgd =c0004000
[ 59.291211] [fffffff0] *pgd=a0906021, *pte=00000000, *ppte=00000000 [ 59.317151] Internal error: Oops: 17 [#1] PREEMPT
[ 59.331114] Modules linked in:
[ 59.340167] CPU: 0 Not tainted (2.6.31-cmx0sc #20)
[ 59.355456] PC is atubi_leb_read+0x14/0x190
[ 59.368136] LR is atgluebi_read+0xdc/0x114
[ 59.380566] pc : [<c021c070>] lr : [<c0223ef0>] psr: 60000013 [ 59.380581] sp :e39b1eb8ip :e39b1ef8fp :e39b1ef4
[ 59.414702] r10:e3cbe4c0r9 : 00000200 r8 : 00000000
[ 59.430237] r7 :e393e000r6 :e3c5b000r5 : 00000200 r4 :
00000200
[ 59.449648] r3 : 00000000 r2 :e3c5b000r1 : 00000000 r0 :fffffff0
[ 59.469060] Flags: nZCv IRQs on FIQs on ModeSVC_32ISA ARM Segment kernel
[ 59.490795] Control:0000397fTable:c3d74018DAC: 00000035 [ 59.507880] Process mtdblockd (pid: 293, stack limit =0xe39b0278) [ 59.526255] Stack: (0xe39b1eb8to0xe39b2000)
[ 59.539200] 1ea0:c019effce39b61c0
[ 59.563754] 1ec0:e3be164000000000 00000000 00000200 00000200e3c5b000e393e00000000000
[ 59.588306] 1ee0: 00000200e3cbe4c0e39b1f34e39b1ef8c0223ef0c021c06800000200 00000000
[ 59.612861] 1f00: 00000000 00000000e3be164000000000e39b1f4c00000200 00000000 00000000
[ 59.637415] 1f20:0001f000e3c5b000e39b1f84e39b1f38c020d0dcc0223e2000000200e39b1f54
[ 59.661968] 1f40:e3c5b000e3be1640e39b1f6ce393e000c0190cb0c019b0c000000008 00000008
[ 59.686522] 1f60:e3be164000000000c03fc1dce3c5b00000000000e39ab900e39b1fc4e39b1f88
[ 59.711076] 1f80:c020c8a0c020d08cc02d8350e39b0000e39ab910e39b61c0e39b1fc4e3823f08
[ 59.735629] 1fa0:c03fc1dcc020c69000000000 00000000 00000000 00000000e39b1ff4e39b1fc8
[ 59.760183] 1fc0:c005ff28c020c69c00000000 00000000e39b1fd0e39b1fd000000000 00000000
[ 59.784738] 1fe0: 00000000 00000000 00000000e39b1ff8c0025fe8c005feac2064656c72642600
[ 59.809306] [<c021c070>] (ubi_leb_read+0x14/0x190) from [<c0223ef0>] (gluebi_read+0xdc/0x114)
[ 59.834650] [<c0223ef0>] (gluebi_read+0xdc/0x114) from [<c020d0dc>] (mtdblock_readsect+0x5c/0x134)
[ 59.861298] [<c020d0dc>] (mtdblock_readsect+0x5c/0x134) from [<c020c8a0>] (mtd_blktrans_thread+0x210/0x32c)
[ 59.890244] [<c020c8a0>] (mtd_blktrans_thread+0x210/0x32c) from [<c005ff28>] (kthread+0x88/0x90)
[ 59.916376] [<c005ff28>] (kthread+0x88/0x90) from [<c0025fe8>] (kernel_thread_exit+0x0/0x8)
[ 59.941211] Code:e92ddff0e24cb004e24dd014ebf823de(e5904000)I think that the problem may be ralated to the fact that
/dev/mtd6, which is emulated fromubi0_0is "double-accessed" without proper lock or something else. Can someone give me a hint?Best Regards,
P.S.: I'm not subscribed on the list--
Raphael Derosso Pereira
DATAPROM®
Departamento de Engenharia
Tel.: +55 41 3014-1325
Fax.: +55 41 3014-1201www.dataprom.com
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Hello,
The patch is already applied. I have disabled gluebi from kernel (turned it to be compiled as module) and the Oops vanished. It really seems that the problem is related to have an UBI volume mounted and trying to use gluebi on top of that volume.
Best Regards,
Em Qua, 2009-09-16 às 08:21 +0900, Kyungmin Park escreveu:
Quoted 8 lines
Hi,
I think it's not ubifs bug. Instead it's related with
mtd_blkdev.Before read the ubi glue layer it should be call the
get_devicefirst.Please see the following patch
Quoted 96 lines
http://git.infradead.org/mtd-2.6.git/commitdiff/8022c13c27b822cf22f13df10b42aae89cd56bf0
Thank you,
Kyungmin ParkQuoted 89 lines · Raphael Derosso Pereira
Hello,
I have just compiled a UBIFS enable 2.6.31 kernel and when I use it to boot with a NAND ubifs root partition, as soon as the udev daemon starts to populate the nodes, I get a Oops:
[ 59.261166] Unable to handle kernel paging request at virtual address fffffff0 [ 59.283061] pgd = c0004000 [ 59.291211] [fffffff0] *pgd=a0906021, *pte=00000000, *ppte=00000000 [ 59.317151] Internal error: Oops: 17 [#1] PREEMPT [ 59.331114] Modules linked in: [ 59.340167] CPU: 0 Not tainted (2.6.31-cmx0sc #20) [ 59.355456] PC is at ubi_leb_read+0x14/0x190 [ 59.368136] LR is at gluebi_read+0xdc/0x114 [ 59.380566] pc : [<c021c070>] lr : [<c0223ef0>] psr: 60000013 [ 59.380581] sp : e39b1eb8 ip : e39b1ef8 fp : e39b1ef4 [ 59.414702] r10: e3cbe4c0 r9 : 00000200 r8 : 00000000 [ 59.430237] r7 : e393e000 r6 : e3c5b000 r5 : 00000200 r4 : 00000200 [ 59.449648] r3 : 00000000 r2 : e3c5b000 r1 : 00000000 r0 : fffffff0 [ 59.469060] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 59.490795] Control: 0000397f Table: c3d74018 DAC: 00000035 [ 59.507880] Process mtdblockd (pid: 293, stack limit = 0xe39b0278) [ 59.526255] Stack: (0xe39b1eb8 to 0xe39b2000) [ 59.539200] 1ea0: c019effc e39b61c0 [ 59.563754] 1ec0: e3be1640 00000000 00000000 00000200 00000200 e3c5b000 e393e000 00000000 [ 59.588306] 1ee0: 00000200 e3cbe4c0 e39b1f34 e39b1ef8 c0223ef0 c021c068 00000200 00000000 [ 59.612861] 1f00: 00000000 00000000 e3be1640 00000000 e39b1f4c 00000200 00000000 00000000 [ 59.637415] 1f20: 0001f000 e3c5b000 e39b1f84 e39b1f38 c020d0dc c0223e20 00000200 e39b1f54 [ 59.661968] 1f40: e3c5b000 e3be1640 e39b1f6c e393e000 c0190cb0 c019b0c0 00000008 00000008 [ 59.686522] 1f60: e3be1640 00000000 c03fc1dc e3c5b000 00000000 e39ab900 e39b1fc4 e39b1f88 [ 59.711076] 1f80: c020c8a0 c020d08c c02d8350 e39b0000 e39ab910 e39b61c0 e39b1fc4 e3823f08 [ 59.735629] 1fa0: c03fc1dc c020c690 00000000 00000000 00000000 00000000 e39b1ff4 e39b1fc8 [ 59.760183] 1fc0: c005ff28 c020c69c 00000000 00000000 e39b1fd0 e39b1fd0 00000000 00000000 [ 59.784738] 1fe0: 00000000 00000000 00000000 e39b1ff8 c0025fe8 c005feac 2064656c 72642600 [ 59.809306] [<c021c070>] (ubi_leb_read+0x14/0x190) from [<c0223ef0>] (gluebi_read+0xdc/0x114) [ 59.834650] [<c0223ef0>] (gluebi_read+0xdc/0x114) from [<c020d0dc>] (mtdblock_readsect+0x5c/0x134) [ 59.861298] [<c020d0dc>] (mtdblock_readsect+0x5c/0x134) from [<c020c8a0>] (mtd_blktrans_thread+0x210/0x32c) [ 59.890244] [<c020c8a0>] (mtd_blktrans_thread+0x210/0x32c) from [<c005ff28>] (kthread+0x88/0x90) [ 59.916376] [<c005ff28>] (kthread+0x88/0x90) from [<c0025fe8>] (kernel_thread_exit+0x0/0x8) [ 59.941211] Code: e92ddff0 e24cb004 e24dd014 ebf823de (e5904000)I think that the problem may be ralated to the fact that
/dev/mtd6, which is emulated fromubi0_0is "double-accessed" without proper lock or something else. Can someone give me a hint?Best Regards,
P.S.: I'm not subscribed on the list--
Raphael Derosso Pereira
DATAPROM®
Departamento de Engenharia
Tel.: +55 41 3014-1325
Fax.: +55 41 3014-1201www.dataprom.com
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
--
Raphael Derosso Pereira
DATAPROM®
Departamento de Engenharia
Tel.: +55 41 3014-1325
Fax.: +55 41 3014-1201
www.dataprom.com
Quoted 6 lines · Raphael Derosso Pereira
Hello,
The patch is already applied. I have disabled gluebi from kernel (turned it to be compiled as module) and the Oops vanished. It really seems that the problem is related to have an UBI volume mounted and trying to use gluebi on top of that volume.
I think I fixed this at some point:
and it is a 2.6.31. Are you sure you are using 2.6.31?
Signature · 2 lines
Best Regards, Artem Bityutskiy (Артём Битюцкий)
Hi,
I'm sure about 2.6.31 and have checked the sources to make sure the patch was there and it is.
--
Raphael Derosso Pereira
DATAPROM®
Departamento de Engenharia
Tel.: +55 41 3014-1325
Fax.: +55 41 3014-1201
www.dataprom.com
Em Qua, 2009-09-16 às 14:34 +0300, Artem Bityutskiy escreveu:
Quoted 14 lines · Raphael Derosso Pereira
Quoted 6 lines
Hello,
The patch is already applied. I have disabled gluebi from kernel (turned it to be compiled as module) and the Oops vanished. It really seems that the problem is related to have an UBI volume mounted and trying to use gluebi on top of that volume.
I think I fixed this at some point:
and it is a 2.6.31. Are you sure you are using 2.6.31?
Quoted 2 lines · Raphael Derosso Pereira
I'm sure about 2.6.31 and have checked the sources to make sure the patch was there and it is.
If you provide me a description how I can reproduce this with nandsim and mtdram, I'll try to investigate this.
Signature · 2 lines
Best Regards, Artem Bityutskiy (Артём Битюцкий)
I am not completely sure, but what I have here is an ubifs partition as root with gluebi compiled in kernel (not a module). My partition has udev, so just after mount, udev tries to read first 512 bytes from mtd6 (which in my case is attached to ubi0). That Oops.
--
Raphael Derosso Pereira
DATAPROM®
Departamento de Engenharia
Tel.: +55 41 3014-1325
Fax.: +55 41 3014-1201
www.dataprom.com
Em Qua, 2009-09-16 às 14:40 +0300, Artem Bityutskiy escreveu:
Quoted 7 lines · Raphael Derosso Pereira
Quoted 2 lines
I'm sure about 2.6.31 and have checked the sources to make sure the patch was there and it is.
If you provide me a description how I can reproduce this with nandsim and mtdram, I'll try to investigate this.