Skip to contentSkip to conversation

Oops on 2.6.31 with udev and root using ubifs

DISCUSSION Raphael Derosso Pereira 3 participants 7 messages Sep 15, 2009 – Sep 16, 2009 Memory technology devices (MTD)

lore
Share & tools
lore
#0 lore raw

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

[email protected]

www.dataprom.com

#1 lore raw

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 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

[email protected]

www.dataprom.com

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

#2 lore raw

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_device first.

Please see the following patch

Quoted 96 lines

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 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

[email protected]

www.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

[email protected]

www.dataprom.com

#3 lore raw
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:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8022c13c27b822cf22f13df10b42aae89cd56bf0

and it is a 2.6.31. Are you sure you are using 2.6.31?

Signature · 2 lines
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
#4 lore raw

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

[email protected]

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:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8022c13c27b822cf22f13df10b42aae89cd56bf0

and it is a 2.6.31. Are you sure you are using 2.6.31?

#5 lore raw
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 (Артём Битюцкий)
#6 lore raw

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

[email protected]

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.