On Sat, Apr 20, 2002 at 01:46:15PM -0700, Andrew Morton <[EMAIL PROTECTED]> wrote: > That's a livelock in the lock-break patch. Blame me for that. I do not blame you Andrew, I never blame a kernel hacker. Btw, your patch does not help. I was going mad, and did some tests. It showed that if I write on a loop device, and sync for example, then conditional_schedule_needed() will be constant 1 (one), and nr_rescheds is zero all the time. Thus it steps into the true leaf of the if, and as it returns with -EAGAIN, it tries again, then again etc. Thus the question is what is the change between disable the lock break patch (it is enough to disable it and recompile, writing on loop devices will work), and the enabled state, where conditional_schedule_needed() does not get back to zero.
> It perhaps does imply that a large number of buffers of the > wrong dirty state are getting onto the wrong list. JFS > maybe missing a refile_buffer() call somewhere. I do not know. But beware, this bug affects the XFS+preemption+lock break tri as well. It seems 'plug in' journaling filesystems change something in a wrong way, as notice that I have ext2 on my loop filesystems, and the system freezes. If you have other ideas for a fix, I would be happy to try them out. Thanks, Laszlo _______________________________________________ Jfs-discussion mailing list [EMAIL PROTECTED] http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jfs-discussion
