[PATCH V2 3/3] mmc: mmci: Reverse IRQ handling for the arm_variant

John Stultz john.stultz at linaro.org
Mon Jun 16 16:29:33 PDT 2014

On Mon, Jun 16, 2014 at 3:41 PM, John Stultz <john.stultz at linaro.org> wrote:
> On Mon, Jun 16, 2014 at 2:20 PM, Ulf Hansson <ulf.hansson at linaro.org> wrote:
>> This patch based upon my latest mmc tree and the next branch. I tried
>> to apply it for 3.15, and I think you will be able resolve the
>> conflict - I should be quite trivial.
> No worries. I just didn't want to waste time resolving it if it was
> logically dependent on some other change.
> I'll give it a shot and get back to you.

So unfortunately I'm still seeing trouble..

[   94.202843] EXT4-fs error (device mmcblk0p5):
ext4_mb_generate_buddy:756: group 1, 2303 clusters in bitmap, 2272 in
gd; block bitmap corrupt.
[   94.203873] Aborting journal on device mmcblk0p5-8.
[   94.206553] Kernel panic - not syncing: EXT4-fs (device mmcblk0p5):
panic forced after error
[   94.206553]
[   94.207420] CPU: 0 PID: 1 Comm: init Not tainted
3.15.0-00002-g044f37a-dirty #589
[   94.208330] [<c0011725>] (unwind_backtrace) from [<c000f3f1>]
[   94.208835] [<c000f3f1>] (show_stack) from [<c042d599>]
[   94.209288] [<c042d599>] (dump_stack) from [<c042a57f>] (panic+0x67/0x178)
[   94.209724] [<c042a57f>] (panic) from [<c0135055>]
[   94.210184] [<c0135055>] (ext4_handle_error) from [<c01358db>]
[   94.210747] [<c01358db>] (__ext4_grp_locked_error) from
[<c0143691>] (ext4_mb_generate_buddy+0x1b1/0x29c)
[   94.211392] [<c0143691>] (ext4_mb_generate_buddy) from [<c0144dfd>]
[   94.211959] [<c0144dfd>] (ext4_mb_init_cache) from [<c014517f>]
[   94.213973] [<c014517f>] (ext4_mb_init_group) from [<c01452f3>]
[   94.214873] [<c01452f3>] (ext4_mb_good_group) from [<c01462ab>]
[   94.215953] [<c01462ab>] (ext4_mb_regular_allocator) from
[<c01486b1>] (ext4_mb_new_blocks+0x2fd/0x4e4)
[   94.216939] [<c01486b1>] (ext4_mb_new_blocks) from [<c013fe41>]
[   94.217694] [<c013fe41>] (ext4_ext_map_blocks) from [<c01230ff>]
[   94.219200] [<c0126839>] (mpage_map_and_submit_extent) from
[<c0127049>] (ext4_writepages+0x2b9/0x4e8)
[   94.219972] [<c0127049>] (ext4_writepages) from [<c0094e69>]
[   94.220648] [<c0094e69>] (do_writepages) from [<c008cbcd>]
[   94.221391] [<c008cbcd>] (__filemap_fdatawrite_range) from
[<c008cc3f>] (filemap_flush+0x23/0x28)
[   94.222135] [<c008cc3f>] (filemap_flush) from [<c012c419>]
[   94.222806] [<c012c419>] (ext4_rename) from [<c00c3707>]
[   94.223496] [<c00c3707>] (vfs_rename) from [<c00c3c0b>]
[   94.224154] [<c00c3c0b>] (SyS_renameat2) from [<c00c3c83>]
[   94.224801] [<c00c3c83>] (SyS_rename) from [<c000cd41>]

That said, this mirrors the behavior when I was reverting your change
by hand on-top of 3.15. While git bisect pointed to your patch and
reverting it from the commit seems to resolve the issue at that point,
there seems to be some other commit in the 3.14->3.15-rc1 interval
that is causing problems as well.

Are there any sort of debugging options for mmc that I can use to try
to better narrow down whats going wrong?


More information about the linux-arm-kernel mailing list