On Sun, 2002-04-28 at 15:04, Christoph Hellwig wrote:
> Robert, have you also looked at the initial bug report?
>
> It triggers a debug_lock_break(551), and my reading of the lock_break
> stuff is that 551 is your magic constant for "should not happen"..
Not exactly - 551 is my value for "I have not received a value here
yet". I.e., I do not assume I know the lock depth ever. Instead, I set
all the debugs to 551 and filled them in appropriately. I did this to
make sure I was right - if I just filled in "1" or whatever I thought
the depth was, I would see no debug message and thus not know if I was
right or not hitting the code path.
> Althouhh I haven't found out in which function as the patch in whiches
> context this happened is to big to understand without applying I guess
> it is fsync_inode_buffers. Rationale: besides the different lists
> they operate on fsync_inode_buffers and fsync_inode_data_buffers are the
> same thing in mainline (XXX: backport Al's 2.5 change to make both call a
> generic version taking a list_head), but the lock_break stuff is different
> without any reaon understandable to me.
>
> GCS: could you please rerun your testcase after you replaced the occurance
> of debug_lock_break(551); in fsync_inode_buffers with debug_lock_break(1)
> and retry?
Well, if DEBUG is set and the code is 551 - you should see a message in
syslog whenever you hit the path with the correct lock depth. Is it 1?
Robert Love
_______________________________________________
Jfs-discussion mailing list
[EMAIL PROTECTED]
http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jfs-discussion
