[sisyphus] kernel 2.6.14 reload

[sisyphus] kernel 2.6.14 reload

[Artem]

Здравствуйте!

Обновил kernel. (was 2.6.12)

1)  При shutdown -r  или ctrl-alt-del - система делает kill, unmount,
доходит до стадии reset - и на этом все заканчивается (с однократным
миганием светодиодов клавиатуры - как будто "вот-вот перегазрузится").
Все дело "висит" и окончательно перезапустить систему можно только ее
полным выключением.  Ноутбук hp nx6110.  Пересборкой с
оптимизацией-конфигурированием  еще не занимался - никто не подскажет,
куда сразу заглянуть по этому поводу?

2) Сборка kernel-modules-slmodem-std26-up-2.9.10-alt4.132622.2 .  При
insmod полученных slamr и slusb - ругань на unresolved symbols:

class_simple_device_add
class_simple_destroy
class_simple_device_remove
class_simple_create

исправления в виде патча - в bugzilla.  # 8648  ;-)
также имеется # 8457 (патч) на тему поддержки в slamr чипсетов ICH6 и ICH7

Из хорошего:
1) cущественно улучшилось качество совместной работы vesafb и  xorg+dri 
. Проблемы с insmod b44 при vesafb - также отсутствуют.

2) время запуска системы в runlevel 3 сократилось на треть ( 57 сек - 
2.6.14 против 90 сек. - 2.6.12 ), сервисы заметно быстрее стартуют.


Rgds, Artem.

Re: [sisyphus] kernel 2.6.14-alt is a good choice to die...

[Nick Fedchik]

В сообщении от Wednesday 14 December 2005 21:21 Artem написал(a):
> Здравствуйте!
> Обновил kernel. (was 2.6.12)
> Из хорошего:
... у меня ничего из хорошего
зато плохое
при загрузке ядрышко помирает с рыданием:
EIP is at scsi_run_queue
Call trace
	scsi_end_request
ну и остальное бла-бла-бла

Мать Intel 915, сказёв нема, один винт SATA 120

-- 
Best Regards, Nick Fedchik
Atlantic Link Ltd.

Re: [sisyphus] kernel 2.6.14-alt is a good choice to die...

[Valery V. Inozemtsev]

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

В сообщении от 15 Декабрь 2005 11:42 Nick Fedchik написал(a):
> В сообщении от Wednesday 14 December 2005 21:21 Artem написал(a):
> > Здравствуйте!
> > Обновил kernel. (was 2.6.12)
> > Из хорошего:
>
> ... у меня ничего из хорошего
> зато плохое
> при загрузке ядрышко помирает с рыданием:
> EIP is at scsi_run_queue
> Call trace
> 	scsi_end_request
> ну и остальное бла-бла-бла
>
> Мать Intel 915, сказёв нема, один винт SATA 120

у меня на i865 с сата такое разок было

-- 
Valery V. Inozemtsev

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

Re: [sisyphus] kernel 2.6.14-alt is a good choice to die...

[Nick Fedchik]

В сообщении от Thursday 15 December 2005 10:42 Nick Fedchik написал(a):
> при загрузке ядрышко помирает с рыданием:
> EIP is at scsi_run_queue
> Call trace
> 	scsi_end_request
> ну и остальное бла-бла-бла
> Мать Intel 915, сказёв нема, один винт SATA 120
Добавлю что ядро -smp
1 шт. Intel(R) Pentium(R) 4 CPU 3.00GHz
IDE interface: Intel Corporation 82801FB/FW (ICH6/ICH6W) SATA Controller
Пробовал ваниллу 2.6.14.2 - работа без указанной проблемы

-- 
Best Regards, Nick Fedchik
Atlantic Link Ltd.

Re: [sisyphus] kernel 2.6.14 reload

[Artem]

Artem wrote:
> Здравствуйте!
> 
> Обновил kernel. (was 2.6.12)
> 
> 1)  При shutdown -r  или ctrl-alt-del - система делает kill, unmount,
> доходит до стадии reset - и на этом все заканчивается (с однократным
> миганием светодиодов клавиатуры - как будто "вот-вот перегазрузится").
> Все дело "висит" и окончательно перезапустить систему можно только ее
> полным выключением.  Ноутбук hp nx6110.  Пересборкой с
> оптимизацией-конфигурированием  еще не занимался - никто не подскажет,
> куда сразу заглянуть по этому поводу?
> 
C этим уже разобрался: необходимо добавить  reboot=b к параметрам 
загрузки kernel-a (в 2.6.12 подобные настройки делались внутри ядра, а 
теперь их убрали)

> 2) время запуска системы в runlevel 3 сократилось на треть ( 57 сек - 
> 2.6.14 против 90 сек. - 2.6.12 ), сервисы заметно быстрее стартуют.
> 
И с этим разобрался. 2.6.12 у меня был собран с CONFIG_PREEMPT. Если и 
2.6.14 собрать с _этим_ - время загрузки так же на треть увеличивается.


Rgds, Artem.

[sisyphus] Re: kernel 2.6.14 reload

[Konstantin A. Lepikhov]

<цитата от="Artem">
<skip>
>> 2) время запуска системы в runlevel 3 сократилось на треть ( 57 сек -
>> 2.6.14 против 90 сек. - 2.6.12 ), сервисы заметно быстрее стартуют.
>>
> И с этим разобрался. 2.6.12 у меня был собран с CONFIG_PREEMPT. Если и
> 2.6.14 собрать с _этим_ - время загрузки так же на треть увеличивается.
странно. для wks26 это дает совсем обратный результат (т.е. вполне для
PREEMPT  предсказуемый).

-- 
WBR et al.

Re: [sisyphus] Re: kernel 2.6.14 reload

[Sviataslau Svirydau]

Konstantin A. Lepikhov wrote on 12/15/2005 5:22 PM:
> <skip>
>   
> странно. для wks26 это дает совсем обратный результат (т.е. вполне для
> PREEMPT  предсказуемый).
>   
Кстати, а когда можно ожидать wks26-2.6.14 в сизифе?

-- 
Best Regards,
Sviatoslav Sviridov

[sisyphus] Re: kernel 2.6.14 reload

[Konstantin A. Lepikhov]

<цитата от="Sviataslau Svirydau">
> Konstantin A. Lepikhov wrote on 12/15/2005 5:22 PM:
>> <skip>
>>
>> странно. для wks26 это дает совсем обратный результат (т.е. вполне для
>> PREEMPT  предсказуемый).
>>
> Кстати, а когда можно ожидать wks26-2.6.14 в сизифе?
скоро :) особо нетерпеливые могут забрать, то, что лежит сейчас в kernel cvs.


-- 
WBR et al.

Re: [sisyphus] Re: kernel 2.6.14 reload

[Sergey Vlasov]

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

On Thu, Dec 15, 2005 at 06:22:01PM +0300, Konstantin A. Lepikhov wrote:
> 
> <цитата от="Artem">
> <skip>
> >> 2) время запуска системы в runlevel 3 сократилось на треть ( 57 сек -
> >> 2.6.14 против 90 сек. - 2.6.12 ), сервисы заметно быстрее стартуют.
> >>
> > И с этим разобрался. 2.6.12 у меня был собран с CONFIG_PREEMPT. Если и
> > 2.6.14 собрать с _этим_ - время загрузки так же на треть увеличивается.
> странно. для wks26 это дает совсем обратный результат (т.е. вполне для
> PREEMPT  предсказуемый).

Этот эффект наблюдается уже давно - как минимум, начиная с 2.6.11
(хотя замедление от CONFIG_PREEMPT было и раньше, но не до такой
степени).  Похоже, стандартный scheduler в комбинации с CONFIG_PREEMPT
ведёт себя плохо.  В wks26 используется staircase scheduler от Con
Kolivas, у которого таких проблем не наблюдается.

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

[sisyphus] Re: kernel 2.6.14 reload

[Konstantin A. Lepikhov]

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

Hi Sergey!

Thursday 15, at 07:10:51 PM you wrote:

> Этот эффект наблюдается уже давно - как минимум, начиная с 2.6.11
> (хотя замедление от CONFIG_PREEMPT было и раньше, но не до такой
> степени).  Похоже, стандартный scheduler в комбинации с CONFIG_PREEMPT
> ведёт себя плохо.  В wks26 используется staircase scheduler от Con
> Kolivas, у которого таких проблем не наблюдается.
хех, ну я std26 уже давно не юзаю, может поэтому и не заметил :) Кстати,
насчет шедулеров - тогда уж если действительно PREEMPT, тогда надо ll26 -
там переколбашен и он и вся работа с блокировками и прерываниями. Впрочем,
ll26 уже почти готов для Сизифа.

PS Сейчас все мои ядра будут тестироваться и собираться для 2х архитектур
- i586 и x86_64, так что процесс их выкладывания в Сизиф будет довольно
  длительным. Поэтому, кому очень хочется тестировать новые рюшки и фишки,
  то он может собирать их самостоятельно из kernel cvs. Также туда будут
  выкладываться такие полезные вещи как readahead патч и dyntick патч, но
  только в виде отдельных -feat, т.к. их использование предполагает
  знакомство пользователя с теорией их работы и всеми граблями, которые
  они порождают.

-- 
WBR, Konstantin	      chat with ==>ICQ: 109916175
     Lepikhov,	      speak  to ==>JID: lakostis@jabber.org
aka L.A. Kostis       write  to ==>mailto:lakostis@pisem.net.nospam

...The information is like the bank... 			  (c) EC8OR

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

[sisyphus] Re: kernel 2.6.14 reload

[Arioch]

Konstantin A. Lepikhov пишет:

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

Вот бы эту теориюю опакетить вместе с патчами, чтобы 
поставил/почитал/ужаснулся/снес :)

[sisyphus] Re: kernel 2.6.14 reload

[Konstantin A. Lepikhov]

Hi Arioch!

Sunday 18, at 05:37:30 PM you wrote:

> Konstantin A. Lepikhov пишет:
> 
> >  только в виде отдельных -feat, т.к. их использование предполагает
> >  знакомство пользователя с теорией их работы и всеми граблями, которые
> >  они порождают.
> 
> Вот бы эту теориюю опакетить вместе с патчами, чтобы 
> поставил/почитал/ужаснулся/снес :)
архивы -ck-devel? :)

-- 
WBR, Konstantin	      chat with ==>ICQ: 109916175
     Lepikhov,	      speak  to ==>JID: lakostis@jabber.org
aka L.A. Kostis       write  to ==>mailto:lakostis@pisem.net.nospam

...The information is like the bank... 			  (c) EC8OR

Re: [sisyphus] Re: kernel 2.6.14 reload

[Artem]

Sergey Vlasov wrote:
> On Thu, Dec 15, 2005 at 06:22:01PM +0300, Konstantin A. Lepikhov wrote:
> 
>><цитата от="Artem">
>><skip>
>>
>>>>2) время запуска системы в runlevel 3 сократилось на треть ( 57 сек -
>>>>2.6.14 против 90 сек. - 2.6.12 ), сервисы заметно быстрее стартуют.
>>>>
>>>
>>>И с этим разобрался. 2.6.12 у меня был собран с CONFIG_PREEMPT. Если и
>>>2.6.14 собрать с _этим_ - время загрузки так же на треть увеличивается.
>>
>>странно. для wks26 это дает совсем обратный результат (т.е. вполне для
>>PREEMPT  предсказуемый).
> 
> 
> Этот эффект наблюдается уже давно - как минимум, начиная с 2.6.11
> (хотя замедление от CONFIG_PREEMPT было и раньше, но не до такой
> степени).  Похоже, стандартный scheduler в комбинации с CONFIG_PREEMPT
> ведёт себя плохо.  В wks26 используется staircase scheduler от Con
> Kolivas, у которого таких проблем не наблюдается.
> 
Собрал wks из cvs - совершенно верно. В нем с CONFIG_PREEMPT время 
загрузки - 53 сек. vs 57 сек без CONFIG_PREEMPT на std26


Rgds, Artem.

Re: [sisyphus] Re: kernel 2.6.14 reload

[Andrey Rahmatullin]

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

On Thu, Dec 15, 2005 at 06:22:01PM +0300, Konstantin A. Lepikhov wrote:
> странно. для wks26 это дает совсем обратный результат (т.е. вполне для
> PREEMPT  предсказуемый).
Кем предсказуемый?
vsu говорил, что preempt увеличивает скорость отклика и уменьшает скорость
работы.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

JFYI, до сих пор для security team вся линейка mozilla-based браузеров
интереса не представляла, и я не виду причин к изменению ситуации. :(
		-- ldv in devel@

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

Re: [sisyphus] kernel 2.6.14 reload

[Andrey Rahmatullin]

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

On Thu, Dec 15, 2005 at 01:03:30PM +0200, Artem wrote:
> И с этим разобрался. 2.6.12 у меня был собран с CONFIG_PREEMPT. Если и 
> 2.6.14 собрать с _этим_ - время загрузки так же на треть увеличивается.
Угу...
Было дело.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

Благие пожелания к `rpmquery -f /etc/chroot.d/functions` приветствуются
в случае занесения оных в BTS.
		-- ldv in community@

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