On Tue, 22 Feb 2000, Benno Senoner wrote:
> > OK, I commented out the bh->b_count++; schedule(); bh->b_count-- in
> > buffer.c and got the expected result; stuck process problem goes away
> > and latency increases to 12msec.
> >
> > Apparently the schedule() is needed, what is the safe way to do it?
> > What is the scenario which results in the stuck process?
> >
> > Wm
>
> Has someone out here figured out why 2.2.10N6B does not crash,
> since it contains the same
> bh->b_count++; schedule(); bh->b_count--
> in the buffer.c part of the patch ?
>
> But anyway, again we see that the disk I/O + buffering are the most expensive
> in terms of execution path len.
>
Sorry, I spoke too soon. It just took longer this time.
BTW, my machine no longer crashes/oopses it only gets a stuck process.
I now have /bin/sync stuck in state D. Details below:
# ps ax
.
.
168 tty1 S 0:00 -su
587 tty1 D 0:00 sync
600 ttyp0 R 0:00 ps ax
# cat /proc/version
Linux version 2.2.14aa7 (root@vmebox) (gcc version 2.7.2.3) #6 Tue Feb 22
09:44:52 EST 2000
# dmesg
.
.
Entering kdb due to Keyboard Entry
kdb> btp 587
EBP EIP Function(args)
0xc6cf5f54 0xc0112a58 schedule+0x150( )
0xc6cf5f74 0xc012825e __wait_on_buffer+0x92( 0xc0412360)
0xc6cf5f9c 0xc0128491 sync_buffers+0x1f1( 0x0, 0x1)
0xc6cf5fb0 0xc0128533 fsync_dev+0x27( 0x0)
0xc6cf5fbc 0xc0128546 sys_sync+0xa( 0xbffffad4, 0x0, 0x804a040, 0x1,
0xbffffad4)
0xbffffa88 0xc0108c1c system_call
kdb> go
Any ideas?
Wm
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:30 EST