On Mon, Oct 23, 2000 at 02:38:01AM +0400, Dmitry V. Levin wrote:
> Чего только не бывает с новыми ядрами.
> Я уже было обрадовался, что ipl3mdk прошло все тесты, VM больше X не
> сносит, и прочие радости жизни.
> 
> Однако вдруг неожиданно выяснилось, что ядро это загружается с
> вероятностью около 30% (данные получены по результатам десятка загрузок).
> Т.е оно нормально загружается вплоть до запуска init.
> Дальше, вне зависимости от того, какой именно init запускается (я проверял
> /sbin/init и /sbin/sash), система виснет; не всегда, и если виснет, то не
> мгновенно, с задержкой вплоть до 1-2 секунд. Виснет не наглухо, SysRq
> работает (в частности, показывает, что init запущен), а вот сам init
> стоит, и Shift-PgUp тоже не отзывается).
> 
> Сталкивался ли кто-нибудь с подобным, известны ли методы поиска
> неисправностей подобного плана?

Проблема была локализована и решена; грех будет не поделиться опытом:

1. Локализация проявления неисправности.
  В данном случае это было очевидно, ибо происходило в одном и том же
  месте.

2. Локализация участка кода, приводящего к неисправности.
  Здесь мы имеем классический пример, где удается применить элементарную
  арифметику. :)
  Итак, в пакете ядра мы имеем 12 tarball'ов и около 200 (на данный момент
  203) патча. Применяем метод половинного деления: отбрасываем половину
  патчей, собираем ядро и проверяем наличие неисправности. В зависимости
  от результата, оставляем ту или иную половину, с оставшейся половиной
  проделываем аналогичную операцию, и т.д. В идеале получается, что за
  ln(203)/ln(2)=8 попыток "неправильный патч" локализуется. К сожалению, в
  реальной ситуации строго половинное деление патчей не удается, ибо
  многие патчи (более или менее) тесно взаимосвязаны. Кроме того, удаление
  некоторых патчей зачастую приводит к необходимости модифицировать
  оставшиеся. Тем не менее, если запастись терпением (несколько дней
  пересобирать ядро), удается локализовать "неправильный(е) патч(и)".

3. Поиск и устранение неисправности.
  Здесь все как обычно. Чем меньше кода приходится смотреть, тем быстрее
  будет получен результат.

Что касается данной конкретной ошибки, то мне совершенно непонятно,
как в Mandrake 7.2 ядро будет работать, ибо она там не исправлена, и,
возможно, не проявляется по случайному стечению байтов.


Итак, ядро готово и протестировано на localhost'е, после сборки и
тестирования на photo пакеты будут залиты на ftp, после чего я напишу
анонс. Как я уже говорил, помимо ядра залиты будут также
glibc-2.1.95-ipl2mdk, strace-4.2-ipl3mdk, lvm-0.8final-ipl1mdk.
Для тех, кто готов начать тестирование уже сейчас, я выложил
ftp://ftp.logic.ru/pub/logic/linux/mandrake70re/devel/SRPMS/kernel-2.2.17-ipl3mdk.nosrc.rpm

Для него дополнительно потребуются:
ftp://ftp.kernel.org/pub/linux/kernel/v2.2/linux-2.2.17.tar.bz2
ftp://sourceforge.org/pcmcia/pcmcia-cs-3.1.21.tar.bz2
ftp://tsx-11.mit.edu/pub/linux/BETA/ibcs2/ibcs-2.1-981105.tar.bz2
README.kernel-sources
ftp://ftp.ocs.com.au/pub/ksymoops/ksymoops-2.3.4.tar.bz2
ftp://ftp.alsa-project.org/pub/driver/alsa-driver-0.5.9d.tar.bz2
ftp://opensource.creative.com/pub/snapshots/emu10k1-20001025.tar.bz2

Не все они на самом деле .bz2, некоторые в оригинале только .gz;
кроме того, linux-2.2.17.tar.bz2, ibcs-2.1-981105.tar.bz2,
README.kernel-sources, ksymoops-2.3.4.tar.bz2 не изменились по сравнению с
kernel-2.2.17-ipl2mdk.


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@fandra.org
Software Engineer   PGP pubkey http://www.fandra.org/users/ldv/pgpkeys.html
IPLabs Linux Team   http://linux.iplabs.ru
Fandra Project      http://www.fandra.org
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who it's friends are.