Re: [devel] I: kernel-image-xen-dom0-2.6.18-alt2.1

[Aleksey Avdeev <solo@solin.spb.ru>]

Михаил Якушин пишет:
> Aleksey Avdeev пишет:
>> Михаил Якушин пишет:
>>> Aleksey Avdeev пишет:
>>>> Михаил Якушин пишет:
>>>>> Aleksey Avdeev пишет:
>>>>>> Aleksey Avdeev пишет:
>>>>>>> Приветствую.
>>>>>>>
>>>>>>>   На Arima NM46 (nVidia nForce Professional 3600 MCP (MCP55-Pro),
>>>>>>> <http://www.arima.com.tw/server/Product/ViewProduct.asp?View=NM46X>)
>>>>>>> словил что-то странное с сетью (встроенная в чипсет, работает через
>>>>>>> forcedeth): в какой то момент она перестала работать (ip статические, но
>>>>>>> пакеты в сеть не уходят/не принимаются). Вылечил только холодной, с
>>>>>>> физическим отключением питания, перезагрузкой (не выключая питание
>>>>>>> перегружался несколько раз -- не помогало).
>>>>>>   Т. к. проблема повторилась -- собрал
>>>>>> kernel-image-xen-dom0-2.6.18-alt2.1 (см.
>>>>>> <http://git.altlinux.ru/people/solo/packages/?p=kernel-image-2.6.18.git;a=commit;h=b164122b1a86bb92192637790910112b0d28fdc6>,
>>>>>> пакет отправлен в incoming/Daedalus) с патчами от lakostis@:
>>>>>>
>>>>>>   + fix-core--arch
>>>>   Применён в kernel-image-std-smp/2.6.18-alt8.
>>>>
>>>>>>   + fix-drivers-input
>>>>   От версии смерженной с kernel-image-std-smp/2.6.18-alt1 отличается
>>>> добавлением:
>>>>
>>>>     Input: i8042 - fix AUX port detection with some chips
>>>>
>>>>     The i8042 driver fails detection of the AUX port with some chips,
>>>>     because they apparently do not change the I8042_CTR_AUXDIS bit
>>>>     immediately. This is known to affect at least HP500/HP510 notebooks,
>>>>     consequently the built-in touchpad will not work. The patch will simply
>>>>     reread the value until it gets the expected value or a retry limit is
>>>>     hit, without touching other workaround code in the same area.
>>>>
>>>>     Signed-off-by: Roland Scheidegger <sroland@tungstengraphics.com>
>>>>     Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
>>>>     (cherry picked from commit d2ada5597d33a9108acb2caf912f85cbc9caab1e)
>>>>
>>>>>>   + fix-drivers-mmc--sdhci
>>>>   От версии смерженной с kernel-image-std-smp/2.6.18-alt6 отличается
>>>> добавлением 3х патчей.
>>>>>>   + fix-drivers-net--forcedeth
>>>>   То, ради чего всё и затеяно -- от содержимого 2.6.18 отличается весьма
>>>> сильно.
>>>>
>>>>>>   + fix-drivers-net--skge
>>>>   От содержимого 2.6.18 отличается весьма сильно.
>>>>
>>>>>>   + fix-drivers-net--tg3
>>>>   От того, что приложено к kernel-image-std-smp/2.6.18-alt4 отличаетя
>>>> весьма сильно.
>>>>
>>>>   Железка использующая данный драйвер у меня есть, и там тоже нужен XEN.
>>>> (На данный момент, с kernel-image-xen-dom0-2.6.18-alt2, у неё проблем нет.)
>>>>
>>>>>>   + fix-net--core
>>>>   От версии смерженной с kernel-image-std-smp/2.6.18-alt6 отличается
>>>> добавлением:
>>>>
>>>>     backport 2.6.20.y 0a0b0c6034b4cbffad5ea4cac33c683bd6c04777 commit:
>>>>
>>>>     [PATCH] NET: Fix race condition about network device name allocation.
>>>>
>>>>     Kenji Kaneshige found this race between device removal and
>>>>     registration.  On unregister it is possible for the old device to
>>>>     exist, because sysfs file is still open.  A new device with 'eth%d'
>>>>     will select the same name, but sysfs kobject register will fail.
>>>>
>>>>     The following changes the shutdown order slightly. It hold a removes
>>>>     the sysfs entries earlier (on unregister_netdevice), but holds a
>>>>     kobject reference.  Then when todo runs the actual last put free
>>>>     happens.
>>>>
>>>>     Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
>>>>     Signed-off-by: David S. Miller <davem@davemloft.net>
>>>>     [chrisw: backport to 2.6.20]
>>>>     Signed-off-by: Chris Wright <chrisw@sous-sol.org>
>>>>     Signed-off-by: Konstantin A. Lepikhov <lakostis@altlinux.ru>
>>>>     (cherry picked from commit 0a0b0c6034b4cbffad5ea4cac33c683bd6c04777)
>>>>
>>>>     Conflicts:
>>>>
>>>>     	net/core/dev.c
>>>>
>>>>>>   Насколько оно поможет пока не знаю: до железки доберусь завтра (в
>>>>>> смысле, сегодня утром).
>>>>>>
>>>>> Этих пачей нет у Власова? Если будет стабильно работать втяну себе.
>>>>> И если можно по подробнее про пачи особенно первый и последний.
>>>>   Большей частью есть, но более ранние версии бранчей (прокоментировал
>>>> выше).
>>>>
>>>>   Данная сборка оформлена как NMU, если проблем с ней не будет -- буду
>>>> просить разрешения на заливку в Сизиф.
>>>>
>>> Ясно. Может лучше я pull сделаю, а не ты NMU?
>>   Как тебе удобнее: ты мантейнер, а мне без особой разницы -- лишбы оно
>> работало. :-)
>>
> Ну значит так тому и быть. Только протестируй нормально.
> А на какой это архитектуре тестируется?

1. Hyperion ES360 G2 (см. <http://www.etegro.com/rus/items/77/2.html>),
на материнке Arima NM46 (nVidia nForce Professional 3600 MCP (MCP55-Pro),
<http://www.arima.com.tw/server/Product/ViewProduct.asp?View=NM46X>) --
здесь на текущем ядре (kernel-image-xen-dom0-2.6.18-alt2) проблема с
forcedeth.

2. Hyperion ES310 (см. <http://www.etegro.com/rus/items/13/2.html>) --
тут сеть на tg3 проблем (на kernel-image-xen-dom0-2.6.18-alt2) пока нет,
окромя перескока интерфейсов и отказывающегося работать при запуске xend
маршрутизации во внешнюю сеть...

3. Самосбор на ASUS M2A-VM (здесь мне мультимедия важна будет).

PS: Все -- x86_64.

-- 

С уважением. Алексей.