Кто-нибудь сталкивался с этим(<subj>) зверем? Хоть у кого-нибудь эта хрень работает? Если работает, то как завести?

Из моих бесплодных попыток его завести: если слегка пропатчить drivers/ata/ahci.c (соотв. PCI ID туда зашить), то ядро видит контроллер, определяет его свойства и видит 5 SATA линий. При попытке повесить на контроллер диски ядро матерится: мол теряю IRQ..., а потом наглухо виснет. Пробовал на 2.6.{19,20} - результат одинаковый, на 2.6.21rc3 не пробовал - боюсь, оно уж слишком экспериментальное.

Вчера экспериментировал с запросами к eeprom через i2c интерфейс
(eeprom.ko модуль и пакет lm_sensors) и обнаружил неприятную вещь:
при попытке опросить ееprom видеокарты (через decode-dimms.pl,
ddcmon и тому подобное) ядро выкидывает oops в nvidia драйвере,
версия: 9629. Иксы вешаются намертво, даже в консоль не
переключишься; однако если делать из консоли - консоль остается
живой. У меня большая просьба, ежли кто готов немного
поэкспериментировать со своей системой, не могли бы вы проверить
у себя поведение системы в подобных условиях и описать результаты
здесь?

> yum install lm_sensors
> modprobe eeprom
> decode-dimms.pl или > ddcmon

необходимые данные: дистр или версия ядра(лучше версия ядра),
версия драйвера, архитектура, тип CPU: количество ядер, поддержка ht.

у меня: FC6 без апдейтов, nvidia 9629, x86_64, CPU: 2 cores, no ht -
драйвер падает.

Если баг повторяется отправлю его nvidia, может пофиксят...

Доброго всем дня.

Подскажите пожалуйста, ежли кто знает, вменяемые средства по отлову
race conditions. hellgrind, по неизвестной мне причине, отсутствует в
составе valgrind в ubuntu 6/06.

Заранее спасибо.

P.S. Do not enforce me to google - я там уже был...

Всем доброго!

Есть задачка: запустить inotify на IQ31244 платформе.

Решается просто: берем ядро посвежее, ставим crosstools,
CONFIG_INOTIFY=y и компиляем - все хорошо.

Грузим ядро, монтирую root через NFS все поднимается, работает.
Видно, что inotify в ядре присутсвует, переменные в /proc/sys/fs/inotify
изменяются - все хорошо.

НО!

при попытке вызова 316-318 syscalls - ядро ругается, что данные
syscalls не определены. (sys_init_inotify, sys_inotify_add_watch,
sys_inotify_rm_watch ). Я - в прострации: это как может быть?
Смотрел в сорсы - там все определения есть, структуры на месте,
но не вызывается... вместо них вызывается заглушка возвращающая ENOSYS.

Может кто сталкивался? Хоть какие-нибудь идеи?

Всем доброго дня!

Обнаружил, что течет память при завершении потоков:

Далаем вот такой простой тест:
>>>>>>>>
#include <stdio.h>
#include <pthread.h>



void *thread( void* in )
{
        printf( "I'm running thread\n" );
        return NULL;
}


int main( void )
{
        pthread_t       tid, tid2;
        pthread_create( &tid, NULL, &thread, NULL );
        pthread_create( &tid2, NULL, &thread, NULL );

        /* wait until complete */
        pthread_join( tid, NULL );
        pthread_join( tid2, NULL );
        return 0;
}
<<<<<<<<
собранный: gcc test.c -o test -lpthread
и запущеный через valgrind --tool=memcheck  -v --leak-check=yes --show-reachable=yes  --leak-resolution=high

показывает потерю 136 байт (68 на поток). По стеку видно, что 
теряется TLS. 

Кто-нибудь сталкивался с этим? Является ли это багом libc или я не 
так завершаю поток?

libc: 2.3.6(fedora core 5), 2.3.5(ubuntu breezy)
P.S.
Если завершать через pthread_exit - потерей будет существенно больше :(.

http://sanchess.livejournal.com/1998103.html?page=1

Пока не разобрался в чем прикол - чуть удар не хватил.