Linux и тормозная клава
Надо сразу сказать, что usb-клавиатура, о которой здесь речь, в общем-то не виновата. Вы же не станете винить какую-нибудь юную красотку, если она в ответ на философский вопрос о том, кто она такая на самом деле, поставит на вас круглые глаза и ничего не ответит? То-то и оно.
Дело в том, что система и usb-клавиатура взаимодействуют на двух уровнях. Первый – низкий – обычно не вызывает проблем. Показателем этого является тот факт, что на начальном этапе загрузки, в меню grub, мы можем, нажав определенную клавишу (работает!), выбрать нужный загрузочный пункт или войти в командную строку grub'a и много чего там сделать. Тут действует автономный протокол начальной загрузки (HIDBP), которому не интересны мультимедийные рюшечки или LED-контроллер нашей клавы. Это, образно выражаясь, мир инстинктов, животный уровень.
А вот дальше, когда grub инициализирует загрузочные механизмы операционной системы, вступает в игру высокий уровень, который так и называется – человеческий (Human Interface Device, или сокращенно HID). И наткнувшись на тот же LED-контроллер, система начинает задавать клаве всякие вопросы, на которые та, понятное дело, не умеет ответить. Возникает заминка на несколько секунд... Она проходит бесследно, и о ней никто бы и не вспомнил, если бы у нас не было мощных механизмов слежки за участниками событий – логов системы.
Посмотрим бегло на dmesg. Вот на третьей секунде загрузки появляется запись:
[ 2.281324] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 2.281325] usb 4-1: Product: USB Keyboard
[ 2.281327] usb 4-1: Manufacturer: BTC
[ 2.290864] hidraw: raw HID events driver (C) Jiri Kosina
[ 2.306435] usbcore: registered new interface driver usbhid
[ 2.306436] usbhid: USB HID core driver
[ 2.310264] input: BTC USB Keyboard as /devices/pci0000:00/0000:00:12.1/usb4/4-1/4-1:1.0/input/input4
[ 2.310998] hid-generic 0003:046E:6000.0001: input,hidraw0: USB HID v1.10 Keyboard [BTC USB Keyboard] on usb-0000:00:12.1-1/input0
Вроде бы всё хорошо: usb-клавиатура опознана, определено ее место и опции работы с ней... На этом этапе загрузки у системы чертова уйма забот, опознаются разные устройства, им выделяются ресурсы, и всё это в бешеном темпе.
Но вот, через секунду-полторы (занимающих в dmesg'e около сотни строк) в этой запарке возникает пауза. По временнóй шкале происходящего она просто гигантская – порядка 8–10 секунд! Вот изобличающее свидетельство:
[ 12.299126] hid-generic 0003:046E:6000.0002: usb_submit_urb(ctrl) failed: -1
[ 12.299138] hid-generic 0003:046E:6000.0002: timeout initializing reports
[ 12.299234] input: BTC USB Keyboard as /devices/pci0000:00/0000:00:12.1/usb4/4-1/4-1:1.1/input/input6
[ 12.299314] hid-generic 0003:046E:6000.0002: input,hidraw3: USB HID v1.10 Device [BTC USB Keyboard] on usb-0000:00:12.1-1/input1
То есть, грубо и приблизительно говоря, система спросила клавиатуру о чем-то, подождала ответа, не дождалась и, пробормотав: "Ладно, проехали", продолжила загрузочную работу.
Как, наверное, многие юзеры, я не обращал на этот толстый нюанс особенного внимания, пока все мои системы стояли на HDD и время загрузки по dmesg'у составляло от 30 до 40 секунд и даже больше. Подумаешь, лишних 10 секунд, тем более что серьезной ошибки не возникает, клава продолжает нормально работать, и как правило находятся другие, гораздо более насущные проблемы.
Однако мое отношение к сабжу резко поменялось, как только я приобрел SSD и установил на него систему Linux Mint 17. На общем отрадном фоне сокращения времени загрузки в 2-2,5 раза десятисекундный таймаут начал выглядеть раздражающе и даже обидно: за что деньги-то плочены!?
Решение, хоть и не сразу, нашлось.
Суть его в том, чтобы запретить драйверу usbhid всякие посторонние шуры-муры с нашей usb-клавиатурой.
Лечение
Выясняем id производителя и id продукта клавиатуры. Для этого внимательно присмотримся к первому фрагменту dmesg:
[ 2.281324] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 2.281325] usb 4-1: Product: USB Keyboard
[ 2.281327] usb 4-1: Manufacturer: BTC
В нем для наглядности я выделил синим нужные сведения, а следующие строки подтверждают, что речь идет действительно о нашей usb-клаве, произведенной фирмой BTC.
Те же данные можно узнать и другими способами, например, с помощью команды
Правда, в выводе придется покопаться, зато мы обнаружим там те же нужные нам сведения в еще более удобном виде:
idProduct 0x6000
Далее открываем от рута файл /etc/default/grub, находим в нем строку
и добавляем в нее параметр usbhid.quirks=0x046e:0x6000:0x20000000
Отредактированная строка будет выглядеть так:
Переконфигурируем grub командой
и перезагружаемся.
После этой нехитрой операции время загрузки по данным dmesg составило 10,5 секунд. Вот теперь я чувствую, что не зря потратился на новый диск
2014-09-04 в 12:36:33
Доброго!
Что-то у Вас очень тормознутая клавиатура.
Моя юсбишная OKLICK 410М не стопорит загрузку ни капельки. Часть вывода лога, где есть задержка,
"[ 3.428623] sd 6:0:0:0: [sdc] Attached SCSI removable disk
[ 3.542686] random: nonblocking pool is initialized
[ 9.500309] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null)"
Система так же на SSD, который и есть sdb
Никакого "лечения" не проводилось, кроме оптимизации SSD. Вся загрузка по логу проходит за 11.478220 секунд!
2014-09-04 в 13:46:28
Рад за Вас
Если серьезно, то описанная проблема если и не редкая, то, скорей всего, не частая. Кроме того, как я и сказал, далеко не все юзеры, надо полагать, обращают на нее внимания: ошибка-то не критическая.
Ребята из RedHat грешат на LED-контроллер клавиатуры, причем бренд, кажется, не имеет значения: мне встречались упоминания как об уважаемых, вроде моей BTC или A4Tech, так и о дешевых noname. Кроме того, в эту компанию затесался какой-то неизвестный мне бесперебойник.
В том фрагменте dmesg, который Вы привели, о клаве, к сожалению, вообще нет речи. Зато есть намёк на другую возможную проблему: 6-секундная задержка после
[ 3.542686] random: nonblocking pool is initialized
это многовато. Нужно будет как-нибудь на досуге поглядеть, в чем там дело. Вроде бы что-то специфическое для 64-бит, но толком не знаю.
2014-12-19 в 20:18:06
Приветствую. Была аналогичная проблема на Xubuntu. Так как я новичок в линукс, много гуглил в поисках проблемы. Вспользовавшись командой dmesg нашел вот какую штуку. Тормоза при загрузке включения активности мышки и клавиатуры достигали до 2-3 минут, причиной была обычная usb флешка в вставленная в usb порт. Флешка рабочая полностью и на ней есть некая информация. Флешка Апасер. Так вот после того как флешка была изъята из порта, система стала грузится как положено, при этом все девайсы, клава и мышка, стали работать без каких либо проблем. Может быть кому-то будет полезен этот пост.
2014-12-19 в 21:12:44
Увы, если Ваш коммент и будет кому-то полезен, то лишь потому, что призывает гуглить и изучать dmesg. Это, безусловно, правильное начало расследования причин всяких проблем, но не всегда этого достаточно. В чем состояла Ваша проблема, осталось неизвестно, но совершенно очевидно, что она вовсе не "аналогична" той, которую описал я.