Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

CMA hangs kernel early when booting #308

Closed
wrobelda opened this issue Jun 3, 2013 · 9 comments
Closed

CMA hangs kernel early when booting #308

wrobelda opened this issue Jun 3, 2013 · 9 comments

Comments

@wrobelda
Copy link

wrobelda commented Jun 3, 2013

I have enabled CMA and noticed that about 8/10 boots it would hang the RPI during early phase when booting:

[ 1.301514] io scheduler noop registered
[ 1.305563] io scheduler deadline registered
[ 1.309890] io scheduler cfq registered (default)
[ 1.345174] Console: switching to colour frame buffer device 228x61
[ 1.371584] kgdb: Registered I/O driver kgdboc.
[ 1.376914] vc-cma: Videocore CMA driver
[ 1.380960] vc-cma: vc_cma_base = 0x0d400000
[ 1.385830] vc-cma: vc_cma_size = 0x11800000 (280 MiB)
[ 1.391532] vc-cma: vc_cma_initial = 0x00000000 (0 MiB)
[ 1.406255] brd: module loaded
[ 1.414592] loop: module loaded
[ 1.418209] vchiq: vchiq_init_state: slot_zero = 0xcd400000, is_master = 0
[ 1.426039] vchiq_get_state: g_state.remote->initialised != 1 (0)

I have no extra options defined in config.txt except for gpu_mem=128.
cmdline is also standard with extra: coherent_pool=6M cma=2M smsc95xx.turbo_mode=N

Right upon disabling the cma, everything is back to normal.

me@rpi ~ $ uname -a
Linux rpi 3.6.11+ #456 PREEMPT Mon May 20 17:42:15 BST 2013 armv6l GNU/Linux

me@rpi ~ $ /opt/vc/bin/vcgencmd version
May 26 2013 21:47:02
Copyright (c) 2012 Broadcom
version 53261d4ede3ba2b660e4201aca9bd4544565a3ce (clean) (release)
@licaon-kter
Copy link

Do test without coherent_pool=6M cma=2M too since afaik is not needed as long as config.txt has say:

gpu_mem_256=112
cma_lwm=16
cma_hwm=32
cma_offline_start=16

@wrobelda
Copy link
Author

wrobelda commented Jun 3, 2013

I tried - nothing's changed, same issue.

@wrobelda
Copy link
Author

wrobelda commented Jun 5, 2013

I also tried this on another PI board with same result.

@popcornmix
Copy link
Collaborator

From my point of view, CMA has never been completely reliable, so it not recommended, nor supported.
I'm hoping we'll some more kernel bug tracking manpower soon, and CMA is one of the things that would be good to get reliable (but it won't be top of the list...)

@licaon-kter
Copy link

WTH?
I had Raspbian+custom 3.9.x for a while.
I reinstalled Raspbian+custom 3.9.x+prior packages and now CMA fails like @wrobelda said.

/LE: adding coherent_pool=6M in /boot/cmdline.txt fixed it, strangely it worked without it before.

@wrobelda: can you test like this too? ( just coherent_pool=6M added, but not cma=2M and the config.txt like I said above )

@wrobelda
Copy link
Author

@licaon-kter
I tried that today the way you described but it still failed in the same way as previously.

@programista-zacny
Copy link

I have the same issue. I tried everything desribed above.

@Ruffio
Copy link

Ruffio commented Jul 28, 2016

@wrobelda has this issue been resolved? If yes, then please close this issue.

@Ruffio
Copy link

Ruffio commented Aug 29, 2016

@popcornmix please consider closing this issue, as there has been merged a commit a year ago and no response to my ping a month ago has been performed

popcornmix pushed a commit that referenced this issue Mar 14, 2023
@gregkh
ubifs: ubifs_releasepage: Remove ubifs_assert(0) to valid this process
7750be5 
[ Upstream commit 66f4742 ]

There are two states for ubifs writing pages:
1. Dirty, Private
2. Not Dirty, Not Private

The normal process cannot go to ubifs_releasepage() which means there
exists pages being private but not dirty. Reproducer[1] shows that it
could occur (which maybe related to [2]) with following process:

     PA                     PB                    PC
lock(page)[PA]
ubifs_write_end
  attach_page_private         // set Private
  __set_page_dirty_nobuffers  // set Dirty
unlock(page)

write_cache_pages[PA]
  lock(page)
  clear_page_dirty_for_io(page)	// clear Dirty
  ubifs_writepage

                        do_truncation[PB]
			  truncate_setsize
			    i_size_write(inode, newsize) // newsize = 0

    i_size = i_size_read(inode)	// i_size = 0
    end_index = i_size >> PAGE_SHIFT
    if (page->index > end_index)
      goto out // jump
out:
unlock(page)   // Private, Not Dirty

						generic_fadvise[PC]
						  lock(page)
						  invalidate_inode_page
						    try_to_release_page
						      ubifs_releasepage
						        ubifs_assert(c, 0)
		                                        // bad assertion!
						  unlock(page)
			  truncate_pagecache[PB]

Then we may get following assertion failed:
  UBIFS error (ubi0:0 pid 1683): ubifs_assert_failed [ubifs]:
  UBIFS assert failed: 0, in fs/ubifs/file.c:1513
  UBIFS warning (ubi0:0 pid 1683): ubifs_ro_mode [ubifs]:
  switched to read-only mode, error -22
  CPU: 2 PID: 1683 Comm: aa Not tainted 5.16.0-rc5-00184-g0bca5994cacc-dirty #308
  Call Trace:
    dump_stack+0x13/0x1b
    ubifs_ro_mode+0x54/0x60 [ubifs]
    ubifs_assert_failed+0x4b/0x80 [ubifs]
    ubifs_releasepage+0x67/0x1d0 [ubifs]
    try_to_release_page+0x57/0xe0
    invalidate_inode_page+0xfb/0x130
    __invalidate_mapping_pages+0xb9/0x280
    invalidate_mapping_pagevec+0x12/0x20
    generic_fadvise+0x303/0x3c0
    ksys_fadvise64_64+0x4c/0xb0

[1] https://bugzilla.kernel.org/show_bug.cgi?id=215373
[2] https://linux-mtd.infradead.narkive.com/NQoBeT1u/patch-rfc-ubifs-fix-assert-failed-in-ubifs-set-page-dirty

Fixes: 1e51764 ("UBIFS: add new flash file system")
Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Sasha Levin <sashal@kernel.org>
popcornmix pushed a commit that referenced this issue Mar 14, 2023
@gregkh
ubifs: ubifs_releasepage: Remove ubifs_assert(0) to valid this process
bd188ff 
[ Upstream commit 66f4742 ]

There are two states for ubifs writing pages:
1. Dirty, Private
2. Not Dirty, Not Private

The normal process cannot go to ubifs_releasepage() which means there
exists pages being private but not dirty. Reproducer[1] shows that it
could occur (which maybe related to [2]) with following process:

     PA                     PB                    PC
lock(page)[PA]
ubifs_write_end
  attach_page_private         // set Private
  __set_page_dirty_nobuffers  // set Dirty
unlock(page)

write_cache_pages[PA]
  lock(page)
  clear_page_dirty_for_io(page)	// clear Dirty
  ubifs_writepage

                        do_truncation[PB]
			  truncate_setsize
			    i_size_write(inode, newsize) // newsize = 0

    i_size = i_size_read(inode)	// i_size = 0
    end_index = i_size >> PAGE_SHIFT
    if (page->index > end_index)
      goto out // jump
out:
unlock(page)   // Private, Not Dirty

						generic_fadvise[PC]
						  lock(page)
						  invalidate_inode_page
						    try_to_release_page
						      ubifs_releasepage
						        ubifs_assert(c, 0)
		                                        // bad assertion!
						  unlock(page)
			  truncate_pagecache[PB]

Then we may get following assertion failed:
  UBIFS error (ubi0:0 pid 1683): ubifs_assert_failed [ubifs]:
  UBIFS assert failed: 0, in fs/ubifs/file.c:1513
  UBIFS warning (ubi0:0 pid 1683): ubifs_ro_mode [ubifs]:
  switched to read-only mode, error -22
  CPU: 2 PID: 1683 Comm: aa Not tainted 5.16.0-rc5-00184-g0bca5994cacc-dirty #308
  Call Trace:
    dump_stack+0x13/0x1b
    ubifs_ro_mode+0x54/0x60 [ubifs]
    ubifs_assert_failed+0x4b/0x80 [ubifs]
    ubifs_releasepage+0x67/0x1d0 [ubifs]
    try_to_release_page+0x57/0xe0
    invalidate_inode_page+0xfb/0x130
    __invalidate_mapping_pages+0xb9/0x280
    invalidate_mapping_pagevec+0x12/0x20
    generic_fadvise+0x303/0x3c0
    ksys_fadvise64_64+0x4c/0xb0

[1] https://bugzilla.kernel.org/show_bug.cgi?id=215373
[2] https://linux-mtd.infradead.narkive.com/NQoBeT1u/patch-rfc-ubifs-fix-assert-failed-in-ubifs-set-page-dirty

Fixes: 1e51764 ("UBIFS: add new flash file system")
Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@popcornmix @wrobelda @Ruffio @licaon-kter @programista-zacny