public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox