> On Tue, 22 Jan 2008 09:29:27 +0100 Oliver Neukum <[EMAIL PROTECTED]> wrote: > Am Dienstag, 22. Januar 2008 00:28:57 schrieb Serge Gavrilov: > > vuescan D c066ce00 4972 25367 1 > > d8adfdb4 00000046 c066ce00 c066ce00 00000282 d8adfd94 c046c0f9 > > d878ac80 > > c066ce00 c2071080 d8be6c70 00000000 00857e29 00000282 d8adfdc4 > > 00857e29 > > d8adfe24 d8adfdec c0469d66 00000046 c058a120 e1ba9b94 dfa75c10 > > 00857e29 > > Call Trace: > > [<c0469d66>] schedule_timeout+0x46/0x90 > > [<c0469cee>] io_schedule_timeout+0x1e/0x30 > > [<c016fdcb>] congestion_wait+0x7b/0xa0 > > [<c016a0ce>] balance_dirty_pages+0xae/0x170 > > [<c016a277>] balance_dirty_pages_ratelimited_nr+0x97/0xb0 > > [<c016a1d1>] set_page_dirty_balance+0x41/0x50 > > [<c0172bd6>] do_wp_page+0x256/0x470 > > [<c01740b9>] handle_mm_fault+0x239/0x2a0 > > [<c011c247>] do_page_fault+0x157/0x660 > > [<c046c5b2>] error_code+0x72/0x78 > > This looks like a VM problem. Vuescan just triggers it because a raw scan > is huge. >
This could be caused if a block device isn't performing writes for some reason: nothing is cleaning dirty pages, system gets stuck. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
