[BUG] Re: mtd_stresstest module bricked my dockstar

From: Roland Kletzing
Date: Mon Oct 24 2011 - 15:33:06 EST


cc`ing correct email of Adrian Hunter and i found that mtd_torturetest (and the
other modules) have the same issue and there is another author i could find the
email for.

If you can't restore it with JTAG, it means the hardware is really dead.
JTAG is used when you blank the flash, and is supposed to work. I don't
know what the module does, but I fail to see how to could wear the flash
that fast. At worst it could have wiped it, or the flash was already bad.

Yes, i think accidentally insmodding "mtd_stresstest" has just wiped it, not killed.
The problem is, that it is important stuff for booting and you can`t pull it out and
re-write externally, like a disk. Sorry, i that was probably not clearly stated.

Anyway - what would people think if linux had a kernel module which wipes
/dev/sda1 when loaded ? :)

I got one Iomega Iconnect with a faulty flash that I got replaced for a
good one, so it's more likely the case here.

Yes, i could give debricking with JTAG a try. But what about the cost for the JTAG
and the work to be spent with it? I could buy another Dockstar for that.....

I agree with you. I remember the very old ISA NE2000 driver who used to
scan various addresses to find a NIC, causing some of them to reconfigure
their address to *none* and definitely stop responding on the bus to any
reconfiguration request. That was pretty annoying too. After killing a
few, I stopped using Linux on a machine with such a NIC for a long time!

Oh, that could be an explanation why i had 2 broken NE2000 NICs in the nineties.. ;)

You should keep it and retry the JTAG adapter. You just need a boot loader
so if you manage to find a usable memory location that you can select by
soldering two pins together, you could manage to store it and bood from
another device.

I`m sure debricking with JTAG is possible and it would be an interesting task.
Maybe i like to spend some money and time with this one day. For now i don`t.

In the meantime i`d rather being interested in what can be done to add more
safety to the mtd tests.

By writing these lines and looking into the source, i started getting curious - i
see there is dev param with that module(s), but i did not pass a device number,
nor did i pass anything to it.



i see:

static int dev; <-!
module_param(dev, int, S_IRUGO);
MODULE_PARM_DESC(dev, "MTD device number to use");

static int count = 10000;
module_param(count, int, S_IRUGO);
MODULE_PARM_DESC(count, "Number of operations to do (default is 10000)");

and then

static int __init mtd_stresstest_init(void)
int err;
int i, op;
uint64_t tmp;

printk(KERN_INFO "\n");
printk(KERN_INFO "=================================================\n");
printk(PRINT_PREF "MTD device: %d\n", dev);

mtd = get_mtd_device(NULL, dev);
if (IS_ERR(mtd)) {
err = PTR_ERR(mtd);
printk(PRINT_PREF "error: cannot get MTD device\n");
return err;

My kernel log showed:

mtd_stresstest: MTD device: 0
mtd_stresstest: MTD device size 1048576 etc...

So, apparenly the module accidentally picked mtd0 instead of exiting cleanly (as
i did not pass a device number)

I`m not a programmer, but doesn`t look that like an "unitialized variable" issue ?

If yes, then i would call my Dockstar "victim of a bug".


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/