From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <41866820.7010702@altlinux.com> Date: Mon, 01 Nov 2004 19:45:20 +0300 From: Anton Farygin Organization: ALT Linux User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.7.2) Gecko/20040808 X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: ALT Linux kernel packages development Subject: Re: [d-kernel] sata_sil =?KOI8-R?Q?=D7_initrd?= References: <41865F4C.3020502@altlinux.com> <20041101163048.GE29646@master.mivlgu.local> In-Reply-To: <20041101163048.GE29646@master.mivlgu.local> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ALT Linux kernel packages development List-Id: ALT Linux kernel packages development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2004 16:45:23 -0000 Archived-At: List-Archive: List-Post: Sergey Vlasov пишет: > On Mon, Nov 01, 2004 at 07:07:40PM +0300, Anton Farygin wrote: > >>Всем привет. >> >>Заметил приличный секс при обновлении с ядра 2.4.26 до ядра 2.6.9 или >>2.4.27. >> >>Проблема заключается в наличии вот такого устройства: >>$ pciscan -v -c 001:04 >>Recommended driver Description >>------------------ ----------- >>unknown Silicon Image|Sil3112A Serial ATA[RAID bus >>controller] >> 1095:3112:1095:6112 drivers: unknown >>class:001:04:00 > > > Я об этом предупреждал ;) Я в курсе. Просто сейчас это еще происходит и при установке каждого нового ядра. > > >>В hwdatabase драйвер я для него пропишу без проблем. >>Остается только правильно этот драйвер прописывать в initrd >> >>Есть следующее предложение: >> >>считать что нужно в initrd прописывать все драйвера, возвращаемые >>pciscan -r -c 001 >> >>Где 001 - это все Mass storage controller >> >>По умолчанию pciscan -r -c 001 будет возвращать драйвера _для текущего_ >>ядра. >> >>Передав ему параметр -k 2.4.27 получим драйвера для ядра 2.4.27. >> >>Возражения ? > > > Т.е., предлагается соответствующим образом править mkinitrd? Да. Вот только я думаю - что стоит сделать раньше - добавить возможность настраивать поведение libhw-tools или поправить mkinitrd ? ;-) Если поправить mkinitrd, то приоритет написания конфигов к libhw-tools вырастет очень сильно ;-) > > В принципе это правильно (модули иногда ещё и переименовываются, вот опять > же при переходе 2.4.26->2.4.27 произошло переименование carmel -> sx8). Угу. Для того и придумано. Правда придется делать зависимости у ядер на hwdatabase нужной версии, но это как раз не страшно. > > Но при существующем положении вещей получится ерунда с Adaptec > (aic7xxx/aic79xx) - там с PCI ID такой бардак :( Хотя в 2.6-mm его > всё-таки стали чинить, в результате, как обычно, сначала сломали ;) ;-) Дело в том, что hwdatabase существует независимо от ядра. Т.е. - в принципе там мы сможем прописать то, что нам нужно и для какого нужно ядра. Надеюсь, что в ближайшее время появится web интерфейс для более удобного управления hwdatabase и соответствующие тулзы, позволяющие пользователю сделать отчет об обнаруженном у него железе. А вот с текущей hwdatabase надо действительно разбираться. У меня это в TODO - займусь недели через две. Rgds, Rider