Re: kernel messages from INFTL

[Greg Ungerer <gerg@snapgear.com>]

Hi Andre,

Andre wrote:
> Greg Ungerer wrote:
>>Andre wrote:
[snip]
>>>INFTL: formatting chain at block 24574
>>>INFTL: formatting block 24574
>>>INFTL: corrupt block 24575 in chain 24575, chain length 0, erase mark
>>>0xffff?
>>>INFTL: formatting chain at block 24575
>>>INFTL: formatting block 24575
>>> inftla: inftla1
>>>==================
>>>The INFTL messages do not appear on subsequent loads of the inftl
>>>module. Can somebody please explain what happened, i.e. should I be
>>>concerned?
>>
>>The INFTL code is telling you that it didn't think the chains
>>where logically correct. So it went ahead and tried to fix them up.
>>Once fixed you should not see any messages on the next boot (as
>>you didn't). Certainly not normal (or good).
> 
> 
> The device really started to act up on subsequent boot and I couldn't even
> format it anymore with m-sys tools. The dformat utility complained about not
> being able to find the bad block table.

My best guess is that the bad block info is stored differently than
what the current INFTL code can deal with then. I have only used it
on the Disk-on-chip Millenium+ parts, and the bad block table is stored
in the factory reserved region on those parts (which I believe is
different to their other DoC parts).

Can you fully restore it with the M-systems tools?

You will need to debug the INFTL init logic and figure out what how
the initial block layout is different.

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Dude       EMAIL:     gerg@snapgear.com
SnapGear -- a CyberGuard Company            PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com