From: David Woodhouse <dwmw2@infradead.org>
To: Nicolas Pitre <nico@cam.org>
Cc: mtd@infradead.org
Subject: Re: corruption with mtdblock
Date: Mon, 06 Nov 2000 15:19:47 +0000 [thread overview]
Message-ID: <21552.973523987@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.10.10011061506410.530-100000@xanadu.gn.com>
nico@cam.org said:
> Nope. The only place where the queue can be plugged is:
> if (list_empty(head)) {
> q->plug_device_fn(q, bh->b_rdev); /* is atomic */
> Therefore the queue can't be plugged until we emptied it.
But it starts off empty - so doesn't it get plugged the first time a
request is added? But it doesn't actually bite us until requests are merged
- when we do 'cat /dev/mtdblock0' or massive writes.
> To be sure I tried to disable plugging by providing a dummy plug
> function that does nothing. No difference.
Ah. If something is mucking with the request at the head of the queue while
(q->head_active && !q->plugged) then I think that has to be a kernel bug.
Just before the end_request() in mtdblock_handle_request(), can you put in
a sanity check for req->bh->b_end_io? If it's not a sane value, can you
print the current values of q->head_active and q->plugged?
--
dwmw2
To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
next prev parent reply other threads:[~2000-11-06 15:19 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-05 22:52 Erase unit header corrupted when using FTL Brian Kuschak
2000-11-06 0:57 ` David Woodhouse
2000-11-06 2:10 ` corruption with mtdblock Nicolas Pitre
2000-11-06 7:27 ` David Woodhouse
2000-11-06 17:54 ` Nicolas Pitre
2000-11-06 14:47 ` David Woodhouse
2000-11-06 20:11 ` Nicolas Pitre
2000-11-06 15:19 ` David Woodhouse [this message]
2000-11-07 9:04 ` Nicolas Pitre
2000-11-08 21:50 ` David Woodhouse
2000-11-09 0:28 ` Nicolas Pitre
2000-11-09 7:58 ` David Woodhouse
2000-11-09 14:22 ` Nicolas Pitre
2000-11-09 8:12 ` David Woodhouse
2000-11-09 11:34 ` David Woodhouse
2000-11-09 15:21 ` Nicolas Pitre
2000-11-09 22:36 ` David Woodhouse
2000-11-11 23:38 ` Detecting the Disk-On-Chip 2800 Adam Agnew
2000-11-12 23:27 ` David Woodhouse
2000-11-13 0:24 ` Ollie Lho
2000-11-13 6:35 ` Adam Agnew
2000-11-09 14:34 ` corruption with mtdblock Nicolas Pitre
2000-11-09 14:23 ` David Woodhouse
2000-11-06 15:31 ` David Woodhouse
2000-11-06 21:24 ` Nicolas Pitre
2000-11-06 17:31 ` David Woodhouse
2000-11-07 1:02 ` Nicolas Pitre
2000-11-06 14:54 ` David Woodhouse
2000-11-06 21:27 ` Nicolas Pitre
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=21552.973523987@redhat.com \
--to=dwmw2@infradead.org \
--cc=mtd@infradead.org \
--cc=nico@cam.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.