https://bugzilla.kernel.org/show_bug.cgi?id=25832 --- Comment #22 from Theodore Tso <tytso@xxxxxxx> 2011-02-07 01:20:01 --- Memory doesn't get freed just because a device disappears. The file system is still shown as mounted after the system resumes. Attempts to access the mounted file system will result in errors, but the data structures don't get magically freed until you explicit umount the failed file system. It's more likely that the kernel is stuck in some loop trying to access the failed file system, and looping, but in that case, it would be caused by a specific process trying to access the file system after the system resumed. Say, if you were executing a program that was located on the now-failed file system, or if a file from the now-failed file system was mmap'ed into memory, and for some reason the kernel was looping forever instead of returning an error to the program and/or killing the program. This is why I asked you if you could use the various sysrq commands to try to figure out what the kernel was doing after it locked up. In answer to your previous message, no, sysrq doesn't require access over the network. It requires access to the console. If you have a VT console, sysrq-p can be triggered by holding down the alt, sysrq and p keys; sysrq-l can be triggered by alt-sysrq-l, etc. If you have a serial console, you can send a break followed by an l to trigger a sysrq-l, and so on. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
