On Fri, Nov 9, 2018 at 3:36 PM Eugeniy Paltsev <eugeniy.paltsev@xxxxxxxxxxxx> wrote: > I still can reproduce errors about hung task when I run bonnie++ benchmark on arc/hsdk board > (ARC HS38 CPU, Synopsys DW MMC controller). Hm I didn't use bonnie++ but I used iozone excessively to verify Adrians patches, at times leaving it running for days without any problems. (Though not on these hardwares.) > Error message > is like: > ----------------------------->8---------------------------- > # mount /dev/mmcblk0p4 /mnt/mmcblk0p4 > EXT4-fs (mmcblk0p4): mounted filesystem with > ordered data mode. Opts: (null) > # bonnie++ -u root -r 256 -s 512 -x 1 -d /mnt/mmcblk0p4 > Using uid:0, gid:0. > Writing with putc()...done > Writing > intelligently...done > Rewriting...INFO: task bonnie++:187 blocked for more than 10 seconds. > Not tainted 4.19.0 #2 I'm not sure hanging for more than 10 seconds is really a problem. eMMCs can sometimes become really slow when doing internal garbage collection. Are you sure this is not the case? If you run it without the hang checks, will it still complete, or is this one of those benchmarks that just keep running until you interrupt it? > (filemap_fdatawait_keep_errors) from > [<c02cc3d0>] (jbd2_journal_commit_transaction+0x9b8/0x167c) > [ 6402.570857] [<c02cc3d0>] > (jbd2_journal_commit_transaction) from [<c02d0478>] (kjournald2+0xe4/0x2c8) > [ 6402.580011] [<c02d0478>] (kjournald2) from [<c013ab04>] This seems more like some excessive wait in the file system journal to me (OK I might be wrong). Which is also known to thrash the specific sectors where the journal is kept which may very well lead to a lot of garbage collection in the card. (OK I am half-guessing...) What filesystem are you using on this eMMC? If something exotic, could you just try ext4 as most embedded systems use and see what happens? Yours, Linus Walleij
