> Marcelo Tosatti wrote:
>
> >
> >On Mon, 26 May 2003, manish wrote:
> >
> >>Hello !
> >>
> >>I am running the 2.4.20 kernel on a system with 3.5 GB RAM and dual CPU.
> >>I am running bonnie accross four drives in parallel:
> >>
> >>bonnie -s 1000 -d /<dir-name>
> >>
> >>bdflush settings on this system:
> >>
> >>[root@dyn-10-123-130-235 vm]# cat bdflush
> >>2 50 32 100 50 300 1 0 0
> >>
> >>All the bonnie process and any other process (like df, ps -ef etc.) are
> >>hung in __lock_page. Breaking into kdb, I observe the following for one
> >>such bonnie process:
> >>
> >>schedule(..)
> >>__lock_page(..)
> >>lock_page(..)
> >>do_generic_file_read(..)
> >>generic_file_read(..)
> >>
> >>After this, the processes never exit the hang. At times, a couple of
> >>bonnie processes complete but the hang still occurs with the remaining
> >>processes and with the other processes.
> >>
> >>I tried out the 2.5.33 kernel (one of the 2.5 series) and observed that
> >>the hang does not occur. If I run, two bonnie processes, they never get
> >>stuck. Actually, if I run 4 parallel mke2fs, they too get stuck.
> >>
> >>Any clues where this could be happening?
> >>
> >
> >Hi,
> >
> >Are you sure there is no disk activity ?
> >
> >Run vmstat and check that, please.
> >
> Hello !
>
> Thanks for the response.
>
> The light on the controller does not blink at all. Intitially, it does
> blink. However, after this hang, it does not at all.
>
> vmstat after the hang
>
> 1 1 0 780 2056892 5784 1415324 0 0 0 4 102 7
> 49 1 50
> 1 1 0 780 2056892 5784 1415324 0 0 0 4 102 9
> 49 1 50
> 1 1 0 780 2056892 5784 1415324 0 0 0 5 104 10
> 29 21 50
> 0 1 0 780 2056708 5784 1415324 0 0 0 1 104 12
> 0 13 86
> 1 1 0 780 2222904 5784 1249396 0 0 0 172 126 25
> 0 4 96
> 0 1 0 780 3081052 5784 391324 0 0 0 403 161 43
> 0 12 88
> procs memory swap io
> system cpu
> r b w swpd free buff cache si so bi bo in cs us
> sy id
> 0 1 0 780 3080952 5788 391408 0 0 29 9 120 72
> 0 0 100
> 0 1 0 780 3080952 5788 391408 0 0 0 0 111 19
> 0 0 100
> 0 1 0 780 3080952 5788 391408 0 0 0 1 103 9
> 0 0 100
> 0 1 0 780 3080952 5788 391408 0 0 0 0 101 9
> 0 0 100
> 0 1 0 780 3080952 5788 391408 0 0 0 0 101 7
> 0 0 100
> 0 1 0 780 3080952 5788 391408 0 0 0 0 101 9
> 0 0 100
> 0 1 0 780 3080952 5788 391408 0 0 0 0 102 9
> 0 0 100
> 0 1 0 780 3080952 5788 391408 0 0 0 1 101 8
> 0 0 100
> 0 1 0 780 3081308 5788 391420 0 0 0 231 150 92
> 3 0 97
> 0 1 0 780 3081308 5788 391420 0 0 0 0 102 7
> 0 0 100
> 0 1 0 780 3081308 5788 391420 0 0 0 0 102 7
> 0 0 100
> 0 1 0 780 3081304 5788 391420 0 0 0 0 101 9
> 0 0 100
> 0 1 0 780 3081304 5788 391420 0 0 0 0 102 8
> 0 0 100
> 0 1 0 780 3081300 5788 391420 0 0 0 0 101 8
> 0 0 100
> 0 1 0 780 3081300 5788 391420 0 0 0 0 101 9
> 0 0 100
> 0 1 0 780 3081296 5788 391420 0 0 0 0 101 7
Ok, and does it happen with the stock kernel?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/