All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Yigal Sadgat <YSadgat1@gcte.com>
Cc: linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org,
	jwboyer@linux.vnet.ibm.com, joern@logfs.org
Subject: Re: Compact Flash Question
Date: Tue, 6 May 2008 23:09:54 +0100	[thread overview]
Message-ID: <20080506230954.6e034cba@core> (raw)
In-Reply-To: <005b01c8afc4$77f4ec90$6401a8c0@techwriter>

> (1) Can you really ignore bit(2) (CORR) in the Status register offset 7 that 
> tells
> you that the CF has detected and corrected a soft error?, etc.

I guess it might be interesting to log the error rate but we don't
currently do that. A corrected error is just that however - corrected by
the card itself.

> (2) An engineer at SanDisk Engineering told me NOT to do wear leveling.
> The file allocation table is written very frequently back into the flash. So
> is it really safe to assume that I don't need wear leveling???

Depends on your hardware vendor. Wear management is done within the CF
card and only the hardware vendor can tell you what they do. 

> (3) Re. the BUSY bit in the status register (offset 7, bit D7), anybody 
> experienced
> time outs?

Yes - both from failing CF cards and also other random events (bad
connections, people removing live cards etc)

> (4) Re Error register (offset 1) bit D7 (BBK), again, I was told that it 
> cannot (???)
> happen since the CF performs read-after-write and it automatically switches 
> good blocks
> for bad ones... Is this correct?

Depends on your hardware vendor. It certainly *can* occur with some CF
cards perhaps when they run out of spare blocks.

Alan

WARNING: multiple messages have this Message-ID (diff)
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: "Yigal Sadgat" <YSadgat1@gcte.com>
Cc: <linux-kernel@vger.kernel.org>, <linux-ide@vger.kernel.org>,
	<jwboyer@linux.vnet.ibm.com>, <joern@logfs.org>
Subject: Re: Compact Flash Question
Date: Tue, 6 May 2008 23:09:54 +0100	[thread overview]
Message-ID: <20080506230954.6e034cba@core> (raw)
In-Reply-To: <005b01c8afc4$77f4ec90$6401a8c0@techwriter>

> (1) Can you really ignore bit(2) (CORR) in the Status register offset 7 that 
> tells
> you that the CF has detected and corrected a soft error?, etc.

I guess it might be interesting to log the error rate but we don't
currently do that. A corrected error is just that however - corrected by
the card itself.

> (2) An engineer at SanDisk Engineering told me NOT to do wear leveling.
> The file allocation table is written very frequently back into the flash. So
> is it really safe to assume that I don't need wear leveling???

Depends on your hardware vendor. Wear management is done within the CF
card and only the hardware vendor can tell you what they do. 

> (3) Re. the BUSY bit in the status register (offset 7, bit D7), anybody 
> experienced
> time outs?

Yes - both from failing CF cards and also other random events (bad
connections, people removing live cards etc)

> (4) Re Error register (offset 1) bit D7 (BBK), again, I was told that it 
> cannot (???)
> happen since the CF performs read-after-write and it automatically switches 
> good blocks
> for bad ones... Is this correct?

Depends on your hardware vendor. It certainly *can* occur with some CF
cards perhaps when they run out of spare blocks.

Alan

  reply	other threads:[~2008-05-06 22:19 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-06 21:59 Compact Flash Question Yigal Sadgat
2008-05-06 21:59 ` Yigal Sadgat
2008-05-06 22:09 ` Alan Cox [this message]
2008-05-06 22:09   ` Alan Cox
2008-05-13 17:13   ` Yigal Sadgat
2008-05-13 17:13     ` Yigal Sadgat
2008-05-06 22:22 ` linux-os (Dick Johnson)
2008-05-06 22:22   ` linux-os (Dick Johnson)
2008-05-07  6:15 ` Bart Van Assche
2008-05-07  7:39   ` Alan Cox
  -- strict thread matches above, loose matches on Subject: below --
2008-05-07  7:12 Tomasz Chmielewski
2008-05-07  7:44 ` Bart Van Assche
2008-05-07  7:54   ` Tomasz Chmielewski
2008-05-07  7:58     ` Bart Van Assche
2008-05-07 12:31     ` Helge Hafting
2008-05-07 15:01       ` Stéphane ANCELOT
2008-05-07 16:46         ` Bart Van Assche
2008-05-08 13:26           ` Mark Lord
2008-05-08 14:27           ` Lennart Sorensen
2008-05-08 14:59             ` Willy Tarreau
2008-05-07 14:53 ` Lennart Sorensen
2008-05-07  7:27 Tomasz Chmielewski

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=20080506230954.6e034cba@core \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=YSadgat1@gcte.com \
    --cc=joern@logfs.org \
    --cc=jwboyer@linux.vnet.ibm.com \
    --cc=linux-ide@vger.kernel.org \
    --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 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.