From: Artem Bityutskiy <dedekind@infradead.org>
To: Cal Page <pagcal@runbox.com>
Cc: ubifs <linux-mtd@lists.infradead.org>
Subject: Re: ubifs backtrace for - BUG: scheduling while atomic - when runs out of space
Date: Thu, 18 Dec 2008 08:16:01 +0200 [thread overview]
Message-ID: <1229580961.17960.51.camel@sauron> (raw)
In-Reply-To: <1229580771.17960.46.camel@sauron>
On Thu, 2008-12-18 at 08:12 +0200, Artem Bityutskiy wrote:
> On Wed, 2008-12-17 at 10:37 -0500, Cal Page wrote:
> > !!! Note: BUG() placed at kernel/sched.c schedule() at 'scheduling while atomic'
> >
> > Backtrace:
> >
> > [<c0e1e640>] (schedule+0x0/0x6dc) from [<c0d2245c>] (wait_op_done+0xb0/0x150)
> > [<c0d223ac>] (wait_op_done+0x0/0x150) from [<c0d22740>] (send_prog_page+0x64/0x74)
> > r5 = C0F2ABE0 r4 = C661FAC0
> > [<c0d226dc>] (send_prog_page+0x0/0x74) from [<c0d22934>] (mxc_nand_command+0x16c/0x3ec)
> > [<c0d227c8>] (mxc_nand_command+0x0/0x3ec) from [<c0d1ddd8>] (nand_write_page+0x80/0xd4)
> > [<c0d1dd58>] (nand_write_page+0x0/0xd4) from [<c0d1e83c>] (nand_do_write_ops+0x2b0/0x340)
> > r7 = 0004AA60 r6 = C4B07000 r5 = 00000000 r4 = 00000800
> > [<c0d1e58c>] (nand_do_write_ops+0x0/0x340) from [<c0d1f71c>] (nand_write+0xa0/0xc0)
> > [<c0d1f67c>] (nand_write+0x0/0xc0) from [<c0d153e8>] (part_write+0xb0/0xec)
> > [<c0d15338>] (part_write+0x0/0xec) from [<c0d2a6b0>] (ubi_io_write+0x78/0xb4)
> > r7 = FFFFFFE2 r6 = C4B07000 r5 = 00000000 r4 = 00010000
> > [<c0d2a638>] (ubi_io_write+0x0/0xb4) from [<c0d28af0>] (ubi_eba_write_leb+0x94/0x83c)
> > [<c0d28a5c>] (ubi_eba_write_leb+0x0/0x83c) from [<c0d27d9c>] (ubi_leb_write+0xec/0x104)
> > [<c0d27cb0>] (ubi_leb_write+0x0/0x104) from [<c0c77fac>] (dbg_leb_write+0x9c/0xb8)
> > r8 = C4B07000 r7 = 0000003C r6 = C509BB00 r5 = 00000800 r4 = C44DE000
> > [<c0c77f10>] (dbg_leb_write+0x0/0xb8) from [<c0c542ac>] (ubifs_wbuf_write_nolock+0x444/0x6f4)
> > [<c0c53e68>] (ubifs_wbuf_write_nolock+0x0/0x6f4) from [<c0c46f30>] (write_head+0x10c/0x150)
> > [<c0c46e24>] (write_head+0x0/0x150) from [<c0c470d0>] (ubifs_jnl_write_inode+0x12c/0x25c)
> > [<c0c46fa4>] (ubifs_jnl_write_inode+0x0/0x25c) from [<c0c50c38>] (ubifs_write_inode+0x118/0x18c)
> > [<c0c50b20>] (ubifs_write_inode+0x0/0x18c) from [<c0bf2e68>] (__writeback_single_inode+0x200/0x384)
> > r7 = C405C5EC r6 = C459EC00 r5 = C405C554 r4 = 00000001
> > [<c0bf2c68>] (__writeback_single_inode+0x0/0x384) from [<c0bf32a0>] (sync_sb_inodes+0x1d8/0x2c8)
> > [<c0bf30c8>] (sync_sb_inodes+0x0/0x2c8) from [<c0bf35a4>] (generic_sync_sb_inodes+0x10/0x14)
> > [<c0bf3594>] (generic_sync_sb_inodes+0x0/0x14) from [<c0c65534>] (ubifs_budget_space+0x98c/0xe98)
> > [<c0c64ba8>] (ubifs_budget_space+0x0/0xe98) from [<c0c4a578>] (ubifs_prepare_write+0x18c/0x1a4)
> > [<c0c4a3ec>] (ubifs_prepare_write+0x0/0x1a4) from [<c0bb22f4>] (generic_file_buffered_write+0x2a0/0x694)
> > [<c0bb2058>] (generic_file_buffered_write+0x4/0x694) from [<c0bb2c24>] (__generic_file_aio_write_nolock+0x53c/0x5bc)
> > [<c0bb26e8>] (__generic_file_aio_write_nolock+0x0/0x5bc) from [<c0bb2d20>] (generic_file_aio_write+0x7c/0xf0)
> > [<c0bb2ca8>] (generic_file_aio_write+0x4/0xf0) from [<c0c49220>] (ubifs_aio_write+0x1b4/0x244)
> > [<c0c49070>] (ubifs_aio_write+0x4/0x244) from [<c0bd2718>] (do_sync_write+0xc0/0x114)
> > [<c0bd2658>] (do_sync_write+0x0/0x114) from [<c0bd30d8>] (vfs_write+0xb8/0x194)
> > r6 = C44DFF80 r5 = BEF15AF8 r4 = C5183CA0
> > [<c0bd3020>] (vfs_write+0x0/0x194) from [<c0bd37f0>] (sys_write+0x4c/0x80)
> > r7 = 00000004 r6 = 00000000 r5 = 0006E000 r4 = C5183CA0
> > [<c0bd37a4>] (sys_write+0x0/0x80) from [<c0b6fde0>] (ret_fast_syscall+0x0/0x2c)
> > r6 = 4001D660 r5 = BEF15AF8 r4 = 00002000
> > Code: e59f0650 ebf5b444 ebf554f6 e3a03000 (e5833000)
>
> Sorry, I do not have ideas. It sounds like you have schedule() called
> while having a spinlock locked. None of these functions seem to do have
> spinlocks.
>
> What I would do, I'd put explicit 'schedule()' call at the beginning of
> each function in the dump. Hopefully this would show the offender
> function.
Also, please, enable lockdep. It is under "Kernel hacking -> Lock
debugging: prove locking correctness" in the kernel config menu.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
prev parent reply other threads:[~2008-12-18 6:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-17 15:37 ubifs backtrace for - BUG: scheduling while atomic - when runs out of space Cal Page
2008-12-18 6:12 ` Artem Bityutskiy
2008-12-18 6:16 ` Artem Bityutskiy [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1229580961.17960.51.camel@sauron \
--to=dedekind@infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=pagcal@runbox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox