lkml.org 
[lkml]   [2011]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subject[BUG] Re: mtd_stresstest module bricked my dockstar
Date
Hello,

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.

in

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/mtd/tests/mtd_stresstest.c;h=63920476b57a24c7e61563303eb3abb773b73fdf;hb=7163cea15f7b362795b858e7c130cd617aecc0aa

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".

regards
Roland



\
 
 \ /
  Last update: 2011-10-24 21:35    [W:0.314 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site