[f2fs-dev] Kernel BUG when writing to f2fs drive, PowerPC, SD card, USB3

[f2fs-dev] Kernel BUG when writing to f2fs drive, PowerPC, SD card, USB3

[Oded Gabbay]

[-- Attachment #1.1: Type: text/plain, Size: 4406 bytes --]

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: ogabbay@advaoptical.com <%5C%22mailto:ogabbay@advaoptical.com%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


[-- Attachment #1.2: Type: text/html, Size: 7671 bytes --]

[-- Attachment #2: Type: text/plain, Size: 184 bytes --]

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

Build for Windows Store.

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

[-- Attachment #3: Type: text/plain, Size: 179 bytes --]

_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Re: [f2fs-dev] Kernel BUG when writing to f2fs drive, PowerPC, SD card, USB3

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

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 3e7cb33..28d31f1 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -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;
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index b15debc..b191449 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -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 */
diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
index 062424a..a96f7f4 100644
--- a/fs/f2fs/segment.h
+++ b/fs/f2fs/segment.h
@@ -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 */

On Sun, Jun 16, 2013 at 7:51 PM, Oded Gabbay <ogabbay@advaoptical.com> wrote:
> 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: ogabbay@advaoptical.com
>
> 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
> Linux-f2fs-devel@lists.sourceforge.net
> 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

Re: [f2fs-dev] Kernel BUG when writing to f2fs drive, PowerPC, SD card, USB3

[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:
> 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: ogabbay@advaoptical.com
>  
> 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 Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

-- 
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
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Re: [f2fs-dev] Kernel BUG when writing to f2fs drive, PowerPC, SD card, USB3

[Oded Gabbay]

Hi,

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

On 06/17/2013 10:20 AM, Huajun Li wrote:
> 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.
>
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index 3e7cb33..28d31f1 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -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;
> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> index b15debc..b191449 100644
> --- a/fs/f2fs/segment.c
> +++ b/fs/f2fs/segment.c
> @@ -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 */
> diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
> index 062424a..a96f7f4 100644
> --- a/fs/f2fs/segment.h
> +++ b/fs/f2fs/segment.h
> @@ -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 */
>
> On Sun, Jun 16, 2013 at 7:51 PM, Oded Gabbay <ogabbay@advaoptical.com> wrote:
>> 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: ogabbay@advaoptical.com
>>
>> 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
>> Linux-f2fs-devel@lists.sourceforge.net
>> 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

[f2fs-dev] [Virus Scan Error!] Re: Kernel BUG when writing to f2fs drive, PowerPC, SD card, USB3

[Oded Gabbay]

[-- Attachment #1.1: Type: text/plain, Size: 6422 bytes --]

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

On 06/17/2013 03:11 PM, Jaegeuk Kim wrote:
> 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:
>> 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: ogabbay@advaoptical.com
>>   
>> 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 Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel


[-- Attachment #1.2: Type: text/html, Size: 7538 bytes --]

[-- Attachment #2: test_file.gz --]
[-- Type: application/gzip, Size: 407582 bytes --]

[-- Attachment #3: Type: text/plain, Size: 184 bytes --]

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

Build for Windows Store.

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

[-- Attachment #4: Type: text/plain, Size: 179 bytes --]

_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Re: [f2fs-dev] Kernel BUG when writing to f2fs drive, PowerPC, SD card, USB3

[Oded Gabbay]

[-- Attachment #1.1: Type: text/plain, Size: 11187 bytes --]

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
On 06/17/2013 05:21 PM, Oded Gabbay wrote:
> 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
>
> On 06/17/2013 03:11 PM, Jaegeuk Kim wrote:
>> 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:
>>> 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:ogabbay@advaoptical.com
>>>   
>>> 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 listLinux-f2fs-devel@lists.sourceforge.net  https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
>


[-- Attachment #1.2: Type: text/html, Size: 13365 bytes --]

[-- Attachment #2: Type: text/plain, Size: 184 bytes --]

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

Build for Windows Store.

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

[-- Attachment #3: Type: text/plain, Size: 179 bytes --]

_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Re: [f2fs-dev] Kernel BUG when writing to f2fs drive, PowerPC, SD card, USB3

[Oded Gabbay]

[-- Attachment #1.1: Type: text/plain, Size: 13590 bytes --]

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


On 06/18/2013 12:44 PM, Oded Gabbay wrote:
> 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
> On 06/17/2013 05:21 PM, Oded Gabbay wrote:
>> 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
>>
>> On 06/17/2013 03:11 PM, Jaegeuk Kim wrote:
>>> 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:
>>>> 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:ogabbay@advaoptical.com
>>>>   
>>>> 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 listLinux-f2fs-devel@lists.sourceforge.net  https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
>>
>


[-- Attachment #1.2: Type: text/html, Size: 16592 bytes --]

[-- Attachment #2: Type: text/plain, Size: 184 bytes --]

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

Build for Windows Store.

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

[-- Attachment #3: Type: text/plain, Size: 179 bytes --]

_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Re: [f2fs-dev] Kernel BUG when writing to f2fs drive, PowerPC, SD card, USB3

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

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:
> 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
> 
> 
> On 06/18/2013 12:44 PM, Oded Gabbay wrote:
> 
> > 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
> > On 06/17/2013 05:21 PM, Oded Gabbay wrote:
> > 
> > > 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
> > > 
> > > On 06/17/2013 03:11 PM, Jaegeuk Kim wrote:
> > > 
> > > > 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:
> > > > > 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 
> > > > > 
> > > > 
-- 
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
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

[f2fs-dev] [PATCH 1/2] lib, mkfs: fix endian conversion for crc calculation

[Jaegeuk Kim]

>From 860da681961e6891d625abffa02d6df7dea4f5b2 Mon Sep 17 00:00:00 2001
From: Jaegeuk Kim <jaegeuk.kim@samsung.com>
Date: Wed, 19 Jun 2013 20:49:47 +0900
Subject: [PATCH 1/2] lib, mkfs: fix endian conversion for crc calculation
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net

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

Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
---
 include/f2fs_fs.h  |  1 +
 mkfs/f2fs_format.c | 19 ++++++++-----------
 2 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/include/f2fs_fs.h b/include/f2fs_fs.h
index b4ac876..ad10815 100644
--- a/include/f2fs_fs.h
+++ b/include/f2fs_fs.h
@@ -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
diff --git a/mkfs/f2fs_format.c b/mkfs/f2fs_format.c
index 8e49ed4..9115520 100644
--- a/mkfs/f2fs_format.c
+++ b/mkfs/f2fs_format.c
@@ -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;
-- 
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

[f2fs-dev] [PATCH 2/2] mkfs: fix to store __le32 for checkpoint flags

[Jaegeuk Kim]

>From 55e3fbfb074e8e1bf769b5b0c1e6de8ea9df7260 Mon Sep 17 00:00:00 2001
From: Jaegeuk Kim <jaegeuk.kim@samsung.com>
Date: Wed, 19 Jun 2013 21:36:39 +0900
Subject: [PATCH 2/2] mkfs: fix to store __le32 for checkpoint flags
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net

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

Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
---
 mkfs/f2fs_format.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mkfs/f2fs_format.c b/mkfs/f2fs_format.c
index 9115520..06771ff 100644
--- a/mkfs/f2fs_format.c
+++ b/mkfs/f2fs_format.c
@@ -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);
-- 
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

[f2fs-dev] [PATCH] f2fs: fix crc endian conversion

[Jaegeuk Kim]

>From ed1e92d596f5356ff2f8f8af2818d36ca31f5cf1 Mon Sep 17 00:00:00 2001
From: Jaegeuk Kim <jaegeuk.kim@samsung.com>
Date: Wed, 19 Jun 2013 20:47:19 +0900
Subject: [PATCH] f2fs: fix crc endian conversion
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net

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.

Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
---
 fs/f2fs/checkpoint.c | 12 ++++++------
 fs/f2fs/f2fs.h       | 19 +++++++++++++++----
 2 files changed, 21 insertions(+), 10 deletions(-)

diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 9a77509..66a6b85 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -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);
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 863a5e91..467d42d 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -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;
 }
 
 /*
-- 
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

Re: [f2fs-dev] Kernel BUG when writing to f2fs drive, PowerPC, SD card, USB3

[Oded Gabbay]

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

On 06/19/2013 03:43 PM, Jaegeuk Kim wrote:
> 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:
>> 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
>>
>>
>> On 06/18/2013 12:44 PM, Oded Gabbay wrote:
>>
>>> 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
>>> On 06/17/2013 05:21 PM, Oded Gabbay wrote:
>>>
>>>> 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
>>>>
>>>> On 06/17/2013 03:11 PM, Jaegeuk Kim wrote:
>>>>
>>>>> 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:
>>>>>> 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
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Re: [f2fs-dev] Kernel BUG when writing to f2fs drive, PowerPC, SD card, USB3

[Oded Gabbay]

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.
On 06/19/2013 03:43 PM, Jaegeuk Kim wrote:
> 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:
>> 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
>>
>>
>> On 06/18/2013 12:44 PM, Oded Gabbay wrote:
>>
>>> 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
>>> On 06/17/2013 05:21 PM, Oded Gabbay wrote:
>>>
>>>> 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
>>>>
>>>> On 06/17/2013 03:11 PM, Jaegeuk Kim wrote:
>>>>
>>>>> 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:
>>>>>> 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
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel