> > On 2.6.23 it could happen even without loopback
>
> Let's focus on this point, because we already know how the lockup
> happens _with_ loopback and any other kind of bdi stacking.
>
> Can you describe the setup? Or better still, can you reproduce it and
> post the sysrq-t output?
Hi
The
On 2.6.23 it could happen even without loopback
Let's focus on this point, because we already know how the lockup
happens _with_ loopback and any other kind of bdi stacking.
Can you describe the setup? Or better still, can you reproduce it and
post the sysrq-t output?
Hi
The trace is
> On 2.6.23 it could happen even without loopback
Let's focus on this point, because we already know how the lockup
happens _with_ loopback and any other kind of bdi stacking.
Can you describe the setup? Or better still, can you reproduce it and
post the sysrq-t output?
Thanks,
Miklos
-
To
On 2.6.23 it could happen even without loopback
Let's focus on this point, because we already know how the lockup
happens _with_ loopback and any other kind of bdi stacking.
Can you describe the setup? Or better still, can you reproduce it and
post the sysrq-t output?
Thanks,
Miklos
-
To
> > Why are there over-limit dirty pages that no one is writing?
>
> Please do a sysrq-t, and cat /proc/vmstat during the hang. Those
> will show us what exactly is happening.
I did and I posted relevant information from my finding --- it looped in
balance_dirty_pages.
> I've seen this type
Why are there over-limit dirty pages that no one is writing?
Please do a sysrq-t, and cat /proc/vmstat during the hang. Those
will show us what exactly is happening.
I did and I posted relevant information from my finding --- it looped in
balance_dirty_pages.
I've seen this type of hang
> > > Arguably we just have the wrong backing-device here, and what we should do
> > > is to propagate the real backing device's pointer through up into the
> > > filesystem. There's machinery for this which things like DM stacks use.
> > >
> > > I wonder if the post-2.6.23 changes happened to
> > > Arguably we just have the wrong backing-device here, and what we
> > > should do is to propagate the real backing device's pointer through
> > > up into the filesystem. There's machinery for this which things
> > > like DM stacks use.
Just thinking about the new implementation --- you
On Sun, 11 Nov 2007, Mikulas Patocka wrote:
> On Sat, 10 Nov 2007, Andrew Morton wrote:
>
> > On Sat, 10 Nov 2007 20:51:31 +0100 (CET) Mikulas Patocka <[EMAIL
> > PROTECTED]> wrote:
> >
> > > Hi
> > >
> > > I am experiencing a transient lockup in 'D' state with loopback device.
> > > It
> >
> > Arguably we just have the wrong backing-device here, and what we should do
> > is to propagate the real backing device's pointer through up into the
> > filesystem. There's machinery for this which things like DM stacks use.
> >
> > I wonder if the post-2.6.23 changes happened to make this
On Sat, 10 Nov 2007, Andrew Morton wrote:
> On Sat, 10 Nov 2007 20:51:31 +0100 (CET) Mikulas Patocka <[EMAIL PROTECTED]>
> wrote:
>
> > Hi
> >
> > I am experiencing a transient lockup in 'D' state with loopback device. It
> > happens when process writes to a filesystem in loopback with
On Sat, 2007-11-10 at 14:54 -0800, Andrew Morton wrote:
> On Sat, 10 Nov 2007 20:51:31 +0100 (CET) Mikulas Patocka <[EMAIL PROTECTED]>
> wrote:
>
> > Hi
> >
> > I am experiencing a transient lockup in 'D' state with loopback device. It
> > happens when process writes to a filesystem in
On Sat, 10 Nov 2007 20:51:31 +0100 (CET) Mikulas Patocka <[EMAIL PROTECTED]>
wrote:
> Hi
>
> I am experiencing a transient lockup in 'D' state with loopback device. It
> happens when process writes to a filesystem in loopback with command like
> dd if=/dev/zero of=/s/fill bs=4k
>
> CPU is
Hi
I am experiencing a transient lockup in 'D' state with loopback device. It
happens when process writes to a filesystem in loopback with command like
dd if=/dev/zero of=/s/fill bs=4k
CPU is idle, disk is idle too, yet the dd process is waiting in 'D' in
congestion_wait called from
Hi
I am experiencing a transient lockup in 'D' state with loopback device. It
happens when process writes to a filesystem in loopback with command like
dd if=/dev/zero of=/s/fill bs=4k
CPU is idle, disk is idle too, yet the dd process is waiting in 'D' in
congestion_wait called from
On Sat, 10 Nov 2007 20:51:31 +0100 (CET) Mikulas Patocka [EMAIL PROTECTED]
wrote:
Hi
I am experiencing a transient lockup in 'D' state with loopback device. It
happens when process writes to a filesystem in loopback with command like
dd if=/dev/zero of=/s/fill bs=4k
CPU is idle, disk
On Sat, 2007-11-10 at 14:54 -0800, Andrew Morton wrote:
On Sat, 10 Nov 2007 20:51:31 +0100 (CET) Mikulas Patocka [EMAIL PROTECTED]
wrote:
Hi
I am experiencing a transient lockup in 'D' state with loopback device. It
happens when process writes to a filesystem in loopback with
Arguably we just have the wrong backing-device here, and what we should do
is to propagate the real backing device's pointer through up into the
filesystem. There's machinery for this which things like DM stacks use.
I wonder if the post-2.6.23 changes happened to make this problem go
On Sat, 10 Nov 2007, Andrew Morton wrote:
On Sat, 10 Nov 2007 20:51:31 +0100 (CET) Mikulas Patocka [EMAIL PROTECTED]
wrote:
Hi
I am experiencing a transient lockup in 'D' state with loopback device. It
happens when process writes to a filesystem in loopback with command like
dd
On Sun, 11 Nov 2007, Mikulas Patocka wrote:
On Sat, 10 Nov 2007, Andrew Morton wrote:
On Sat, 10 Nov 2007 20:51:31 +0100 (CET) Mikulas Patocka [EMAIL
PROTECTED] wrote:
Hi
I am experiencing a transient lockup in 'D' state with loopback device.
It
happens when process
Arguably we just have the wrong backing-device here, and what we
should do is to propagate the real backing device's pointer through
up into the filesystem. There's machinery for this which things
like DM stacks use.
Just thinking about the new implementation --- you shouldn't
Arguably we just have the wrong backing-device here, and what we should do
is to propagate the real backing device's pointer through up into the
filesystem. There's machinery for this which things like DM stacks use.
I wonder if the post-2.6.23 changes happened to make this
22 matches
Mail list logo
