Неадекватное поведение драйверов libata с материнкой ASUS P5W DH Deluxe
Приветствую всех!
Есть проблема с материнкой ASUS P5W DH Deluxe.
На ней интегрирован RAID контроллер Silicon 4237 (он же EZ Backup) c двумя SATA портами, который подключен через порт SATA2 от чипсета, не требует никаких настроек и автоматом создает RAID из двух дисков.
Контроллер никак не управляется через BIOS, т.е. - отключить его невозможно. Также, в BIOS невозможно запретить определение устройств на портах SATA (хотя, такое отключение врядли поможет). Версия BIOS у меня наираспоследнейшая.
SATA контроллер у меня настроен в режиме AHCI.
Ядро 2.6.20.3, Gentoo Linux собран вчера со stage1, portage tree актуальное, ядро стандартное, не гентушное, без патчей. К портам Silicon не подключено ничего.
При загрузке доходит до опроса порта SATA2 (который на материнке по факту отсутствует, есть только место, куда он по идее должен быть впаян), пишет "link up at 3.0 Gbps.". Висит 30 секунд, выдает timeout, потом пишет "port is slow to respond, please be patient", еще 10 секунд, сброс устройства, еще 5 секунд, повторное определение линка на порту, еще 5 секунд и ядро определяет диск 0Мб 640 секторов и подключает его как sdb. Содержимое диска, естественно, нули. Читается. Писать не пробовал, ибо боюсь запортачить, скорее всего это какая-то служебная область Silicon-а.
Короче - загрузка системы происходит по-эстонски.
Погуглил - нашел немного обсуждений на эту тему (в основном англоязычные), но решения проблемы в них не предложил никто.
Попробовал своими силами патчить libata-core.c, получилось пропустить вертеп с обращением к ata2. Я не силен в структуре драйверов SATA, поэтому заплатка получилась корявая: все в принципе работает как надо, но при пропуске определения утсройства на порту ata2 и дальнейшей загрузке индикатор активности HDD постоянно светится. Скорее всего, мне надо где-то сделать reset или что-то в этом роде, но я не знаю как, и боюсь шутить с такими вещами.
Господа! Может, кто-то посоветует, как правильно пропустить обращение к порту SATA2 при определении устройств? Или может, есть способ как-то собрать ядро, чтобы эти грабли не всплывали? Или кто-то знает как отключить этот EZ-Backup вообще?
Заранее благодарен за помощь.
- Для комментирования войдите или зарегистрируйтесь
[РЕШЕНО]
Если поднятая мной проблема кого-то интересует...
Я все-таки смог решить описанную выше проблему. Все оказалось довольно просто, я нашел процедуру в libata-core.c, где нужно изменить код, в результате чего дурацкая задержка при старте ядра исчезла.
Правда, изменения жесткие, т.е. - с моими изменениями в коде устройство на порту ata2 никогда не будет определяться.
Разбираться с тем, как парсить командную строку ядра у меня не было времени, но если здесь есть более опытный спец по ядру в целом, то ему не составит труда пропатчить libata так, чтобы можно было применять параметр загрузки sata2=nodetect или что-то в этом роде, примерно так же, как это сделано с IDE...
В общем - если это кому-то это интересно, пишите. Мой вариант работает, проверено, осталось только привести его в вид, удобный для повседневного использования.
а написать про
а написать про баг разработчикам ядра не пробовали? Думаю Вам были бы благодарны многие
libata-core.c & ASUS P5W DH Deluxe
В том-то и дело, что это не баг. Это фича... Разработчики мамки решили посадить на SATA2 автономный сплиттер. Поскольку он на материнке подсоединен только к питанию и к порту SATA2, ядро без специального ПО не может знать о том, что на этом порту не жесткий диск, а сплиттер. Я писал - ответа ноль.
Тут вопрос-то в общем в чем: есть общая схема работы с SATA контроллерами и устройствами, реализованная в libata. Какие-то аппаратнозависимые вещи обрабатываются собственными драйверами контроллеров, а общие - в libata. Процедура определения линка и устройств на портах инициируется именно из общего кода, а уже потом, при необходимости, может быть задействован код, специфичный для конкретного контроллера. Проблемы в коде как таковой не существует - это аппаратная проблема, которую должен решать производитель оборудования. Поэтому, я думаю, разработчики ядра и молчат.
Возможно, они неадекватно восприняли мой английский... Я им, в общем-то, предлагал сделать следующее:
Есть стандартный драйвер, работающий с устройствами IDE. Его код обрабатывает командную строку ядра, и понимает команду типа "hdx=nodetect". При выполнении процедуры определения он пропускает ее для устройств, указанных в командной строке. Драйвер libata, к большому сожалению, командную строку не обрабатывает, и выполняет процедуру определения устройств на всех обнаруженных портах. Я предложил им сделать изменения в libata, чтобы этот драйвер имел возможности, аналогичные IDE, даже указал, где именно нужно внести обработку... Но - или им это неинтересно, либо они меня не поняли... Хотя - идея эта хорошая и нужная, я на много сотен процентов уверен, что ее замечательно воспримут многие и многие.
попробуйте
попробуйте повторно написать с вопросом - будет ли это сделано и если нет, то почему.
Если вы мне
Если вы мне прдоставите подробную информацию, то я постараюсь выпустить небольшой патч для libata.