Re: Kernel oops in jffs2 mount - any ideas?

[Robin Gilks <robin.gilks@tait.co.nz>]

Artem Bityutskiy wrote:

> So the crash is somewhere in the CFI code. You should try to dig it and
> realize why it oopses.
> 
Refering to standard 2.6.18 kernel...

OK - making progress in sorting bugs in the CFI code but still not fixed 
the kernel panic which is looking more & more to be in the depths of the 
jffs2 code :-(

1. In cfi_cmdset_0001.c, the fixup table is processed in order top to 
bottom. The m28w320cb chip fixup disables buffer write method but the 
buffer write fixup has already been executed by then so it tries to do 
buffered writes which are not supported! The chip fixups *MUST* be first 
in the table for this whole idea to work.

2. The chip ID as defined by ST is 0x88bb and that is what is read (in 
my case) in 16 bit mode into cfi->id but the table only has the 8 bit 
short code. Should this be masked to 8 bits so the table lookup works or 
should the 8 bit probe be extended to get both halves of the ID or 
should the table have the full 16 bit codes. In fact this chip only 
supports 16 bit mode as far as I can see!!

-- 
Robin


=======================================================================
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
 altered or corrupted during transmission.
=======================================================================