DOC Write Support and the TODO list
dwmw2 at infradead.org
Fri May 5 05:38:25 EDT 2000
Sorry for the delay - it's taking me a while to catch up.
trevw at zentropix.com said:
> To business, I think I've fallen foul of some of the missing write
> When I rebooted my DOC system yesterday it stopped after
> 'Uncompressing Linux...' with the error message:
> crc error
> -- System halted
> When I rebooted into my standard hdd-based system, the NFTL
> initialisation routine complained:
> EUN 317: Erasemark not 0x3c69 (0x3461 0x3461 instead)
> EUN 356: dittto
Odd. I can understand a few bits going south - but the _same_ bits in four
different places? Sounds more like hardware to me - the high bit was tied
low, perhaps during the write of the Erasemark.
> I was able to mount the device, etc but it would not boot (and it's
> been mothballed for weeks).
Can you check the data in the most recently changed files - see if the high
bits are all zeroed? That would probably explain a CRC error during
> The plot thickens:- I then altered the device to boot a kernel using
> the M-Systems driver, which worked and then....I went back to my MTD
> driver kernel and that worked fine too!
> So, what do you think?
I'd have thought that's fairly unlikely to be bad blocks of flash - the
chances of 8 bits going bad, all coincidentally being the high bit of a
byte, are quite low. I'm more inclined to blame it on the system bus or
DiskOnChip ASIC rather than the flash chips themselves.
> Is this an example of a block going bad, being
> ignored by the nftl code but found and fixed by the M-Systems driver?
There's nothing the M-Systems driver can do to make us stop attempting to
use those blocks. If the MTD driver is working now, then those blocks are
To unsubscribe, send "unsubscribe mtd" to majordomo at infradead.org
More information about the linux-mtd