On Sat, 12 Jan 2013, Alex Riesen wrote: > On Sat, Jan 12, 2013 at 8:39 PM, Alex Riesen <raa.l...@gmail.com> wrote: > > On Sat, Jan 12, 2013 at 6:37 PM, Alan Stern <st...@rowland.harvard.edu> > > wrote: > >> On Sat, 12 Jan 2013, Alex Riesen wrote: > >>> One more detail: I usually use the "noop" elevator. That time it was > >>> the "deadline". And I just reproduced it easily with "deadline". > >> > >> I doubt the elevator has anything to do with this. > > > > But it looks like it does: just using the deadline elevator is a sure way > > to reproduce the bug. The system always recovers (sometimes after a while) > > with "noop". > > And no, it does not. Not by itself, but the fact that deadline elevator was > compiled as module certainly helped! > > This explains the hanging modprobe in the dmesg output (the part after device > connect). I still wonder, why didn't it froze at boot, mounting SATA devices > (the root, /var, and /home are on an SSD connected by SATA)? And why hanging > khubd at reboot? > > Anyway, building the elevator in the kernel avoids the problem. Sorry for > not spotting this earlier. > > Now, who would be interested to handle this kind of misconfiguration ...
So the whole thing was a false alarm? Maybe you should report to the block-layer maintainers that it's possible to mess up the system by building an elevator as a module. That sounds like the sort of thing they'd be interested to hear. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
