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

["Михаил Якушин" <silicium@altlinux.ru>]

Aleksey Avdeev пишет:
> Михаил Якушин пишет:
>> 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.
Кстати есть alt3. под xen 3.1.1
> 
> 2. Hyperion ES310 (см. <http://www.etegro.com/rus/items/13/2.html>) --
> тут сеть на tg3 проблем (на kernel-image-xen-dom0-2.6.18-alt2) пока нет,
> окромя перескока интерфейсов и отказывающегося работать при запуске xend
> маршрутизации во внешнюю сеть...
Маршрутизации? может NAT? Вообще NAT криво работает с бриджом. Думаю это
его вина.
> 
> 3. Самосбор на ASUS M2A-VM (здесь мне мультимедия важна будет).
> 
> PS: Все -- x86_64.
> 

ясно у меня просто тоже везде x86_64. поэтому нормально i586 тестить не
получается.