Created attachment 59802 [details]
It seems I messed up the first submission, so here goes again:
With kernels 126.96.36.199 - 2.6.39, plug-in of a specific WD Elements USB HDD (see crash log for details) crashes my system. Plugging the drive in is enough, takes a few seconds to lock up the filesystem and the rest of the system with it. With two other WD USB HDDs this does not happen, but these are earlier models.
- crash log captured via serial console
- .config for 188.8.131.52
- lsusb with the disk in question plugged in
If you need anything else, please let me know.
Created attachment 59812 [details]
Created attachment 59822 [details]
Created attachment 59832 [details]
Created attachment 59902 [details]
csash log via serial
Yesterday I has a hard filesystem lockup that looked much the same as the issuse I reported here. This was on a different system with 184.108.40.206 after an UML instance running with user permission crashed. It seems there is some fundamental show-stopper in the filesystem code or the SMP code that causes hard system crashes and was introduced in 220.127.116.11 or before. The lockup on USB plugin in 18.104.22.168 and later may just be a symptom or a secondary effect. It can however serve as a valuable debugging aid, as it reliably causes the system to crash.
For the moment, I am back to 22.214.171.124, as I really cannot have my mail-server crash at random times.
Is anybody looking at this? Hard filesystem crashes caused by software are something I did not have for a long, long time. Scary.
BTW, I know that these are hard filesystem crashes, as I observed software RAID1 partitions resyncing after reboot and had one instance of a file containing nonsense at the end (I had that open in an editor during the crash), where the ext3 log seems to already have contained the medadata but not the file data itself.
Kernel 126.96.36.199: No change, still hard crash on plug-in of the specific WD USB disk.
Due to bugzilla flakiness, this is a duplicate of my original submission. Marked as such.
*** This bug has been marked as a duplicate of bug 36092 ***