Skip to contentSkip to conversation

Kernel BUG when writing to f2fs drive, PowerPC, SD card, USB3

f2fs-dev New Oded Gabbay 3 participants 13 messages Jun 16, 2013 – Jun 20, 2013 F2FS file system

lore
Share & tools
lore
#0 lore raw

Hi,

I'm working on a custom board with a PowerPC processor (Freescale P2020).
On the board there is an SD card, which is connected to a USB3 chip (from TI), which is connected to the PCI-e controller of the CPU. I'm running with Linux kernel 3.9.6, with our custom rootFS.

I formatted an SD card using the mkfs.f2fs utility (after fixing some Big-endian issues - sent a patch a few days ago).
I then mounted the SD card, using "mount -o noatime,nodiratime,rw,nosuid,nodev,relatime,active_logs=6,uhelper=udisks2,background_gc_off /dev/sda /mnt/sd1" Then, I started a small user-space test application which opens a file on the mount folder and starts to do "fwrite" into the file. After 2-3 seconds, the kernel gives me a BUG and the system restarts.
When the system is up and I try to re-mount the SD card, I get the following error message:

F2FS-fs (sda): Failed to get valid F2FS checkpoint
mount: you must specify the filesystem type

Only way is to re-format the card using mkfs.f2fs

I took the f2fs patch that Jaegeuk Kim sent to Linus for 3.10 (here - https://lkml.org/lkml/2013/5/8/122) and applied it cleanly to 3.9.6 I repeated the procedure but got the same result.

The BUG is from this line, from segment.c:

        if (!f2fs_clear_bit(offset, se->cur_valid_map))
            BUG();

Additional information I can give is

1. I tried using F2FS in ArchLinux, kernel 3.9.5, on an x86 machine, with the same SD card and the same USB3-to-PCIe chip and it worked flawlessly there.
2. I can work with other FS on the SD card on our custom board, such as Ext3, Ext4 and vfat, so this is not a H/W issue.

Could you please try to help me pinpoint/debug the problem ?

Here is the complete kernel BUG print:

kernel BUG at .../linux-3.9.6-adva/fs/f2fs/segment.c:214!

Oops: Exception in kernel mode, sig: 5 [#1]
PREEMPT SMP NR_CPUS=2 P2020 FSP150
Modules linked in: mdio(O) hardware_version(PO) clipresent(PO) monotonic(O) restartcause(PO) panic_buffer(O)
NIP: c026a7e0 LR: c026a660 CTR: 00000000
REGS: ee761a60 TRAP: 0700   Tainted: P           O (3.9.6-dev_ogabbay-109482*)
MSR: 00029000 <CE,EE,ME>  CR: 24a52588  XER: 20000000

TASK = efb444c0[1755] 'flush-8:0' THREAD: ee760000 CPU: 1
GPR00: 00000000 ee761b10 efb444c0 0000004c 00000000 00000000 01dc4900 eb0fa700
GPR08: 00000000 eb24cb00 00000040 00000040 00000038 00000000 ee761c64 00000000
GPR16: c0aeea80 00080000 00000000 00000000 0000ed31 eb0fa700 00000000 eb0fa734
GPR24: eb0fa700 00000080 f2030620 ffffffff ffffffc8 0000ed31 ffffffff c55a1000 NIP [c026a7e0] update_sit_entry+0x240/0x248
LR [c026a660] update_sit_entry+0xc0/0x248

Call Trace:

[ee761b10] [c55a1000] 0xc55a1000 (unreliable)
[ee761b40] [c026d1f4] do_write_page+0x198/0x660
[ee761b80] [c026d84c] write_data_page+0xa4/0xb8
[ee761bc0] [c0265118] do_write_data_page+0x1e8/0x20c [ee761c20] [c02653dc] f2fs_write_data_page+0x2a0/0x2c0 [ee761c40] [c0263ad8] __f2fs_writepage+0x24/0x80
[ee761c50] [c00b05dc] write_cache_pages+0x1d0/0x35c [ee761d00] [c0263cf4] f2fs_write_data_pages+0xf4/0xfc [ee761d30] [c00b1d3c] do_writepages+0x30/0x64
[ee761d40] [c0103fbc] __writeback_single_inode+0x34/0x10c [ee761d60] [c0104ef8] writeback_sb_inodes+0x204/0x370 [ee761dd0] [c01050f4] __writeback_inodes_wb+0x90/0xd4 [ee761e00] [c01054cc] wb_writeback+0x204/0x20c
[ee761e50] [c0105844] wb_do_writeback+0x144/0x20c
[ee761eb0] [c0105980] bdi_writeback_thread+0x74/0x144 [ee761ee0] [c0059dc4] kthread+0xa8/0xac
[ee761f40] [c000f014] ret_from_kernel_thread+0x64/0x6c Instruction dump:
4bffff2c 813a0004 5720e8fe 7f39c8f8 39400001 5739077e 7d6900ae 7d59c830 7d6ac878 7d68c839 7d4901ae 4082fef0 <0fe00000> 0fe00000 9421ffe0 7c0802a6

Signature · 14 lines
Best regards,
Oded Gabbay
Principal Engineer Advanced Packet Technologies
ADVA Optical Networking Israel Ltd.
P.O. Box 2552
2 Hatidhar St.
Raanana 4366504, Israel
Tel: +(972)-9-7750130
Fax: +(972)-9-7462092
Mobile: +(972)-54-6543998
E-mail: [email protected] <%5C%22mailto:[email protected]%5C%22>
www.advaoptical.com <%5C%22http://www.advaoptical.com%5C%22>
*Let's ADVANCE*
ADVA Optical Networking SE is a European stock corporation (\"Societas Europaea\") with registered offices at Maerzenquelle 1-3, D-98617 Meiningen, Germany * CEO: Brian L. Protiva, Chief Officers: Dr. Christoph Glingener, Christian Unterberger, Jaswir Singh * Chairman of the Supervisory Board: Anthony Maher * AG Jena HRB 508155 * VAT No. DE 175 446 349

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev

_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

#1 lore raw

Hi,
Is it possible caused by bitmap ? you know, bitmaps are unsigned variable, while f2fs_{clear, set, test}_bit() parameter is signed variable.
So, could you please try following patch, and update the same issue in mkfs.f2fs tool.

fs/f2fs/f2fs.h +4 -4
index 3e7cb33..28d31f1 100644
@@ -209,7 +209,7 @@ struct f2fs_nm_info {
     struct mutex build_lock;    /* lock for build free nids */
 
     /* for checkpoint */
-    char *nat_bitmap;        /* NAT bitmap pointer */
+    unsigned char *nat_bitmap;    /* NAT bitmap pointer */
     int bitmap_size;        /* bitmap size */
 };
 
@@ -820,7 +820,7 @@ static inline block_t datablock_addr(struct page *node_page,
     return le32_to_cpu(addr_array[offset]);
 }
 
-static inline int f2fs_test_bit(unsigned int nr, char *addr)
+static inline int f2fs_test_bit(unsigned int nr, unsigned char *addr)
 {
     int mask;
 
@@ -829,7 +829,7 @@ static inline int f2fs_test_bit(unsigned int nr, char *addr)
     return mask & *addr;
 }
 
-static inline int f2fs_set_bit(unsigned int nr, char *addr)
+static inline int f2fs_set_bit(unsigned int nr, unsigned char *addr)
 {
     int mask;
     int ret;
@@ -841,7 +841,7 @@ static inline int f2fs_set_bit(unsigned int nr, char *addr)
     return ret;
 }
 
-static inline int f2fs_clear_bit(unsigned int nr, char *addr)
+static inline int f2fs_clear_bit(unsigned int nr, unsigned char *addr)
 {
     int mask;
     int ret;
fs/f2fs/segment.c +1 -1
index b15debc..b191449 100644
@@ -1402,7 +1402,7 @@ static int build_sit_info(struct f2fs_sb_info *sbi)
     struct f2fs_checkpoint *ckpt = F2FS_CKPT(sbi);
     struct sit_info *sit_i;
     unsigned int sit_segs, start;
-    char *src_bitmap, *dst_bitmap;
+    unsigned char *src_bitmap, *dst_bitmap;
     unsigned int bitmap_size;
 
     /* allocate memory for SIT information */
fs/f2fs/segment.h +1 -1
index 062424a..a96f7f4 100644
@@ -175,7 +175,7 @@ struct sit_info {
     block_t sit_base_addr;        /* start block address of SIT area */
     block_t sit_blocks;        /* # of blocks used by SIT area */
     block_t written_valid_blocks;    /* # of valid blocks in main area */
-    char *sit_bitmap;        /* SIT bitmap pointer */
+    unsigned char *sit_bitmap;    /* SIT bitmap pointer */
     unsigned int bitmap_size;    /* SIT bitmap size */
 
     unsigned long *dirty_sentries_bitmap;    /* bitmap for dirty sentries */
Quoted 111 lines · Oded Gabbay

Hi,

I'm working on a custom board with a PowerPC processor (Freescale P2020). On the board there is an SD card, which is connected to a USB3 chip (from TI), which is connected to the PCI-e controller of the CPU. I'm running with Linux kernel 3.9.6, with our custom rootFS.

I formatted an SD card using the mkfs.f2fs utility (after fixing some Big-endian issues - sent a patch a few days ago).
I then mounted the SD card, using "mount -o noatime,nodiratime,rw,nosuid,nodev,relatime,active_logs=6,uhelper=udisks2,background_gc_off /dev/sda /mnt/sd1"
Then, I started a small user-space test application which opens a file on the mount folder and starts to do "fwrite" into the file.
After 2-3 seconds, the kernel gives me a BUG and the system restarts.
When the system is up and I try to re-mount the SD card, I get the following error message:

F2FS-fs (sda): Failed to get valid F2FS checkpoint
mount: you must specify the filesystem type

Only way is to re-format the card using mkfs.f2fs

I took the f2fs patch that Jaegeuk Kim sent to Linus for 3.10 (here -
https://lkml.org/lkml/2013/5/8/122) and applied it cleanly to 3.9.6 I repeated the procedure but got the same result.

The BUG is from this line, from segment.c:

        if (!f2fs_clear_bit(offset, se->cur_valid_map))
            BUG();

Additional information I can give is

1. I tried using F2FS in ArchLinux, kernel 3.9.5, on an x86 machine, with the same SD card and the same USB3-to-PCIe chip and it worked flawlessly there.
2. I can work with other FS on the SD card on our custom board, such as Ext3, Ext4 and vfat, so this is not a H/W issue.

Could you please try to help me pinpoint/debug the problem ?

Here is the complete kernel BUG print:

kernel BUG at .../linux-3.9.6-adva/fs/f2fs/segment.c:214!

Oops: Exception in kernel mode, sig: 5 [#1]
PREEMPT SMP NR_CPUS=2 P2020 FSP150
Modules linked in: mdio(O) hardware_version(PO) clipresent(PO) monotonic(O)

restartcause(PO) panic_buffer(O)
NIP: c026a7e0 LR: c026a660 CTR: 00000000
REGS: ee761a60 TRAP: 0700 Tainted: P O
(3.9.6-dev_ogabbay-109482*)
MSR: 00029000 <CE,EE,ME> CR: 24a52588 XER: 20000000
TASK = efb444c0[1755] 'flush-8:0' THREAD: ee760000 CPU: 1
GPR00: 00000000 ee761b10 efb444c0 0000004c 00000000 00000000 01dc4900 eb0fa700
GPR08: 00000000 eb24cb00 00000040 00000040 00000038 00000000 ee761c64 00000000
GPR16: c0aeea80 00080000 00000000 00000000 0000ed31 eb0fa700 00000000 eb0fa734
GPR24: eb0fa700 00000080 f2030620 ffffffff ffffffc8 0000ed31 ffffffff c55a1000
NIP [c026a7e0] update_sit_entry+0x240/0x248
LR [c026a660] update_sit_entry+0xc0/0x248

Call Trace:

[ee761b10] [c55a1000] 0xc55a1000 (unreliable)
[ee761b40] [c026d1f4] do_write_page+0x198/0x660
[ee761b80] [c026d84c] write_data_page+0xa4/0xb8
[ee761bc0] [c0265118] do_write_data_page+0x1e8/0x20c [ee761c20] [c02653dc] f2fs_write_data_page+0x2a0/0x2c0 [ee761c40] [c0263ad8] __f2fs_writepage+0x24/0x80
[ee761c50] [c00b05dc] write_cache_pages+0x1d0/0x35c [ee761d00] [c0263cf4] f2fs_write_data_pages+0xf4/0xfc [ee761d30] [c00b1d3c] do_writepages+0x30/0x64
[ee761d40] [c0103fbc] __writeback_single_inode+0x34/0x10c [ee761d60] [c0104ef8] writeback_sb_inodes+0x204/0x370 [ee761dd0] [c01050f4] __writeback_inodes_wb+0x90/0xd4 [ee761e00] [c01054cc] wb_writeback+0x204/0x20c
[ee761e50] [c0105844] wb_do_writeback+0x144/0x20c
[ee761eb0] [c0105980] bdi_writeback_thread+0x74/0x144 [ee761ee0] [c0059dc4] kthread+0xa8/0xac
[ee761f40] [c000f014] ret_from_kernel_thread+0x64/0x6c Instruction dump:
4bffff2c 813a0004 5720e8fe 7f39c8f8 39400001 5739077e 7d6900ae 7d59c830 7d6ac878 7d68c839 7d4901ae 4082fef0 <0fe00000> 0fe00000 9421ffe0 7c0802a6

--
Best regards,
Oded Gabbay
Principal Engineer Advanced Packet Technologies
ADVA Optical Networking Israel Ltd.
P.O. Box 2552
2 Hatidhar St.
Raanana 4366504, Israel
Tel: +(972)-9-7750130
Fax: +(972)-9-7462092
Mobile: +(972)-54-6543998
E-mail: [email protected]

www.advaoptical.com
Let's ADVANCE

ADVA Optical Networking SE is a European stock corporation (\"Societas Europaea\") with registered offices at Maerzenquelle 1-3, D-98617 Meiningen, Germany * CEO: Brian L. Protiva, Chief Officers: Dr. Christoph Glingener, Christian Unterberger, Jaswir Singh * Chairman of the Supervisory Board:
Anthony Maher * AG Jena HRB 508155 * VAT No. DE 175 446 349

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Quoted 8 lines

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev

#2 lore raw

Hi,

Thanks for the patch.
Unfortunately, I tried it and it didn't help. I got the same result. Oded

Quoted 186 lines · Huajun Li

Hi,
Is it possible caused by bitmap ? you know, bitmaps are unsigned variable, while f2fs_{clear, set, test}_bit() parameter is signed variable.
So, could you please try following patch, and update the same issue in mkfs.f2fs tool.

fs/f2fs/f2fs.h +4 -4
index 3e7cb33..28d31f1 100644
@@ -209,7 +209,7 @@ struct f2fs_nm_info {
      struct mutex build_lock;    /* lock for build free nids */
 
      /* for checkpoint */
-    char *nat_bitmap;        /* NAT bitmap pointer */
+    unsigned char *nat_bitmap;    /* NAT bitmap pointer */
      int bitmap_size;        /* bitmap size */
  };
 
@@ -820,7 +820,7 @@ static inline block_t datablock_addr(struct page *node_page,
      return le32_to_cpu(addr_array[offset]);
  }
 
-static inline int f2fs_test_bit(unsigned int nr, char *addr)
+static inline int f2fs_test_bit(unsigned int nr, unsigned char *addr)
  {
      int mask;
 
@@ -829,7 +829,7 @@ static inline int f2fs_test_bit(unsigned int nr, char *addr)
      return mask & *addr;
  }
 
-static inline int f2fs_set_bit(unsigned int nr, char *addr)
+static inline int f2fs_set_bit(unsigned int nr, unsigned char *addr)
  {
      int mask;
      int ret;
@@ -841,7 +841,7 @@ static inline int f2fs_set_bit(unsigned int nr, char *addr)
      return ret;
  }
 
-static inline int f2fs_clear_bit(unsigned int nr, char *addr)
+static inline int f2fs_clear_bit(unsigned int nr, unsigned char *addr)
  {
      int mask;
      int ret;
fs/f2fs/segment.c +1 -1
index b15debc..b191449 100644
@@ -1402,7 +1402,7 @@ static int build_sit_info(struct f2fs_sb_info *sbi)
      struct f2fs_checkpoint *ckpt = F2FS_CKPT(sbi);
      struct sit_info *sit_i;
      unsigned int sit_segs, start;
-    char *src_bitmap, *dst_bitmap;
+    unsigned char *src_bitmap, *dst_bitmap;
      unsigned int bitmap_size;
 
      /* allocate memory for SIT information */
fs/f2fs/segment.h +1 -1
index 062424a..a96f7f4 100644
@@ -175,7 +175,7 @@ struct sit_info {
      block_t sit_base_addr;        /* start block address of SIT area */
      block_t sit_blocks;        /* # of blocks used by SIT area */
      block_t written_valid_blocks;    /* # of valid blocks in main area */
-    char *sit_bitmap;        /* SIT bitmap pointer */
+    unsigned char *sit_bitmap;    /* SIT bitmap pointer */
      unsigned int bitmap_size;    /* SIT bitmap size */
 
      unsigned long *dirty_sentries_bitmap;    /* bitmap for dirty sentries */
Quoted 111 lines · Oded Gabbay

Hi,

I'm working on a custom board with a PowerPC processor (Freescale P2020). On the board there is an SD card, which is connected to a USB3 chip (from TI), which is connected to the PCI-e controller of the CPU. I'm running with Linux kernel 3.9.6, with our custom rootFS.

I formatted an SD card using the mkfs.f2fs utility (after fixing some Big-endian issues - sent a patch a few days ago).
I then mounted the SD card, using "mount -o noatime,nodiratime,rw,nosuid,nodev,relatime,active_logs=6,uhelper=udisks2,background_gc_off /dev/sda /mnt/sd1"
Then, I started a small user-space test application which opens a file on the mount folder and starts to do "fwrite" into the file.
After 2-3 seconds, the kernel gives me a BUG and the system restarts.
When the system is up and I try to re-mount the SD card, I get the following error message:

F2FS-fs (sda): Failed to get valid F2FS checkpoint
mount: you must specify the filesystem type

Only way is to re-format the card using mkfs.f2fs

I took the f2fs patch that Jaegeuk Kim sent to Linus for 3.10 (here -
https://lkml.org/lkml/2013/5/8/122) and applied it cleanly to 3.9.6 I repeated the procedure but got the same result.

The BUG is from this line, from segment.c:

         if (!f2fs_clear_bit(offset, se->cur_valid_map))
             BUG();

Additional information I can give is

1. I tried using F2FS in ArchLinux, kernel 3.9.5, on an x86 machine, with the same SD card and the same USB3-to-PCIe chip and it worked flawlessly there.
2. I can work with other FS on the SD card on our custom board, such as Ext3, Ext4 and vfat, so this is not a H/W issue.

Could you please try to help me pinpoint/debug the problem ?

Here is the complete kernel BUG print:

kernel BUG at .../linux-3.9.6-adva/fs/f2fs/segment.c:214!

Oops: Exception in kernel mode, sig: 5 [#1]
PREEMPT SMP NR_CPUS=2 P2020 FSP150
Modules linked in: mdio(O) hardware_version(PO) clipresent(PO) monotonic(O)

restartcause(PO) panic_buffer(O)
NIP: c026a7e0 LR: c026a660 CTR: 00000000
REGS: ee761a60 TRAP: 0700 Tainted: P O
(3.9.6-dev_ogabbay-109482*)
MSR: 00029000 <CE,EE,ME> CR: 24a52588 XER: 20000000
TASK = efb444c0[1755] 'flush-8:0' THREAD: ee760000 CPU: 1
GPR00: 00000000 ee761b10 efb444c0 0000004c 00000000 00000000 01dc4900 eb0fa700
GPR08: 00000000 eb24cb00 00000040 00000040 00000038 00000000 ee761c64 00000000
GPR16: c0aeea80 00080000 00000000 00000000 0000ed31 eb0fa700 00000000 eb0fa734
GPR24: eb0fa700 00000080 f2030620 ffffffff ffffffc8 0000ed31 ffffffff c55a1000
NIP [c026a7e0] update_sit_entry+0x240/0x248
LR [c026a660] update_sit_entry+0xc0/0x248

Call Trace:

[ee761b10] [c55a1000] 0xc55a1000 (unreliable)
[ee761b40] [c026d1f4] do_write_page+0x198/0x660
[ee761b80] [c026d84c] write_data_page+0xa4/0xb8
[ee761bc0] [c0265118] do_write_data_page+0x1e8/0x20c [ee761c20] [c02653dc] f2fs_write_data_page+0x2a0/0x2c0 [ee761c40] [c0263ad8] __f2fs_writepage+0x24/0x80
[ee761c50] [c00b05dc] write_cache_pages+0x1d0/0x35c [ee761d00] [c0263cf4] f2fs_write_data_pages+0xf4/0xfc [ee761d30] [c00b1d3c] do_writepages+0x30/0x64
[ee761d40] [c0103fbc] __writeback_single_inode+0x34/0x10c [ee761d60] [c0104ef8] writeback_sb_inodes+0x204/0x370 [ee761dd0] [c01050f4] __writeback_inodes_wb+0x90/0xd4 [ee761e00] [c01054cc] wb_writeback+0x204/0x20c
[ee761e50] [c0105844] wb_do_writeback+0x144/0x20c
[ee761eb0] [c0105980] bdi_writeback_thread+0x74/0x144 [ee761ee0] [c0059dc4] kthread+0xa8/0xac
[ee761f40] [c000f014] ret_from_kernel_thread+0x64/0x6c Instruction dump:
4bffff2c 813a0004 5720e8fe 7f39c8f8 39400001 5739077e 7d6900ae 7d59c830 7d6ac878 7d68c839 7d4901ae 4082fef0 <0fe00000> 0fe00000 9421ffe0 7c0802a6

--
Best regards,
Oded Gabbay
Principal Engineer Advanced Packet Technologies
ADVA Optical Networking Israel Ltd.
P.O. Box 2552
2 Hatidhar St.
Raanana 4366504, Israel
Tel: +(972)-9-7750130
Fax: +(972)-9-7462092
Mobile: +(972)-54-6543998
E-mail: [email protected]

www.advaoptical.com
Let's ADVANCE

ADVA Optical Networking SE is a European stock corporation (\"Societas Europaea\") with registered offices at Maerzenquelle 1-3, D-98617 Meiningen, Germany * CEO: Brian L. Protiva, Chief Officers: Dr. Christoph Glingener, Christian Unterberger, Jaswir Singh * Chairman of the Supervisory Board:
Anthony Maher * AG Jena HRB 508155 * VAT No. DE 175 446 349

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Quoted 8 lines
Quoted 8 lines

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev

#3 lore raw
In reply to Oded Gabbay

Hi,

Thank you for the report. :)

Can you send me the disk image right after formatting f2fs? As your previous patch, I strongly suspect the endian conversion bug.

Otherwise, I recommend you to test with the latest tree from:
http://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs.git

Thanks,

2013-06-16 (일), 14:51 +0300, Oded Gabbay:

Quoted 117 lines

Hi,

I'm working on a custom board with a PowerPC processor (Freescale P2020).
On the board there is an SD card, which is connected to a USB3 chip (from TI), which is connected to the PCI-e controller of the CPU. I'm running with Linux kernel 3.9.6, with our custom rootFS.

I formatted an SD card using the mkfs.f2fs utility (after fixing some
Big-endian issues - sent a patch a few days ago).
I then mounted the SD card, using "mount -o noatime,nodiratime,rw,nosuid,nodev,relatime,active_logs=6,uhelper=udisks2,background_gc_off /dev/sda /mnt/sd1" Then, I started a small user-space test application which opens a file
on the mount folder and starts to do "fwrite" into the file.
After 2-3 seconds, the kernel gives me a BUG and the system restarts.
When the system is up and I try to re-mount the SD card, I get the
following error message:

F2FS-fs (sda): Failed to get valid F2FS checkpoint
mount: you must specify the filesystem type

Only way is to re-format the card using mkfs.f2fs

I took the f2fs patch that Jaegeuk Kim sent to Linus for 3.10 (here -
https://lkml.org/lkml/2013/5/8/122) and applied it cleanly to 3.9.6 I repeated the procedure but got the same result.

The BUG is from this line, from segment.c:

        if (!f2fs_clear_bit(offset, se->cur_valid_map))
            BUG();

Additional information I can give is

1. I tried using F2FS in ArchLinux, kernel 3.9.5, on an x86 machine, with the same SD card and the same USB3-to-PCIe chip and it worked flawlessly there.
2. I can work with other FS on the SD card on our custom board, such as Ext3, Ext4 and vfat, so this is not a H/W issue.

Could you please try to help me pinpoint/debug the problem ?

Here is the complete kernel BUG print:

kernel BUG at .../linux-3.9.6-adva/fs/f2fs/segment.c:214!

Oops: Exception in kernel mode, sig: 5 [#1]
PREEMPT SMP NR_CPUS=2 P2020 FSP150
Modules linked in: mdio(O) hardware_version(PO) clipresent(PO)

monotonic(O) restartcause(PO) panic_buffer(O)
NIP: c026a7e0 LR: c026a660 CTR: 00000000
REGS: ee761a60 TRAP: 0700 Tainted: P O
(3.9.6-dev_ogabbay-109482*)
MSR: 00029000 <CE,EE,ME> CR: 24a52588 XER: 20000000
TASK = efb444c0[1755] 'flush-8:0' THREAD: ee760000 CPU: 1
GPR00: 00000000 ee761b10 efb444c0 0000004c 00000000 00000000 01dc4900 eb0fa700
GPR08: 00000000 eb24cb00 00000040 00000040 00000038 00000000 ee761c64 00000000
GPR16: c0aeea80 00080000 00000000 00000000 0000ed31 eb0fa700 00000000 eb0fa734
GPR24: eb0fa700 00000080 f2030620 ffffffff ffffffc8 0000ed31 ffffffff c55a1000
NIP [c026a7e0] update_sit_entry+0x240/0x248
LR [c026a660] update_sit_entry+0xc0/0x248

Call Trace:

[ee761b10] [c55a1000] 0xc55a1000 (unreliable) [ee761b40] [c026d1f4] do_write_page+0x198/0x660 [ee761b80] [c026d84c] write_data_page+0xa4/0xb8 [ee761bc0] [c0265118] do_write_data_page+0x1e8/0x20c [ee761c20] [c02653dc] f2fs_write_data_page+0x2a0/0x2c0 [ee761c40] [c0263ad8] __f2fs_writepage+0x24/0x80 [ee761c50] [c00b05dc] write_cache_pages+0x1d0/0x35c [ee761d00] [c0263cf4] f2fs_write_data_pages+0xf4/0xfc [ee761d30] [c00b1d3c] do_writepages+0x30/0x64 [ee761d40] [c0103fbc] __writeback_single_inode+0x34/0x10c [ee761d60] [c0104ef8] writeback_sb_inodes+0x204/0x370 [ee761dd0] [c01050f4] __writeback_inodes_wb+0x90/0xd4 [ee761e00] [c01054cc] wb_writeback+0x204/0x20c [ee761e50] [c0105844] wb_do_writeback+0x144/0x20c [ee761eb0] [c0105980] bdi_writeback_thread+0x74/0x144 [ee761ee0] [c0059dc4] kthread+0xa8/0xac
[ee761f40] [c000f014] ret_from_kernel_thread+0x64/0x6c Instruction dump:
4bffff2c 813a0004 5720e8fe 7f39c8f8 39400001 5739077e 7d6900ae 7d59c830
7d6ac878 7d68c839 7d4901ae 4082fef0 <0fe00000> 0fe00000 9421ffe0 7c0802a6

Signature · 29 lines
Best regards,
Oded Gabbay
Principal Engineer Advanced Packet Technologies
ADVA Optical Networking Israel Ltd.
P.O. Box 2552
2 Hatidhar St.
Raanana 4366504, Israel
Tel: +(972)-9-7750130
Fax: +(972)-9-7462092
Mobile: +(972)-54-6543998
E-mail: [email protected]
 
www.advaoptical.com
Let's ADVANCE
 
ADVA Optical Networking SE is a European stock corporation (\"Societas
Europaea\") with registered offices at Maerzenquelle 1-3, D-98617
Meiningen, Germany * CEO: Brian L. Protiva, Chief Officers: Dr.
Christoph Glingener, Christian Unterberger, Jaswir Singh * Chairman of
the Supervisory Board: Anthony Maher * AG Jena HRB 508155 * VAT No. DE
175 446 349

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Signature · 15 lines
Jaegeuk Kim
Samsung



------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
#4 lore raw

Hi,

I also suspect the endian conversion issue.
Attached is a gzip-ed file, which represent an image of a freshly formatted disk in f2fs in powerpc machine. I preferred to do it this way so I could have a small file to send you. I did the following to create it:

[cj:~] # dd if=/dev/zero of=/tmp/test_file bs=4096 count=102400 102400+0 records in
102400+0 records out
419430400 bytes (419 MB) copied, 1.05112 s, 399 MB/s [cj:~] # losetup /dev/loop0 /tmp/test_file
[cj:~] # mkfs.f2fs -l label /dev/loop0

        F2FS-tools: mkfs.f2fs Ver: 1.1.0 (2013-06-13)

Info: Label = label
Info: sector size = 512
Info: total sectors = 819200 (in 512bytes)
Info: zone aligned segment0 blkaddr: 512
Info: format successful
[cj:~] # losetup -d /dev/loop0
[cj:/tmp] # gzip test_file

I then run my test application and got the same kernel BUG message.

Oded

Quoted 7 lines · Jaegeuk Kim

Hi,

Thank you for the report. :)

Can you send me the disk image right after formatting f2fs? As your previous patch, I strongly suspect the endian conversion bug.

Quoted 123 lines

Otherwise, I recommend you to test with the latest tree from:
http://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs.git

Thanks,

2013-06-16 (일), 14:51 +0300, Oded Gabbay:

Quoted 117 lines

Hi,

I'm working on a custom board with a PowerPC processor (Freescale P2020).
On the board there is an SD card, which is connected to a USB3 chip (from TI), which is connected to the PCI-e controller of the CPU. I'm running with Linux kernel 3.9.6, with our custom rootFS.

I formatted an SD card using the mkfs.f2fs utility (after fixing some
Big-endian issues - sent a patch a few days ago).
I then mounted the SD card, using "mount -o noatime,nodiratime,rw,nosuid,nodev,relatime,active_logs=6,uhelper=udisks2,background_gc_off /dev/sda /mnt/sd1" Then, I started a small user-space test application which opens a file
on the mount folder and starts to do "fwrite" into the file.
After 2-3 seconds, the kernel gives me a BUG and the system restarts.
When the system is up and I try to re-mount the SD card, I get the
following error message:

F2FS-fs (sda): Failed to get valid F2FS checkpoint
mount: you must specify the filesystem type

Only way is to re-format the card using mkfs.f2fs

I took the f2fs patch that Jaegeuk Kim sent to Linus for 3.10 (here -
https://lkml.org/lkml/2013/5/8/122) and applied it cleanly to 3.9.6 I repeated the procedure but got the same result.

The BUG is from this line, from segment.c:

         if (!f2fs_clear_bit(offset, se->cur_valid_map))
             BUG();

Additional information I can give is

1. I tried using F2FS in ArchLinux, kernel 3.9.5, on an x86 machine, with the same SD card and the same USB3-to-PCIe chip and it worked flawlessly there.
2. I can work with other FS on the SD card on our custom board, such as Ext3, Ext4 and vfat, so this is not a H/W issue.

Could you please try to help me pinpoint/debug the problem ?

Here is the complete kernel BUG print:

kernel BUG at .../linux-3.9.6-adva/fs/f2fs/segment.c:214!

Oops: Exception in kernel mode, sig: 5 [#1]
PREEMPT SMP NR_CPUS=2 P2020 FSP150
Modules linked in: mdio(O) hardware_version(PO) clipresent(PO)

monotonic(O) restartcause(PO) panic_buffer(O)
NIP: c026a7e0 LR: c026a660 CTR: 00000000
REGS: ee761a60 TRAP: 0700 Tainted: P O
(3.9.6-dev_ogabbay-109482*)
MSR: 00029000 <CE,EE,ME> CR: 24a52588 XER: 20000000
TASK = efb444c0[1755] 'flush-8:0' THREAD: ee760000 CPU: 1
GPR00: 00000000 ee761b10 efb444c0 0000004c 00000000 00000000 01dc4900 eb0fa700
GPR08: 00000000 eb24cb00 00000040 00000040 00000038 00000000 ee761c64 00000000
GPR16: c0aeea80 00080000 00000000 00000000 0000ed31 eb0fa700 00000000 eb0fa734
GPR24: eb0fa700 00000080 f2030620 ffffffff ffffffc8 0000ed31 ffffffff c55a1000
NIP [c026a7e0] update_sit_entry+0x240/0x248
LR [c026a660] update_sit_entry+0xc0/0x248

Call Trace:

[ee761b10] [c55a1000] 0xc55a1000 (unreliable) [ee761b40] [c026d1f4] do_write_page+0x198/0x660 [ee761b80] [c026d84c] write_data_page+0xa4/0xb8 [ee761bc0] [c0265118] do_write_data_page+0x1e8/0x20c [ee761c20] [c02653dc] f2fs_write_data_page+0x2a0/0x2c0 [ee761c40] [c0263ad8] __f2fs_writepage+0x24/0x80 [ee761c50] [c00b05dc] write_cache_pages+0x1d0/0x35c [ee761d00] [c0263cf4] f2fs_write_data_pages+0xf4/0xfc [ee761d30] [c00b1d3c] do_writepages+0x30/0x64 [ee761d40] [c0103fbc] __writeback_single_inode+0x34/0x10c [ee761d60] [c0104ef8] writeback_sb_inodes+0x204/0x370 [ee761dd0] [c01050f4] __writeback_inodes_wb+0x90/0xd4 [ee761e00] [c01054cc] wb_writeback+0x204/0x20c [ee761e50] [c0105844] wb_do_writeback+0x144/0x20c [ee761eb0] [c0105980] bdi_writeback_thread+0x74/0x144 [ee761ee0] [c0059dc4] kthread+0xa8/0xac
[ee761f40] [c000f014] ret_from_kernel_thread+0x64/0x6c Instruction dump:
4bffff2c 813a0004 5720e8fe 7f39c8f8 39400001 5739077e 7d6900ae 7d59c830
7d6ac878 7d68c839 7d4901ae 4082fef0 <0fe00000> 0fe00000 9421ffe0 7c0802a6

Signature · 29 lines
Best regards,
Oded Gabbay
Principal Engineer Advanced Packet Technologies
ADVA Optical Networking Israel Ltd.
P.O. Box 2552
2 Hatidhar St.
Raanana 4366504, Israel
Tel: +(972)-9-7750130
Fax: +(972)-9-7462092
Mobile: +(972)-54-6543998
E-mail: [email protected]
  
www.advaoptical.com
Let's ADVANCE
  
ADVA Optical Networking SE is a European stock corporation (\"Societas
Europaea\") with registered offices at Maerzenquelle 1-3, D-98617
Meiningen, Germany * CEO: Brian L. Protiva, Chief Officers: Dr.
Christoph Glingener, Christian Unterberger, Jaswir Singh * Chairman of
the Supervisory Board: Anthony Maher * AG Jena HRB 508155 * VAT No. DE
175 446 349

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev

_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

#5 lore raw

Hi,

I would like to share additional information I have from pr_err I put into the update_sit_entry function.

The following is the printout from the terminal. This is only the end of the printout. The start was with "segoff = 3584" and it went sequentially up until 9215, where then it jumped to 99329 and after that 99328 - which is the entry that caused the crash. Each time I repeated the experiment I got exactly the same results.

I put the pr_err after the line: "offset = GET_SEGOFF_FROM_SEG0(sbi, blkaddr) & (sbi->blocks_per_seg - 1);" where segoff = GET_SEGOFF_FROM_SEG0(sbi, blkaddr)

Hope this helps.

REMOVE_ME update_sit_entry(202): offset = 0, segoff = 3584, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 1, segoff = 3585, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 2, segoff = 3586, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 3, segoff = 3587, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 4, segoff = 3588, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 5, segoff = 3589, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 6, segoff = 3590, sbi->blocks_per_seg = 512 :::
REMOVE_ME update_sit_entry(202): offset = 502, segoff = 9206, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 503, segoff = 9207, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 504, segoff = 9208, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 505, segoff = 9209, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 506, segoff = 9210, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 507, segoff = 9211, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 508, segoff = 9212, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 509, segoff = 9213, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 510, segoff = 9214, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 511, segoff = 9215, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 1, segoff = 99329, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 0, segoff = 99328, sbi->blocks_per_seg = 512

------------[ cut here ]------------
kernel BUG at /home/ogabbay/views/r5.xcj/software/os-software/powerpc/usr/src/linux-3.9.6-adva/fs/f2fs/segment.c:217!
Oops: Exception in kernel mode, sig: 5 [#1]
PREEMPT SMP NR_CPUS=2 P2020 FSP150
Modules linked in: mdio(O) hardware_version(PO) clipresent(PO) monotonic(O) restartcause(PO) panic_buffer(O)
NIP: c026c038 LR: c026bf0c CTR: 00000000
REGS: c5665a60 TRAP: 0700   Tainted: P           O (3.9.6-dev_ogabbay-109564*)
MSR: 00029000 <CE,EE,ME>  CR: 24f82c48  XER: 20000000

TASK = ef943e80[1774] 'flush-7:0' THREAD: c5664000 CPU: 1
GPR00: 00000000 c5665b10 ef943e80 000000a6 00021000 00000000 f1e26054 725f7365
GPR08: 00000000 c5a13e40 00000040 00000040 00000067 00000000 c5665c64 00000000
GPR16: c1419240 00080000 00000000 00000000 000000bb ef8ce100 00000000 ef8ce134
GPR24: ffffffff ffffff99 000000bb ef8ce100 00000080 f1e57760 ffffffff c561e800 NIP [c026c038] update_sit_entry+0x234/0x23c
LR [c026bf0c] update_sit_entry+0x108/0x23c

Call Trace:
[c5665b10] [c026bed4] update_sit_entry+0xd0/0x23c (unreliable)
[c5665b40] [c026d1e8] do_write_page+0x198/0x660
[c5665b80] [c026d840] write_data_page+0xa4/0xb8
[c5665bc0] [c0265118] do_write_data_page+0x1e8/0x20c
[c5665c20] [c02653dc] f2fs_write_data_page+0x2a0/0x2c0
[c5665c40] [c0263ad8] __f2fs_writepage+0x24/0x80
[c5665c50] [c00b05dc] write_cache_pages+0x1d0/0x35c
[c5665d00] [c0263cf4] f2fs_write_data_pages+0xf4/0xfc
[c5665d30] [c00b1d3c] do_writepages+0x30/0x64
[c5665d40] [c0103fbc] __writeback_single_inode+0x34/0x10c
[c5665d60] [c0104ef8] writeback_sb_inodes+0x204/0x370
[c5665dd0] [c01050f4] __writeback_inodes_wb+0x90/0xd4
[c5665e00] [c01054cc] wb_writeback+0x204/0x20c
[c5665e50] [c0105844] wb_do_writeback+0x144/0x20c
[c5665eb0] [c0105980] bdi_writeback_thread+0x74/0x144
[c5665ee0] [c0059dc4] kthread+0xa8/0xac
[c5665f40] [c000f014] ret_from_kernel_thread+0x64/0x6c

--- Exception: 0 at (null)
LR = (null)
Instruction dump:
4bffff80 813d0004 5780e8fe 7f9ce0f8 39400001 579c077e 7d6900ae 7d5ce030 7d6ae078 7d68e039 7d4901ae 4082ff44 <0fe00000> 0fe00000 9421ffe0 7c0802a6

---[ end trace 707fc0870875373e ]---

Oded

Quoted 23 lines · Oded Gabbay

Hi,

I also suspect the endian conversion issue.
Attached is a gzip-ed file, which represent an image of a freshly formatted disk in f2fs in powerpc machine. I preferred to do it this way so I could have a small file to send you. I did the following to create it:

[cj:~] # dd if=/dev/zero of=/tmp/test_file bs=4096 count=102400 102400+0 records in
102400+0 records out
419430400 bytes (419 MB) copied, 1.05112 s, 399 MB/s [cj:~] # losetup /dev/loop0 /tmp/test_file
[cj:~] # mkfs.f2fs -l label /dev/loop0

        F2FS-tools: mkfs.f2fs Ver: 1.1.0 (2013-06-13)

Info: Label = label
Info: sector size = 512
Info: total sectors = 819200 (in 512bytes)
Info: zone aligned segment0 blkaddr: 512
Info: format successful
[cj:~] # losetup -d /dev/loop0
[cj:/tmp] # gzip test_file

Quoted 136 lines

I then run my test application and got the same kernel BUG message.

Oded

Quoted 130 lines · Jaegeuk Kim

Hi,

Thank you for the report. :)

Can you send me the disk image right after formatting f2fs? As your previous patch, I strongly suspect the endian conversion bug.

Otherwise, I recommend you to test with the latest tree from:
http://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs.git

Thanks,

2013-06-16 (일), 14:51 +0300, Oded Gabbay:

Quoted 117 lines

Hi,

I'm working on a custom board with a PowerPC processor (Freescale P2020).
On the board there is an SD card, which is connected to a USB3 chip (from TI), which is connected to the PCI-e controller of the CPU. I'm running with Linux kernel 3.9.6, with our custom rootFS.

I formatted an SD card using the mkfs.f2fs utility (after fixing some
Big-endian issues - sent a patch a few days ago).
I then mounted the SD card, using "mount -o noatime,nodiratime,rw,nosuid,nodev,relatime,active_logs=6,uhelper=udisks2,background_gc_off /dev/sda /mnt/sd1" Then, I started a small user-space test application which opens a file
on the mount folder and starts to do "fwrite" into the file.
After 2-3 seconds, the kernel gives me a BUG and the system restarts.
When the system is up and I try to re-mount the SD card, I get the
following error message:

F2FS-fs (sda): Failed to get valid F2FS checkpoint
mount: you must specify the filesystem type

Only way is to re-format the card using mkfs.f2fs

I took the f2fs patch that Jaegeuk Kim sent to Linus for 3.10 (here -
https://lkml.org/lkml/2013/5/8/122) and applied it cleanly to 3.9.6 I repeated the procedure but got the same result.

The BUG is from this line, from segment.c:

         if (!f2fs_clear_bit(offset, se->cur_valid_map))
             BUG();

Additional information I can give is

1. I tried using F2FS in ArchLinux, kernel 3.9.5, on an x86 machine, with the same SD card and the same USB3-to-PCIe chip and it worked flawlessly there.
2. I can work with other FS on the SD card on our custom board, such as Ext3, Ext4 and vfat, so this is not a H/W issue.

Could you please try to help me pinpoint/debug the problem ?

Here is the complete kernel BUG print:

kernel BUG at .../linux-3.9.6-adva/fs/f2fs/segment.c:214!

Oops: Exception in kernel mode, sig: 5 [#1]
PREEMPT SMP NR_CPUS=2 P2020 FSP150
Modules linked in: mdio(O) hardware_version(PO) clipresent(PO)

monotonic(O) restartcause(PO) panic_buffer(O)
NIP: c026a7e0 LR: c026a660 CTR: 00000000
REGS: ee761a60 TRAP: 0700 Tainted: P O
(3.9.6-dev_ogabbay-109482*)
MSR: 00029000 <CE,EE,ME> CR: 24a52588 XER: 20000000
TASK = efb444c0[1755] 'flush-8:0' THREAD: ee760000 CPU: 1
GPR00: 00000000 ee761b10 efb444c0 0000004c 00000000 00000000 01dc4900 eb0fa700
GPR08: 00000000 eb24cb00 00000040 00000040 00000038 00000000 ee761c64 00000000
GPR16: c0aeea80 00080000 00000000 00000000 0000ed31 eb0fa700 00000000 eb0fa734
GPR24: eb0fa700 00000080 f2030620 ffffffff ffffffc8 0000ed31 ffffffff c55a1000
NIP [c026a7e0] update_sit_entry+0x240/0x248
LR [c026a660] update_sit_entry+0xc0/0x248

Call Trace:

[ee761b10] [c55a1000] 0xc55a1000 (unreliable) [ee761b40] [c026d1f4] do_write_page+0x198/0x660 [ee761b80] [c026d84c] write_data_page+0xa4/0xb8 [ee761bc0] [c0265118] do_write_data_page+0x1e8/0x20c [ee761c20] [c02653dc] f2fs_write_data_page+0x2a0/0x2c0 [ee761c40] [c0263ad8] __f2fs_writepage+0x24/0x80 [ee761c50] [c00b05dc] write_cache_pages+0x1d0/0x35c [ee761d00] [c0263cf4] f2fs_write_data_pages+0xf4/0xfc [ee761d30] [c00b1d3c] do_writepages+0x30/0x64 [ee761d40] [c0103fbc] __writeback_single_inode+0x34/0x10c [ee761d60] [c0104ef8] writeback_sb_inodes+0x204/0x370 [ee761dd0] [c01050f4] __writeback_inodes_wb+0x90/0xd4 [ee761e00] [c01054cc] wb_writeback+0x204/0x20c [ee761e50] [c0105844] wb_do_writeback+0x144/0x20c [ee761eb0] [c0105980] bdi_writeback_thread+0x74/0x144 [ee761ee0] [c0059dc4] kthread+0xa8/0xac
[ee761f40] [c000f014] ret_from_kernel_thread+0x64/0x6c Instruction dump:
4bffff2c 813a0004 5720e8fe 7f39c8f8 39400001 5739077e 7d6900ae 7d59c830
7d6ac878 7d68c839 7d4901ae 4082fef0 <0fe00000> 0fe00000 9421ffe0 7c0802a6

Signature · 29 lines
Best regards,
Oded Gabbay
Principal Engineer Advanced Packet Technologies
ADVA Optical Networking Israel Ltd.
P.O. Box 2552
2 Hatidhar St.
Raanana 4366504, Israel
Tel: +(972)-9-7750130
Fax: +(972)-9-7462092
Mobile: +(972)-54-6543998
E-mail:[email protected]
  
www.advaoptical.com
Let's ADVANCE
  
ADVA Optical Networking SE is a European stock corporation (\"Societas
Europaea\") with registered offices at Maerzenquelle 1-3, D-98617
Meiningen, Germany * CEO: Brian L. Protiva, Chief Officers: Dr.
Christoph Glingener, Christian Unterberger, Jaswir Singh * Chairman of
the Supervisory Board: Anthony Maher * AG Jena HRB 508155 * VAT No. DE
175 446 349

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________ Linux-f2fs-devel mailing [email protected]  https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev

_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

#6 lore raw

Hi,

I printed also the segment no. and it appears that every time that segment 187 is written to, which is assigned to the HOT data, the system crashes. BTW, even if I just do "echo oded > /mnt/file" and then just wait for about 30-45 seconds, the crash occurs

I got the following prints when I did the echo thing:

REMOVE_ME update_sit_entry(202):
offset = 0, segoff = 3584, blkaddr = 4096, segno = 0 REMOVE_ME update_sit_entry(202):
offset = 1, segoff = 99329, blkaddr = 99841, segno = 187 REMOVE_ME update_sit_entry(202):
offset = 0, segoff = 99328, blkaddr = 99840, segno = 187

------------[ cut here ]------------
kernel BUG at /home/ogabbay/views/r5.xcj/software/os-software/powerpc/usr/src/linux-3.9.6-adva/fs/f2fs/segment.c:217!

Here is the print from the debugfs. You can see segment 187 is allocated to HOT data:

[cj:~] # cat /sys/kernel/debug/f2fs/status

=====[ partition info(loop0). #0 ]=====
[SB: 1] [CP: 2] [SIT: 2] [NAT: 2] [SSA: 1] [MAIN: 192(OverProv:55 Resv:48)]

Utilization: 0% (4 valid blocks)
- Node: 2 (Inode: 2, Other: 0)
- Data: 2

Main area: 192 segs, 192 secs 192 zones

  - COLD  data: 0, 0, 0
  - WARM  data: 1, 1, 1
  - HOT   data: 187, 187, 187
  - Dir   dnode: 190, 190, 190

- File dnode: 189, 189, 189
- Indir nodes: 188, 188, 188

- Valid: 6
- Dirty: 0
- Prefree: 0
- Free: 186 (186)

GC calls: 0 (BG: 0)
- data segments : 0
- node segments : 0
Try to move 0 blocks
- data blocks : 0
- node blocks : 0

Extent Hit Ratio: 0 / 0

Balancing F2FS Async:
- nodes 1 in 2
- dents 1 in dirs: 1
- meta 0 in 21
- NATs 2 > 29120
- SITs: 0
- free_nids: 2270

Distribution of User Blocks: [ valid | invalid | free ]
[|---|-----------------------------------------------]

SSR: 0 blocks in 0 segments
LFS: 0 blocks in 0 segments

BDF: 100, avg. vblocks: 0

Memory: 154 KB = static: 60 + cached: 94

Quoted 71 lines · Oded Gabbay

Hi,

I would like to share additional information I have from pr_err I put into the update_sit_entry function.

The following is the printout from the terminal. This is only the end of the printout. The start was with "segoff = 3584" and it went sequentially up until 9215, where then it jumped to 99329 and after that 99328 - which is the entry that caused the crash. Each time I repeated the experiment I got exactly the same results.

I put the pr_err after the line: "offset = GET_SEGOFF_FROM_SEG0(sbi, blkaddr) & (sbi->blocks_per_seg - 1);" where segoff = GET_SEGOFF_FROM_SEG0(sbi, blkaddr)

Hope this helps.

REMOVE_ME update_sit_entry(202): offset = 0, segoff = 3584, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 1, segoff = 3585, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 2, segoff = 3586, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 3, segoff = 3587, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 4, segoff = 3588, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 5, segoff = 3589, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 6, segoff = 3590, sbi->blocks_per_seg = 512 :::
REMOVE_ME update_sit_entry(202): offset = 502, segoff = 9206, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 503, segoff = 9207, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 504, segoff = 9208, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 505, segoff = 9209, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 506, segoff = 9210, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 507, segoff = 9211, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 508, segoff = 9212, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 509, segoff = 9213, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 510, segoff = 9214, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 511, segoff = 9215, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 1, segoff = 99329, sbi->blocks_per_seg = 512 REMOVE_ME update_sit_entry(202): offset = 0, segoff = 99328, sbi->blocks_per_seg = 512

------------[ cut here ]------------
kernel BUG at /home/ogabbay/views/r5.xcj/software/os-software/powerpc/usr/src/linux-3.9.6-adva/fs/f2fs/segment.c:217!
Oops: Exception in kernel mode, sig: 5 [#1]
PREEMPT SMP NR_CPUS=2 P2020 FSP150
Modules linked in: mdio(O) hardware_version(PO) clipresent(PO) monotonic(O) restartcause(PO) panic_buffer(O)
NIP: c026c038 LR: c026bf0c CTR: 00000000
REGS: c5665a60 TRAP: 0700   Tainted: P           O (3.9.6-dev_ogabbay-109564*)
MSR: 00029000 <CE,EE,ME>  CR: 24f82c48  XER: 20000000

TASK = ef943e80[1774] 'flush-7:0' THREAD: c5664000 CPU: 1
GPR00: 00000000 c5665b10 ef943e80 000000a6 00021000 00000000 f1e26054 725f7365
GPR08: 00000000 c5a13e40 00000040 00000040 00000067 00000000 c5665c64 00000000
GPR16: c1419240 00080000 00000000 00000000 000000bb ef8ce100 00000000 ef8ce134
GPR24: ffffffff ffffff99 000000bb ef8ce100 00000080 f1e57760 ffffffff c561e800 NIP [c026c038] update_sit_entry+0x234/0x23c
LR [c026bf0c] update_sit_entry+0x108/0x23c

Call Trace:
[c5665b10] [c026bed4] update_sit_entry+0xd0/0x23c (unreliable)
[c5665b40] [c026d1e8] do_write_page+0x198/0x660
[c5665b80] [c026d840] write_data_page+0xa4/0xb8
[c5665bc0] [c0265118] do_write_data_page+0x1e8/0x20c
[c5665c20] [c02653dc] f2fs_write_data_page+0x2a0/0x2c0
[c5665c40] [c0263ad8] __f2fs_writepage+0x24/0x80
[c5665c50] [c00b05dc] write_cache_pages+0x1d0/0x35c
[c5665d00] [c0263cf4] f2fs_write_data_pages+0xf4/0xfc
[c5665d30] [c00b1d3c] do_writepages+0x30/0x64
[c5665d40] [c0103fbc] __writeback_single_inode+0x34/0x10c
[c5665d60] [c0104ef8] writeback_sb_inodes+0x204/0x370
[c5665dd0] [c01050f4] __writeback_inodes_wb+0x90/0xd4
[c5665e00] [c01054cc] wb_writeback+0x204/0x20c
[c5665e50] [c0105844] wb_do_writeback+0x144/0x20c
[c5665eb0] [c0105980] bdi_writeback_thread+0x74/0x144
[c5665ee0] [c0059dc4] kthread+0xa8/0xac
[c5665f40] [c000f014] ret_from_kernel_thread+0x64/0x6c

--- Exception: 0 at (null)
LR = (null)
Instruction dump:
4bffff80 813d0004 5780e8fe 7f9ce0f8 39400001 579c077e 7d6900ae 7d5ce030 7d6ae078 7d68e039 7d4901ae 4082ff44 <0fe00000> 0fe00000 9421ffe0 7c0802a6

Quoted 164 lines
---[ end trace 707fc0870875373e ]---

Oded

Quoted 159 lines · Oded Gabbay

Hi,

I also suspect the endian conversion issue.
Attached is a gzip-ed file, which represent an image of a freshly formatted disk in f2fs in powerpc machine. I preferred to do it this way so I could have a small file to send you. I did the following to create it:

[cj:~] # dd if=/dev/zero of=/tmp/test_file bs=4096 count=102400 102400+0 records in
102400+0 records out
419430400 bytes (419 MB) copied, 1.05112 s, 399 MB/s [cj:~] # losetup /dev/loop0 /tmp/test_file
[cj:~] # mkfs.f2fs -l label /dev/loop0

        F2FS-tools: mkfs.f2fs Ver: 1.1.0 (2013-06-13)

Info: Label = label
Info: sector size = 512
Info: total sectors = 819200 (in 512bytes)
Info: zone aligned segment0 blkaddr: 512
Info: format successful
[cj:~] # losetup -d /dev/loop0
[cj:/tmp] # gzip test_file

I then run my test application and got the same kernel BUG message.

Oded

Quoted 130 lines · Jaegeuk Kim

Hi,

Thank you for the report. :)

Can you send me the disk image right after formatting f2fs? As your previous patch, I strongly suspect the endian conversion bug.

Otherwise, I recommend you to test with the latest tree from:
http://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs.git

Thanks,

2013-06-16 (일), 14:51 +0300, Oded Gabbay:

Quoted 117 lines

Hi,

I'm working on a custom board with a PowerPC processor (Freescale P2020).
On the board there is an SD card, which is connected to a USB3 chip (from TI), which is connected to the PCI-e controller of the CPU. I'm running with Linux kernel 3.9.6, with our custom rootFS.

I formatted an SD card using the mkfs.f2fs utility (after fixing some
Big-endian issues - sent a patch a few days ago).
I then mounted the SD card, using "mount -o noatime,nodiratime,rw,nosuid,nodev,relatime,active_logs=6,uhelper=udisks2,background_gc_off /dev/sda /mnt/sd1" Then, I started a small user-space test application which opens a file
on the mount folder and starts to do "fwrite" into the file.
After 2-3 seconds, the kernel gives me a BUG and the system restarts.
When the system is up and I try to re-mount the SD card, I get the
following error message:

F2FS-fs (sda): Failed to get valid F2FS checkpoint
mount: you must specify the filesystem type

Only way is to re-format the card using mkfs.f2fs

I took the f2fs patch that Jaegeuk Kim sent to Linus for 3.10 (here -
https://lkml.org/lkml/2013/5/8/122) and applied it cleanly to 3.9.6 I repeated the procedure but got the same result.

The BUG is from this line, from segment.c:

         if (!f2fs_clear_bit(offset, se->cur_valid_map))
             BUG();

Additional information I can give is

1. I tried using F2FS in ArchLinux, kernel 3.9.5, on an x86 machine, with the same SD card and the same USB3-to-PCIe chip and it worked flawlessly there.
2. I can work with other FS on the SD card on our custom board, such as Ext3, Ext4 and vfat, so this is not a H/W issue.

Could you please try to help me pinpoint/debug the problem ?

Here is the complete kernel BUG print:

kernel BUG at .../linux-3.9.6-adva/fs/f2fs/segment.c:214!

Oops: Exception in kernel mode, sig: 5 [#1]
PREEMPT SMP NR_CPUS=2 P2020 FSP150
Modules linked in: mdio(O) hardware_version(PO) clipresent(PO)

monotonic(O) restartcause(PO) panic_buffer(O)
NIP: c026a7e0 LR: c026a660 CTR: 00000000
REGS: ee761a60 TRAP: 0700 Tainted: P O
(3.9.6-dev_ogabbay-109482*)
MSR: 00029000 <CE,EE,ME> CR: 24a52588 XER: 20000000
TASK = efb444c0[1755] 'flush-8:0' THREAD: ee760000 CPU: 1
GPR00: 00000000 ee761b10 efb444c0 0000004c 00000000 00000000 01dc4900 eb0fa700
GPR08: 00000000 eb24cb00 00000040 00000040 00000038 00000000 ee761c64 00000000
GPR16: c0aeea80 00080000 00000000 00000000 0000ed31 eb0fa700 00000000 eb0fa734
GPR24: eb0fa700 00000080 f2030620 ffffffff ffffffc8 0000ed31 ffffffff c55a1000
NIP [c026a7e0] update_sit_entry+0x240/0x248
LR [c026a660] update_sit_entry+0xc0/0x248

Call Trace:

[ee761b10] [c55a1000] 0xc55a1000 (unreliable) [ee761b40] [c026d1f4] do_write_page+0x198/0x660 [ee761b80] [c026d84c] write_data_page+0xa4/0xb8 [ee761bc0] [c0265118] do_write_data_page+0x1e8/0x20c [ee761c20] [c02653dc] f2fs_write_data_page+0x2a0/0x2c0 [ee761c40] [c0263ad8] __f2fs_writepage+0x24/0x80 [ee761c50] [c00b05dc] write_cache_pages+0x1d0/0x35c [ee761d00] [c0263cf4] f2fs_write_data_pages+0xf4/0xfc [ee761d30] [c00b1d3c] do_writepages+0x30/0x64 [ee761d40] [c0103fbc] __writeback_single_inode+0x34/0x10c [ee761d60] [c0104ef8] writeback_sb_inodes+0x204/0x370 [ee761dd0] [c01050f4] __writeback_inodes_wb+0x90/0xd4 [ee761e00] [c01054cc] wb_writeback+0x204/0x20c [ee761e50] [c0105844] wb_do_writeback+0x144/0x20c [ee761eb0] [c0105980] bdi_writeback_thread+0x74/0x144 [ee761ee0] [c0059dc4] kthread+0xa8/0xac
[ee761f40] [c000f014] ret_from_kernel_thread+0x64/0x6c Instruction dump:
4bffff2c 813a0004 5720e8fe 7f39c8f8 39400001 5739077e 7d6900ae 7d59c830
7d6ac878 7d68c839 7d4901ae 4082fef0 <0fe00000> 0fe00000 9421ffe0 7c0802a6

Signature · 29 lines
Best regards,
Oded Gabbay
Principal Engineer Advanced Packet Technologies
ADVA Optical Networking Israel Ltd.
P.O. Box 2552
2 Hatidhar St.
Raanana 4366504, Israel
Tel: +(972)-9-7750130
Fax: +(972)-9-7462092
Mobile: +(972)-54-6543998
E-mail:[email protected]
  
www.advaoptical.com
Let's ADVANCE
  
ADVA Optical Networking SE is a European stock corporation (\"Societas
Europaea\") with registered offices at Maerzenquelle 1-3, D-98617
Meiningen, Germany * CEO: Brian L. Protiva, Chief Officers: Dr.
Christoph Glingener, Christian Unterberger, Jaswir Singh * Chairman of
the Supervisory Board: Anthony Maher * AG Jena HRB 508155 * VAT No. DE
175 446 349

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________ Linux-f2fs-devel mailing [email protected]  https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev

_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

#7 lore raw

Hi,
Could you test the following three patches sent right after this email?

For f2fs-tools:
1. store crc as __le32
2. store checkpoint flags as __le32

For f2fs:
1. handle crc as __le32

I suspect that:
1. mount failure is able to be occurred due to the crc endian error.
2. update_sit_entry bug_on is caused by the endian problem on the checkpoint flags.

If wrong checkpoint flag is got at mount time, we cannot build the latest sit entries correctly.

Thanks,

2013-06-18 (화), 15:10 +0300, Oded Gabbay:

Quoted 318 lines

Hi,

I printed also the segment no. and it appears that every time that segment 187 is written to, which is assigned to the HOT data, the system crashes.
BTW, even if I just do "echo oded > /mnt/file" and then just wait for about 30-45 seconds, the crash occurs

I got the following prints when I did the echo thing:

REMOVE_ME update_sit_entry(202):
offset = 0, segoff = 3584, blkaddr = 4096, segno = 0 REMOVE_ME update_sit_entry(202):
offset = 1, segoff = 99329, blkaddr = 99841, segno = 187 REMOVE_ME update_sit_entry(202):
offset = 0, segoff = 99328, blkaddr = 99840, segno = 187

------------[ cut here ]------------
kernel BUG

at /home/ogabbay/views/r5.xcj/software/os-software/powerpc/usr/src/linux-3.9.6-adva/fs/f2fs/segment.c:217!

Here is the print from the debugfs. You can see segment 187 is allocated to HOT data:

[cj:~] # cat /sys/kernel/debug/f2fs/status

=====[ partition info(loop0). #0 ]=====
[SB: 1] [CP: 2] [SIT: 2] [NAT: 2] [SSA: 1] [MAIN: 192(OverProv:55 Resv:48)]

Utilization: 0% (4 valid blocks)
- Node: 2 (Inode: 2, Other: 0)
- Data: 2

Main area: 192 segs, 192 secs 192 zones

  - COLD  data: 0, 0, 0
  - WARM  data: 1, 1, 1
  - HOT   data: 187, 187, 187
  - Dir   dnode: 190, 190, 190

- File dnode: 189, 189, 189
- Indir nodes: 188, 188, 188

- Valid: 6
- Dirty: 0
- Prefree: 0
- Free: 186 (186)

GC calls: 0 (BG: 0)
- data segments : 0
- node segments : 0
Try to move 0 blocks
- data blocks : 0
- node blocks : 0

Extent Hit Ratio: 0 / 0

Balancing F2FS Async:
- nodes 1 in 2
- dents 1 in dirs: 1
- meta 0 in 21
- NATs 2 > 29120
- SITs: 0
- free_nids: 2270

Distribution of User Blocks: [ valid | invalid | free ]
[|---|-----------------------------------------------]

SSR: 0 blocks in 0 segments
LFS: 0 blocks in 0 segments

BDF: 100, avg. vblocks: 0

Memory: 154 KB = static: 60 + cached: 94

Quoted 242 lines · Oded Gabbay

Hi,

I would like to share additional information I have from pr_err I put into the update_sit_entry function.

The following is the printout from the terminal. This is only the end of the printout. The start was with "segoff = 3584" and it went sequentially up until 9215, where then it jumped to 99329 and after that 99328 - which is the entry that caused the crash. Each time I repeated the experiment I got exactly the same results.

I put the pr_err after the line: "offset = GET_SEGOFF_FROM_SEG0(sbi, blkaddr) & (sbi->blocks_per_seg - 1);"
where segoff = GET_SEGOFF_FROM_SEG0(sbi, blkaddr)

Hope this helps.

REMOVE_ME update_sit_entry(202): offset = 0, segoff = 3584, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 1, segoff = 3585, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 2, segoff = 3586, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 3, segoff = 3587, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 4, segoff = 3588, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 5, segoff = 3589, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 6, segoff = 3590, sbi->blocks_per_seg = 512
:::
REMOVE_ME update_sit_entry(202): offset = 502, segoff = 9206, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 503, segoff = 9207, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 504, segoff = 9208, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 505, segoff = 9209, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 506, segoff = 9210, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 507, segoff = 9211, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 508, segoff = 9212, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 509, segoff = 9213, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 510, segoff = 9214, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 511, segoff = 9215, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 1, segoff = 99329, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 0, segoff = 99328, sbi->blocks_per_seg = 512

------------[ cut here ]------------
kernel BUG
at /home/ogabbay/views/r5.xcj/software/os-software/powerpc/usr/src/linux-3.9.6-adva/fs/f2fs/segment.c:217!
Oops: Exception in kernel mode, sig: 5 [#1]
PREEMPT SMP NR_CPUS=2 P2020 FSP150
Modules linked in: mdio(O) hardware_version(PO) clipresent(PO)

monotonic(O) restartcause(PO) panic_buffer(O)
NIP: c026c038 LR: c026bf0c CTR: 00000000
REGS: c5665a60 TRAP: 0700 Tainted: P O
(3.9.6-dev_ogabbay-109564*)
MSR: 00029000 <CE,EE,ME> CR: 24f82c48 XER: 20000000 TASK = ef943e80[1774] 'flush-7:0' THREAD: c5664000 CPU: 1
GPR00: 00000000 c5665b10 ef943e80 000000a6 00021000 00000000 f1e26054 725f7365
GPR08: 00000000 c5a13e40 00000040 00000040 00000067 00000000 c5665c64 00000000
GPR16: c1419240 00080000 00000000 00000000 000000bb ef8ce100 00000000 ef8ce134
GPR24: ffffffff ffffff99 000000bb ef8ce100 00000080 f1e57760 ffffffff c561e800
NIP [c026c038] update_sit_entry+0x234/0x23c
LR [c026bf0c] update_sit_entry+0x108/0x23c

Call Trace:
[c5665b10] [c026bed4] update_sit_entry+0xd0/0x23c (unreliable)
[c5665b40] [c026d1e8] do_write_page+0x198/0x660
[c5665b80] [c026d840] write_data_page+0xa4/0xb8
[c5665bc0] [c0265118] do_write_data_page+0x1e8/0x20c
[c5665c20] [c02653dc] f2fs_write_data_page+0x2a0/0x2c0
[c5665c40] [c0263ad8] __f2fs_writepage+0x24/0x80
[c5665c50] [c00b05dc] write_cache_pages+0x1d0/0x35c
[c5665d00] [c0263cf4] f2fs_write_data_pages+0xf4/0xfc
[c5665d30] [c00b1d3c] do_writepages+0x30/0x64
[c5665d40] [c0103fbc] __writeback_single_inode+0x34/0x10c
[c5665d60] [c0104ef8] writeback_sb_inodes+0x204/0x370
[c5665dd0] [c01050f4] __writeback_inodes_wb+0x90/0xd4
[c5665e00] [c01054cc] wb_writeback+0x204/0x20c
[c5665e50] [c0105844] wb_do_writeback+0x144/0x20c
[c5665eb0] [c0105980] bdi_writeback_thread+0x74/0x144
[c5665ee0] [c0059dc4] kthread+0xa8/0xac
[c5665f40] [c000f014] ret_from_kernel_thread+0x64/0x6c

--- Exception: 0 at (null)
LR = (null)
Instruction dump:
4bffff80 813d0004 5780e8fe 7f9ce0f8 39400001 579c077e 7d6900ae 7d5ce030
7d6ae078 7d68e039 7d4901ae 4082ff44 <0fe00000> 0fe00000 9421ffe0 7c0802a6

---[ end trace 707fc0870875373e ]---

Oded

Quoted 133 lines · Oded Gabbay

Hi,

I also suspect the endian conversion issue.
Attached is a gzip-ed file, which represent an image of a freshly formatted disk in f2fs in powerpc machine. I preferred to do it this way so I could have a small file to send you.
I did the following to create it:

[cj:~] # dd if=/dev/zero of=/tmp/test_file bs=4096 count=102400 102400+0 records in
102400+0 records out
419430400 bytes (419 MB) copied, 1.05112 s, 399 MB/s [cj:~] # losetup /dev/loop0 /tmp/test_file
[cj:~] # mkfs.f2fs -l label /dev/loop0

        F2FS-tools: mkfs.f2fs Ver: 1.1.0 (2013-06-13)

Info: Label = label
Info: sector size = 512
Info: total sectors = 819200 (in 512bytes)
Info: zone aligned segment0 blkaddr: 512
Info: format successful
[cj:~] # losetup -d /dev/loop0
[cj:/tmp] # gzip test_file

I then run my test application and got the same kernel BUG message.

Oded

Quoted 101 lines · Jaegeuk Kim

Hi,

Thank you for the report. :)

Can you send me the disk image right after formatting f2fs? As your previous patch, I strongly suspect the endian conversion bug.

Otherwise, I recommend you to test with the latest tree from:
http://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs.git

Thanks,

2013-06-16 (일), 14:51 +0300, Oded Gabbay:

Quoted 87 lines

Hi,

I'm working on a custom board with a PowerPC processor (Freescale P2020).
On the board there is an SD card, which is connected to a USB3 chip (from TI), which is connected to the PCI-e controller of the CPU. I'm running with Linux kernel 3.9.6, with our custom rootFS.

I formatted an SD card using the mkfs.f2fs utility (after fixing some
Big-endian issues - sent a patch a few days ago).
I then mounted the SD card, using "mount -o noatime,nodiratime,rw,nosuid,nodev,relatime,active_logs=6,uhelper=udisks2,background_gc_off /dev/sda /mnt/sd1" Then, I started a small user-space test application which opens a file
on the mount folder and starts to do "fwrite" into the file.
After 2-3 seconds, the kernel gives me a BUG and the system restarts.
When the system is up and I try to re-mount the SD card, I get the
following error message:

F2FS-fs (sda): Failed to get valid F2FS checkpoint
mount: you must specify the filesystem type

Only way is to re-format the card using mkfs.f2fs

I took the f2fs patch that Jaegeuk Kim sent to Linus for 3.10 (here -
https://lkml.org/lkml/2013/5/8/122) and applied it cleanly to 3.9.6 I repeated the procedure but got the same result.

The BUG is from this line, from segment.c:

        if (!f2fs_clear_bit(offset, se->cur_valid_map))
            BUG();

Additional information I can give is

1. I tried using F2FS in ArchLinux, kernel 3.9.5, on an x86 machine, with the same SD card and the same USB3-to-PCIe chip and it worked flawlessly there.
2. I can work with other FS on the SD card on our custom board, such as Ext3, Ext4 and vfat, so this is not a H/W issue.

Could you please try to help me pinpoint/debug the problem ?

Here is the complete kernel BUG print:

kernel BUG at .../linux-3.9.6-adva/fs/f2fs/segment.c:214!

Oops: Exception in kernel mode, sig: 5 [#1]
PREEMPT SMP NR_CPUS=2 P2020 FSP150
Modules linked in: mdio(O) hardware_version(PO) clipresent(PO)

monotonic(O) restartcause(PO) panic_buffer(O)
NIP: c026a7e0 LR: c026a660 CTR: 00000000
REGS: ee761a60 TRAP: 0700 Tainted: P O
(3.9.6-dev_ogabbay-109482*)
MSR: 00029000 <CE,EE,ME> CR: 24a52588 XER: 20000000
TASK = efb444c0[1755] 'flush-8:0' THREAD: ee760000 CPU: 1
GPR00: 00000000 ee761b10 efb444c0 0000004c 00000000 00000000 01dc4900 eb0fa700
GPR08: 00000000 eb24cb00 00000040 00000040 00000038 00000000 ee761c64 00000000
GPR16: c0aeea80 00080000 00000000 00000000 0000ed31 eb0fa700 00000000 eb0fa734
GPR24: eb0fa700 00000080 f2030620 ffffffff ffffffc8 0000ed31 ffffffff c55a1000
NIP [c026a7e0] update_sit_entry+0x240/0x248
LR [c026a660] update_sit_entry+0xc0/0x248

Call Trace:

[ee761b10] [c55a1000] 0xc55a1000 (unreliable) [ee761b40] [c026d1f4] do_write_page+0x198/0x660 [ee761b80] [c026d84c] write_data_page+0xa4/0xb8 [ee761bc0] [c0265118] do_write_data_page+0x1e8/0x20c [ee761c20] [c02653dc] f2fs_write_data_page+0x2a0/0x2c0 [ee761c40] [c0263ad8] __f2fs_writepage+0x24/0x80 [ee761c50] [c00b05dc] write_cache_pages+0x1d0/0x35c [ee761d00] [c0263cf4] f2fs_write_data_pages+0xf4/0xfc [ee761d30] [c00b1d3c] do_writepages+0x30/0x64 [ee761d40] [c0103fbc] __writeback_single_inode+0x34/0x10c [ee761d60] [c0104ef8] writeback_sb_inodes+0x204/0x370 [ee761dd0] [c01050f4] __writeback_inodes_wb+0x90/0xd4 [ee761e00] [c01054cc] wb_writeback+0x204/0x20c [ee761e50] [c0105844] wb_do_writeback+0x144/0x20c [ee761eb0] [c0105980] bdi_writeback_thread+0x74/0x144 [ee761ee0] [c0059dc4] kthread+0xa8/0xac
[ee761f40] [c000f014] ret_from_kernel_thread+0x64/0x6c Instruction dump:
4bffff2c 813a0004 5720e8fe 7f39c8f8 39400001 5739077e 7d6900ae 7d59c830
7d6ac878 7d68c839 7d4901ae 4082fef0 <0fe00000> 0fe00000 9421ffe0 7c0802a6

Signature · 15 lines
Jaegeuk Kim
Samsung



------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
#8 lore raw

PATCH 1/2 lib, mkfs: fix endian conversion for crc calculation

Quoted 1 line

From 860da681961e6891d625abffa02d6df7dea4f5b2 Mon Sep 17 00:00:00 2001

From: Jaegeuk Kim <[email protected]>
Date: Wed, 19 Jun 2013 20:49:47 +0900
Subject: [PATCH 1/2] lib, mkfs: fix endian conversion for crc calculation
Cc: [email protected], [email protected], [email protected]

Let's store the crc value for the checkpoint blocks with __le32.

---
 include/f2fs_fs.h  |  1 +
 mkfs/f2fs_format.c | 19 ++++++++-----------
 2 files changed, 9 insertions(+), 11 deletions(-)
include/f2fs_fs.h +1 -0
index b4ac876..ad10815 100644
@@ -124,6 +124,7 @@
 #define PAGE_CACHE_SIZE		4096
 #define BITS_PER_BYTE		8
 #define F2FS_SUPER_MAGIC	0xF2F52010	/* F2FS Magic Number */
+#define CHECKSUM_OFFSET		4092
 
 /* for mkfs */
 #define F2FS_MIN_VOLUME_SIZE	104857600
mkfs/f2fs_format.c +8 -11
index 8e49ed4..9115520 100644
@@ -525,7 +525,7 @@ static int f2fs_write_check_point_pack(void)
 	}
 
 	/* 1. cp page 1 of checkpoint pack 1 */
-	ckp->checkpoint_ver = 1;
+	ckp->checkpoint_ver = cpu_to_le64(1);
 	ckp->cur_node_segno[0] =
 		cpu_to_le32(config.cur_seg[CURSEG_HOT_NODE]);
 	ckp->cur_node_segno[1] =
@@ -578,12 +578,11 @@ static int f2fs_write_check_point_pack(void)
 			((le32_to_cpu(super_block.segment_count_nat) / 2) <<
 			 le32_to_cpu(super_block.log_blocks_per_seg)) / 8);
 
-	ckp->checksum_offset = cpu_to_le32(4092);
+	ckp->checksum_offset = cpu_to_le32(CHECKSUM_OFFSET);
 
-	crc = f2fs_cal_crc32(F2FS_SUPER_MAGIC, ckp,
-					le32_to_cpu(ckp->checksum_offset));
-	*((u_int32_t *)((unsigned char *)ckp +
-				le32_to_cpu(ckp->checksum_offset))) = crc;
+	crc = f2fs_cal_crc32(F2FS_SUPER_MAGIC, ckp, CHECKSUM_OFFSET);
+	*((__le32 *)((unsigned char *)ckp + CHECKSUM_OFFSET)) =
+							cpu_to_le32(crc);
 
 	blk_size_bytes = 1 << le32_to_cpu(super_block.log_blocksize);
 	cp_seg_blk_offset = le32_to_cpu(super_block.segment0_blkaddr);
@@ -690,11 +689,9 @@ static int f2fs_write_check_point_pack(void)
 	 */
 	ckp->checkpoint_ver = 0;
 
-	crc = f2fs_cal_crc32(F2FS_SUPER_MAGIC, ckp,
-					le32_to_cpu(ckp->checksum_offset));
-	*((u_int32_t *)((unsigned char *)ckp +
-				le32_to_cpu(ckp->checksum_offset))) = crc;
-
+	crc = f2fs_cal_crc32(F2FS_SUPER_MAGIC, ckp, CHECKSUM_OFFSET);
+	*((__le32 *)((unsigned char *)ckp + CHECKSUM_OFFSET)) =
+							cpu_to_le32(crc);
 	cp_seg_blk_offset = (le32_to_cpu(super_block.segment0_blkaddr) +
 				config.blks_per_seg) *
 				blk_size_bytes;
Signature · 15 lines
1.8.3.1.437.g0dbd812



-- 
Jaegeuk Kim
Samsung


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
#9 lore raw

PATCH 2/2 mkfs: fix to store __le32 for checkpoint flags

In reply to Jaegeuk Kim
Quoted 1 line

From 55e3fbfb074e8e1bf769b5b0c1e6de8ea9df7260 Mon Sep 17 00:00:00 2001

From: Jaegeuk Kim <[email protected]>
Date: Wed, 19 Jun 2013 21:36:39 +0900
Subject: [PATCH 2/2] mkfs: fix to store __le32 for checkpoint flags
Cc: [email protected], [email protected], [email protected]

The checkpoint flags also should be stored as little endian style.

---
 mkfs/f2fs_format.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
mkfs/f2fs_format.c +1 -1
index 9115520..06771ff 100644
@@ -563,7 +563,7 @@ static int f2fs_write_check_point_pack(void)
 			le32_to_cpu(ckp->overprov_segment_count)) *
 			 config.blks_per_seg));
 	ckp->cp_pack_total_block_count = cpu_to_le32(8);
-	ckp->ckpt_flags |= CP_UMOUNT_FLAG;
+	ckp->ckpt_flags = cpu_to_le32(CP_UMOUNT_FLAG);
 	ckp->cp_pack_start_sum = cpu_to_le32(1);
 	ckp->valid_node_count = cpu_to_le32(1);
 	ckp->valid_inode_count = cpu_to_le32(1);
Signature · 15 lines
1.8.3.1.437.g0dbd812



-- 
Jaegeuk Kim
Samsung


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
#10 lore raw

PATCH 1/1 f2fs: fix crc endian conversion

In reply to Jaegeuk Kim
Quoted 1 line

From ed1e92d596f5356ff2f8f8af2818d36ca31f5cf1 Mon Sep 17 00:00:00 2001

From: Jaegeuk Kim <[email protected]>
Date: Wed, 19 Jun 2013 20:47:19 +0900
Subject: [PATCH] f2fs: fix crc endian conversion
Cc: [email protected], [email protected], [email protected]

While calculating CRC for the checkpoint block, we use __u32, but when storing the crc value to the disk, we use __le32.

Let's fix the inconsistency.

---
 fs/f2fs/checkpoint.c | 12 ++++++------
 fs/f2fs/f2fs.h       | 19 +++++++++++++++----
 2 files changed, 21 insertions(+), 10 deletions(-)
fs/f2fs/checkpoint.c +6 -6
index 9a77509..66a6b85 100644
@@ -357,8 +357,8 @@ static struct page *validate_checkpoint(struct f2fs_sb_info *sbi,
 	unsigned long blk_size = sbi->blocksize;
 	struct f2fs_checkpoint *cp_block;
 	unsigned long long cur_version = 0, pre_version = 0;
-	unsigned int crc = 0;
 	size_t crc_offset;
+	__u32 crc = 0;
 
 	/* Read the 1st cp block in this CP pack */
 	cp_page_1 = get_meta_page(sbi, cp_addr);
@@ -369,7 +369,7 @@ static struct page *validate_checkpoint(struct f2fs_sb_info *sbi,
 	if (crc_offset >= blk_size)
 		goto invalid_cp1;
 
-	crc = *(unsigned int *)((unsigned char *)cp_block + crc_offset);
+	crc = le32_to_cpu(*((__u32 *)((unsigned char *)cp_block + crc_offset)));
 	if (!f2fs_crc_valid(crc, cp_block, crc_offset))
 		goto invalid_cp1;
 
@@ -384,7 +384,7 @@ static struct page *validate_checkpoint(struct f2fs_sb_info *sbi,
 	if (crc_offset >= blk_size)
 		goto invalid_cp2;
 
-	crc = *(unsigned int *)((unsigned char *)cp_block + crc_offset);
+	crc = le32_to_cpu(*((__u32 *)((unsigned char *)cp_block + crc_offset)));
 	if (!f2fs_crc_valid(crc, cp_block, crc_offset))
 		goto invalid_cp2;
 
@@ -648,7 +648,7 @@ static void do_checkpoint(struct f2fs_sb_info *sbi, bool is_umount)
 	block_t start_blk;
 	struct page *cp_page;
 	unsigned int data_sum_blocks, orphan_blocks;
-	unsigned int crc32 = 0;
+	__u32 crc32 = 0;
 	void *kaddr;
 	int i;
 
@@ -717,8 +717,8 @@ static void do_checkpoint(struct f2fs_sb_info *sbi, bool is_umount)
 	get_nat_bitmap(sbi, __bitmap_ptr(sbi, NAT_BITMAP));
 
 	crc32 = f2fs_crc32(ckpt, le32_to_cpu(ckpt->checksum_offset));
-	*(__le32 *)((unsigned char *)ckpt +
-				le32_to_cpu(ckpt->checksum_offset))
+	*((__le32 *)((unsigned char *)ckpt +
+				le32_to_cpu(ckpt->checksum_offset)))
 				= cpu_to_le32(crc32);
 
 	start_blk = __start_cp_addr(sbi);
fs/f2fs/f2fs.h +15 -4
index 863a5e91..467d42d 100644
@@ -47,14 +47,25 @@ struct f2fs_mount_info {
 	unsigned int	opt;
 };
 
-static inline __u32 f2fs_crc32(void *buff, size_t len)
+#define CRCPOLY_LE 0xedb88320
+
+static inline __u32 f2fs_crc32(void *buf, size_t len)
 {
-	return crc32_le(F2FS_SUPER_MAGIC, buff, len);
+	unsigned char *p = (unsigned char *)buf;
+	__u32 crc = F2FS_SUPER_MAGIC;
+	int i;
+
+	while (len--) {
+		crc ^= *p++;
+		for (i = 0; i < 8; i++)
+			crc = (crc >> 1) ^ ((crc & 1) ? CRCPOLY_LE : 0);
+	}
+	return crc;
 }
 
-static inline bool f2fs_crc_valid(__u32 blk_crc, void *buff, size_t buff_size)
+static inline bool f2fs_crc_valid(__u32 blk_crc, void *buf, size_t buf_size)
 {
-	return f2fs_crc32(buff, buff_size) == blk_crc;
+	return f2fs_crc32(buf, buf_size) == blk_crc;
 }
 
 /*
Signature · 15 lines
1.8.3.1.437.g0dbd812



-- 
Jaegeuk Kim
Samsung


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
#11 lore raw
In reply to Jaegeuk Kim

Hi,

I tried your patches and they seem to work :)
I fixed umount flag yesterday but the CRC was the keypoint. Thanks. I will now stress-test the SD card on my board and let you know the results.

Best regards,
Oded

Quoted 15 lines · Jaegeuk Kim

Hi,
Could you test the following three patches sent right after this email?

For f2fs-tools:
1. store crc as __le32
2. store checkpoint flags as __le32

For f2fs:
1. handle crc as __le32

I suspect that:
1. mount failure is able to be occurred due to the crc endian error.
2. update_sit_entry bug_on is caused by the endian problem on the checkpoint flags.

Quoted 323 lines

If wrong checkpoint flag is got at mount time, we cannot build the latest sit entries correctly.

Thanks,

2013-06-18 (화), 15:10 +0300, Oded Gabbay:

Quoted 317 lines

Hi,

I printed also the segment no. and it appears that every time that segment 187 is written to, which is assigned to the HOT data, the system crashes.
BTW, even if I just do "echo oded > /mnt/file" and then just wait for about 30-45 seconds, the crash occurs

I got the following prints when I did the echo thing:

REMOVE_ME update_sit_entry(202):
offset = 0, segoff = 3584, blkaddr = 4096, segno = 0 REMOVE_ME update_sit_entry(202):
offset = 1, segoff = 99329, blkaddr = 99841, segno = 187 REMOVE_ME update_sit_entry(202):
offset = 0, segoff = 99328, blkaddr = 99840, segno = 187

------------[ cut here ]------------
kernel BUG

at /home/ogabbay/views/r5.xcj/software/os-software/powerpc/usr/src/linux-3.9.6-adva/fs/f2fs/segment.c:217!

Here is the print from the debugfs. You can see segment 187 is allocated to HOT data:

[cj:~] # cat /sys/kernel/debug/f2fs/status

=====[ partition info(loop0). #0 ]=====
[SB: 1] [CP: 2] [SIT: 2] [NAT: 2] [SSA: 1] [MAIN: 192(OverProv:55 Resv:48)]

Utilization: 0% (4 valid blocks)
- Node: 2 (Inode: 2, Other: 0)
- Data: 2

Main area: 192 segs, 192 secs 192 zones

   - COLD  data: 0, 0, 0
   - WARM  data: 1, 1, 1
   - HOT   data: 187, 187, 187
   - Dir   dnode: 190, 190, 190

- File dnode: 189, 189, 189
- Indir nodes: 188, 188, 188

- Valid: 6
- Dirty: 0
- Prefree: 0
- Free: 186 (186)

GC calls: 0 (BG: 0)
- data segments : 0
- node segments : 0
Try to move 0 blocks
- data blocks : 0
- node blocks : 0

Extent Hit Ratio: 0 / 0

Balancing F2FS Async:
- nodes 1 in 2
- dents 1 in dirs: 1
- meta 0 in 21
- NATs 2 > 29120
- SITs: 0
- free_nids: 2270

Distribution of User Blocks: [ valid | invalid | free ]
[|---|-----------------------------------------------]

SSR: 0 blocks in 0 segments
LFS: 0 blocks in 0 segments

BDF: 100, avg. vblocks: 0

Memory: 154 KB = static: 60 + cached: 94

Quoted 241 lines · Oded Gabbay

Hi,

I would like to share additional information I have from pr_err I put into the update_sit_entry function.

The following is the printout from the terminal. This is only the end of the printout. The start was with "segoff = 3584" and it went sequentially up until 9215, where then it jumped to 99329 and after that 99328 - which is the entry that caused the crash. Each time I repeated the experiment I got exactly the same results.

I put the pr_err after the line: "offset = GET_SEGOFF_FROM_SEG0(sbi, blkaddr) & (sbi->blocks_per_seg - 1);"
where segoff = GET_SEGOFF_FROM_SEG0(sbi, blkaddr)

Hope this helps.

REMOVE_ME update_sit_entry(202): offset = 0, segoff = 3584, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 1, segoff = 3585, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 2, segoff = 3586, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 3, segoff = 3587, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 4, segoff = 3588, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 5, segoff = 3589, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 6, segoff = 3590, sbi->blocks_per_seg = 512
:::
REMOVE_ME update_sit_entry(202): offset = 502, segoff = 9206, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 503, segoff = 9207, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 504, segoff = 9208, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 505, segoff = 9209, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 506, segoff = 9210, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 507, segoff = 9211, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 508, segoff = 9212, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 509, segoff = 9213, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 510, segoff = 9214, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 511, segoff = 9215, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 1, segoff = 99329, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 0, segoff = 99328, sbi->blocks_per_seg = 512

------------[ cut here ]------------
kernel BUG
at /home/ogabbay/views/r5.xcj/software/os-software/powerpc/usr/src/linux-3.9.6-adva/fs/f2fs/segment.c:217!
Oops: Exception in kernel mode, sig: 5 [#1]
PREEMPT SMP NR_CPUS=2 P2020 FSP150
Modules linked in: mdio(O) hardware_version(PO) clipresent(PO)

monotonic(O) restartcause(PO) panic_buffer(O)
NIP: c026c038 LR: c026bf0c CTR: 00000000
REGS: c5665a60 TRAP: 0700 Tainted: P O
(3.9.6-dev_ogabbay-109564*)
MSR: 00029000 <CE,EE,ME> CR: 24f82c48 XER: 20000000 TASK = ef943e80[1774] 'flush-7:0' THREAD: c5664000 CPU: 1
GPR00: 00000000 c5665b10 ef943e80 000000a6 00021000 00000000 f1e26054 725f7365
GPR08: 00000000 c5a13e40 00000040 00000040 00000067 00000000 c5665c64 00000000
GPR16: c1419240 00080000 00000000 00000000 000000bb ef8ce100 00000000 ef8ce134
GPR24: ffffffff ffffff99 000000bb ef8ce100 00000080 f1e57760 ffffffff c561e800
NIP [c026c038] update_sit_entry+0x234/0x23c
LR [c026bf0c] update_sit_entry+0x108/0x23c

Call Trace:
[c5665b10] [c026bed4] update_sit_entry+0xd0/0x23c (unreliable)
[c5665b40] [c026d1e8] do_write_page+0x198/0x660
[c5665b80] [c026d840] write_data_page+0xa4/0xb8
[c5665bc0] [c0265118] do_write_data_page+0x1e8/0x20c
[c5665c20] [c02653dc] f2fs_write_data_page+0x2a0/0x2c0
[c5665c40] [c0263ad8] __f2fs_writepage+0x24/0x80
[c5665c50] [c00b05dc] write_cache_pages+0x1d0/0x35c
[c5665d00] [c0263cf4] f2fs_write_data_pages+0xf4/0xfc
[c5665d30] [c00b1d3c] do_writepages+0x30/0x64
[c5665d40] [c0103fbc] __writeback_single_inode+0x34/0x10c
[c5665d60] [c0104ef8] writeback_sb_inodes+0x204/0x370
[c5665dd0] [c01050f4] __writeback_inodes_wb+0x90/0xd4
[c5665e00] [c01054cc] wb_writeback+0x204/0x20c
[c5665e50] [c0105844] wb_do_writeback+0x144/0x20c
[c5665eb0] [c0105980] bdi_writeback_thread+0x74/0x144
[c5665ee0] [c0059dc4] kthread+0xa8/0xac
[c5665f40] [c000f014] ret_from_kernel_thread+0x64/0x6c

--- Exception: 0 at (null)
LR = (null)
Instruction dump:
4bffff80 813d0004 5780e8fe 7f9ce0f8 39400001 579c077e 7d6900ae 7d5ce030
7d6ae078 7d68e039 7d4901ae 4082ff44 <0fe00000> 0fe00000 9421ffe0 7c0802a6

---[ end trace 707fc0870875373e ]---

Oded

Quoted 132 lines · Oded Gabbay

Hi,

I also suspect the endian conversion issue.
Attached is a gzip-ed file, which represent an image of a freshly formatted disk in f2fs in powerpc machine. I preferred to do it this way so I could have a small file to send you.
I did the following to create it:

[cj:~] # dd if=/dev/zero of=/tmp/test_file bs=4096 count=102400 102400+0 records in
102400+0 records out
419430400 bytes (419 MB) copied, 1.05112 s, 399 MB/s [cj:~] # losetup /dev/loop0 /tmp/test_file
[cj:~] # mkfs.f2fs -l label /dev/loop0

         F2FS-tools: mkfs.f2fs Ver: 1.1.0 (2013-06-13)

Info: Label = label
Info: sector size = 512
Info: total sectors = 819200 (in 512bytes)
Info: zone aligned segment0 blkaddr: 512
Info: format successful
[cj:~] # losetup -d /dev/loop0
[cj:/tmp] # gzip test_file

I then run my test application and got the same kernel BUG message.

Oded

Quoted 100 lines · Jaegeuk Kim

Hi,

Thank you for the report. :)

Can you send me the disk image right after formatting f2fs? As your previous patch, I strongly suspect the endian conversion bug.

Otherwise, I recommend you to test with the latest tree from:
http://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs.git

Thanks,

2013-06-16 (일), 14:51 +0300, Oded Gabbay:

Quoted 87 lines

Hi,

I'm working on a custom board with a PowerPC processor (Freescale P2020).
On the board there is an SD card, which is connected to a USB3 chip (from TI), which is connected to the PCI-e controller of the CPU. I'm running with Linux kernel 3.9.6, with our custom rootFS.

I formatted an SD card using the mkfs.f2fs utility (after fixing some
Big-endian issues - sent a patch a few days ago).
I then mounted the SD card, using "mount -o noatime,nodiratime,rw,nosuid,nodev,relatime,active_logs=6,uhelper=udisks2,background_gc_off /dev/sda /mnt/sd1" Then, I started a small user-space test application which opens a file
on the mount folder and starts to do "fwrite" into the file.
After 2-3 seconds, the kernel gives me a BUG and the system restarts.
When the system is up and I try to re-mount the SD card, I get the
following error message:

F2FS-fs (sda): Failed to get valid F2FS checkpoint
mount: you must specify the filesystem type

Only way is to re-format the card using mkfs.f2fs

I took the f2fs patch that Jaegeuk Kim sent to Linus for 3.10 (here -
https://lkml.org/lkml/2013/5/8/122) and applied it cleanly to 3.9.6 I repeated the procedure but got the same result.

The BUG is from this line, from segment.c:

         if (!f2fs_clear_bit(offset, se->cur_valid_map))
             BUG();

Additional information I can give is

1. I tried using F2FS in ArchLinux, kernel 3.9.5, on an x86 machine, with the same SD card and the same USB3-to-PCIe chip and it worked flawlessly there.
2. I can work with other FS on the SD card on our custom board, such as Ext3, Ext4 and vfat, so this is not a H/W issue.

Could you please try to help me pinpoint/debug the problem ?

Here is the complete kernel BUG print:

kernel BUG at .../linux-3.9.6-adva/fs/f2fs/segment.c:214!

Oops: Exception in kernel mode, sig: 5 [#1]
PREEMPT SMP NR_CPUS=2 P2020 FSP150
Modules linked in: mdio(O) hardware_version(PO) clipresent(PO)

monotonic(O) restartcause(PO) panic_buffer(O)
NIP: c026a7e0 LR: c026a660 CTR: 00000000
REGS: ee761a60 TRAP: 0700 Tainted: P O
(3.9.6-dev_ogabbay-109482*)
MSR: 00029000 <CE,EE,ME> CR: 24a52588 XER: 20000000
TASK = efb444c0[1755] 'flush-8:0' THREAD: ee760000 CPU: 1
GPR00: 00000000 ee761b10 efb444c0 0000004c 00000000 00000000 01dc4900 eb0fa700
GPR08: 00000000 eb24cb00 00000040 00000040 00000038 00000000 ee761c64 00000000
GPR16: c0aeea80 00080000 00000000 00000000 0000ed31 eb0fa700 00000000 eb0fa734
GPR24: eb0fa700 00000080 f2030620 ffffffff ffffffc8 0000ed31 ffffffff c55a1000
NIP [c026a7e0] update_sit_entry+0x240/0x248
LR [c026a660] update_sit_entry+0xc0/0x248

Call Trace:

[ee761b10] [c55a1000] 0xc55a1000 (unreliable) [ee761b40] [c026d1f4] do_write_page+0x198/0x660 [ee761b80] [c026d84c] write_data_page+0xa4/0xb8 [ee761bc0] [c0265118] do_write_data_page+0x1e8/0x20c [ee761c20] [c02653dc] f2fs_write_data_page+0x2a0/0x2c0 [ee761c40] [c0263ad8] __f2fs_writepage+0x24/0x80 [ee761c50] [c00b05dc] write_cache_pages+0x1d0/0x35c [ee761d00] [c0263cf4] f2fs_write_data_pages+0xf4/0xfc [ee761d30] [c00b1d3c] do_writepages+0x30/0x64 [ee761d40] [c0103fbc] __writeback_single_inode+0x34/0x10c [ee761d60] [c0104ef8] writeback_sb_inodes+0x204/0x370 [ee761dd0] [c01050f4] __writeback_inodes_wb+0x90/0xd4 [ee761e00] [c01054cc] wb_writeback+0x204/0x20c [ee761e50] [c0105844] wb_do_writeback+0x144/0x20c [ee761eb0] [c0105980] bdi_writeback_thread+0x74/0x144 [ee761ee0] [c0059dc4] kthread+0xa8/0xac
[ee761f40] [c000f014] ret_from_kernel_thread+0x64/0x6c Instruction dump:
4bffff2c 813a0004 5720e8fe 7f39c8f8 39400001 5739077e 7d6900ae 7d59c830
7d6ac878 7d68c839 7d4901ae 4082fef0 <0fe00000> 0fe00000 9421ffe0 7c0802a6

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

#12 lore raw
In reply to Jaegeuk Kim

Hi,

After stress-testing the F2FS on SD card and iNAND, and doing multiple mounts/umounts, I believe I can say the fix is working for the powerpc.

Thanks for all the help

Oded.

Quoted 15 lines · Jaegeuk Kim

Hi,
Could you test the following three patches sent right after this email?

For f2fs-tools:
1. store crc as __le32
2. store checkpoint flags as __le32

For f2fs:
1. handle crc as __le32

I suspect that:
1. mount failure is able to be occurred due to the crc endian error.
2. update_sit_entry bug_on is caused by the endian problem on the checkpoint flags.

Quoted 323 lines

If wrong checkpoint flag is got at mount time, we cannot build the latest sit entries correctly.

Thanks,

2013-06-18 (화), 15:10 +0300, Oded Gabbay:

Quoted 317 lines

Hi,

I printed also the segment no. and it appears that every time that segment 187 is written to, which is assigned to the HOT data, the system crashes.
BTW, even if I just do "echo oded > /mnt/file" and then just wait for about 30-45 seconds, the crash occurs

I got the following prints when I did the echo thing:

REMOVE_ME update_sit_entry(202):
offset = 0, segoff = 3584, blkaddr = 4096, segno = 0 REMOVE_ME update_sit_entry(202):
offset = 1, segoff = 99329, blkaddr = 99841, segno = 187 REMOVE_ME update_sit_entry(202):
offset = 0, segoff = 99328, blkaddr = 99840, segno = 187

------------[ cut here ]------------
kernel BUG

at /home/ogabbay/views/r5.xcj/software/os-software/powerpc/usr/src/linux-3.9.6-adva/fs/f2fs/segment.c:217!

Here is the print from the debugfs. You can see segment 187 is allocated to HOT data:

[cj:~] # cat /sys/kernel/debug/f2fs/status

=====[ partition info(loop0). #0 ]=====
[SB: 1] [CP: 2] [SIT: 2] [NAT: 2] [SSA: 1] [MAIN: 192(OverProv:55 Resv:48)]

Utilization: 0% (4 valid blocks)
- Node: 2 (Inode: 2, Other: 0)
- Data: 2

Main area: 192 segs, 192 secs 192 zones

   - COLD  data: 0, 0, 0
   - WARM  data: 1, 1, 1
   - HOT   data: 187, 187, 187
   - Dir   dnode: 190, 190, 190

- File dnode: 189, 189, 189
- Indir nodes: 188, 188, 188

- Valid: 6
- Dirty: 0
- Prefree: 0
- Free: 186 (186)

GC calls: 0 (BG: 0)
- data segments : 0
- node segments : 0
Try to move 0 blocks
- data blocks : 0
- node blocks : 0

Extent Hit Ratio: 0 / 0

Balancing F2FS Async:
- nodes 1 in 2
- dents 1 in dirs: 1
- meta 0 in 21
- NATs 2 > 29120
- SITs: 0
- free_nids: 2270

Distribution of User Blocks: [ valid | invalid | free ]
[|---|-----------------------------------------------]

SSR: 0 blocks in 0 segments
LFS: 0 blocks in 0 segments

BDF: 100, avg. vblocks: 0

Memory: 154 KB = static: 60 + cached: 94

Quoted 241 lines · Oded Gabbay

Hi,

I would like to share additional information I have from pr_err I put into the update_sit_entry function.

The following is the printout from the terminal. This is only the end of the printout. The start was with "segoff = 3584" and it went sequentially up until 9215, where then it jumped to 99329 and after that 99328 - which is the entry that caused the crash. Each time I repeated the experiment I got exactly the same results.

I put the pr_err after the line: "offset = GET_SEGOFF_FROM_SEG0(sbi, blkaddr) & (sbi->blocks_per_seg - 1);"
where segoff = GET_SEGOFF_FROM_SEG0(sbi, blkaddr)

Hope this helps.

REMOVE_ME update_sit_entry(202): offset = 0, segoff = 3584, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 1, segoff = 3585, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 2, segoff = 3586, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 3, segoff = 3587, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 4, segoff = 3588, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 5, segoff = 3589, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 6, segoff = 3590, sbi->blocks_per_seg = 512
:::
REMOVE_ME update_sit_entry(202): offset = 502, segoff = 9206, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 503, segoff = 9207, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 504, segoff = 9208, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 505, segoff = 9209, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 506, segoff = 9210, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 507, segoff = 9211, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 508, segoff = 9212, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 509, segoff = 9213, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 510, segoff = 9214, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 511, segoff = 9215, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 1, segoff = 99329, sbi->blocks_per_seg = 512
REMOVE_ME update_sit_entry(202): offset = 0, segoff = 99328, sbi->blocks_per_seg = 512

------------[ cut here ]------------
kernel BUG
at /home/ogabbay/views/r5.xcj/software/os-software/powerpc/usr/src/linux-3.9.6-adva/fs/f2fs/segment.c:217!
Oops: Exception in kernel mode, sig: 5 [#1]
PREEMPT SMP NR_CPUS=2 P2020 FSP150
Modules linked in: mdio(O) hardware_version(PO) clipresent(PO)

monotonic(O) restartcause(PO) panic_buffer(O)
NIP: c026c038 LR: c026bf0c CTR: 00000000
REGS: c5665a60 TRAP: 0700 Tainted: P O
(3.9.6-dev_ogabbay-109564*)
MSR: 00029000 <CE,EE,ME> CR: 24f82c48 XER: 20000000 TASK = ef943e80[1774] 'flush-7:0' THREAD: c5664000 CPU: 1
GPR00: 00000000 c5665b10 ef943e80 000000a6 00021000 00000000 f1e26054 725f7365
GPR08: 00000000 c5a13e40 00000040 00000040 00000067 00000000 c5665c64 00000000
GPR16: c1419240 00080000 00000000 00000000 000000bb ef8ce100 00000000 ef8ce134
GPR24: ffffffff ffffff99 000000bb ef8ce100 00000080 f1e57760 ffffffff c561e800
NIP [c026c038] update_sit_entry+0x234/0x23c
LR [c026bf0c] update_sit_entry+0x108/0x23c

Call Trace:
[c5665b10] [c026bed4] update_sit_entry+0xd0/0x23c (unreliable)
[c5665b40] [c026d1e8] do_write_page+0x198/0x660
[c5665b80] [c026d840] write_data_page+0xa4/0xb8
[c5665bc0] [c0265118] do_write_data_page+0x1e8/0x20c
[c5665c20] [c02653dc] f2fs_write_data_page+0x2a0/0x2c0
[c5665c40] [c0263ad8] __f2fs_writepage+0x24/0x80
[c5665c50] [c00b05dc] write_cache_pages+0x1d0/0x35c
[c5665d00] [c0263cf4] f2fs_write_data_pages+0xf4/0xfc
[c5665d30] [c00b1d3c] do_writepages+0x30/0x64
[c5665d40] [c0103fbc] __writeback_single_inode+0x34/0x10c
[c5665d60] [c0104ef8] writeback_sb_inodes+0x204/0x370
[c5665dd0] [c01050f4] __writeback_inodes_wb+0x90/0xd4
[c5665e00] [c01054cc] wb_writeback+0x204/0x20c
[c5665e50] [c0105844] wb_do_writeback+0x144/0x20c
[c5665eb0] [c0105980] bdi_writeback_thread+0x74/0x144
[c5665ee0] [c0059dc4] kthread+0xa8/0xac
[c5665f40] [c000f014] ret_from_kernel_thread+0x64/0x6c

--- Exception: 0 at (null)
LR = (null)
Instruction dump:
4bffff80 813d0004 5780e8fe 7f9ce0f8 39400001 579c077e 7d6900ae 7d5ce030
7d6ae078 7d68e039 7d4901ae 4082ff44 <0fe00000> 0fe00000 9421ffe0 7c0802a6

---[ end trace 707fc0870875373e ]---

Oded

Quoted 132 lines · Oded Gabbay

Hi,

I also suspect the endian conversion issue.
Attached is a gzip-ed file, which represent an image of a freshly formatted disk in f2fs in powerpc machine. I preferred to do it this way so I could have a small file to send you.
I did the following to create it:

[cj:~] # dd if=/dev/zero of=/tmp/test_file bs=4096 count=102400 102400+0 records in
102400+0 records out
419430400 bytes (419 MB) copied, 1.05112 s, 399 MB/s [cj:~] # losetup /dev/loop0 /tmp/test_file
[cj:~] # mkfs.f2fs -l label /dev/loop0

         F2FS-tools: mkfs.f2fs Ver: 1.1.0 (2013-06-13)

Info: Label = label
Info: sector size = 512
Info: total sectors = 819200 (in 512bytes)
Info: zone aligned segment0 blkaddr: 512
Info: format successful
[cj:~] # losetup -d /dev/loop0
[cj:/tmp] # gzip test_file

I then run my test application and got the same kernel BUG message.

Oded

Quoted 100 lines · Jaegeuk Kim

Hi,

Thank you for the report. :)

Can you send me the disk image right after formatting f2fs? As your previous patch, I strongly suspect the endian conversion bug.

Otherwise, I recommend you to test with the latest tree from:
http://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs.git

Thanks,

2013-06-16 (일), 14:51 +0300, Oded Gabbay:

Quoted 87 lines

Hi,

I'm working on a custom board with a PowerPC processor (Freescale P2020).
On the board there is an SD card, which is connected to a USB3 chip (from TI), which is connected to the PCI-e controller of the CPU. I'm running with Linux kernel 3.9.6, with our custom rootFS.

I formatted an SD card using the mkfs.f2fs utility (after fixing some
Big-endian issues - sent a patch a few days ago).
I then mounted the SD card, using "mount -o noatime,nodiratime,rw,nosuid,nodev,relatime,active_logs=6,uhelper=udisks2,background_gc_off /dev/sda /mnt/sd1" Then, I started a small user-space test application which opens a file
on the mount folder and starts to do "fwrite" into the file.
After 2-3 seconds, the kernel gives me a BUG and the system restarts.
When the system is up and I try to re-mount the SD card, I get the
following error message:

F2FS-fs (sda): Failed to get valid F2FS checkpoint
mount: you must specify the filesystem type

Only way is to re-format the card using mkfs.f2fs

I took the f2fs patch that Jaegeuk Kim sent to Linus for 3.10 (here -
https://lkml.org/lkml/2013/5/8/122) and applied it cleanly to 3.9.6 I repeated the procedure but got the same result.

The BUG is from this line, from segment.c:

         if (!f2fs_clear_bit(offset, se->cur_valid_map))
             BUG();

Additional information I can give is

1. I tried using F2FS in ArchLinux, kernel 3.9.5, on an x86 machine, with the same SD card and the same USB3-to-PCIe chip and it worked flawlessly there.
2. I can work with other FS on the SD card on our custom board, such as Ext3, Ext4 and vfat, so this is not a H/W issue.

Could you please try to help me pinpoint/debug the problem ?

Here is the complete kernel BUG print:

kernel BUG at .../linux-3.9.6-adva/fs/f2fs/segment.c:214!

Oops: Exception in kernel mode, sig: 5 [#1]
PREEMPT SMP NR_CPUS=2 P2020 FSP150
Modules linked in: mdio(O) hardware_version(PO) clipresent(PO)

monotonic(O) restartcause(PO) panic_buffer(O)
NIP: c026a7e0 LR: c026a660 CTR: 00000000
REGS: ee761a60 TRAP: 0700 Tainted: P O
(3.9.6-dev_ogabbay-109482*)
MSR: 00029000 <CE,EE,ME> CR: 24a52588 XER: 20000000
TASK = efb444c0[1755] 'flush-8:0' THREAD: ee760000 CPU: 1
GPR00: 00000000 ee761b10 efb444c0 0000004c 00000000 00000000 01dc4900 eb0fa700
GPR08: 00000000 eb24cb00 00000040 00000040 00000038 00000000 ee761c64 00000000
GPR16: c0aeea80 00080000 00000000 00000000 0000ed31 eb0fa700 00000000 eb0fa734
GPR24: eb0fa700 00000080 f2030620 ffffffff ffffffc8 0000ed31 ffffffff c55a1000
NIP [c026a7e0] update_sit_entry+0x240/0x248
LR [c026a660] update_sit_entry+0xc0/0x248

Call Trace:

[ee761b10] [c55a1000] 0xc55a1000 (unreliable) [ee761b40] [c026d1f4] do_write_page+0x198/0x660 [ee761b80] [c026d84c] write_data_page+0xa4/0xb8 [ee761bc0] [c0265118] do_write_data_page+0x1e8/0x20c [ee761c20] [c02653dc] f2fs_write_data_page+0x2a0/0x2c0 [ee761c40] [c0263ad8] __f2fs_writepage+0x24/0x80 [ee761c50] [c00b05dc] write_cache_pages+0x1d0/0x35c [ee761d00] [c0263cf4] f2fs_write_data_pages+0xf4/0xfc [ee761d30] [c00b1d3c] do_writepages+0x30/0x64 [ee761d40] [c0103fbc] __writeback_single_inode+0x34/0x10c [ee761d60] [c0104ef8] writeback_sb_inodes+0x204/0x370 [ee761dd0] [c01050f4] __writeback_inodes_wb+0x90/0xd4 [ee761e00] [c01054cc] wb_writeback+0x204/0x20c [ee761e50] [c0105844] wb_do_writeback+0x144/0x20c [ee761eb0] [c0105980] bdi_writeback_thread+0x74/0x144 [ee761ee0] [c0059dc4] kthread+0xa8/0xac
[ee761f40] [c000f014] ret_from_kernel_thread+0x64/0x6c Instruction dump:
4bffff2c 813a0004 5720e8fe 7f39c8f8 39400001 5739077e 7d6900ae 7d59c830
7d6ac878 7d68c839 7d4901ae 4082fef0 <0fe00000> 0fe00000 9421ffe0 7c0802a6

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel