https://bugzilla.kernel.org/show_bug.cgi?id=25832 --- Comment #28 from rocko <rockorequin@xxxxxxxxxxx> 2011-02-07 23:49:14 --- Actually, the lockup doesn't take place _immediately_ after resume - there is a random interval of up to several seconds. A couple of times I even managed to type my password in for the screensaver and get back to the desktop before the freeze. So there is certainly time for a userspace process to try and access a missing drive. And there is a process that umount drives when it detects they are missing (I think it is udev?). They disappear from my Gnome desktop when I pull out the drive or when I resume after removing the drives. These (sample) messages after resume show it happening: Feb 7 10:04:04 pegasus-maverick ntfs-3g[2745]: Unmounting /dev/sdf1 (My Passport) Feb 7 10:04:04 pegasus-maverick kernel: [ 128.908709] JBD: I/O error detected when updating journal superblock for sde1. Feb 7 10:04:04 pegasus-maverick kernel: [ 128.934868] scsi 9:0:0:1: rejecting I/O to dead device Feb 7 10:04:04 pegasus-maverick kernel: [ 128.949322] EXT3-fs (sde1): I/O error while writing superblock The first message implies that a umount happens for at least missing ntfs drives. The bug in comment #10 happened during a sys_umount call, which was triggered by Gnome automatically in response to the missing drive. The most confusing thing is how the sytem might have crashed when firefox was trying to access a valid mounted ext4 partition. That's why I'm thinking it's caused by a memory corruption or invalid pointer. -- 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
