Re: 2.4.20: Proccess stuck in __lock_page ...

[Marcelo Tosatti (marcelo@conectiva.com.br)]

On Mon, 26 May 2003, manish wrote:

> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/