From: Andrew Morton <akpm@osdl.org>
To: Chris Caputo <ccaputo@alt.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: bdev_lock deadlock in 2.6.10-ac8 / e1000 / rfc2385 patch
Date: Sun, 16 Jan 2005 21:25:49 -0800 [thread overview]
Message-ID: <20050116212549.0decf159.akpm@osdl.org> (raw)
In-Reply-To: <Pine.LNX.4.44.0501161644490.22840-100000@nacho.alt.net>
Chris Caputo <ccaputo@alt.net> wrote:
>
> I've been seeing bdev_lock based deadlock's since 2.6.9. Here's a latest
> one with 2.6.10-ac8. Not sure if the problem is related to the e1000
> driver (with NAPI) or the rfc2385 patches or what. Anyone else seeing
> this?
>
> Chris
>
> --
> 2.6.10-ac8 + rfc2385 md5 patch:
>
> <Jan/16 10:55 pm>SysRq : Show Regs
> <Jan/16 10:55 pm>Pid: 820, comm: sh
> <Jan/16 10:55 pm>EIP: 0060:[<c0309276>] CPU: 0
> <Jan/16 10:55 pm>EIP is at _spin_lock+0x36/0x90
> <Jan/16 10:55 pm> EFLAGS: 00000246 Not tainted (2.6.10-ac8)
> <Jan/16 10:55 pm>EAX: 00000000 EBX: 00000000 ECX: c0355300 EDX: c0414000
> <Jan/16 10:55 pm>ESI: c03a1600 EDI: ffffffff EBP: c0414fc4 DS: 007b ES: 007b
> <Jan/16 10:55 pm>CR0: 8005003b CR2: b7fd6f68 CR3: 02463000 CR4: 000006d0
>
> >>EIP; c0309276 <_spin_lock+36/90> <=====
>
> >>ECX; c0355300 <contig_page_data+0/e00>
> >>EDX; c0414000 <softirq_stack+0/4000>
> >>ESI; c03a1600 <bdev_lock+0/80>
> >>EDI; ffffffff <__kernel_rt_sigreturn+1bbf/????>
> >>EBP; c0414fc4 <softirq_stack+fc4/4000>
>
> <Jan/16 10:55 pm> [<c02dc0f0>] defense_timer_handler+0x0/0x40
> <Jan/16 10:55 pm> [<c015bbed>] nr_blockdev_pages+0xd/0x60
> <Jan/16 10:55 pm>
> <Jan/16 10:55 pm> [<c013a601>] si_meminfo+0x21/0x40
> <Jan/16 10:55 pm> [<c02dbe97>] update_defense_level+0x17/0x270
You should be able to fix this with
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/broken-out/cancel_rearming_delayed_work.patch
and
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/broken-out/ipvs-deadlock-fix.patch
I haven't pushed these along because I'm not very happy with the
cancel_rearming_delayed_work.patch concept.
But I forget why ;) It seems a bit livelocky. Let me think about it a bit
more.
prev parent reply other threads:[~2005-01-17 5:26 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.44.0412171503510.22212-100000@nacho.alt.net>
2005-01-17 0:53 ` Chris Caputo
2005-01-17 5:25 ` Andrew Morton [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050116212549.0decf159.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=ccaputo@alt.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®