Это ошибка в ядре, и она все еще присутствует в ядре 3.13 amd64 (из Ubuntu Trusty).
Как _Vi проверил на своей виртуальной машине, используя VBoxManage controlvm <vm_name> keyboardputscancode 1d 38 54 24 a4 d4 b8 9d
со следующими результатами:
3.3.6-pf-vi+ : Reproducible
3.2.0-zen-vi+ : Reproducible
3.0.4-zen-vi+ : Reproducible
2.6.37.5-zen-... : Reproducible
2.6.33-zen2-... : Reproducible
2.6.32-zen1-... : Reproducible
2.6.31-zen11-... : Not reproducible
2.6.30-zen2-... : Not reproducible
От Дэйва Чиннера мы можем прочитать:
Размораживание файловой системы через sysrq-j происходит бесконечно, поскольку она неправильно обнаруживает размороженные файловые системы как замороженные и пытается несколько раз разморозить. Это регрессия, вызванная 4504230a71566785a05d3e6b53fa1ee071b864eb ("freeze_bdev: захватить активную ссылку на замороженные суперблоки") в том, что она больше не возвращает -EINVAL для суперблоков, которые не были заморожены.
Более глубокие проблемы возникли при дальнейшей проверке - файловые системы, замороженные с помощью freeze_super (), не могли быть разморажены thaw_bdev (), поэтому аварийное размораживание не работало на чем-либо, замороженном вручную, и возникали взаимные блокировки на sb-> s_umount, так как суперблоки повторяются в аварийном размораживании с это уже проведено для чтения.
Везде, где мы замерзаем или оттаиваем, у нас уже есть суперблок, или мы можем легко его получить, поэтому мы можем напрямую вызвать freeze_super (). Следовательно, мы можем убить операции уровня bdev и переместить всю инфраструктуру вложений на уровень суперблока, чтобы у нас был единый согласованный интерфейс.
Источник: Re: 2.6.34 echo j> /proc /sysrq-trigger вызывает событие inifniteunfreeze /Thaw в архиве списка рассылки linux-kernel