lkml.org 
[lkml]   [2008]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjecthow to debug: processes with -D (uninterruptible sleep)
Hi,
I am using linux 2.6.22. I am testing my nand driver/nand device.
I am using a arm based processor.

To test my nand device, i am using fs-tests package that comes
with mtd-utils git tree.

These are standard filesystem regression tests.

I am running the test to test a particular partition.

During one of the tests: The test process hangs.
When i do a ps -eal i get a -D against that process.
That particular process remains in that state forever.

I have eliminated all the infinte loops (checks for busy/read pin/nand reset)
in my nand driver. I have tried to put debug prints to print
failures in my nand
device. I dont see any failure prints when i run the tests.

I tried doing "echo t > /proc/sysrq-trigger" i am appending the results.

Basically, i am trying to isolate the code that is causing the process
to go into an uniterruptible sleep state.

It is to be noted that - When the fs-tests process has gone into
"uninterruptible
sleep state" accessing the partion under test makes that process
also go into the uninterruptible sleep state"

What i am trying to say is - If i try to copy something to the
"partition under test"
that process (cp) also goes into that state.

In other words, Once the fs-test process goes into -D state
("uninterruptible sleep state")
I cannot access the partition under test.

However, i can access other partitions in the nand device without
any problem.

I need some suggestions/advices to debug the issue.
How does one debug such a issue.

please advice.

Thanks and Regards,
sriram




Output of echo t > /proc/sysrq-trigger
-----------------------------------------------------



test_2 D C022BB54 0 267 248 (NOTLB)
[<c022b620>] (schedule+0x0/0x608) from [<c022c434>] (io_schedule+0x2c/0x48)
[<c022c408>] (io_schedule+0x0/0x48) from [<c0077eb4>] (sync_page+0x50/0x5c)
r5:00000000 r4:c38a3a34
[<c0077e64>] (sync_page+0x0/0x5c) from [<c022c62c>] (__wait_on_bit+0x64/0xa8)
[<c022c5c8>] (__wait_on_bit+0x0/0xa8) from [<c0078258>]
(wait_on_page_bit+0xa8/0xb8)
[<c00781b0>] (wait_on_page_bit+0x0/0xb8) from [<c0079e60>]
(read_cache_page+0x38/0x58)
r6:00007080 r5:c0340a80 r4:00000000
[<c0079e28>] (read_cache_page+0x0/0x58) from [<c0113c50>]
(jffs2_gc_fetch_page+0x28/0x60)
r5:00007000 r4:c38a3afc
[<c0113c28>] (jffs2_gc_fetch_page+0x0/0x60) from [<c011128c>]
(jffs2_garbage_collect_pass+0x1130/0x185c)
r4:00007850
[<c011015c>] (jffs2_garbage_collect_pass+0x0/0x185c) from [<c010b358>]
(jffs2_reserve_space+0x134/0x1d0)
[<c010b224>] (jffs2_reserve_space+0x0/0x1d0) from [<c010dd18>]
(jffs2_write_inode_range+0x60/0x37c)
[<c010dcb8>] (jffs2_write_inode_range+0x0/0x37c) from [<c0108f08>]
(jffs2_commit_write+0x130/0x264)
[<c0108dd8>] (jffs2_commit_write+0x0/0x264) from [<c007a5c4>]
(generic_file_buffered_write+0x41c/0x610)
[<c007a1ac>] (generic_file_buffered_write+0x4/0x610) from [<c007af84>]
(__generic_file_aio_write_nolock+0x51c/0x54c)
[<c007aa68>] (__generic_file_aio_write_nolock+0x0/0x54c) from
[<c007b034>] (generic_file_aio_write+0x80/0xf4)
[<c007afb8>] (generic_file_aio_write+0x4/0xf4) from [<c0097d10>]
(do_sync_write+0xc0/0x110)
[<c0097c50>] (do_sync_write+0x0/0x110) from [<c0097e2c>] (vfs_write+0xcc/0x150)
r9:c38a2000 r8:00000000 r7:00000190 r6:c38a3f78 r5:bec68b1c
r4:c3d313e0
[<c0097d60>] (vfs_write+0x0/0x150) from [<c0097f70>] (sys_write+0x4c/0x74)
r7:00007850 r6:c38a3f78 r5:c3d313e0 r4:c3d31400
[<c0097f24>] (sys_write+0x0/0x74) from [<c0038de0>] (ret_fast_syscall+0x0/0x2c)
r8:c0038f84 r7:00000004 r6:00800000 r5:bec68cac r4:00000000


\
 
 \ /
  Last update: 2008-04-01 17:41    [W:1.063 / U:1.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site