[d-kernel] rtlinux package
Sergey Vlasov
vsu at altlinux.ru
Fri Jan 2 23:42:35 MSK 2004
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 может существенно отличаться, из-за чего
некоторые ошибки могут проявляться только при определённых значениях.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/devel-kernel/attachments/20040102/b0a520c8/attachment.bin
More information about the devel-kernel
mailing list