Re: DOC Write Support and the TODO list

[David Woodhouse <dwmw2@infradead.org>]

Sorry for the delay - it's taking me a while to catch up.

trevw@zentropix.com said:
> To business, I think I've fallen foul of some of the missing write
> functionality:

> 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 
uncompress :)

> 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 
(now) fine. 



--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org