Messages in this thread | | | Date | Wed, 19 Apr 2006 14:06:50 -0300 | From | "Thiago Galesi" <> | Subject | Possible MTD bug in 2.6.15 |
| |
Ok, a couple of comments/questions
1 - Wouldn't it be better to map all flash, and leave the unneeded part as read only?
2 - Please follow Documentation/SubmittingPatches format for sending patches (especially the signed-off part and sending patches inline)
3 - No C++ style comments, please
Thiago
On 4/19/06, Jim Ramsay <kernel@jimramsay.com> wrote: > We have an interesting problem with MTD and a flash chip on an > embedded board. The problem stems from the fact that due to hardware > constraints we can only access up to 32M of address space on an > attached flash device. However, the actual part attached to the board > is 64M. Yes, I know this is not likely to happen, but it points at a > kernel bug which will happen if you ever specify a MTD map->size which > is less than the actual size of the CFI flash chip. > > When we specify the map->size as 32M (0x02000000) and do the CFI > probe, the chip is properly detected, but then in gen_probe.c the > following happens: > > - genprobe_ident_chips is run > - It sets cfi.chipshift based on the cfi.cfiq->DevSize, which gets > properly set to 0x1a (64M flash chip). > - It then sets the local "max_chips" variable by shifting down > map->size by this chipshift, which shifts our size (0x02000000 = 32M) > down all the way to 0. > - Since 'max_chips' is zero, no memory is allocated for this chip, > and the waitqueue is not initialized. The will cause a kernel panic > later, if you ever try to read from this chip. > > The routine completes and you are left with a seemingly valid MTD > device. However, if you ever try to read or write this device, the > waitqueue is uninitialized, which causes a nasty kernel panic. > > My proposed fix is attached (a patch against 2.6.15). After shifting > the map->size down by cfi.chipshift, I just ensure that max_chips is > at least one. Does this seem like a reasonable fix? > > Note: Please CC my email address in reply, as I am not currently > subscribed to the linux-kernel list. > > -- > Jim Ramsay > "Me fail English? That's unpossible!" > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |