[lkml]   [2011]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subjectmtd_stresstest module bricked my dockstar

Hello folks,
i was (really) happily fiddling  with my dockstar NAS for the last 2 days and managed to get 3.0.4 vanilla kernel running on that device, and since i wanted do do some more testing with heartbeat/led, i fired up my proven "load all sort of modules until the kernel oopses, crashes, freezes" routine (i happily ran on x86 for years as a proven source for oopsing or hanging the kernel and/or for reporting unknown bugs) and this was the last thing i saw in dmesg:
mtd_stresstest: MTD device size 1048576, eraseblock size 131072, page size 2048, count of eraseblocks 8, pages per eraseblock 64, OOB
 size 64
mtd_stresstest: scanning for bad eraseblocks
mtd_stresstest: scanned 8 eraseblocks, 0 are bad
mtd_stresstest: doing operations
mtd_stresstest: 0 operations done
mtd_stresstest: 1024 operations done
mtd_stresstest: 2048 operations done
could not stop that, could not kill modprobe, could not unload module - device dead, no signs of life after power-cycle anymore.


Let`s have a look:;a=commit;h=7163cea15f7b362795b858e7c130cd617aecc0aa

ok - in there for a while.


config MTD_TESTS
tristate "MTD tests support"
depends on m
  This option includes various MTD tests into compilation. The tests
  should normally be compiled as kernel modules. The modules perform
  various checks and verifications when loaded.

"depends on m" ? 
Perform checks and verification when loaded ?
So, there is a linux kernel module which (apparently) stress-tests (i.e. overwrites) the MTD and somehow from a derived config in a third party kernel that module got it´s way into my 3.0.4 build - and on module load, it started to hammer on the first mtd it came across without any sign of warning and without any safeguard ? (i.e. the module kills your data just by loading it?)

It may be that it`s not recommended or considered "best practise" to load all sorts of unkown modules (i.e. find /lib/modules.... -name "*.ko"....)  - but people do (see[] ). And it`s not obvious that it`s THAT dangerous. And for me this is the first time Linux REALLY managed to badly brick my hardware in such a rigorous way.  Maybe someone can understand that i`m not really amused, as there is no easy way to recover, as seen on[
Luckily, i got that dockstar for cheap and have some more, so let`s call that "shit really happens".

I don`t want to accuse anybody, that module has it`s purpose, but please consider adding more safeguard against such issues.

One last question:
Is there any other really dangerous stuff like this inside the kernel ? (found mtd_torturetest, which seems another beast like this)


Someone want the Dockstar for spending the hours and the money for debrick ? Or for extracting gold and other precious metals from electronic waste ? ;)

SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen!
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at
 \ /
  Last update: 2011-10-23 20:47    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean