Ядро не видит SATA диск
| Ded1997 |
|
|
Темы:
1
Сообщения:
33
Участник с: 10 мая 2018
|
vasek, ну как будет апгрейд, будем смотреть... |
| redix |
|
Темы:
34
Сообщения:
3432
Участник с: 11 марта 2013
|
Обсуждалось на лоре, такой же винт и похожая проблема: https://www.linux.org.ru/forum/linux-install/8140978
In Tux We Trust
|
| nafanja |
|
Темы:
94
Сообщения:
9252
Участник с: 02 июня 2012
заблокирован
|
redix, так он уже два разных винта пробовал, результат один и тот же...
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874 |
| Ded1997 |
|
|
Темы:
1
Сообщения:
33
Участник с: 10 мая 2018
|
Разные дистры тоже не видят... |
| vasek |
|
|
Темы:
47
Сообщения:
11743
Участник с: 17 февраля 2013
|
Вообщем читать о проблеме одно, а видеть и пощупать ее самому, это другое, а потому решил провести эксперимент. Загрузился с установочного archiso , смотрю выводы lspci -v -s 00:1f.2 Выгружаю модуль ahci - modprobe -r ahci Диск sda пропал - его нет в выводах lsblk, fdisk, ls /dev/sd* Почти все как у ТС, но заметил одно отличие в выводе lspci -v -s <id> у ТС Ded1997у меня Загрузил модуль обратно modprobe -v ahci (опция -v показывает. что грузиться) И тут я вспомнил, что когда писал ТС про загрузку модулей, то была такая фраза (в части указания опции -v для информативности) Ded1997 В итоге, имхо, с большой долей вероятности, что проблема в загрузке драйвера ahci - он загружается не полностью - а вот почему, это уже другой вопрос. И пока вывод lspci -v -s <id> не примет вид Нужно подгружать модули в ручную и обязательно с опцией -v, чтобы убедиться в подгрузке модуля (должно быть сообщение, типа insmod <модуль> ...) EDIT 1 - а вот если модуль полностью все-таки не загрузиться, то тогда нужно смотреть и думать - почему он не загружается
Ошибки не исчезают с опытом - они просто умнеют
|
| Ded1997 |
|
|
Темы:
1
Сообщения:
33
Участник с: 10 мая 2018
|
Уже удавалось загрузить модули. Kernel modules: ahci и недостающий libata в lsmod | grep ahci оказались на месте. Также это ничего не меняет. |
| vasek |
|
|
Темы:
47
Сообщения:
11743
Участник с: 17 февраля 2013
|
Ded1997Вот это и странно. Будет время и желание попробуй еще раз загрузиться и выполнить следующее - за один раз, что б больше к этому не возвращаться. Плюс к этому, тогда не выгрузили сначала все эти модули, а просто пытались загрузить не достающие. 1. ls /dev/sd* 2. ls /dev/disk/by-id 3. lspci -v -s <id> (вроде бы <id> = 00:11.0) 4. lsmod | grep ahci и вдобавок отдельно зависимые модули lsmod | grep libahci lsmod | grep libata lsmod | grep scsi_mod Выгружаем модуль ahci 5. modprobe -v -r ahci должно проинформировать какие модули были выгружены - и лучше проверить их наличие согласно п.4 - если что то осталось(что маловероятно, то выгрузить отдельно и снова проверить) 6.lspci -v -s <id> Загружаем модуль обратно 7. modprobe -v ahci в выводе должно быть указано три модуля insmod /lib/modules/.../<модуль>.ko.gz 9. Проверяем загрузку модулей согласно п.4 10. Смотрим выводы согласно пп.1, 2, 3 Если опять ничего нет, попробуем загрузить модули в ручную, для чего 11. Выгружаем все модули, как это делали раньше в п.5 12. И загружем все модули используя insmod 13. И опять смотрим окончательные выводы по пп. 1, 2, 3 и наличие диска. UPD 1- все-таки советую это проделать, нет гарантии, что после апгрейд все наладится. UPD 2- и все таки мне не понятно, это наблюдается только с этими двумя дисками или есть проблемы и с другими? Такое впечатление, что libata не понимает эти диски, а потому и не грузится данный модуль libata. EDIT 1 - Как всегда, что-нибудь да забуду. 1. Рекомендую увеличить уровень логирования ядра - dmesg -n 8 и просматривать вывод логов после выгрузки и загрузки модулей (думаю строк 20 хватит) - dmesg | tail -20 2. Попробуй загрузиться с параметром libata.force=noncq (отключение NCQ SATA, может проблема с поддержкой NCQ)
Ошибки не исчезают с опытом - они просто умнеют
|
| vasek |
|
|
Темы:
47
Сообщения:
11743
Участник с: 17 февраля 2013
|
Появилось у меня одно правдоподобное объяснение - вспомнил, что встречалось похожее раньше и были нарекания к HDD Seagate и некоторым другим HDD (в основном не определялись в BIOS и иногда в системе) - запомнилось название проблемы - муха СС, а потому и вспомнилось. Сделал поиск по своей базе - и да был такой баг у некоторых HDD - описывать не буду, но грубо говоря зацикленная ошибка (Exception - ситуация при которой контроллер дуреет и не знает что ему делать). UPD - кодов ошибки несколько, но в основном это LED:000000CC, LED:00000047 При этих ошибке диск не определяется и чтобы вывести его из этого режима, необходимо послать соответствующую SCSI команду. Вообщем в домашних условиях это не излечимо. Но можно попробовать сменить прошивку. Этот баг наблюдается у HDD, имеющих прошивку Firmware: CC4B (нужно вытащить диск и уточнить прошивку). Советуют поменять ее на CC4A или CC4H. Но у меня устаревшие данные, возможно этим страдают и другие прошивки , нужно гуглить. Возможно предположение и ошибочное, но уж очень похоже на правду. Смущает одно, почему в данном случае наблюдается только в Linux.
Ошибки не исчезают с опытом - они просто умнеют
|
| Ded1997 |
|
|
Темы:
1
Сообщения:
33
Участник с: 10 мая 2018
|
vasek, прошивка CC43. Иду пробовать новый лист команд... |
| Ded1997 |
|
|
Темы:
1
Сообщения:
33
Участник с: 10 мая 2018
|
Модули нормально включались и выключались, показывали нужные логи, обнаруживались в lsmod, когда им надо было там обнаруживаться. lspci -v -s при отключенных модулях показывал только Kernel modules: ahci, строка драйверов исчезла. NCQ отключил. Всё как всегда. |