[lkml]   [2002]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: ext3 deadlock?
Paul Mackerras wrote:
> I'm having a problem with 2.5.15 on an old slow powerbook 3400. It
> gets stuck during boot at the point where it starts syslogd. At that
> point show_state() reveals that kjournald and one of the two syslogd
> processes are stuck in D state. The stack trace for kjournald is:
> schedule
> __wait_on_buffer
> journal_commit_transaction
> kjournald

kjournald is actually running a commit. So recovery was successful
and the filesystem is up and running.

It's this trace which is the problem. All the other processes
are blocked by kjournald.

kjournald is pretty much write-only. It will perform the
occasional read to load the indirect blocks which describe the
journal location. But that would show a different backtrace.

It appears that kjournald has submitted a block for writeout
(via submit_bh() or ll_rw_block()) and the interrupt which
signifies completion simply hasn't happened.

> ...
> Can anyone suggest where I could start looking to work out why
> kjournald is getting stuck in __wait_on_buffer? Where in the code
> does the corresponding wakeup happen?

journal_commit_transaction() writes blocks from several different
places, via ll_rw_block() or submit_bh(). It waits for the
buffers to come unlocked in the end_buffer_io_sync() or
journal_end_buffer_io_sync() completion handlers.

Possibly the device driver has failed to deliver an interrupt.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:26    [W:0.033 / U:6.788 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site