3.16.7-ckt2 -stable review patch. If anyone has any objections, please let me
know.
--
From: Thorsten Knabe
commit 2a2361228c5e6d8c1733f00653481de918598e50 upstream.
Starting with Linux 3.12 processes get stuck in D state forever in
UserModeLinux under sync heavy workloads
3.16.7-ckt2 -stable review patch. If anyone has any objections, please let me
know.
--
From: Thorsten Knabe li...@thorsten-knabe.de
commit 2a2361228c5e6d8c1733f00653481de918598e50 upstream.
Starting with Linux 3.12 processes get stuck in D state forever in
UserModeLinux under
From: Thorsten Knabe
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 2a2361228c5e6d8c1733f00653481de918598e50 upstream.
Starting with Linux 3.12 processes get stuck in D state forever in
UserModeLinux under sync heavy workloads. This bug
From: Thorsten Knabe li...@thorsten-knabe.de
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 2a2361228c5e6d8c1733f00653481de918598e50 upstream.
Starting with Linux 3.12 processes get stuck in D state forever in
UserModeLinux under sync heavy
3.14-stable review patch. If anyone has any objections, please let me know.
--
From: Thorsten Knabe
commit 2a2361228c5e6d8c1733f00653481de918598e50 upstream.
Starting with Linux 3.12 processes get stuck in D state forever in
UserModeLinux under sync heavy workloads. This bug
3.17-stable review patch. If anyone has any objections, please let me know.
--
From: Thorsten Knabe
commit 2a2361228c5e6d8c1733f00653481de918598e50 upstream.
Starting with Linux 3.12 processes get stuck in D state forever in
UserModeLinux under sync heavy workloads. This bug
3.17-stable review patch. If anyone has any objections, please let me know.
--
From: Thorsten Knabe li...@thorsten-knabe.de
commit 2a2361228c5e6d8c1733f00653481de918598e50 upstream.
Starting with Linux 3.12 processes get stuck in D state forever in
UserModeLinux under sync
3.14-stable review patch. If anyone has any objections, please let me know.
--
From: Thorsten Knabe li...@thorsten-knabe.de
commit 2a2361228c5e6d8c1733f00653481de918598e50 upstream.
Starting with Linux 3.12 processes get stuck in D state forever in
UserModeLinux under sync
3.13.11.10 -stable review patch. If anyone has any objections, please let me
know.
--
From: Thorsten Knabe
commit 2a2361228c5e6d8c1733f00653481de918598e50 upstream.
Starting with Linux 3.12 processes get stuck in D state forever in
UserModeLinux under sync heavy workloads
3.13.11.10 -stable review patch. If anyone has any objections, please let me
know.
--
From: Thorsten Knabe li...@thorsten-knabe.de
commit 2a2361228c5e6d8c1733f00653481de918598e50 upstream.
Starting with Linux 3.12 processes get stuck in D state forever in
UserModeLinux under
>>>> Am 23.08.2014 19:43, schrieb Thorsten Knabe:
>>>>>> Hi Richard.
>>>>>>
>>>>>> On 08/23/2014 05:34 PM, Richard Weinberger wrote:
>>>>>>> Hi!
>>>>>>>
>>>>>>> A
Thorsten Knabe:
Hi Richard.
On 08/23/2014 05:34 PM, Richard Weinberger wrote:
Hi!
Am 23.08.2014 15:47, schrieb Thorsten Knabe:
From: Thorsten Knabe li...@thorsten-knabe.de
UML: UBD: Fix for processes stuck in D state forever in UserModeLinux.
Starting with Linux 3.12 processes get stuck
; Hi Richard.
>>>>>
>>>>> On 08/23/2014 05:34 PM, Richard Weinberger wrote:
>>>>>> Hi!
>>>>>>
>>>>>> Am 23.08.2014 15:47, schrieb Thorsten Knabe:
>>>>>>> From: Thorsten Knabe
>>>>
8/23/2014 05:34 PM, Richard Weinberger wrote:
>>>>> Hi!
>>>>>
>>>>> Am 23.08.2014 15:47, schrieb Thorsten Knabe:
>>>>>> From: Thorsten Knabe
>>>>>>
>>>>>> UML: UBD: Fix for processes stuck in D state forever in
>>>> Am 23.08.2014 15:47, schrieb Thorsten Knabe:
>>>>> From: Thorsten Knabe
>>>>>
>>>>> UML: UBD: Fix for processes stuck in D state forever in UserModeLinux.
>>>>>
>>>>> Starting with Linux 3.12 processes get stu
-knabe.de
UML: UBD: Fix for processes stuck in D state forever in UserModeLinux.
Starting with Linux 3.12 processes get stuck in D state forever in
UserModeLinux under sync heavy workloads. This bug was introduced by
commit 805f11a0d5 (um: ubd: Add REQ_FLUSH suppport).
Fix bug by adding a check
Thorsten Knabe:
From: Thorsten Knabe li...@thorsten-knabe.de
UML: UBD: Fix for processes stuck in D state forever in UserModeLinux.
Starting with Linux 3.12 processes get stuck in D state forever in
UserModeLinux under sync heavy workloads. This bug was introduced by
commit 805f11a0d5 (um: ubd
wrote:
Hi!
Am 23.08.2014 15:47, schrieb Thorsten Knabe:
From: Thorsten Knabe li...@thorsten-knabe.de
UML: UBD: Fix for processes stuck in D state forever in UserModeLinux.
Starting with Linux 3.12 processes get stuck in D state forever in
UserModeLinux under sync heavy workloads. This bug
From: Thorsten Knabe
>>>>
>>>> UML: UBD: Fix for processes stuck in D state forever in UserModeLinux.
>>>>
>>>> Starting with Linux 3.12 processes get stuck in D state forever in
>>>> UserModeLinux under sync heavy workloads. This bug was
Am 23.08.2014 19:43, schrieb Thorsten Knabe:
> Hi Richard.
>
> On 08/23/2014 05:34 PM, Richard Weinberger wrote:
>> Hi!
>>
>> Am 23.08.2014 15:47, schrieb Thorsten Knabe:
>>> From: Thorsten Knabe
>>>
>>> UML: UBD: Fix for processes stuck
Am 23.08.2014 19:43, schrieb Thorsten Knabe:
Hi Richard.
On 08/23/2014 05:34 PM, Richard Weinberger wrote:
Hi!
Am 23.08.2014 15:47, schrieb Thorsten Knabe:
From: Thorsten Knabe li...@thorsten-knabe.de
UML: UBD: Fix for processes stuck in D state forever in UserModeLinux.
Starting
in D state forever in UserModeLinux.
Starting with Linux 3.12 processes get stuck in D state forever in
UserModeLinux under sync heavy workloads. This bug was introduced by
commit 805f11a0d5 (um: ubd: Add REQ_FLUSH suppport).
Fix bug by adding a check if FLUSH request was successfully submitted
Hi Richard.
On 08/23/2014 05:34 PM, Richard Weinberger wrote:
> Hi!
>
> Am 23.08.2014 15:47, schrieb Thorsten Knabe:
>> From: Thorsten Knabe
>>
>> UML: UBD: Fix for processes stuck in D state forever in UserModeLinux.
>>
>> Starting with Linux 3.12
Hi!
Am 23.08.2014 15:47, schrieb Thorsten Knabe:
> From: Thorsten Knabe
>
> UML: UBD: Fix for processes stuck in D state forever in UserModeLinux.
>
> Starting with Linux 3.12 processes get stuck in D state forever in
> UserModeLinux under sync heavy workloads. This
From: Thorsten Knabe
UML: UBD: Fix for processes stuck in D state forever in UserModeLinux.
Starting with Linux 3.12 processes get stuck in D state forever in
UserModeLinux under sync heavy workloads. This bug was introduced by
commit 805f11a0d5 (um: ubd: Add REQ_FLUSH suppport).
Fix bug
From: Thorsten Knabe li...@thorsten-knabe.de
UML: UBD: Fix for processes stuck in D state forever in UserModeLinux.
Starting with Linux 3.12 processes get stuck in D state forever in
UserModeLinux under sync heavy workloads. This bug was introduced by
commit 805f11a0d5 (um: ubd: Add REQ_FLUSH
Hi!
Am 23.08.2014 15:47, schrieb Thorsten Knabe:
From: Thorsten Knabe li...@thorsten-knabe.de
UML: UBD: Fix for processes stuck in D state forever in UserModeLinux.
Starting with Linux 3.12 processes get stuck in D state forever in
UserModeLinux under sync heavy workloads. This bug
Hi Richard.
On 08/23/2014 05:34 PM, Richard Weinberger wrote:
Hi!
Am 23.08.2014 15:47, schrieb Thorsten Knabe:
From: Thorsten Knabe li...@thorsten-knabe.de
UML: UBD: Fix for processes stuck in D state forever in UserModeLinux.
Starting with Linux 3.12 processes get stuck in D state
nday.
Ok. Not sure why it didn't boot the first time (black screen) but it
booted the second time. This time both CPUs got initialised and are in
use, no kernel oops during init and no kernel processes stuck in D
state. Should've tried .24 earlier but .23 failed to compile under sarge
du
screen) but it
booted the second time. This time both CPUs got initialised and are in
use, no kernel oops during init and no kernel processes stuck in D
state. Should've tried .24 earlier but .23 failed to compile under sarge
due to a buggy binutils so I figured .24 would too.
--
To the extent
On Fri, Jan 11, 2008 at 12:20:58PM +0100, Stefan Richter wrote:
> CaT wrote:
> > Not sure what other info to provide
>
> Is the bug present in 2.6.24-rc7?
Can't rightly say. I didn't try it before because 2.6.23 fails to
compile under debian sarge. 2.6.24-rc7 did compile but it has failed to
On Fri, Jan 11, 2008 at 07:12:33PM +1100, CaT wrote:
> I recently upgraded from an amd 64bit system to an intel one and changed my
> kernekl accordingly. Everything's great except this:
>
> root 6 0.0 0.0 00 ?D< 17:11 0:00 [migration/1]
> root 7 0.0 0.0
CaT wrote:
> Not sure what other info to provide
Is the bug present in 2.6.24-rc7?
--
Stefan Richter
-=-==--- ---= -=-==
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
I recently upgraded from an amd 64bit system to an intel one and changed my
kernekl accordingly. Everything's great except this:
root 6 0.0 0.0 00 ?D< 17:11 0:00 [migration/1]
root 7 0.0 0.0 00 ?D< 17:11 0:00 [ksoftirqd/1]
root
I recently upgraded from an amd 64bit system to an intel one and changed my
kernekl accordingly. Everything's great except this:
root 6 0.0 0.0 00 ?D 17:11 0:00 [migration/1]
root 7 0.0 0.0 00 ?D 17:11 0:00 [ksoftirqd/1]
root 8
CaT wrote:
Not sure what other info to provide
Is the bug present in 2.6.24-rc7?
--
Stefan Richter
-=-==--- ---= -=-==
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Fri, Jan 11, 2008 at 07:12:33PM +1100, CaT wrote:
I recently upgraded from an amd 64bit system to an intel one and changed my
kernekl accordingly. Everything's great except this:
root 6 0.0 0.0 00 ?D 17:11 0:00 [migration/1]
root 7 0.0 0.0 0
On Fri, Jan 11, 2008 at 12:20:58PM +0100, Stefan Richter wrote:
CaT wrote:
Not sure what other info to provide
Is the bug present in 2.6.24-rc7?
Can't rightly say. I didn't try it before because 2.6.23 fails to
compile under debian sarge. 2.6.24-rc7 did compile but it has failed to
come
On Tue, 13 Nov 2007 16:11:45 +1100 Stephen Rothwell <[EMAIL PROTECTED]> wrote:
> On Wed, 7 Nov 2007 14:46:47 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote:
> >
> > Thank you(including David:-)) for the confirmation.
> >
> > Andrew: so mm-speed-up-writeback-ramp-up-on-clean-systems.patch is a
> >
On Wed, 7 Nov 2007 14:46:47 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote:
>
> Thank you(including David:-)) for the confirmation.
>
> Andrew: so mm-speed-up-writeback-ramp-up-on-clean-systems.patch is a
> safe and working patch ;-)
So is anything happening with this patch? It is really
On Wed, 7 Nov 2007 14:46:47 +0800 Fengguang Wu [EMAIL PROTECTED] wrote:
Thank you(including David:-)) for the confirmation.
Andrew: so mm-speed-up-writeback-ramp-up-on-clean-systems.patch is a
safe and working patch ;-)
So is anything happening with this patch? It is really necessary to
On Tue, 13 Nov 2007 16:11:45 +1100 Stephen Rothwell [EMAIL PROTECTED] wrote:
On Wed, 7 Nov 2007 14:46:47 +0800 Fengguang Wu [EMAIL PROTECTED] wrote:
Thank you(including David:-)) for the confirmation.
Andrew: so mm-speed-up-writeback-ramp-up-on-clean-systems.patch is a
safe and
On Wed, Nov 07, 2007 at 02:26:09PM +1100, Stephen Rothwell wrote:
> On Wed, 7 Nov 2007 14:17:17 +1100 Stephen Rothwell <[EMAIL PROTECTED]> wrote:
> >
> > On Tue, Nov 06, 2007 at 04:00:06PM +0800, Fengguang Wu wrote:
> > >
> > > Could you try with the attached 4 patches? Two of them are expected
On Wed, 7 Nov 2007 14:17:17 +1100 Stephen Rothwell <[EMAIL PROTECTED]> wrote:
>
> On Tue, Nov 06, 2007 at 04:00:06PM +0800, Fengguang Wu wrote:
> >
> > Could you try with the attached 4 patches? Two of them are expected to
> > fix your problem, another two are debugging ones(in case the problem
>
On Tue, 6 Nov 2007 17:46:26 +1100 Stephen Rothwell <[EMAIL PROTECTED]> wrote:
>
> I am seeing something very similar on a PowerPC machine where copying a
> file from an LVM volume with ext3 on it to a simple scsi partition (again
> ext3) on the same disk will hang in congestion_wait. If I am
On Tue, Nov 06, 2007 at 04:00:06PM +0800, Fengguang Wu wrote:
>
> Could you try with the attached 4 patches? Two of them are expected to
> fix your problem, another two are debugging ones(in case the problem
> persists).
Applying these four patches fixes it for me. Obviously the reiserfs patch
Fengguang Wu wrote:
> On Mon, Nov 05, 2007 at 06:23:07PM +, David wrote:
>
>> I've attached the output of Sysrq-T to this mail... system is a
>> dual-core AMD64, and files are on a RAID-1 root partition connected two
>> SATA disks on the on-board NVidia controller. I've had no problems
>>
On Tue, 2007-11-06 at 17:46 +1100, Stephen Rothwell wrote:
> On Mon, 05 Nov 2007 18:23:07 + David <[EMAIL PROTECTED]> wrote:
> >
> > I've been testing rc1 for a week or so, and about 25% of the time I'm
> > seeing Firefox and Thunderbird getting stuck in 'D' state as they startup.
> >
> >
[added CC list]
On Tue, Nov 06, 2007 at 04:00:06PM +0800, Fengguang Wu wrote:
> On Mon, Nov 05, 2007 at 06:23:07PM +, David wrote:
> > I've been testing rc1 for a week or so, and about 25% of the time I'm
> > seeing Firefox and Thunderbird getting stuck in 'D' state as they startup.
> >
> >
On Mon, Nov 05, 2007 at 06:23:07PM +, David wrote:
> I've been testing rc1 for a week or so, and about 25% of the time I'm
> seeing Firefox and Thunderbird getting stuck in 'D' state as they startup.
>
> I've attached the output of Sysrq-T to this mail... system is a
> dual-core AMD64, and
On Mon, Nov 05, 2007 at 06:23:07PM +, David wrote:
I've been testing rc1 for a week or so, and about 25% of the time I'm
seeing Firefox and Thunderbird getting stuck in 'D' state as they startup.
I've attached the output of Sysrq-T to this mail... system is a
dual-core AMD64, and files
[added CC list]
On Tue, Nov 06, 2007 at 04:00:06PM +0800, Fengguang Wu wrote:
On Mon, Nov 05, 2007 at 06:23:07PM +, David wrote:
I've been testing rc1 for a week or so, and about 25% of the time I'm
seeing Firefox and Thunderbird getting stuck in 'D' state as they startup.
I've
On Tue, 2007-11-06 at 17:46 +1100, Stephen Rothwell wrote:
On Mon, 05 Nov 2007 18:23:07 + David [EMAIL PROTECTED] wrote:
I've been testing rc1 for a week or so, and about 25% of the time I'm
seeing Firefox and Thunderbird getting stuck in 'D' state as they startup.
I've attached
Fengguang Wu wrote:
On Mon, Nov 05, 2007 at 06:23:07PM +, David wrote:
I've attached the output of Sysrq-T to this mail... system is a
dual-core AMD64, and files are on a RAID-1 root partition connected two
SATA disks on the on-board NVidia controller. I've had no problems
before .24
On Tue, Nov 06, 2007 at 04:00:06PM +0800, Fengguang Wu wrote:
Could you try with the attached 4 patches? Two of them are expected to
fix your problem, another two are debugging ones(in case the problem
persists).
Applying these four patches fixes it for me. Obviously the reiserfs patch was
On Tue, 6 Nov 2007 17:46:26 +1100 Stephen Rothwell [EMAIL PROTECTED] wrote:
I am seeing something very similar on a PowerPC machine where copying a
file from an LVM volume with ext3 on it to a simple scsi partition (again
ext3) on the same disk will hang in congestion_wait. If I am patient
On Wed, 7 Nov 2007 14:17:17 +1100 Stephen Rothwell [EMAIL PROTECTED] wrote:
On Tue, Nov 06, 2007 at 04:00:06PM +0800, Fengguang Wu wrote:
Could you try with the attached 4 patches? Two of them are expected to
fix your problem, another two are debugging ones(in case the problem
On Wed, Nov 07, 2007 at 02:26:09PM +1100, Stephen Rothwell wrote:
On Wed, 7 Nov 2007 14:17:17 +1100 Stephen Rothwell [EMAIL PROTECTED] wrote:
On Tue, Nov 06, 2007 at 04:00:06PM +0800, Fengguang Wu wrote:
Could you try with the attached 4 patches? Two of them are expected to
fix your
On Mon, 05 Nov 2007 18:23:07 + David <[EMAIL PROTECTED]> wrote:
>
> I've been testing rc1 for a week or so, and about 25% of the time I'm
> seeing Firefox and Thunderbird getting stuck in 'D' state as they startup.
>
> I've attached the output of Sysrq-T to this mail... system is a
>
I've been testing rc1 for a week or so, and about 25% of the time I'm
seeing Firefox and Thunderbird getting stuck in 'D' state as they startup.
I've attached the output of Sysrq-T to this mail... system is a
dual-core AMD64, and files are on a RAID-1 root partition connected two
SATA disks on
I've been testing rc1 for a week or so, and about 25% of the time I'm
seeing Firefox and Thunderbird getting stuck in 'D' state as they startup.
I've attached the output of Sysrq-T to this mail... system is a
dual-core AMD64, and files are on a RAID-1 root partition connected two
SATA disks on
On Mon, 05 Nov 2007 18:23:07 + David [EMAIL PROTECTED] wrote:
I've been testing rc1 for a week or so, and about 25% of the time I'm
seeing Firefox and Thunderbird getting stuck in 'D' state as they startup.
I've attached the output of Sysrq-T to this mail... system is a
dual-core AMD64,
Claudio Martins wrote:
On Tuesday 12 April 2005 01:46, Andrew Morton wrote:
Claudio Martins <[EMAIL PROTECTED]> wrote:
I think I'm going to give a try to Neil's patch, but I'll have to apply
some patches from -mm.
Just this one if you're using 2.6.12-rc2:
---
Chen, Kenneth W wrote:
Nick Piggin wrote on Tuesday, April 12, 2005 4:09 AM
Chen, Kenneth W wrote:
I like the patch a lot and already did bench it on our db setup. However,
I'm seeing a negative regression compare to a very very crappy patch (see
attached, you can laugh at me for doing things
On Tuesday 12 April 2005 01:46, Andrew Morton wrote:
> Claudio Martins <[EMAIL PROTECTED]> wrote:
> > I think I'm going to give a try to Neil's patch, but I'll have to apply
> > some patches from -mm.
>
> Just this one if you're using 2.6.12-rc2:
>
> ---
Nick Piggin wrote on Tuesday, April 12, 2005 4:09 AM
> Chen, Kenneth W wrote:
> > I like the patch a lot and already did bench it on our db setup. However,
> > I'm seeing a negative regression compare to a very very crappy patch (see
> > attached, you can laugh at me for doing things like that
Nick Piggin wrote:
It is a bit subtle: get_request may only drop the lock and return NULL
(after retaking the lock), if we fail on a memory allocation. If we
just fail due to unavailable queue slots, then the lock is never
dropped. And the mem allocation can't fail because it is a mempool
alloc
Chen, Kenneth W wrote:
On Tue, Apr 12 2005, Nick Piggin wrote:
Actually the patches I have sent you do fix real bugs, but they also
make the block layer less likely to recurse into page reclaim, so it
may be eg. hiding the problem that Neil's patch fixes.
Jens Axboe wrote on Tuesday, April 12,
Nick Piggin wrote:
Nick Piggin wrote:
Chen, Kenneth W wrote:
I like the patch a lot and already did bench it on our db setup.
However,
I'm seeing a negative regression compare to a very very crappy patch
(see
attached, you can laugh at me for doing things like that :-).
OK - if we go that
Nick Piggin wrote:
Chen, Kenneth W wrote:
I like the patch a lot and already did bench it on our db setup.
However,
I'm seeing a negative regression compare to a very very crappy patch (see
attached, you can laugh at me for doing things like that :-).
OK - if we go that way, perhaps the
On Tue, Apr 12 2005, Nick Piggin wrote:
> Actually the patches I have sent you do fix real bugs, but they also
> make the block layer less likely to recurse into page reclaim, so it
> may be eg. hiding the problem that Neil's patch fixes.
Jens Axboe wrote on Tuesday, April 12, 2005 12:08 AM
> Can
On Tue, Apr 12 2005, Nick Piggin wrote:
> Actually the patches I have sent you do fix real bugs, but they also
> make the block layer less likely to recurse into page reclaim, so it
> may be eg. hiding the problem that Neil's patch fixes.
Can you push those to Andrew? I'm quite happy with the way
On Tue, Apr 12 2005, Nick Piggin wrote:
Actually the patches I have sent you do fix real bugs, but they also
make the block layer less likely to recurse into page reclaim, so it
may be eg. hiding the problem that Neil's patch fixes.
Can you push those to Andrew? I'm quite happy with the way
On Tue, Apr 12 2005, Nick Piggin wrote:
Actually the patches I have sent you do fix real bugs, but they also
make the block layer less likely to recurse into page reclaim, so it
may be eg. hiding the problem that Neil's patch fixes.
Jens Axboe wrote on Tuesday, April 12, 2005 12:08 AM
Can you
Nick Piggin wrote:
Chen, Kenneth W wrote:
I like the patch a lot and already did bench it on our db setup.
However,
I'm seeing a negative regression compare to a very very crappy patch (see
attached, you can laugh at me for doing things like that :-).
OK - if we go that way, perhaps the
Nick Piggin wrote:
Nick Piggin wrote:
Chen, Kenneth W wrote:
I like the patch a lot and already did bench it on our db setup.
However,
I'm seeing a negative regression compare to a very very crappy patch
(see
attached, you can laugh at me for doing things like that :-).
OK - if we go that
Chen, Kenneth W wrote:
On Tue, Apr 12 2005, Nick Piggin wrote:
Actually the patches I have sent you do fix real bugs, but they also
make the block layer less likely to recurse into page reclaim, so it
may be eg. hiding the problem that Neil's patch fixes.
Jens Axboe wrote on Tuesday, April 12,
Nick Piggin wrote:
It is a bit subtle: get_request may only drop the lock and return NULL
(after retaking the lock), if we fail on a memory allocation. If we
just fail due to unavailable queue slots, then the lock is never
dropped. And the mem allocation can't fail because it is a mempool
alloc
Nick Piggin wrote on Tuesday, April 12, 2005 4:09 AM
Chen, Kenneth W wrote:
I like the patch a lot and already did bench it on our db setup. However,
I'm seeing a negative regression compare to a very very crappy patch (see
attached, you can laugh at me for doing things like that :-).
OK
On Tuesday 12 April 2005 01:46, Andrew Morton wrote:
Claudio Martins [EMAIL PROTECTED] wrote:
I think I'm going to give a try to Neil's patch, but I'll have to apply
some patches from -mm.
Just this one if you're using 2.6.12-rc2:
---
Chen, Kenneth W wrote:
Nick Piggin wrote on Tuesday, April 12, 2005 4:09 AM
Chen, Kenneth W wrote:
I like the patch a lot and already did bench it on our db setup. However,
I'm seeing a negative regression compare to a very very crappy patch (see
attached, you can laugh at me for doing things
Claudio Martins wrote:
On Tuesday 12 April 2005 01:46, Andrew Morton wrote:
Claudio Martins [EMAIL PROTECTED] wrote:
I think I'm going to give a try to Neil's patch, but I'll have to apply
some patches from -mm.
Just this one if you're using 2.6.12-rc2:
---
On Tue, 2005-04-12 at 01:22 +0100, Claudio Martins wrote:
> On Monday 11 April 2005 23:59, Nick Piggin wrote:
> >
> > > OK, I'll try them in a few minutes and report back.
> >
> > I'm not overly hopeful. If they fix the problem, then it's likely
> > that the real bug is hidden.
> >
>
> Well,
Claudio Martins <[EMAIL PROTECTED]> wrote:
>
> I think I'm going to give a try to Neil's patch, but I'll have to apply
> some
> patches from -mm.
Just this one if you're using 2.6.12-rc2:
--- 25/drivers/md/md.c~avoid-deadlock-in-sync_page_io-by-using-gfp_noio Mon Apr
11 16:55:07 2005
+++
On Tuesday 12 April 2005 00:46, Neil Brown wrote:
> On Monday April 11, [EMAIL PROTECTED] wrote:
> > Neil, have you had a look at the traces? Do they mean much to you?
>
> Just looked.
> bio_alloc_bioset seems implicated, as does sync_page_io.
>
> sync_page_io used to use a 'struct bio' on the
On Monday 11 April 2005 23:59, Nick Piggin wrote:
>
> > OK, I'll try them in a few minutes and report back.
>
> I'm not overly hopeful. If they fix the problem, then it's likely
> that the real bug is hidden.
>
Well, the thing is, they do fix the problem. Or at least they hide it very
well
On Monday April 11, [EMAIL PROTECTED] wrote:
>
> Neil, have you had a look at the traces? Do they mean much to you?
>
Just looked.
bio_alloc_bioset seems implicated, as does sync_page_io.
sync_page_io used to use a 'struct bio' on the stack, but Jens Axboe
change it to use bio_alloc (don't
Claudio Martins wrote:
Right. I'm using two Seagate ATA133 disks (ide controler is AMD-8111) each
with 4 partitions, so I get 4 md Raid1 devices. The first one, md0, is for
swap. The rest are
~$ df -h
FilesystemSize Used Avail Use% Mounted on
/dev/md1 4.6G 1.9G
On Monday 11 April 2005 13:45, Nick Piggin wrote:
>
> No luck yet (on SMP i386). How many disks are you using in each
> raid1 array? You are using one array for swap, and one mounted as
> ext3 for the working area of the `stress` program, right?
>
Right. I'm using two Seagate ATA133 disks
Nick Piggin wrote:
The common theme seems to be: try_to_free_pages, swap_writepage,
mempool_alloc, down/down_failed in .text.lock.md. Next I would suspect
md/raid1 - maybe some deadlock in an uncommon memory allocation
failure path?
I'll see if I can reproduce it here.
No luck yet (on SMP i386).
Claudio Martins wrote:
On Sunday 10 April 2005 03:47, Andrew Morton wrote:
Suggest you boot with `nmi_watchdog=0' to prevent the nmi watchdog from
cutting in during long sysrq traces.
Also, capture the `sysrq-m' output so we can see if the thing is out of
memory.
Hi Andrew,
Thanks for the
Claudio Martins wrote:
On Sunday 10 April 2005 03:47, Andrew Morton wrote:
Suggest you boot with `nmi_watchdog=0' to prevent the nmi watchdog from
cutting in during long sysrq traces.
Also, capture the `sysrq-m' output so we can see if the thing is out of
memory.
Hi Andrew,
Thanks for the
Claudio Martins wrote:
On Sunday 10 April 2005 03:47, Andrew Morton wrote:
Suggest you boot with `nmi_watchdog=0' to prevent the nmi watchdog from
cutting in during long sysrq traces.
Also, capture the `sysrq-m' output so we can see if the thing is out of
memory.
Hi Andrew,
Thanks for the
Claudio Martins wrote:
On Sunday 10 April 2005 03:47, Andrew Morton wrote:
Suggest you boot with `nmi_watchdog=0' to prevent the nmi watchdog from
cutting in during long sysrq traces.
Also, capture the `sysrq-m' output so we can see if the thing is out of
memory.
Hi Andrew,
Thanks for the
Nick Piggin wrote:
The common theme seems to be: try_to_free_pages, swap_writepage,
mempool_alloc, down/down_failed in .text.lock.md. Next I would suspect
md/raid1 - maybe some deadlock in an uncommon memory allocation
failure path?
I'll see if I can reproduce it here.
No luck yet (on SMP i386).
On Monday 11 April 2005 13:45, Nick Piggin wrote:
No luck yet (on SMP i386). How many disks are you using in each
raid1 array? You are using one array for swap, and one mounted as
ext3 for the working area of the `stress` program, right?
Right. I'm using two Seagate ATA133 disks (ide
Claudio Martins wrote:
Right. I'm using two Seagate ATA133 disks (ide controler is AMD-8111) each
with 4 partitions, so I get 4 md Raid1 devices. The first one, md0, is for
swap. The rest are
~$ df -h
FilesystemSize Used Avail Use% Mounted on
/dev/md1 4.6G 1.9G
On Monday April 11, [EMAIL PROTECTED] wrote:
Neil, have you had a look at the traces? Do they mean much to you?
Just looked.
bio_alloc_bioset seems implicated, as does sync_page_io.
sync_page_io used to use a 'struct bio' on the stack, but Jens Axboe
change it to use bio_alloc (don't know
On Monday 11 April 2005 23:59, Nick Piggin wrote:
OK, I'll try them in a few minutes and report back.
I'm not overly hopeful. If they fix the problem, then it's likely
that the real bug is hidden.
Well, the thing is, they do fix the problem. Or at least they hide it very
well ;-)
On Tuesday 12 April 2005 00:46, Neil Brown wrote:
On Monday April 11, [EMAIL PROTECTED] wrote:
Neil, have you had a look at the traces? Do they mean much to you?
Just looked.
bio_alloc_bioset seems implicated, as does sync_page_io.
sync_page_io used to use a 'struct bio' on the stack, but
1 - 100 of 121 matches
Mail list logo
