Tetsuo Handa
from-****@I-lov*****
2008年 11月 29日 (土) 00:56:24 JST
熊猫です。 Naohiro Aota さんは書きました: > 2ch のほうであれこれしてましたがあらためてこちらに。 http://pc11.2ch.net/test/read.cgi/linux/1212502041/591- は青田さんだったのですね。 > Nov 26 07:11:58 [kernel] Call Trace: > Nov 26 07:11:58 [kernel] [<ffffffff8038b28a>] ? find_next_domain+0x4ca/0x910 > Nov 26 07:11:58 [kernel] [<ffffffff8038bfd8>] ? search_binary_handler_with_transition+0xf8/0x6f0 > Nov 26 07:11:58 [kernel] [<ffffffff802803bd>] ? follow_page+0x1cd/0x200 > - Last output repeated twice - > Nov 26 07:11:58 [kernel] [<ffffffff80281ad4>] ? get_user_pages+0x104/0x430 > Nov 26 07:11:58 [kernel] [<ffffffff8029e1a7>] ? copy_strings+0x1c7/0x1f0 > Nov 26 07:11:58 [kernel] [<ffffffff8029f706>] ? do_execve+0x296/0x2d0 > Nov 26 07:11:58 [kernel] [<ffffffff8020a6f9>] ? sys_execve+0x49/0x80 > Nov 26 07:11:58 [kernel] [<ffffffff8020c61a>] ? stub_execve+0x6a/0xc0 > Nov 26 07:11:58 [kernel] RIP [<ffffffff80390839>] ccs_free+0x19/0x80 > Nov 26 07:11:58 [kernel] RSP <ffff880054b3bc28> う〜ん、全部「 ? 」付きということで、特定に繋がりそうなトレースではないようですね。 128 バイトある ccs_free() の中の 25 バイト目で引っかかっているようですので、 objdump からヒントが得られないかと思い、こちらでもクロスコンパイルを 試みたのですが、 # cd /usr/portage/sys-kernel/ # svn checkout http://svn.sourceforge.jp/svnroot/tomoyo/tags/htdocs/repos/gentoo-overlay/sys-kernel/ccs-sources/ # emerge ccs-sources Calculating dependencies -!!! Digest verification failed: !!! /usr/portage/sys-kernel/ccs-sources/ccs-sources-2.6.25-r7.ebuild !!! Reason: Filesize does not match recorded size !!! Got: 960 !!! Expected: 1079 !!! Digest verification failed: !!! /usr/portage/sys-kernel/ccs-sources/ccs-sources-2.6.25-r7.ebuild !!! Reason: Filesize does not match recorded size !!! Got: 960 !!! Expected: 1079 という結果になり、クロスコンパイル以前で止まってしまいました。 というわけで、 objdump -D fs/realpath.o の結果を( tomoyo-dev または熊猫宛に)送っていただけますか? ただし、アセンブラはほとんど読めないので期待しないでください。(^^; > ;; はっきりしていないといえば、 updatedb 中に suspend させると TOMOYO ま > ;; わりでひっかかかって suspend できなかった記憶があるのですが、これまた > ;; うまく再現できていません。 カーネルまわりの再現は難しいですね…。 http://search.luky.org/linux-kernel.2004/msg73653.html がヒットしました。 TOMOYO カーネルでなくても updatedb 実行中にサスペンドが失敗することがあるようです。 カーネル内のメモリが一時的に不足(またはフラグメント化)していたのかもしれませんね。