[d-kernel] lm_sensors: prog/hotplug/p4b_smbus

[d-kernel] lm_sensors: prog/hotplug/p4b_smbus

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 507 bytes --]

Hello!

А как общественность относится к сборке модуля
prog/hotplug/p4b_smbus.c из lm_sensors-2.8.0? Понятно, что это грязный
хак, но это необходимо для работы lm_sensors с платами от ASUS на
интеловских чипсетах (помимо упомянутой в названии модуля P4B, это как
минимум P4B533, P4PE, P4T533).

Альтернативный вариант - тащить в ядро код из ветки 2.6, включающий
SMBus при обработке PCI quirks. Это работает, но требует пересборки
ядра для добавления новых идентификаторов.

-- 
Sergey Vlasov

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] lm_sensors: prog/hotplug/p4b_smbus

[Ed V. Bartosh]

>>>>> "SV" == Sergey Vlasov writes:

 SV>  А как общественность относится к сборке модуля
 SV>  prog/hotplug/p4b_smbus.c из lm_sensors-2.8.0? Понятно, что это
 SV>  грязный хак, но это необходимо для работы lm_sensors с платами
 SV>  от ASUS на интеловских чипсетах (помимо упомянутой в названии
 SV>  модуля P4B, это как минимум P4B533, P4PE, P4T533).
  
 SV>  Альтернативный вариант - тащить в ядро код из ветки 2.6,
 SV>  включающий SMBus при обработке PCI quirks. Это работает, но
 SV>  требует пересборки ядра для добавления новых идентификаторов.

Я бы пока предпочел первый вариант.  

-- 
Best regards,
Ed V. Bartosh

[d-kernel] Re: lm_sensors: prog/hotplug/p4b_smbus

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 779 bytes --]

On Wed, 06 Aug 2003 20:05:26 +0400
ed@altlinux.ru (Ed V. Bartosh) wrote:

> 
> >>>>> "SV" == Sergey Vlasov writes:
> 
>  SV>  А как общественность относится к сборке модуля
>  SV>  prog/hotplug/p4b_smbus.c из lm_sensors-2.8.0? Понятно, что это
>  SV>  грязный хак, но это необходимо для работы lm_sensors с платами
>  SV>  от ASUS на интеловских чипсетах (помимо упомянутой в названии
>  SV>  модуля P4B, это как минимум P4B533, P4PE, P4T533).
>   
>  SV>  Альтернативный вариант - тащить в ядро код из ветки 2.6,
>  SV>  включающий SMBus при обработке PCI quirks. Это работает, но
>  SV>  требует пересборки ядра для добавления новых идентификаторов.
> 
> Я бы пока предпочел первый вариант.  

А вот в 2.4.23-pre3 приплыл второй. Взять его оттуда, что ли...

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] Re: lm_sensors: prog/hotplug/p4b_smbus

[Anton Farygin]

[-- Attachment #1: Type: text/plain, Size: 887 bytes --]

Sergey Vlasov пишет:
> On Wed, 06 Aug 2003 20:05:26 +0400
> ed@altlinux.ru (Ed V. Bartosh) wrote:
> 
> 
>>>>>>>"SV" == Sergey Vlasov writes:
>>
>> SV>  А как общественность относится к сборке модуля
>> SV>  prog/hotplug/p4b_smbus.c из lm_sensors-2.8.0? Понятно, что это
>> SV>  грязный хак, но это необходимо для работы lm_sensors с платами
>> SV>  от ASUS на интеловских чипсетах (помимо упомянутой в названии
>> SV>  модуля P4B, это как минимум P4B533, P4PE, P4T533).
>>  
>> SV>  Альтернативный вариант - тащить в ядро код из ветки 2.6,
>> SV>  включающий SMBus при обработке PCI quirks. Это работает, но
>> SV>  требует пересборки ядра для добавления новых идентификаторов.
>>
>>Я бы пока предпочел первый вариант.  
> 
> 
> А вот в 2.4.23-pre3 приплыл второй. Взять его оттуда, что ли...

Взять взять...

я как раз завтра собираюсь собрать ядрышко более новое из CVS.

Rgds,
Rider


[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

[d-kernel] Re: lm_sensors: prog/hotplug/p4b_smbus

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1423 bytes --]

On Sun, 21 Sep 2003 14:12:20 +0400 Anton Farygin wrote:

> Sergey Vlasov пишет:
> > On Wed, 06 Aug 2003 20:05:26 +0400
> > ed@altlinux.ru (Ed V. Bartosh) wrote:
> > 
> > 
> >>>>>>>"SV" == Sergey Vlasov writes:
> >>
> >> SV>  А как общественность относится к сборке модуля
> >> SV>  prog/hotplug/p4b_smbus.c из lm_sensors-2.8.0? Понятно, что это
> >> SV>  грязный хак, но это необходимо для работы lm_sensors с платами
> >> SV>  от ASUS на интеловских чипсетах (помимо упомянутой в названии
> >> SV>  модуля P4B, это как минимум P4B533, P4PE, P4T533).
> >>  
> >> SV>  Альтернативный вариант - тащить в ядро код из ветки 2.6,
> >> SV>  включающий SMBus при обработке PCI quirks. Это работает, но
> >> SV>  требует пересборки ядра для добавления новых идентификаторов.
> >>
> >>Я бы пока предпочел первый вариант.  
> > 
> > 
> > А вот в 2.4.23-pre3 приплыл второй. Взять его оттуда, что ли...
> 
> Взять взять...

Положил в kernel-fix-drivers-pci. Прямо сейчас проверить не на чем, но
предыдущая версия у меня на P4PE работала.

> я как раз завтра собираюсь собрать ядрышко более новое из CVS.

Угу. Там ещё надо agpgart фиксить - патч для поддержки AGP3 на KT400
сломал поддержку AGP2 :-(

Сейчас попробую починить - код из 2.6 у меня работал. Кстати, тот патч
откуда брался? (У меня сейчас нет почты где-то за последнюю неделю)

PS: Интернет провели, вроде сегодня даже не глючит :-)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] Re: lm_sensors: prog/hotplug/p4b_smbus

[Anton Farygin]

[-- Attachment #1: Type: text/plain, Size: 1673 bytes --]

Sergey Vlasov пишет:
> On Sun, 21 Sep 2003 14:12:20 +0400 Anton Farygin wrote:
> 
> 
>>Sergey Vlasov пишет:
>>
>>>On Wed, 06 Aug 2003 20:05:26 +0400
>>>ed@altlinux.ru (Ed V. Bartosh) wrote:
>>>
>>>
>>>
>>>>>>>>>"SV" == Sergey Vlasov writes:
>>>>
>>>>SV>  А как общественность относится к сборке модуля
>>>>SV>  prog/hotplug/p4b_smbus.c из lm_sensors-2.8.0? Понятно, что это
>>>>SV>  грязный хак, но это необходимо для работы lm_sensors с платами
>>>>SV>  от ASUS на интеловских чипсетах (помимо упомянутой в названии
>>>>SV>  модуля P4B, это как минимум P4B533, P4PE, P4T533).
>>>> 
>>>>SV>  Альтернативный вариант - тащить в ядро код из ветки 2.6,
>>>>SV>  включающий SMBus при обработке PCI quirks. Это работает, но
>>>>SV>  требует пересборки ядра для добавления новых идентификаторов.
>>>>
>>>>Я бы пока предпочел первый вариант.  
>>>
>>>
>>>А вот в 2.4.23-pre3 приплыл второй. Взять его оттуда, что ли...
>>
>>Взять взять...
> 
> 
> Положил в kernel-fix-drivers-pci. Прямо сейчас проверить не на чем, но
> предыдущая версия у меня на P4PE работала.
> 
> 
>>я как раз завтра собираюсь собрать ядрышко более новое из CVS.
> 
> 
> Угу. Там ещё надо agpgart фиксить - патч для поддержки AGP3 на KT400
> сломал поддержку AGP2 :-(

Как это ? Вроде как у меня работает... во всяком случае на i845-ом.

> 
> Сейчас попробую починить - код из 2.6 у меня работал. Кстати, тот патч
> откуда брался? (У меня сейчас нет почты где-то за последнюю неделю)

Я не в курсе - Mouse где-то нарыл... нам еще обещают KT600 подогнать - 
там та же проблема.

> 
> PS: Интернет провели, вроде сегодня даже не глючит :-)

Отлично !!!

Ты мне ключик вышли - я тебя в офис проведу.

Rgds,
Rider

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

[d-kernel] Re: lm_sensors: prog/hotplug/p4b_smbus

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 904 bytes --]

On Sun, 21 Sep 2003 15:59:42 +0400 Anton Farygin wrote:

> > Угу. Там ещё надо agpgart фиксить - патч для поддержки AGP3 на KT400
> > сломал поддержку AGP2 :-(
> 
> Как это ? Вроде как у меня работает... во всяком случае на i845-ом.

Сломана работа KT400 со старыми видеокартами - у меня с Radeon 8500LE не
работает. Симптомы те же, что и в противоположном случае - agpgart:
unable to determine aperture size.

В 2.6 проверка идёт не по PCI ID, а по битам в конфигурации - сейчас
пробую перетащить этот код. Заодно пришлось весь патч перекорёжить :-)

> > Сейчас попробую починить - код из 2.6 у меня работал. Кстати, тот патч
> > откуда брался? (У меня сейчас нет почты где-то за последнюю неделю)
> 
> Я не в курсе - Mouse где-то нарыл... нам еще обещают KT600 подогнать - 
> там та же проблема.

У него, кстати, вроде как даже PCI ID тот же самый (по информации из
2.4.0-test5).

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] Re: lm_sensors: prog/hotplug/p4b_smbus

[Anton Farygin]

[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]

Sergey Vlasov пишет:
> On Sun, 21 Sep 2003 15:59:42 +0400 Anton Farygin wrote:
> 
> 
>>>Угу. Там ещё надо agpgart фиксить - патч для поддержки AGP3 на KT400
>>>сломал поддержку AGP2 :-(
>>
>>Как это ? Вроде как у меня работает... во всяком случае на i845-ом.
> 
> 
> Сломана работа KT400 со старыми видеокартами - у меня с Radeon 8500LE не
> работает. Симптомы те же, что и в противоположном случае - agpgart:
> unable to determine aperture size.
> 
> В 2.6 проверка идёт не по PCI ID, а по битам в конфигурации - сейчас
> пробую перетащить этот код. Заодно пришлось весь патч перекорёжить :-)

Да, IMHO это правильнее ;-)

> 
> 
>>>Сейчас попробую починить - код из 2.6 у меня работал. Кстати, тот патч
>>>откуда брался? (У меня сейчас нет почты где-то за последнюю неделю)
>>
>>Я не в курсе - Mouse где-то нарыл... нам еще обещают KT600 подогнать - 
>>там та же проблема.
> 
> 
> У него, кстати, вроде как даже PCI ID тот же самый (по информации из
> 2.4.0-test5).

Да, в нем северный (по моему) мост почти не отличается.

Rgds,
Rider

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

[d-kernel] agpgart

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 525 bytes --]

On Sun, 21 Sep 2003 15:59:42 +0400 Anton Farygin wrote:

> > Угу. Там ещё надо agpgart фиксить - патч для поддержки AGP3 на KT400
> > сломал поддержку AGP2 :-(
> 
> Как это ? Вроде как у меня работает... во всяком случае на i845-ом.

Вроде починил - в режиме AGP 2.0 работает, 3.0 у меня не с чем
запустить. Код перетащил из 2.6.0-test5.

Попутно добавил туда же поддержку AGP для Intel 7x05, ATI Radeon IGP и
Via CLE266 (из 2.4.23-pre*) - эти вроде бы ничего ломать не должны, там
существующий код не правится.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] agpgart

[Anton Farygin]

[-- Attachment #1: Type: text/plain, Size: 604 bytes --]

Sergey Vlasov пишет:
> On Sun, 21 Sep 2003 15:59:42 +0400 Anton Farygin wrote:
> 
> 
>>>Угу. Там ещё надо agpgart фиксить - патч для поддержки AGP3 на KT400
>>>сломал поддержку AGP2 :-(
>>
>>Как это ? Вроде как у меня работает... во всяком случае на i845-ом.
> 
> 
> Вроде починил - в режиме AGP 2.0 работает, 3.0 у меня не с чем
> запустить. Код перетащил из 2.6.0-test5.
> 
> Попутно добавил туда же поддержку AGP для Intel 7x05, ATI Radeon IGP и
> Via CLE266 (из 2.4.23-pre*) - эти вроде бы ничего ломать не должны, там
> существующий код не правится.

Отлично !!!


3.0 проверим завтра.

Rgds,
Rider

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: [d-kernel] Re: lm_sensors: prog/hotplug/p4b_smbus

[Alexander Bokovoy]

On Sun, Sep 21, 2003 at 03:44:30PM +0400, Sergey Vlasov wrote:
> > >> SV>  Альтернативный вариант - тащить в ядро код из ветки 2.6,
> > >> SV>  включающий SMBus при обработке PCI quirks. Это работает, но
> > >> SV>  требует пересборки ядра для добавления новых идентификаторов.
> > >>
> > >>Я бы пока предпочел первый вариант.  
> > > 
> > > 
> > > А вот в 2.4.23-pre3 приплыл второй. Взять его оттуда, что ли...
> > 
> > Взять взять...
> 
> Положил в kernel-fix-drivers-pci. Прямо сейчас проверить не на чем, но
> предыдущая версия у меня на P4PE работала.
OK.

> > я как раз завтра собираюсь собрать ядрышко более новое из CVS.
> 
> Угу. Там ещё надо agpgart фиксить - патч для поддержки AGP3 на KT400
> сломал поддержку AGP2 :-(
> 
> Сейчас попробую починить - код из 2.6 у меня работал. Кстати, тот патч
> откуда брался? (У меня сейчас нет почты где-то за последнюю неделю)
В почте, по-моему, этого не упоминалось.

> PS: Интернет провели, вроде сегодня даже не глючит :-)
Отлично!

Кстати, по отношению к hotplug и прочим автоматикам. Хотелось бы
интегрировать, наконец, имеющиеся наработки по автоматической
идентификации ресурсов на разных этапах. Что мы имеем на сегодня в AW и
что хотелось бы обобщить на весь проект:

  - автоматизация загрузки драйверов блочных устройств (SCSI/IDE), с
    полным выносом как SCSI, так и IDE в модули. Работает и в случае
    двух-трех ходовок (загрузка специальных модулей чипсетов, после чего
    ide-probe начинает видеть контроллер) и в обычных случаях. Все правки
    для mkinitrd/ядра есть;

  - автоматическое детектирование PCI устройств и загрузка драйверов --
    тут нужна более плотная интеграция с имеющимся у нас /etc/modutils.d/
    и развязывание зависимостей на kudzu -- для PCI-устройств kudzu
    является стрельбой из пушки, можно сделать все проще (скрипт pcidetect,
    работающий по этой схеме, уже есть, работает для сети и аналогичных
    устройств), да и расстановка приоритетов привязки драйверов не
    помешает (важно для мульти-хостовых серверов, где имена сетевых
    интерфейсов иногда нужно жестко закреплять за драйверами);

  - поддержка hotswap IDE/SCSI на отдельных чипсетах, которые это умеют
    (есть специальные модули), с нотификацией обработчика событий в
    user-space (наработки есть). Для этого момента хотелось бы унифицировать
    интерфейсы взаимодействия user-space и ядра так, чтобы все выполнялось
    в едином ключе;

  - создание базы типовых конфигураций для sensors для того, чтобы более
    точно детектировать их и устанавливать конфигурации по умолчанию;
    возможно, появление механизма ограничений перебираемых конфигураций --
    для OEM-вариантов, где могут быть ограниченные вариации платформы.
  
-- 
/ Alexander Bokovoy
---
A bit of talcum
Is always walcum
		-- Ogden Nash

Re: [d-kernel] Re: lm_sensors: prog/hotplug/p4b_smbus

[Anton Farygin]

[-- Attachment #1: Type: text/plain, Size: 3389 bytes --]

Alexander Bokovoy пишет:
> On Sun, Sep 21, 2003 at 03:44:30PM +0400, Sergey Vlasov wrote:
> 
>>>>>SV>  Альтернативный вариант - тащить в ядро код из ветки 2.6,
>>>>>SV>  включающий SMBus при обработке PCI quirks. Это работает, но
>>>>>SV>  требует пересборки ядра для добавления новых идентификаторов.
>>>>>
>>>>>Я бы пока предпочел первый вариант.  
>>>>
>>>>
>>>>А вот в 2.4.23-pre3 приплыл второй. Взять его оттуда, что ли...
>>>
>>>Взять взять...
>>
>>Положил в kernel-fix-drivers-pci. Прямо сейчас проверить не на чем, но
>>предыдущая версия у меня на P4PE работала.
> 
> OK.
> 
> 
>>>я как раз завтра собираюсь собрать ядрышко более новое из CVS.
>>
>>Угу. Там ещё надо agpgart фиксить - патч для поддержки AGP3 на KT400
>>сломал поддержку AGP2 :-(
>>
>>Сейчас попробую починить - код из 2.6 у меня работал. Кстати, тот патч
>>откуда брался? (У меня сейчас нет почты где-то за последнюю неделю)
> 
> В почте, по-моему, этого не упоминалось.
> 
> 
>>PS: Интернет провели, вроде сегодня даже не глючит :-)
> 
> Отлично!
> 
> Кстати, по отношению к hotplug и прочим автоматикам. Хотелось бы
> интегрировать, наконец, имеющиеся наработки по автоматической
> идентификации ресурсов на разных этапах. Что мы имеем на сегодня в AW и
> что хотелось бы обобщить на весь проект:
> 
>   - автоматизация загрузки драйверов блочных устройств (SCSI/IDE), с
>     полным выносом как SCSI, так и IDE в модули. Работает и в случае
>     двух-трех ходовок (загрузка специальных модулей чипсетов, после чего
>     ide-probe начинает видеть контроллер) и в обычных случаях. Все правки
>     для mkinitrd/ядра есть;

Можно будет начать примерно недели через две.

> 
>   - автоматическое детектирование PCI устройств и загрузка драйверов --
>     тут нужна более плотная интеграция с имеющимся у нас /etc/modutils.d/
>     и развязывание зависимостей на kudzu -- для PCI-устройств kudzu
>     является стрельбой из пушки, можно сделать все проще (скрипт pcidetect,
>     работающий по этой схеме, уже есть, работает для сети и аналогичных
>     устройств), да и расстановка приоритетов привязки драйверов не
>     помешает (важно для мульти-хостовых серверов, где имена сетевых
>     интерфейсов иногда нужно жестко закреплять за драйверами);

Аналогично... только там есть некоторая проблема: нужно будет еще 
создавать симлинки на устройства (/dev/modem ->/dev/ttyPCT например), 
для некоторых - нужно insmod'ом грузить два драйвера (ptserial_sis 
например), для некоторых - прописывать дополнительные конфигурационные 
файлы (или запускать дополнительные программы)... и т.д.

> 
>   - поддержка hotswap IDE/SCSI на отдельных чипсетах, которые это умеют
>     (есть специальные модули), с нотификацией обработчика событий в
>     user-space (наработки есть). Для этого момента хотелось бы унифицировать
>     интерфейсы взаимодействия user-space и ядра так, чтобы все выполнялось
>     в едином ключе;

Это интересно... можно попробовать. Но тоже недельки через две...

> 
>   - создание базы типовых конфигураций для sensors для того, чтобы более
>     точно детектировать их и устанавливать конфигурации по умолчанию;
>     возможно, появление механизма ограничений перебираемых конфигураций --
>     для OEM-вариантов, где могут быть ограниченные вариации платформы.
>   

Это меня если честно - мало интересует, ибо 1) sensors на многих машинах 
сильно глючат 2) сам не пользуюсь ;-)

Rgds,
Rider

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: [d-kernel] Re: lm_sensors: prog/hotplug/p4b_smbus

[Alexander Bokovoy]

On Sun, Sep 21, 2003 at 04:16:10PM +0400, Anton Farygin wrote:
> >Кстати, по отношению к hotplug и прочим автоматикам. Хотелось бы
> >интегрировать, наконец, имеющиеся наработки по автоматической
> >идентификации ресурсов на разных этапах. Что мы имеем на сегодня в AW и
> >что хотелось бы обобщить на весь проект:
> >
> >  - автоматизация загрузки драйверов блочных устройств (SCSI/IDE), с
> >    полным выносом как SCSI, так и IDE в модули. Работает и в случае
> >    двух-трех ходовок (загрузка специальных модулей чипсетов, после чего
> >    ide-probe начинает видеть контроллер) и в обычных случаях. Все правки
> >    для mkinitrd/ядра есть;
> 
> Можно будет начать примерно недели через две.
> 
> >
> >  - автоматическое детектирование PCI устройств и загрузка драйверов --
> >    тут нужна более плотная интеграция с имеющимся у нас /etc/modutils.d/
> >    и развязывание зависимостей на kudzu -- для PCI-устройств kudzu
> >    является стрельбой из пушки, можно сделать все проще (скрипт pcidetect,
> >    работающий по этой схеме, уже есть, работает для сети и аналогичных
> >    устройств), да и расстановка приоритетов привязки драйверов не
> >    помешает (важно для мульти-хостовых серверов, где имена сетевых
> >    интерфейсов иногда нужно жестко закреплять за драйверами);
> 
> Аналогично... только там есть некоторая проблема: нужно будет еще 
> создавать симлинки на устройства (/dev/modem ->/dev/ttyPCT например), 
> для некоторых - нужно insmod'ом грузить два драйвера (ptserial_sis 
> например), для некоторых - прописывать дополнительные конфигурационные 
> файлы (или запускать дополнительные программы)... и т.д.
Это -- не проблема. Что касается загрузки нескольких драйверов, то:

  - нужно отказываться от использования insmod, как класс, в пользу
    modprobe. Из-за присутствия insmod мы уже наблюдали проблемы в initrd
    при загрузке чипсетов IDE, с modprobe они работают без проблем.
    
  - это достижимо средствами modutils без проблем -- специальные команды
    есть (above/below).

  Вообщем, есть уже готовый аппарат в modutils, который все требуемое
  обеспечивает -- и запуск программ, и вытягивание стеков модулей, и
  последовательное опробывание цепочки драйверов.
 
> >
> >  - поддержка hotswap IDE/SCSI на отдельных чипсетах, которые это умеют
> >    (есть специальные модули), с нотификацией обработчика событий в
> >    user-space (наработки есть). Для этого момента хотелось бы 
> >    унифицировать
> >    интерфейсы взаимодействия user-space и ядра так, чтобы все выполнялось
> >    в едином ключе;
> 
> Это интересно... можно попробовать. Но тоже недельки через две...
> 
> >
> >  - создание базы типовых конфигураций для sensors для того, чтобы более
> >    точно детектировать их и устанавливать конфигурации по умолчанию;
> >    возможно, появление механизма ограничений перебираемых конфигураций --
> >    для OEM-вариантов, где могут быть ограниченные вариации платформы.
> >  
> 
> Это меня если честно - мало интересует, ибо 1) sensors на многих машинах 
> сильно глючат 2) сам не пользуюсь ;-)
Помимо тебя, Антон, и нас, всех остальных разработчиков, есть еще пользователи. :) 
Вот именно для этого, чтобы работало, а не глючило, потенциальные конфигурации 
необходимо определять, по возможности автоматически. Шансы для этого по отношению 
к распространенным чипсетам есть, нужно их использовать. Пусть и не все покроем, 
но на нормальных машинах сможем обеспечить приемлемый уровень покрытия. Особенно 
это важно для современных десктопов и ноутбуков.

Да, забыл в указанном списке упомянуть ACPI и динамическую загрузку
исправленных DSDT. Патч для поиска исправленных DSDT в initrd Сергей
Власов уже нашел, вопрос в создании инфраструктуры и сборке пакетов с
исправленными DSDT с acpi.sf.net.
-- 
/ Alexander Bokovoy
---
We're on Token Ring, and it looks like the token got loose.

[d-kernel] Re: lm_sensors: prog/hotplug/p4b_smbus

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 2129 bytes --]

On Sun, 21 Sep 2003 15:30:58 +0300 Alexander Bokovoy wrote:

> > >  - автоматическое детектирование PCI устройств и загрузка драйверов --
> > >    тут нужна более плотная интеграция с имеющимся у нас /etc/modutils.d/
> > >    и развязывание зависимостей на kudzu -- для PCI-устройств kudzu
> > >    является стрельбой из пушки, можно сделать все проще (скрипт pcidetect,
> > >    работающий по этой схеме, уже есть, работает для сети и аналогичных
> > >    устройств), да и расстановка приоритетов привязки драйверов не
> > >    помешает (важно для мульти-хостовых серверов, где имена сетевых
> > >    интерфейсов иногда нужно жестко закреплять за драйверами);
> > 
> > Аналогично... только там есть некоторая проблема: нужно будет еще 
> > создавать симлинки на устройства (/dev/modem ->/dev/ttyPCT например), 
> > для некоторых - нужно insmod'ом грузить два драйвера (ptserial_sis 
> > например), для некоторых - прописывать дополнительные конфигурационные 
> > файлы (или запускать дополнительные программы)... и т.д.
> Это -- не проблема. Что касается загрузки нескольких драйверов, то:
> 
>   - нужно отказываться от использования insmod, как класс, в пользу
>     modprobe. Из-за присутствия insmod мы уже наблюдали проблемы в initrd
>     при загрузке чипсетов IDE, с modprobe они работают без проблем.

А настоящий источник этих проблем установить так и не удалось?

modprobe в initrd какой затащили? mkrescue хотя бы в простых случаях
работать сможет (будет ли initrd влезать на дискетку)?

>   - это достижимо средствами modutils без проблем -- специальные команды
>     есть (above/below).
> 
>   Вообщем, есть уже готовый аппарат в modutils, который все требуемое
>   обеспечивает -- и запуск программ, и вытягивание стеков модулей, и
>   последовательное опробывание цепочки драйверов.
[skip]
> Да, забыл в указанном списке упомянуть ACPI и динамическую загрузку
> исправленных DSDT. Патч для поиска исправленных DSDT в initrd Сергей
> Власов уже нашел, вопрос в создании инфраструктуры и сборке пакетов с
> исправленными DSDT с acpi.sf.net.

Он уже лежит в kernel-feat-acpi.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] Re: lm_sensors: prog/hotplug/p4b_smbus

[Alexander Bokovoy]

On Sun, Sep 21, 2003 at 05:26:37PM +0400, Sergey Vlasov wrote:
> > > файлы (или запускать дополнительные программы)... и т.д.
> > Это -- не проблема. Что касается загрузки нескольких драйверов, то:
> > 
> >   - нужно отказываться от использования insmod, как класс, в пользу
> >     modprobe. Из-за присутствия insmod мы уже наблюдали проблемы в initrd
> >     при загрузке чипсетов IDE, с modprobe они работают без проблем.
> 
> А настоящий источник этих проблем установить так и не удалось?
Настоящий источник -- insmod, точнее режим, в котором он работает не как
modprobe (последний -- symlink на insmod). Подробнее должен рассказать Женя Калюта в
понедельник-вторник. Что интересно, в Debian как раз modprobe в initrd.

> modprobe в initrd какой затащили? mkrescue хотя бы в простых случаях
> работать сможет (будет ли initrd влезать на дискетку)?
Поскольку modprobe = symlink на insmod, то размер тот же. Мы втащили его
поддержку в mkinitrd.

Сам патч mkinitrd-modprobe.patch вот такой:

--- mkinitrd.orig	2003-08-20 15:26:00.000000000 +0300
+++ mkinitrd	2003-08-20 15:27:40.000000000 +0300
@@ -373,6 +373,8 @@
 		Fatal "Failed to create directories."
 
 	Install /lib/mkinitrd/busybox "$MNTDIR/bin/sh"
+	Install /sbin/modprobe "$MNTDIR/bin/modprobe"
+	Install /sbin/rmmod "$MNTDIR/bin/rmmod"
 	Ln -s sh "$MNTDIR/bin/echo"
 	Ln -s sh "$MNTDIR/bin/insmod"
 	Ln -s sh "$MNTDIR/bin/losetup"
@@ -409,10 +411,10 @@
 
 		Debug "Loading module \"$m\" with options \"$options\""
 		/bin/cat >>"$RCFILE" <<EOF
-/bin/insmod -f $MODULES_DIR/$m $options
+/bin/modprobe $n $options
 EOF
 	done
-
+#/bin/insmod -f $MODULES_DIR/$m $options
 	if [ -n "$HAVE_RAID" ]; then
 		Mknod "$MNTDIR/dev/md0" b 9 0
 		Ln -s sh "$MNTDIR/bin/raidautorun"

Кстати, патч для поддержки модульности IDE в mkinitrd не намного больше:

diff -ur mkinitrd-2.8.8.orig/mkinitrd mkinitrd-2.8.8/mkinitrd
--- mkinitrd-2.8.8.orig/mkinitrd	2003-08-19 15:33:02.000000000 +0300
+++ mkinitrd-2.8.8/mkinitrd	2003-08-19 15:34:39.000000000 +0300
@@ -221,9 +221,14 @@
 	local ide
 	ide=/proc/ide/ide*
 	if [ -n "$ide" ]; then
-		FindModule -ide-mod
-		FindModule -ide-probe-mod
-		FindModule -ide-disk
+	    FindModule -ide-mod
+	    local pci_modules=`find $MODULES_DIR/kernel/drivers/ide/pci -name '*.o' | \
+ 		    while read i; do /sbin/lsmod | awk {'print $1'} | grep  \`basename ${i%%.o}\`; done`
+	    for i in $pci_modules; do
+		FindModule $i;
+	    done
+	    FindModule -ide-probe-mod
+	    FindModule -ide-disk
 	fi
 }
 

> >   Вообщем, есть уже готовый аппарат в modutils, который все требуемое
> >   обеспечивает -- и запуск программ, и вытягивание стеков модулей, и
> >   последовательное опробывание цепочки драйверов.
> [skip]
> > Да, забыл в указанном списке упомянуть ACPI и динамическую загрузку
> > исправленных DSDT. Патч для поиска исправленных DSDT в initrd Сергей
> > Власов уже нашел, вопрос в создании инфраструктуры и сборке пакетов с
> > исправленными DSDT с acpi.sf.net.
> 
> Он уже лежит в kernel-feat-acpi.
Ок. вопрос только в формировании инфраструктуры для хранения DSDT и в поддержке в
mkinitrd/mkrescue.


-- 
/ Alexander Bokovoy
---
You'll never see all the places, or read all the books, but fortunately,
they're not all recommended.

[d-kernel] initrd (modprobe vs insmod)

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1219 bytes --]

On Sun, 21 Sep 2003 17:55:44 +0300 Alexander Bokovoy wrote:

> On Sun, Sep 21, 2003 at 05:26:37PM +0400, Sergey Vlasov wrote:
> > > > файлы (или запускать дополнительные программы)... и т.д.
> > > Это -- не проблема. Что касается загрузки нескольких драйверов, то:
> > > 
> > >   - нужно отказываться от использования insmod, как класс, в пользу
> > >     modprobe. Из-за присутствия insmod мы уже наблюдали проблемы в initrd
> > >     при загрузке чипсетов IDE, с modprobe они работают без проблем.
> > 
> > А настоящий источник этих проблем установить так и не удалось?
> Настоящий источник -- insmod, точнее режим, в котором он работает не как
> modprobe (последний -- symlink на insmod). Подробнее должен рассказать Женя Калюта в
> понедельник-вторник. Что интересно, в Debian как раз modprobe в initrd.

Ладно, подождём.

> > modprobe в initrd какой затащили? mkrescue хотя бы в простых случаях
> > работать сможет (будет ли initrd влезать на дискетку)?
> Поскольку modprobe = symlink на insmod, то размер тот же. Мы втащили его
> поддержку в mkinitrd.

Это в обычной системе. А в mkinitrd у нас busybox (причём статически
собранный с dietlibc), там modprobe добавлять в конфигурацию надо.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] initrd (modprobe vs insmod)

[Alexander Bokovoy]

On Sun, Sep 21, 2003 at 07:26:20PM +0400, Sergey Vlasov wrote:
> > > А настоящий источник этих проблем установить так и не удалось?
> > Настоящий источник -- insmod, точнее режим, в котором он работает не как
> > modprobe (последний -- symlink на insmod). Подробнее должен рассказать Женя Калюта в
> > понедельник-вторник. Что интересно, в Debian как раз modprobe в initrd.
> 
> Ладно, подождём.
> 
> > > modprobe в initrd какой затащили? mkrescue хотя бы в простых случаях
> > > работать сможет (будет ли initrd влезать на дискетку)?
> > Поскольку modprobe = symlink на insmod, то размер тот же. Мы втащили его
> > поддержку в mkinitrd.
> 
> Это в обычной системе. А в mkinitrd у нас busybox (причём статически
> собранный с dietlibc), там modprobe добавлять в конфигурацию надо.
Дык работает же. :) Ровно поверх 1:2.8.9-alt1 и сделано.
-- 
/ Alexander Bokovoy
---
I'm not available for comment..

Re: [d-kernel] initrd (modprobe vs insmod)

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]

On Sun, Sep 21, 2003 at 06:36:22PM +0300, Alexander Bokovoy wrote:
> On Sun, Sep 21, 2003 at 07:26:20PM +0400, Sergey Vlasov wrote:
> > > > А настоящий источник этих проблем установить так и не удалось?
> > > Настоящий источник -- insmod, точнее режим, в котором он работает не как
> > > modprobe (последний -- symlink на insmod). Подробнее должен рассказать Женя Калюта в
> > > понедельник-вторник. Что интересно, в Debian как раз modprobe в initrd.
> > 
> > Ладно, подождём.
> > 
> > > > modprobe в initrd какой затащили? mkrescue хотя бы в простых случаях
> > > > работать сможет (будет ли initrd влезать на дискетку)?
> > > Поскольку modprobe = symlink на insmod, то размер тот же. Мы втащили его
> > > поддержку в mkinitrd.
> > 
> > Это в обычной системе. А в mkinitrd у нас busybox (причём статически
> > собранный с dietlibc), там modprobe добавлять в конфигурацию надо.
> Дык работает же. :) Ровно поверх 1:2.8.9-alt1 и сделано.

Я таких аргументов не принимаю.

На данный момент я понимаю примерно на 90%, почему этот патч на
использование modprobe работает, и не понимаю совершенно, почему не
работает без него.

Пока кто-нибудь не объяснит мне смысл внесения изменений, я их делать не
буду.  Аргументы типа "дык работает же" не рассматриваются.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] initrd (modprobe vs insmod)

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 372 bytes --]

On Sun, Sep 21, 2003 at 07:54:39PM +0400, Dmitry V. Levin wrote:
> Аргументы типа "дык работает же" не рассматриваются.

Вообще говоря, при наличии в качестве "контр"аргумента "дык не
работает" -- лучше рассматривать. :)

("контр" -- применительно к варианту, а не стороне)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] initrd (modprobe vs insmod)

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 424 bytes --]

On Mon, Sep 22, 2003 at 05:00:53PM +0300, Michael Shigorin wrote:
> On Sun, Sep 21, 2003 at 07:54:39PM +0400, Dmitry V. Levin wrote:
> > Аргументы типа "дык работает же" не рассматриваются.
> 
> Вообще говоря, при наличии в качестве "контр"аргумента "дык не
> работает" -- лучше рассматривать. :)

У меня нет инструмента, чтобы рассматривать такие аргументы.

> ("контр" -- применительно к варианту, а не стороне)


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] initrd (modprobe vs insmod)

[Zhenja Kaluta]

 >> > Это в обычной системе. А в mkinitrd у нас busybox (причём статически
 >> > собранный с dietlibc), там modprobe добавлять в конфигурацию надо.
 >> Дык работает же. :) Ровно поверх 1:2.8.9-alt1 и сделано.

 DVL> Я таких аргументов не принимаю.

 DVL> На данный момент я понимаю примерно на 90%, почему этот патч на
 DVL> использование modprobe работает, и не понимаю совершенно, почему не
 DVL> работает без него.

 DVL> Пока кто-нибудь не объяснит мне смысл внесения изменений, я их делать не
 DVL> буду.  Аргументы типа "дык работает же" не рассматриваются.

После 24 сентября должна освободиться система, на которой это явно
наблюдалось, буду смотреть. 

-- 
Zhenja Kaluta                                            ICQ 74596027
GnuPG FingerPrint: B86C B548 7CC4 B58F 0CA3  856E 7EE8 52DE E6B7 8725

Re: [d-kernel] initrd (modprobe vs insmod)

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 768 bytes --]

On Mon, Sep 22, 2003 at 07:12:42PM +0300, Zhenja Kaluta wrote:
>  >> > Это в обычной системе. А в mkinitrd у нас busybox (причём статически
>  >> > собранный с dietlibc), там modprobe добавлять в конфигурацию надо.
>  >> Дык работает же. :) Ровно поверх 1:2.8.9-alt1 и сделано.
> 
>  DVL> Я таких аргументов не принимаю.
> 
>  DVL> На данный момент я понимаю примерно на 90%, почему этот патч на
>  DVL> использование modprobe работает, и не понимаю совершенно, почему не
>  DVL> работает без него.
> 
>  DVL> Пока кто-нибудь не объяснит мне смысл внесения изменений, я их делать не
>  DVL> буду.  Аргументы типа "дык работает же" не рассматриваются.
> 
> После 24 сентября должна освободиться система, на которой это явно
> наблюдалось, буду смотреть. 

Ok


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[d-kernel] Re: initrd (modprobe vs insmod)

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 985 bytes --]

On Sun, 21 Sep 2003 18:36:22 +0300 Alexander Bokovoy wrote:

> On Sun, Sep 21, 2003 at 07:26:20PM +0400, Sergey Vlasov wrote:
> > > > А настоящий источник этих проблем установить так и не удалось?
> > > Настоящий источник -- insmod, точнее режим, в котором он работает не как
> > > modprobe (последний -- symlink на insmod). Подробнее должен рассказать Женя Калюта в
> > > понедельник-вторник. Что интересно, в Debian как раз modprobe в initrd.
> > 
> > Ладно, подождём.
> > 
> > > > modprobe в initrd какой затащили? mkrescue хотя бы в простых случаях
> > > > работать сможет (будет ли initrd влезать на дискетку)?
> > > Поскольку modprobe = symlink на insmod, то размер тот же. Мы втащили его
> > > поддержку в mkinitrd.
> > 
> > Это в обычной системе. А в mkinitrd у нас busybox (причём статически
> > собранный с dietlibc), там modprobe добавлять в конфигурацию надо.
> Дык работает же. :) Ровно поверх 1:2.8.9-alt1 и сделано.

Посмотреть это где-нибудь можно?

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] Re: initrd (modprobe vs insmod)

[Alexander Bokovoy]

On Sun, Sep 21, 2003 at 07:58:27PM +0400, Sergey Vlasov wrote:
> > On Sun, Sep 21, 2003 at 07:26:20PM +0400, Sergey Vlasov wrote:
> > > > > А настоящий источник этих проблем установить так и не удалось?
> > > > Настоящий источник -- insmod, точнее режим, в котором он работает не как
> > > > modprobe (последний -- symlink на insmod). Подробнее должен рассказать Женя Калюта в
> > > > понедельник-вторник. Что интересно, в Debian как раз modprobe в initrd.
> > > 
> > > Ладно, подождём.
> > > 
> > > > > modprobe в initrd какой затащили? mkrescue хотя бы в простых случаях
> > > > > работать сможет (будет ли initrd влезать на дискетку)?
> > > > Поскольку modprobe = symlink на insmod, то размер тот же. Мы втащили его
> > > > поддержку в mkinitrd.
> > > 
> > > Это в обычной системе. А в mkinitrd у нас busybox (причём статически
> > > собранный с dietlibc), там modprobe добавлять в конфигурацию надо.
> > Дык работает же. :) Ровно поверх 1:2.8.9-alt1 и сделано.
> 
> Посмотреть это где-нибудь можно?
Еще в августе отправлено ldv.
-- 
/ Alexander Bokovoy
---
The only function of economic forecasting is to make astrology look respectable.
		-- John Kenneth Galbraith

Re: [d-kernel] Re: lm_sensors: prog/hotplug/p4b_smbus

[Anton Farygin]

[-- Attachment #1: Type: text/plain, Size: 4116 bytes --]

Alexander Bokovoy пишет:
> On Sun, Sep 21, 2003 at 04:16:10PM +0400, Anton Farygin wrote:
> 
>>>Кстати, по отношению к hotplug и прочим автоматикам. Хотелось бы
>>>интегрировать, наконец, имеющиеся наработки по автоматической
>>>идентификации ресурсов на разных этапах. Что мы имеем на сегодня в AW и
>>>что хотелось бы обобщить на весь проект:
>>>
>>> - автоматизация загрузки драйверов блочных устройств (SCSI/IDE), с
>>>   полным выносом как SCSI, так и IDE в модули. Работает и в случае
>>>   двух-трех ходовок (загрузка специальных модулей чипсетов, после чего
>>>   ide-probe начинает видеть контроллер) и в обычных случаях. Все правки
>>>   для mkinitrd/ядра есть;
>>
>>Можно будет начать примерно недели через две.
>>
>>
>>> - автоматическое детектирование PCI устройств и загрузка драйверов --
>>>   тут нужна более плотная интеграция с имеющимся у нас /etc/modutils.d/
>>>   и развязывание зависимостей на kudzu -- для PCI-устройств kudzu
>>>   является стрельбой из пушки, можно сделать все проще (скрипт pcidetect,
>>>   работающий по этой схеме, уже есть, работает для сети и аналогичных
>>>   устройств), да и расстановка приоритетов привязки драйверов не
>>>   помешает (важно для мульти-хостовых серверов, где имена сетевых
>>>   интерфейсов иногда нужно жестко закреплять за драйверами);
>>
>>Аналогично... только там есть некоторая проблема: нужно будет еще 
>>создавать симлинки на устройства (/dev/modem ->/dev/ttyPCT например), 
>>для некоторых - нужно insmod'ом грузить два драйвера (ptserial_sis 
>>например), для некоторых - прописывать дополнительные конфигурационные 
>>файлы (или запускать дополнительные программы)... и т.д.
> 
> Это -- не проблема. Что касается загрузки нескольких драйверов, то:
> 
>   - нужно отказываться от использования insmod, как класс, в пользу
>     modprobe. Из-за присутствия insmod мы уже наблюдали проблемы в initrd
>     при загрузке чипсетов IDE, с modprobe они работают без проблем.

Тогда нужно будет решать как грузить драйвера аля pctel, у которых две 
части и modprobe их грузить нельзя принципиально - они все провайдят 
одинаковый набор функций.

>     
>   - это достижимо средствами modutils без проблем -- специальные команды
>     есть (above/below).
> 
>   Вообщем, есть уже готовый аппарат в modutils, который все требуемое
>   обеспечивает -- и запуск программ, и вытягивание стеков модулей, и
>   последовательное опробывание цепочки драйверов.

Недельки через две попробуем.
>  
> 
>>> - поддержка hotswap IDE/SCSI на отдельных чипсетах, которые это умеют
>>>   (есть специальные модули), с нотификацией обработчика событий в
>>>   user-space (наработки есть). Для этого момента хотелось бы 
>>>   унифицировать
>>>   интерфейсы взаимодействия user-space и ядра так, чтобы все выполнялось
>>>   в едином ключе;
>>
>>Это интересно... можно попробовать. Но тоже недельки через две...
>>
>>
>>> - создание базы типовых конфигураций для sensors для того, чтобы более
>>>   точно детектировать их и устанавливать конфигурации по умолчанию;
>>>   возможно, появление механизма ограничений перебираемых конфигураций --
>>>   для OEM-вариантов, где могут быть ограниченные вариации платформы.
>>> 
>>
>>Это меня если честно - мало интересует, ибо 1) sensors на многих машинах 
>>сильно глючат 2) сам не пользуюсь ;-)
> 
> Помимо тебя, Антон, и нас, всех остальных разработчиков, есть еще пользователи. :) 
> Вот именно для этого, чтобы работало, а не глючило, потенциальные конфигурации 
> необходимо определять, по возможности автоматически. Шансы для этого по отношению 
> к распространенным чипсетам есть, нужно их использовать. Пусть и не все покроем, 
> но на нормальных машинах сможем обеспечить приемлемый уровень покрытия. Особенно 
> это важно для современных десктопов и ноутбуков.

Да, безусловно.

> 
> Да, забыл в указанном списке упомянуть ACPI и динамическую загрузку
> исправленных DSDT. Патч для поиска исправленных DSDT в initrd Сергей
> Власов уже нашел, вопрос в создании инфраструктуры и сборке пакетов с
> исправленными DSDT с acpi.sf.net.

с ACPI все хорошо, но работающего suspend'а на ACPI я еще не видел ;-(

Rgds,
Rider

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: [d-kernel] Re: lm_sensors: prog/hotplug/p4b_smbus

[Alexander Bokovoy]

On Sun, Sep 21, 2003 at 07:21:48PM +0400, Anton Farygin wrote:
> >>для некоторых - нужно insmod'ом грузить два драйвера (ptserial_sis 
> >>например), для некоторых - прописывать дополнительные конфигурационные 
> >>файлы (или запускать дополнительные программы)... и т.д.
> >
> >Это -- не проблема. Что касается загрузки нескольких драйверов, то:
> >
> >  - нужно отказываться от использования insmod, как класс, в пользу
> >    modprobe. Из-за присутствия insmod мы уже наблюдали проблемы в initrd
> >    при загрузке чипсетов IDE, с modprobe они работают без проблем.
> 
> Тогда нужно будет решать как грузить драйвера аля pctel, у которых две 
> части и modprobe их грузить нельзя принципиально - они все провайдят 
> одинаковый набор функций.
Насколько я понимаю. они все же отличаются по чипсетам, для которых
работают. Поэтому разбораться с их загрузкой можно. Антон, ты посмотри на
опции в modules.conf(5), в частности, below и pre-install.

> >Да, забыл в указанном списке упомянуть ACPI и динамическую загрузку
> >исправленных DSDT. Патч для поиска исправленных DSDT в initrd Сергей
> >Власов уже нашел, вопрос в создании инфраструктуры и сборке пакетов с
> >исправленными DSDT с acpi.sf.net.
> 
> с ACPI все хорошо, но работающего suspend'а на ACPI я еще не видел ;-(
suspend куда? Весь мир использует для этого комбинацию APCI+swsup patch.
Почему-то работает и не особенно жалуются.

-- 
/ Alexander Bokovoy
---
The other day I... uh, no, that wasn't me.
		-- Steven Wright

Re: [d-kernel] Re: lm_sensors: prog/hotplug/p4b_smbus

[Anton Farygin]

[-- Attachment #1: Type: text/plain, Size: 1534 bytes --]

Alexander Bokovoy пишет:
> On Sun, Sep 21, 2003 at 07:21:48PM +0400, Anton Farygin wrote:
> 
>>>>для некоторых - нужно insmod'ом грузить два драйвера (ptserial_sis 
>>>>например), для некоторых - прописывать дополнительные конфигурационные 
>>>>файлы (или запускать дополнительные программы)... и т.д.
>>>
>>>Это -- не проблема. Что касается загрузки нескольких драйверов, то:
>>>
>>> - нужно отказываться от использования insmod, как класс, в пользу
>>>   modprobe. Из-за присутствия insmod мы уже наблюдали проблемы в initrd
>>>   при загрузке чипсетов IDE, с modprobe они работают без проблем.
>>
>>Тогда нужно будет решать как грузить драйвера аля pctel, у которых две 
>>части и modprobe их грузить нельзя принципиально - они все провайдят 
>>одинаковый набор функций.
> 
> Насколько я понимаю. они все же отличаются по чипсетам, для которых
> работают. Поэтому разбораться с их загрузкой можно. Антон, ты посмотри на
> опции в modules.conf(5), в частности, below и pre-install.

ok. Через пару недель.

> 
> 
>>>Да, забыл в указанном списке упомянуть ACPI и динамическую загрузку
>>>исправленных DSDT. Патч для поиска исправленных DSDT в initrd Сергей
>>>Власов уже нашел, вопрос в создании инфраструктуры и сборке пакетов с
>>>исправленными DSDT с acpi.sf.net.
>>
>>с ACPI все хорошо, но работающего suspend'а на ACPI я еще не видел ;-(
> 
> suspend куда? Весь мир использует для этого комбинацию APCI+swsup patch.
> Почему-то работает и не особенно жалуются.

suspend 2 memory.

А swsup патч у нас не приложен...

Rgds,
Rider

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: [d-kernel] Re: lm_sensors: prog/hotplug/p4b_smbus

[Alexander Bokovoy]

On Mon, Sep 22, 2003 at 09:42:41AM +0400, Anton Farygin wrote:
> >>>Да, забыл в указанном списке упомянуть ACPI и динамическую загрузку
> >>>исправленных DSDT. Патч для поиска исправленных DSDT в initrd Сергей
> >>>Власов уже нашел, вопрос в создании инфраструктуры и сборке пакетов с
> >>>исправленными DSDT с acpi.sf.net.
> >>
> >>с ACPI все хорошо, но работающего suspend'а на ACPI я еще не видел ;-(
> >
> >suspend куда? Весь мир использует для этого комбинацию APCI+swsup patch.
> >Почему-то работает и не особенно жалуются.
> 
> suspend 2 memory.
Насколько я понимаю, это зависит от корректности DSDT. В некоторых DSDT
эту штуку поправили, потому механизм их прикладывания и нужен.

> А swsup патч у нас не приложен...
Повод включить в план.
-- 
/ Alexander Bokovoy
---
Don't despair; your ideal lover is waiting for you around the corner.

Re: [d-kernel] Re: lm_sensors: prog/hotplug/p4b_smbus

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 294 bytes --]

On Sun, Sep 21, 2003 at 03:05:23PM +0300, Alexander Bokovoy wrote:
> что хотелось бы обобщить на весь проект:

"!!!!" по всем четырем пунктам.

"Истинная правда, всегда так думал" (c) Х.Насреддин

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]