[devel] I: kernel-image-xen-dom0-2.6.18-alt2.1 ушло в incoming/Daedalus (was: Arima NM46 на nVidia nForce Professional 3600 MCP (MCP55-Pro): что-то непонятное с сетью)

[devel] I: kernel-image-xen-dom0-2.6.18-alt2.1 ушло в incoming/Daedalus (was: Arima NM46 на nVidia nForce Professional 3600 MCP (MCP55-Pro): что-то непонятное с сетью)

[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
  + fix-drivers-input
  + fix-drivers-mmc--sdhci
  + fix-drivers-net--forcedeth
  + fix-drivers-net--skge
  + fix-drivers-net--tg3
  + fix-net--core

  Насколько оно поможет пока не знаю: до железки доберусь завтра (в
смысле, сегодня утром).

-- 

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

Re: [devel] I: kernel-image-xen-dom0-2.6.18-alt2.1 ушло в incoming/Daedalus

[Михаил Якушин]

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
>   + fix-drivers-input
>   + fix-drivers-mmc--sdhci
>   + fix-drivers-net--forcedeth
>   + fix-drivers-net--skge
>   + fix-drivers-net--tg3 
>   + fix-net--core
> 
>   Насколько оно поможет пока не знаю: до железки доберусь завтра (в
> смысле, сегодня утром).
> 
Этих пачей нет у Власова? Если будет стабильно работать втяну себе.
И если можно по подробнее про пачи особенно первый и последний.

[devel] (без темы)

[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, если проблем с ней не будет -- буду
просить разрешения на заливку в Сизиф.

-- 

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

Re: [devel] (без темы)

[Михаил Якушин]

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?

Re: [devel] (без темы)

[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?

  Как тебе удобнее: ты мантейнер, а мне без особой разницы -- лишбы оно
работало. :-)

-- 

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

Re: [devel] (без темы)

[Михаил Якушин]

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?
> 
>   Как тебе удобнее: ты мантейнер, а мне без особой разницы -- лишбы оно
> работало. :-)
> 
Ну значит так тому и быть. Только протестируй нормально.
А на какой это архитектуре тестируется?

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

[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.

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.

-- 

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

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

[Михаил Якушин]

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 тестить не
получается.

Re: [devel] I: XEN и NAT (was: kernel-image-xen-dom0-2.6.18-alt2.1)

[Aleksey Avdeev]

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

  Он самый! В какую сторону копать?

  По задачи -- могу внешний интерфейс полностью из бриджа вынести, но не
знаю как это делать гарантированно: простое отключение поднятия бриджа с
ним, на первый взгляд не помогло (но возможно перескок интерфейсов
сыграл роль)...

-- 

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

Re: [devel] I: XEN и NAT

[Михаил Якушин]

Aleksey Avdeev пишет:
> Михаил Якушин пишет:
>> Aleksey Avdeev пишет:
>>> Михаил Якушин пишет:
>>>> Aleksey Avdeev пишет:
> ...
>>> 2. Hyperion ES310 (см. <http://www.etegro.com/rus/items/13/2.html>) --
>>> тут сеть на tg3 проблем (на kernel-image-xen-dom0-2.6.18-alt2) пока нет,
>>> окромя перескока интерфейсов и отказывающегося работать при запуске xend
>>> маршрутизации во внешнюю сеть...
>> Маршрутизации? может NAT? Вообще NAT криво работает с бриджом. Думаю это
>> его вина.
> 
>   Он самый! В какую сторону копать?
> 
>   По задачи -- могу внешний интерфейс полностью из бриджа вынести, но не
> знаю как это делать гарантированно: простое отключение поднятия бриджа с
> ним, на первый взгляд не помогло (но возможно перескок интерфейсов
> сыграл роль)...
> 
Я не очень плотно рыл эту проблему. обычно решал выносом роутера в
виртуалку.
А так вопервых я не уверен какой интерефейс не должен быть в бридже.
Возможно оба. Но есть юз кейс когда в бридже нет SOURCE интрефеса и оно
работает.
Потом есть такая штука где-то в области
/proc/sys/net/bridge/bridge-nf-call-iptables.

Re: [devel] I: XEN и NAT

[Aleksey Avdeev]

Михаил Якушин пишет:
> Aleksey Avdeev пишет:
>> Михаил Якушин пишет:
>>> Aleksey Avdeev пишет:
>>>> Михаил Якушин пишет:
>>>>> Aleksey Avdeev пишет:
>> ...
>>>> 2. Hyperion ES310 (см. <http://www.etegro.com/rus/items/13/2.html>) --
>>>> тут сеть на tg3 проблем (на kernel-image-xen-dom0-2.6.18-alt2) пока нет,
>>>> окромя перескока интерфейсов и отказывающегося работать при запуске xend
>>>> маршрутизации во внешнюю сеть...
>>> Маршрутизации? может NAT? Вообще NAT криво работает с бриджом. Думаю это
>>> его вина.
>>   Он самый! В какую сторону копать?
>>
>>   По задачи -- могу внешний интерфейс полностью из бриджа вынести, но не
>> знаю как это делать гарантированно: простое отключение поднятия бриджа с
>> ним, на первый взгляд не помогло (но возможно перескок интерфейсов
>> сыграл роль)...
>>
> Я не очень плотно рыл эту проблему. обычно решал выносом роутера в
> виртуалку.

  Т. е. -- роутер в domU?

  На доли, в таком случаи вешать IP на интерфейс смотрящий в wan? (У
меня только 1 внешний IP, или имеет смысл пробросить в domU PCI карточку?)

> А так вопервых я не уверен какой интерефейс не должен быть в бридже.

  wan.

> Возможно оба. Но есть юз кейс когда в бридже нет SOURCE интрефеса и оно
> работает.

  У меня так:

1. wan -- сдесь NAT. Вполне могу этот интерфейс в бриджи не запихивать
(сейчас это тестирую).

2. lan -- его хорошо бы иметь в бридже: будут весеть такие вещи как DHCP
и samba (+ всё остальное).

3. dmz -- прямая связь железок. Планирую пихнуть во второй бридж...

> Потом есть такая штука где-то в области
> /proc/sys/net/bridge/bridge-nf-call-iptables.

  OK, гляну.

-- 

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

Re: [devel] I: XEN и NAT

[Михаил Якушин]

Aleksey Avdeev пишет:
> Михаил Якушин пишет:
>> Aleksey Avdeev пишет:
>>> Михаил Якушин пишет:
>>>> Aleksey Avdeev пишет:
>>>>> Михаил Якушин пишет:
>>>>>> Aleksey Avdeev пишет:
>>> ...
>>>>> 2. Hyperion ES310 (см. <http://www.etegro.com/rus/items/13/2.html>) --
>>>>> тут сеть на tg3 проблем (на kernel-image-xen-dom0-2.6.18-alt2) пока нет,
>>>>> окромя перескока интерфейсов и отказывающегося работать при запуске xend
>>>>> маршрутизации во внешнюю сеть...
>>>> Маршрутизации? может NAT? Вообще NAT криво работает с бриджом. Думаю это
>>>> его вина.
>>>   Он самый! В какую сторону копать?
>>>
>>>   По задачи -- могу внешний интерфейс полностью из бриджа вынести, но не
>>> знаю как это делать гарантированно: простое отключение поднятия бриджа с
>>> ним, на первый взгляд не помогло (но возможно перескок интерфейсов
>>> сыграл роль)...
>>>
>> Я не очень плотно рыл эту проблему. обычно решал выносом роутера в
>> виртуалку.
> 
>   Т. е. -- роутер в domU?
> 
>   На доли, в таком случаи вешать IP на интерфейс смотрящий в wan? (У
> меня только 1 внешний IP, или имеет смысл пробросить в domU PCI карточку?)
> 
можно и так и так. если карточка нормально работает с прокидкой PCI то
так имхо лучше.

>> А так вопервых я не уверен какой интерефейс не должен быть в бридже.
> 
>   wan.
> 
>> Возможно оба. Но есть юз кейс когда в бридже нет SOURCE интрефеса и оно
>> работает.
> 
>   У меня так:
> 
> 1. wan -- сдесь NAT. Вполне могу этот интерфейс в бриджи не запихивать
> (сейчас это тестирую).
> 
> 2. lan -- его хорошо бы иметь в бридже: будут весеть такие вещи как DHCP
> и samba (+ всё остальное).
> 
> 3. dmz -- прямая связь железок. Планирую пихнуть во второй бридж...
> 
Так видимо не будет работать.
>> Потом есть такая штука где-то в области
>> /proc/sys/net/bridge/bridge-nf-call-iptables.
> 
>   OK, гляну.
> 

Re: [devel] I: XEN и NAT

[Aleksey Avdeev]

Михаил Якушин пишет:
> Aleksey Avdeev пишет:
>> Михаил Якушин пишет:
>>> Aleksey Avdeev пишет:
>>>> Михаил Якушин пишет:
>>>>> Aleksey Avdeev пишет:
>>>>>> Михаил Якушин пишет:
>>>>>>> Aleksey Avdeev пишет:
>>>> ...
>>>>>> 2. Hyperion ES310 (см. <http://www.etegro.com/rus/items/13/2.html>) --
>>>>>> тут сеть на tg3 проблем (на kernel-image-xen-dom0-2.6.18-alt2) пока нет,
>>>>>> окромя перескока интерфейсов и отказывающегося работать при запуске xend
>>>>>> маршрутизации во внешнюю сеть...
>>>>> Маршрутизации? может NAT? Вообще NAT криво работает с бриджом. Думаю это
>>>>> его вина.
>>>>   Он самый! В какую сторону копать?
>>>>
>>>>   По задачи -- могу внешний интерфейс полностью из бриджа вынести, но не
>>>> знаю как это делать гарантированно: простое отключение поднятия бриджа с
>>>> ним, на первый взгляд не помогло (но возможно перескок интерфейсов
>>>> сыграл роль)...
>>>>
>>> Я не очень плотно рыл эту проблему. обычно решал выносом роутера в
>>> виртуалку.
>>   Т. е. -- роутер в domU?
>>
>>   На доли, в таком случаи вешать IP на интерфейс смотрящий в wan? (У
>> меня только 1 внешний IP, или имеет смысл пробросить в domU PCI карточку?)
>>
> можно и так и так. если карточка нормально работает с прокидкой PCI то
> так имхо лучше.

  Карточка работает через tg3, а у нас ядра для domU (в Сервер 4.0)
старые... Попробую без прокидки карточки...

> 
>>> А так вопервых я не уверен какой интерефейс не должен быть в бридже.
>>   wan.
>>
>>> Возможно оба. Но есть юз кейс когда в бридже нет SOURCE интрефеса и оно
>>> работает.
>>   У меня так:
>>
>> 1. wan -- сдесь NAT. Вполне могу этот интерфейс в бриджи не запихивать
>> (сейчас это тестирую).
>>
>> 2. lan -- его хорошо бы иметь в бридже: будут весеть такие вещи как DHCP
>> и samba (+ всё остальное).
>>
>> 3. dmz -- прямая связь железок. Планирую пихнуть во второй бридж...
>>
> Так видимо не будет работать.

  И не работает...

-- 

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

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

[Aleksey Avdeev]

Михаил Якушин пишет:
> Aleksey Avdeev пишет:
>> Михаил Якушин пишет:
>>> Aleksey Avdeev пишет:
>>>> Михаил Якушин пишет:
...
>>>>> Ясно. Может лучше я 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

  Где? (В git, есть?)

>> 3. Самосбор на ASUS M2A-VM (здесь мне мультимедия важна будет).
>>
>> PS: Все -- x86_64.
>>
> 
> ясно у меня просто тоже везде x86_64. поэтому нормально i586 тестить не
> получается.

  Если с этими получится -- буду один хост с i586 (без аппаратной
виртуализации) под XEN переводить. Но там мне domU с OVZ потребуется...
(Подробности вечером, если нужно.)

-- 

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

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

[Михаил Якушин]

Aleksey Avdeev пишет:
> Михаил Якушин пишет:
>> Aleksey Avdeev пишет:
>>> Михаил Якушин пишет:
>>>> Aleksey Avdeev пишет:
>>>>> Михаил Якушин пишет:
> ...
>>>>>> Ясно. Может лучше я 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
> 
>   Где? (В git, есть?)
В сизифе точно есть. похоже я забыл сделать push
> 
>>> 3. Самосбор на ASUS M2A-VM (здесь мне мультимедия важна будет).
>>>
>>> PS: Все -- x86_64.
>>>
>> ясно у меня просто тоже везде x86_64. поэтому нормально i586 тестить не
>> получается.
> 
>   Если с этими получится -- буду один хост с i586 (без аппаратной
> виртуализации) под XEN переводить. Но там мне domU с OVZ потребуется...
> (Подробности вечером, если нужно.)
> 

круто. domU+ovz давно хотел потестить.

Re: [devel] I: kernel-image-xen-dom0-2.6.18-alt3

[Aleksey Avdeev]

Михаил Якушин пишет:
...
> Кстати есть alt3. под xen 3.1.1

  Обновил git -- нашёл.

  Можно попросить теги расставит? А то искать сложно...

-- 

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

Re: [devel] I: kernel-image-xen-dom0-2.6.18-alt3

[Михаил Якушин]

Aleksey Avdeev пишет:
> Михаил Якушин пишет:
> ...
>> Кстати есть alt3. под xen 3.1.1
> 
>   Обновил git -- нашёл.
> 
>   Можно попросить теги расставит? А то искать сложно...
> 
расставил как смог...

Re: [devel] I: kernel-image-xen-dom0-2.6.18-alt3

[Aleksey Avdeev]

Михаил Якушин пишет:
> Aleksey Avdeev пишет:
>> Михаил Якушин пишет:
>> ...
>>> Кстати есть alt3. под xen 3.1.1
>>   Обновил git -- нашёл.
>>
>>   Можно попросить теги расставит? А то искать сложно...
>>
> расставил как смог...

  Спасибо. Структура стала значительно виднее (gitk теги и бранчи
выделяет явным образом).

  Из просмотра репозитария сложилось впечатление, что cluster patch и
xen patch`и стоит оформить как как и остальные feat-*... Сделать?

-- 

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

Re: [devel] I: kernel-image-xen-dom0-2.6.18-alt3

[Михаил Якушин]

Aleksey Avdeev пишет:
> Михаил Якушин пишет:
>> Aleksey Avdeev пишет:
>>> Михаил Якушин пишет:
>>> ...
>>>> Кстати есть alt3. под xen 3.1.1
>>>   Обновил git -- нашёл.
>>>
>>>   Можно попросить теги расставит? А то искать сложно...
>>>
>> расставил как смог...
> 
>   Спасибо. Структура стала значительно виднее (gitk теги и бранчи
> выделяет явным образом).
> 
>   Из просмотра репозитария сложилось впечатление, что cluster patch и
> xen patch`и стоит оформить как как и остальные feat-*... Сделать?
Я лучше сам тогда бранчами сделаю

Re: [devel] Просьба

[Epiphanov Sergei]

<cut>

Просьба цитировать по существу, а то за деревьями не видно леса.

-- 
С уважением, Епифанов Сергей

Re: [devel] U: kernel-image-xen-dom0-2.6.18-alt2.1 fix %changelog

[Aleksey Avdeev]

Igor Zubkov пишет:
> 2007/11/6, Aleksey Avdeev <solo@>:
>>   Т. к. проблема повторилась -- собрал
>> kernel-image-xen-dom0-2.6.18-alt2.1 (см.
> 
> https://bugzilla.altlinux.org/show_bug.cgi?id=12221
> 
> p.s.: а ты в CC есть... :-/

  Забыл, как и про #13187... :-(

  В git %changelog поправил (тег 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=80b4c243df0933c9103bb46f4069705dcf074c5a>).
В incoming/Daedalus залью после пересборки в haser`е...

-- 

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

Re: [devel] [d-kernel] U: kernel-image-xen-dom0-2.6.18-alt2.1 fix %changelog

[Aleksey Avdeev]

Aleksey Avdeev пишет:
> Igor Zubkov пишет:
>> 2007/11/6, Aleksey Avdeev <solo@>:
>>>   Т. к. проблема повторилась -- собрал
>>> kernel-image-xen-dom0-2.6.18-alt2.1 (см.
>> https://bugzilla.altlinux.org/show_bug.cgi?id=12221
>>
>> p.s.: а ты в CC есть... :-/
> 
>   Забыл, как и про #13187... :-(
> 
>   В git %changelog поправил (тег 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=80b4c243df0933c9103bb46f4069705dcf074c5a>).
> В incoming/Daedalus залью после пересборки в haser`е...

  В incoming/Daedalus пере залил.

-- 

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

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

[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
>   + fix-drivers-input
>   + fix-drivers-mmc--sdhci
>   + fix-drivers-net--forcedeth
>   + fix-drivers-net--skge
>   + fix-drivers-net--tg3
>   + fix-net--core
> 
>   Насколько оно поможет пока не знаю: до железки доберусь завтра (в
> смысле, сегодня утром).
> 

  Первые результаты:

  Горячая перезагрузка с новым (kernel-image-xen-dom0-2.6.18-alt2.1)
ядром сетевые интерфейсы из каматоза не вывела. Холодная перезагрузка
помогла.

  Буду смотреть, что дальше...

-- 

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

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

[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
>>   + fix-drivers-input
>>   + fix-drivers-mmc--sdhci
>>   + fix-drivers-net--forcedeth
>>   + fix-drivers-net--skge
>>   + fix-drivers-net--tg3
>>   + fix-net--core
>>
>>   Насколько оно поможет пока не знаю: до железки доберусь завтра (в
>> смысле, сегодня утром).
>>
> 
>   Первые результаты:
> 
>   Горячая перезагрузка с новым (kernel-image-xen-dom0-2.6.18-alt2.1)
> ядром сетевые интерфейсы из каматоза не вывела. Холодная перезагрузка
> помогла.
> 
>   Буду смотреть, что дальше...

  Ситуация повторилась...

  Из путей, вижу только:

1. Обновление BIOS.

2. Переход на более свежее ядро. (Эх... Придётся впереди паровоза бежать...)

3. Замена самой железки.

-- 

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

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

[Михаил Якушин]

Aleksey Avdeev пишет:
...
>   Ситуация повторилась...
> 
>   Из путей, вижу только:
> 
> 1. Обновление BIOS.
> 
Иногда помогает
> 2. Переход на более свежее ядро. (Эх... Придётся впереди паровоза бежать...)
> 
Ксатати в 23м ванильном появлися xen но только i586 и только domU
> 3. Замена самой железки.
> 
Радикально но эффективно

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

[Aleksey Avdeev]

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

Михаил Якушин пишет:
> Aleksey Avdeev пишет:
> ...
>>   Ситуация повторилась...
>>
>>   Из путей, вижу только:
>>
>> 1. Обновление BIOS.
>>
> Иногда помогает

  Завтра буду пробовать.

>> 2. Переход на более свежее ядро. (Эх... Придётся впереди паровоза бежать...)
>>
> Ксатати в 23м ванильном появлися xen но только i586 и только domU

  Хуже другое: на
<http://xenbits.xensource.com/xen-3.1-testing.hg?file/38adb57319a7/patches/>
патчи только на 2.6.18 вижу... Если их (патчей для dom0) для болие
свежих ядер нет на kernel.org -- данный путь придётся оставить...

>> 3. Замена самой железки.
>>
> Радикально но эффективно

  Ещё думается вариант отказа от использования набортной сети (но он 2х
портовку потребует).

-- 

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 481 bytes --]

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

[Михаил Якушин]

Aleksey Avdeev пишет:
> Михаил Якушин пишет:
>> Aleksey Avdeev пишет:
>> ...
>>>   Ситуация повторилась...
>>>
>>>   Из путей, вижу только:
[skip]

>>> 2. Переход на более свежее ядро. (Эх... Придётся впереди паровоза бежать...)
>>>
>> Ксатати в 23м ванильном появлися xen но только i586 и только domU
> 
>   Хуже другое: на
> <http://xenbits.xensource.com/xen-3.1-testing.hg?file/38adb57319a7/patches/>
> патчи только на 2.6.18 вижу... Если их (патчей для dom0) для болие
> свежих ядер нет на kernel.org -- данный путь придётся оставить...
> 
есть xenовские пачи но они они только на 18е. и есть в 23м но см выше.
>>> 3. Замена самой железки.
>>>
>> Радикально но эффективно
> 
>   Ещё думается вариант отказа от использования набортной сети (но он 2х
> портовку потребует).
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

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

[Aleksey Avdeev]

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

Михаил Якушин пишет:
> Aleksey Avdeev пишет:
>> Михаил Якушин пишет:
>>> Aleksey Avdeev пишет:
>>> ...
>>>>   Ситуация повторилась...
>>>>
>>>>   Из путей, вижу только:
> [skip]
> 
>>>> 2. Переход на более свежее ядро. (Эх... Придётся впереди паровоза бежать...)
>>>>
>>> Ксатати в 23м ванильном появлися xen но только i586 и только domU
>>   Хуже другое: на
>> <http://xenbits.xensource.com/xen-3.1-testing.hg?file/38adb57319a7/patches/>
>> патчи только на 2.6.18 вижу... Если их (патчей для dom0) для болие
>> свежих ядер нет на kernel.org -- данный путь придётся оставить...
>>
> есть xenовские пачи но они они только на 18е. и есть в 23м но см выше.

  Нашёл <git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git>,
но неисключено, что это есть domU для 23его... (Детально я не разбирался.)

-- 

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 481 bytes --]