From: Maksym Veremeyenko <verem@domain.hid>
To: Xenomai help <xenomai@xenomai.org>
Subject: Re: [Xenomai-help] Strange deadlock.
Date: Sat, 10 Feb 2007 00:10:39 +0200 [thread overview]
Message-ID: <45CCF15F.806@domain.hid> (raw)
In-Reply-To: <b647ffbd0702091314y5c452cd2wc48f126763b9b3@domain.hid>
Dmitry Adamushko пишет:
> Just to put aside a few (quite) weird assumptions :
>
> (1) did you have another task that has been using this mutex and has
> (somehow) exited by the moment of lockup?
there are only 2 task that has access to that mutex.
> (2) bus_monitor_proc[0] is created once and never
> exits_then_created_again while the program is running ?
all task starting from begining of program and never restart.
i renamed mutex name twice to avoid name misspelled access and move
throw the struct to avoid offset with another struct - nothing help.
i tried to increase stack size - not helped.
i try to move lock/unlock to macros and add some history logging.
Is possible next scenario:
1. task A lock mutex M
2. task A going to secondary mode
3. task A performing "long" io wait operation and some flags modified.
4. task B tries to lock mutex M
5. core find no task A, because its waiting in secondary mode or it
think that task A is zombie or due to flag modification it's do not
think task A is RT
6. mutex M is granted to task B
7. task A returns from secondary mode
8. task A unlock mutex M because it's owned
9. task B tries to unlock, and not properly cleared some flags due to
step 8.
10. task B tries to lock mutex
11. core see that task B currently not own mutex M and put it into wait
queue
12. task A tries to lock mutex.
13. core see that task B currently not own mutex M and put it into wait
queue
14. deadlock here.
BTW
at some moment i got a kernel oops, not very informative but...
Feb 9 23:26:02 dev-3 kernel: BUG: unable to handle kernel NULL pointer
dereference at virtual address 00000005
Feb 9 23:26:02 dev-3 kernel: printing eip:
Feb 9 23:26:02 dev-3 kernel: c01b53b2
Feb 9 23:26:02 dev-3 kernel: *pde = 0ae5a001
Feb 9 23:26:02 dev-3 kernel: Oops: 0000 [#1]
Feb 9 23:26:02 dev-3 kernel: Modules linked in: ipv6 sunrpc dm_mirror
dm_mod lp parport_pc parport ohci1394 ieee1394 floppy snd_intel8x0
snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_oss i2c_i801
snd_seq_midi_event snd_seq i2c_core snd_seq_device snd_pcm_oss
snd_mixer_oss snd_pcm serio_raw snd_timer e100 snd mxser mii soundcore
snd_page_alloc
Feb 9 23:26:02 dev-3 kernel: CPU: 0
Feb 9 23:26:02 dev-3 kernel: EIP: 0060:[<c01b53b2>] Not tainted VLI
Feb 9 23:26:02 dev-3 kernel: EFLAGS: 00210246 (2.6.17.14-xenomai #1)
Feb 9 23:26:02 dev-3 kernel: EIP is at remove_proc_entry+0x22/0x1b0
Feb 9 23:26:02 dev-3 kernel: eax: 00000000 ebx: c03a90f4 ecx:
ffffffff edx: ce2bfb40
Feb 9 23:26:02 dev-3 kernel: esi: 00000004 edi: 00000005 ebp:
00000000 esp: cfec9e78
Feb 9 23:26:02 dev-3 kernel: ds: 007b es: 007b ss: 0068
Feb 9 23:26:02 dev-3 kernel: Process events/0 (pid: 3,
threadinfo=cfec8000 task=c1259030)
Feb 9 23:26:02 dev-3 kernel: Stack: cafed7a0 c01b51f1 0000033d 00008000
ce2bfb40 00000005 c03a90f4 00000004
Feb 9 23:26:02 dev-3 kernel: ce2bfb40 00000000 c014476e ce2bfb40
cafeda20 c036352c c0363599 00000000
Feb 9 23:26:02 dev-3 kernel: cff254a0 c036352c c0363599 ce2bfcc0
67f8acfc eaeb76d2 75bf19d4 c1e67be3
Feb 9 23:26:02 dev-3 kernel: Call Trace:
Feb 9 23:26:02 dev-3 kernel: <c01b51f1> proc_register+0x31/0xe0
<c014476e> registry_proc_callback+0x17e/0x370
Feb 9 23:26:02 dev-3 kernel: <c01644d0> free_hot_cold_page+0xc0/0x130
<c022f956> memmove+0x36/0x40
Feb 9 23:26:02 dev-3 kernel: <c017b1da> drain_array+0x7a/0xe0
<c034a5a4> schedule+0x2e4/0x690
Feb 9 23:26:02 dev-3 kernel: <c034a5d8> schedule+0x318/0x690
<c0123930> run_workqueue+0x90/0x110
Feb 9 23:26:02 dev-3 kernel: <c01445f0>
registry_proc_callback+0x0/0x370 <c0123e97> worker_thread+0x117/0x140
Feb 9 23:26:02 dev-3 kernel: <c0111c30> default_wake_function+0x0/0x10
<c0123d80> worker_thread+0x0/0x140
Feb 9 23:26:02 dev-3 kernel: <c012676d> kthread+0x9d/0xd0 <c01266d0>
kthread+0x0/0xd0
Feb 9 23:26:02 dev-3 kernel: <c0100cb5> kernel_thread_helper+0x5/0x10
Feb 9 23:26:02 dev-3 kernel: Code: 76 00 8d bc 27 00 00 00 00 55 57 56
53 83 ec 18 85 d2 89 54 24 10 89 44 24 14 0f 84 35 01 00 00 8b 7c 24 14
31 c0 b9 ff ff ff ff <f2> ae f7 d1 49 8b 5c 24 10 89 cd 83 c3 38 8b 3b
85 ff 0f 84 c8
Feb 9 23:26:02 dev-3 kernel: EIP: [<c01b53b2>]
remove_proc_entry+0x22/0x1b0 SS:ESP 0068:cfec9e78
--
________________________________________
Maksym Veremeyenko
next prev parent reply other threads:[~2007-02-09 22:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-09 19:35 [Xenomai-help] Strange deadlock Maksym Veremeyenko
2007-02-09 20:54 ` Philippe Gerum
2007-02-09 21:39 ` Maksym Veremeyenko
2007-02-09 21:14 ` Dmitry Adamushko
2007-02-09 22:10 ` Maksym Veremeyenko [this message]
2007-02-09 23:53 ` Dmitry Adamushko
2007-02-10 4:07 ` Maksym Veremeyenko
2007-02-10 10:34 ` Jan Kiszka
2007-02-11 18:28 ` Maksym Veremeyenko
2007-02-11 19:05 ` Philippe Gerum
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=45CCF15F.806@domain.hid \
--to=verem@domain.hid \
--cc=xenomai@xenomai.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.