Re: [d-kernel] rtlinux package

[Sergey Vlasov <vsu@altlinux.ru>]

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

On Fri, Jan 02, 2004 at 10:26:57PM +0300, Evgeny Sinelnikov wrote:
> Тест памяти (memtest-3.0) ошибок не выявил. Хотя это и было на 192М вместо
> 256М (поражаюсь вашей прозорливостью - с утра машина не загрузилась в
> положенные 256Мб указанные параметром ядра, BIOS, как и memtest, не
> досчитались 64Мб; кстати это уже второй случай, до последнего времени я
> грешил на перебои с питанием, теперь даже не знаю, что и думать, хотя
> напряжение  в сети, в последние дни, тоже оставляло желать лучшего).

А по какой причине был добавлен параметр mem=...?  Ситуации, когда
автоматическое определение объёма памяти не работает, сейчас
встречаются крайне редко.

Вообще симптомы весьма нехорошие...

> Попытка включить CONFIG_DEBUG_SLAB дала следующий результат:
> 
> - ----------------------------------------------------------------------------
> ksymoops 2.4.9 on i686 2.4.22-rts4-up-alt13.  Options used
>      -v /usr/src/RPM/BUILD/kernel-image-rts4-up-2.4.22-alt13/kernel-source-2.4.22/vmlinux (specified)
>      -k /proc/ksyms (default)
>      -l /proc/modules (default)
>      -o /lib/modules/2.4.22-rts4-up-alt13/ (default)
>      -m /boot/System.map-2.4.22-rts4-up-alt13 (default)
> 
> Warning (compare_ksyms_lsmod): module reiserfs is in lsmod but not in ksyms, probably no symbols exported
> CPU:    0
> EIP:    0010:[<c01150b9>]    Not Tainted
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010246
> eax: 00000018   ebx: 00000000   ecx: c9ac2000   edx: cbfec764
> esi: fffffe00   edi: c9ac2000   ebp: c9ac3f84   esp: c9ac3f60
> ds: 0018   es: 0018   ss: 0018
> Process regression.sh (pid: 1429, stackpage=c9ac3000)
> Stack: c0204dde 00000000 fffffe00 c9ac2000 c011631d 00000200 00000000 c9ac2000
>        00000200 c9ac3fbc c011ad6f c9ac2000 00000000 00000000 c9ac3fac 00000000
>        c9ac2000 00000000 00000000 00000000 c9ac2000 c9ac20bc c9ac20bc bffff348
> Call Trace:    [<c0111631d>] [<c01ad6f>] [<c0108ae7>]
> Code: 0f 0b 34 02 d6 4d 20 c0 83 c4 04 8b 4d f4 c1 e1 05 81 c1 20
> 
> 
> >>EIP; c01150b9 <schedule+4d/330>   <=====
> 
> >>ecx; c9ac2000 <_end+97ea230/c939290>
> >>edx; cbfec764 <_end+bd14994/c939290>
> >>edi; c9ac2000 <_end+97ea230/c939290>
> >>ebp; c9ac3f84 <_end+97ec1b4/c939290>
> >>esp; c9ac3f60 <_end+97ec190/c939290>
> 
> Trace; c0111631d <END_OF_CODE+b3441726a/????>
> Trace; 0c01ad6f Before first symbol
> Trace; c0108ae7 <system_call+47/50>
> 
> Code;  c01150b9 <schedule+4d/330>
> 00000000 <_EIP>:
> Code;  c01150b9 <schedule+4d/330>   <=====
>    0:   0f 0b                     ud2a      <=====

Ну это опять таки явный вызов BUG()...

> Code;  c01150bb <schedule+4f/330>
>    2:   34 02                     xor    $0x2,%al

...причём, если kernel/sched.c не патчился, и строка 564 осталась на
месте, это Scheduling in interrupt (что вполне согласуется с
появившимся потом killing interrupt handler).

> Code;  c01150bd <schedule+51/330>
>    4:   d6                        (bad)  
> Code;  c01150be <schedule+52/330>
>    5:   4d                        dec    %ebp
> Code;  c01150bf <schedule+53/330>
>    6:   20 c0                     and    %al,%al
> Code;  c01150c1 <schedule+55/330>
>    8:   83 c4 04                  add    $0x4,%esp
> Code;  c01150c4 <schedule+58/330>
>    b:   8b 4d f4                  mov    0xfffffff4(%ebp),%ecx
> Code;  c01150c7 <schedule+5b/330>
>    e:   c1 e1 05                  shl    $0x5,%ecx
> Code;  c01150ca <schedule+5e/330>
>   11:   81 c1 20 00 00 00         add    $0x20,%ecx
> 
>  <0>Kernel panic: Aiee, killing interrupt handler!
> 
> 1 warning issued.  Results may not be reliable.
> - ----------------------------------------------------------------------------
> 
> Не знаю насколько это показательно, потому что самая частая
> ошибка выглядит так (предыдущая была первой, но появилась
> всего лишь однажды):
> 
> - ----------------------------------------------------------------------------
> ksymoops 2.4.9 on i686 2.4.22-rts4-up-alt13.  Options used
>      -v /usr/src/RPM/BUILD/kernel-image-rts4-up-2.4.22-alt13/kernel-source-2.4.22/vmlinux (specified)
>      -k /proc/ksyms (default)
>      -l /proc/modules (default)
>      -o /lib/modules/2.4.22-rts4-up-alt13/ (default)
>      -m /boot/System.map-2.4.22-rts4-up-alt13 (default)
> 
> Warning (compare_ksyms_lsmod): module reiserfs is in lsmod but not in ksyms, probably no symbols exported
> Oops: 0007
> CPU:    0
> EIP:    0023:[<08072650>]    Not tainted
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010246
> eax: 00000000   ebx: 080cfd88   ecx: 080cb008   edx: 00000000
> esi: 00000000   edi: 080caa08   ebp: bffff1f8   esp: bffff1d0
> ds: 002b   es: 002b   ss: 002b
> Process regression.sh (pid: 1958, stackpage=c5b17000)
>  <0>Kernel panic: Aiee, killing interrupt handler!
> Warning (Oops_read): Code line not seen, dumping what data is available
> 
> 
> >>EIP; 08072650 Before first symbol   <=====

Адрес явно из userspace, да и код 0007 - (user-mode, write, protection
fault).  А вот почему он превратился в Oops, а не в SIGSEGV...
получается, что userspace-код был вызван в процессе обработки
прерывания.  Т.е. тут что-то не в порядке с обработкой прерываний
(насколько я помню, там rtlinux такое выделывает...).

> PS: Какой смысл имеет значение CONFIG_X86_L1_CACHE_SHIFT? Для чего оно
> используется? Если я правильно понял, в данном случае, оно определяет
> выравнивание на 16 и 64 байта. Это верно? Где это может быть критично?

По всему ядру достаточно переменных, помеченных __cacheline_aligned,
да и в функциях распределения памяти используется SLAB_HWCACHE_ALIGN
(в частности, для struct request, struct dentry, struct buffer_head,
struct file, struct dquot, struct kiobuf, struct inode... дальше
искать надоело).  Т.е. распределение памяти при изменении
CONFIG_X86_L1_CACHE_SHIFT может существенно отличаться, из-за чего
некоторые ошибки могут проявляться только при определённых значениях.

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