From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by bombadil.infradead.org with esmtps (Exim 4.68 #1 (Red Hat Linux)) id 1LDCAB-0003cJ-Sx for linux-mtd@lists.infradead.org; Thu, 18 Dec 2008 06:15:12 +0000 Subject: Re: ubifs backtrace for - BUG: scheduling while atomic - when runs out of space From: Artem Bityutskiy To: Cal Page In-Reply-To: <1229580771.17960.46.camel@sauron> References: <49491CA7.5020200@runbox.com> <1229580771.17960.46.camel@sauron> Content-Type: text/plain; charset=utf-8 Date: Thu, 18 Dec 2008 08:16:01 +0200 Message-Id: <1229580961.17960.51.camel@sauron> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: ubifs Reply-To: dedekind@infradead.org List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 whil= e atomic' > >=20 > > Backtrace:=20 > >=20 > > [] (schedule+0x0/0x6dc) from [] (wait_op_done+0xb0/= 0x150) > > [] (wait_op_done+0x0/0x150) from [] (send_prog_page= +0x64/0x74) > > r5 =3D C0F2ABE0 r4 =3D C661FAC0=20 > > [] (send_prog_page+0x0/0x74) from [] (mxc_nand_comm= and+0x16c/0x3ec) > > [] (mxc_nand_command+0x0/0x3ec) from [] (nand_write= _page+0x80/0xd4) > > [] (nand_write_page+0x0/0xd4) from [] (nand_do_writ= e_ops+0x2b0/0x340) > > r7 =3D 0004AA60 r6 =3D C4B07000 r5 =3D 00000000 r4 =3D 00000800 > > [] (nand_do_write_ops+0x0/0x340) from [] (nand_writ= e+0xa0/0xc0) > > [] (nand_write+0x0/0xc0) from [] (part_write+0xb0/0= xec) > > [] (part_write+0x0/0xec) from [] (ubi_io_write+0x78= /0xb4) > > r7 =3D FFFFFFE2 r6 =3D C4B07000 r5 =3D 00000000 r4 =3D 00010000 > > [] (ubi_io_write+0x0/0xb4) from [] (ubi_eba_write_l= eb+0x94/0x83c) > > [] (ubi_eba_write_leb+0x0/0x83c) from [] (ubi_leb_w= rite+0xec/0x104) > > [] (ubi_leb_write+0x0/0x104) from [] (dbg_leb_write= +0x9c/0xb8) > > r8 =3D C4B07000 r7 =3D 0000003C r6 =3D C509BB00 r5 =3D 00000800 r4= =3D C44DE000=20 > > [] (dbg_leb_write+0x0/0xb8) from [] (ubifs_wbuf_wri= te_nolock+0x444/0x6f4) > > [] (ubifs_wbuf_write_nolock+0x0/0x6f4) from [] (wri= te_head+0x10c/0x150) > > [] (write_head+0x0/0x150) from [] (ubifs_jnl_write_= inode+0x12c/0x25c) > > [] (ubifs_jnl_write_inode+0x0/0x25c) from [] (ubifs= _write_inode+0x118/0x18c) > > [] (ubifs_write_inode+0x0/0x18c) from [] (__writeba= ck_single_inode+0x200/0x384) > > r7 =3D C405C5EC r6 =3D C459EC00 r5 =3D C405C554 r4 =3D 00000001 > > [] (__writeback_single_inode+0x0/0x384) from [] (sy= nc_sb_inodes+0x1d8/0x2c8) > > [] (sync_sb_inodes+0x0/0x2c8) from [] (generic_sync= _sb_inodes+0x10/0x14) > > [] (generic_sync_sb_inodes+0x0/0x14) from [] (ubifs= _budget_space+0x98c/0xe98) > > [] (ubifs_budget_space+0x0/0xe98) from [] (ubifs_pr= epare_write+0x18c/0x1a4) > > [] (ubifs_prepare_write+0x0/0x1a4) from [] (generic= _file_buffered_write+0x2a0/0x694) > > [] (generic_file_buffered_write+0x4/0x694) from [] = (__generic_file_aio_write_nolock+0x53c/0x5bc) > > [] (__generic_file_aio_write_nolock+0x0/0x5bc) from [] (generic_file_aio_write+0x7c/0xf0) > > [] (generic_file_aio_write+0x4/0xf0) from [] (ubifs= _aio_write+0x1b4/0x244) > > [] (ubifs_aio_write+0x4/0x244) from [] (do_sync_wri= te+0xc0/0x114) > > [] (do_sync_write+0x0/0x114) from [] (vfs_write+0xb= 8/0x194) > > r6 =3D C44DFF80 r5 =3D BEF15AF8 r4 =3D C5183CA0=20 > > [] (vfs_write+0x0/0x194) from [] (sys_write+0x4c/0x= 80) > > r7 =3D 00000004 r6 =3D 00000000 r5 =3D 0006E000 r4 =3D C5183CA0 > > [] (sys_write+0x0/0x80) from [] (ret_fast_syscall+0= x0/0x2c) > > r6 =3D 4001D660 r5 =3D BEF15AF8 r4 =3D 00002000=20 > > Code: e59f0650 ebf5b444 ebf554f6 e3a03000 (e5833000)=20 >=20 > 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. >=20 > 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. --=20 Best regards, Artem Bityutskiy (=D0=91=D0=B8=D1=82=D1=8E=D1=86=D0=BA=D0=B8=D0=B9 =D0=90= =D1=80=D1=82=D1=91=D0=BC)