From: Laurent Pinchart <laurentp@cse-semaphore.com>
To: linux-mtd@lists.infradead.org
Subject: Deadlock while accessing mtdchar device while erase in progress
Date: Fri, 28 Dec 2007 11:04:26 +0100 [thread overview]
Message-ID: <200712281104.27663.laurentp@cse-semaphore.com> (raw)
Hi everybody,
I sent a mail two weeks ago about an MTD-related deadlock. I haven't received
any answer so far, so I'm pinging the list just in case the message was
missed. Here's the original mail.
I'm having troubles fixing an MTD-related deadlock. I'm not sure if the
problem comes from an MTD and/or JFFS2 kernel bug, or from some userspace
operation performed as root that I shouldn't have started in the first place.
I'd appreciate if someone could share his thoughts (and experience :-)) about
this.
Some background.
My embedded system has a single NOR flash chip (cfi_cmdset_0002 driver) with
128kB sectors. Flash space is divided in 4 partitions, the last one used with
a JFFS2 filesystem.
A userspace process run as root sets its scheduling policy to SCHED_RR. It
writes 400kB of data to the JFFS2 filesystem and restarts by exec()ing
itself, inheriting the SCHED_RR policy.
Soon after being restarted, it opens /dev/mtd0 (boot loader partition) and
reads a few bytes of data. It then close() /dev/mtd0, at which point the
kernel deadlocks.
I added debugging messages to the MTD subsystem and it turned out my process
blocks in cfi_amdstd_sync (drivers/mtd/chips/cfi_cmdset_0002.c). chip->state
is set to FL_ERASING, and the kernel keeps scheduling in the default case.
I'm not sure what goes wrong. I expect the JFFS2 garbage collector to have
kicked in. It might be erasing sectors when I close() /dev/mtd0, at which
point the mtdchar driver tries to sync() the flash and locks in
cfi_amdstd_sync because my process, being scheduled with a SCHED_RR policy,
never gives the JFFS2 garbage collector a chance to run. That's just a wild
guess though.
Any help regarding how to better diagnose the problem (to confirm or reject
the above suspicion) will be appreciated. A fix would be even more
welcome :-)
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
next reply other threads:[~2007-12-28 10:04 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-28 10:04 Laurent Pinchart [this message]
-- strict thread matches above, loose matches on Subject: below --
2007-12-17 10:12 Deadlock while accessing mtdchar device while erase in progress Laurent Pinchart
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=200712281104.27663.laurentp@cse-semaphore.com \
--to=laurentp@cse-semaphore.com \
--cc=linux-mtd@lists.infradead.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