LINUX.ORG.RU
ФорумAdmin

Unable to handle kernel NULL pointer...


0

0

Здрасьте. Помогите соорентироваться по этой ситуации (ниже часть лога).
Это debian etch (еще пока он был testing) c собственноручно скомпилированным vanilla kernel 2.6.15.1 (gcc 4.1.2 20061115). Происходит такое примерно раз в месяц.
Эксперименты проводить не могу (отладка, воспроизведение ошибки),
так как это - рабочая система, на которой офис висит.

1. Для меня непонятна причина:
- это баг ядра? если да, то какой подсистемы? сменить ядро?
- может просто gcc криво скомпилил? (соответсвенно надо просто перекомпилить, может даже лучше версией 2.95.3)
- глючное железо?
Как решить, в чем причина?

2. Куда лучше ломануться с этой проблемой?
В баги debian? Так вроде это к debain прямого отношения не имеет - сам компилил.
Спасибо!

2007-08-21T05:26:34+07:00 saturn XFS mounting filesystem sda1
2007-08-21T05:28:41+07:00 saturn Unable to handle kernel NULL pointer dereference at virtual address 00000032
2007-08-21T05:28:41+07:00 saturn printing eip:
2007-08-21T05:28:41+07:00 saturn c012d04f
2007-08-21T05:28:41+07:00 saturn *pde = 00000000
2007-08-21T05:28:41+07:00 saturn Oops: 0000 [#1]
2007-08-21T05:28:41+07:00 saturn CPU:    0
2007-08-21T05:28:41+07:00 saturn EIP:    0060:[<c012d04f>]    Not tainted VLI
2007-08-21T05:28:41+07:00 saturn EFLAGS: 00210002   (2.6.15.1) 
2007-08-21T05:28:41+07:00 saturn EIP is at find_get_pages+0x39/0x5b
2007-08-21T05:28:41+07:00 saturn eax: 8001002c   ebx: 00000001   ecx: c37a9e98   edx: 00000032
2007-08-21T05:28:41+07:00 saturn esi: 00000003   edi: c37a9f08   ebp: c37a9e8c   esp: c37a9e44
2007-08-21T05:28:41+07:00 saturn ds: 007b   es: 007b   ss: 0068
2007-08-21T05:28:41+07:00 saturn Process umount (pid: 22621, threadinfo=c37a8000 task=c1f9a540)
2007-08-21T05:28:41+07:00 saturn Stack: c463dc94 c37a9e94 00000000 0000000e c37a9e8c 00000000 c013668d c463dc90 
2007-08-21T05:28:41+07:00 saturn 00000000 0000000e c37a9e94 00000001 c01367f8 c37a9e8c c463dc90 00000000 
2007-08-21T05:28:41+07:00 saturn 0000000e 00000000 00000000 00000000 c1079180 00000032 000000bb c7972b48 
2007-08-21T05:28:41+07:00 saturn Call Trace:
2007-08-21T05:28:41+07:00 saturn [<c013668d>] pagevec_lookup+0x2b/0x32
2007-08-21T05:28:41+07:00 saturn [<c01367f8>] truncate_inode_pages+0x60/0x237
2007-08-21T05:28:41+07:00 saturn [<c02192ed>] linvfs_clear_inode+0x52/0x67
2007-08-21T05:28:41+07:00 saturn [<c015ec9b>] dispose_list+0xb2/0xc5
2007-08-21T05:28:41+07:00 saturn [<c015ed7e>] invalidate_inodes+0x3a/0x4e
2007-08-21T05:28:41+07:00 saturn [<c014e07b>] generic_shutdown_super+0x70/0x11a
2007-08-21T05:28:41+07:00 saturn [<c014ea87>] kill_block_super+0x27/0x3d
2007-08-21T05:28:41+07:00 saturn [<c014df93>] deactivate_super+0x67/0x80
2007-08-21T05:28:41+07:00 saturn [<c016188b>] sys_umount+0x39/0x82
2007-08-21T05:28:41+07:00 saturn [<c010e48a>] do_page_fault+0x3b2/0x618
2007-08-21T05:28:41+07:00 saturn [<c01618eb>] sys_oldumount+0x17/0x1b
2007-08-21T05:28:41+07:00 saturn [<c0102945>] syscall_call+0x7/0xb
2007-08-21T05:28:41+07:00 saturn Code: 83 c0 04 8b 54 24 24 89 54 24 0c 8b 54 24 20 89 54 24 08 89 5c 24 04 89 04 24 e8 1e 84 10 00 89 c6 85 c0 74 1a 89 d9 31 db 8b 11 <8b> 02 f6 c4 40 75 16 ff 42 04 83 c3 01 83 c1 04 39 de 75 ea fb 
2007-08-21T05:28:41+07:00 saturn Badness in do_exit at kernel/exit.c:807
2007-08-21T05:28:41+07:00 saturn [<c0117bfb>] do_exit+0x31f/0x324
2007-08-21T05:28:41+07:00 saturn [<c0103270>] do_trap+0x0/0xd0
2007-08-21T05:28:41+07:00 saturn [<c010e36f>] do_page_fault+0x297/0x618
2007-08-21T05:28:41+07:00 saturn [<c010e0d8>] do_page_fault+0x0/0x618
2007-08-21T05:28:41+07:00 saturn [<c0102b6f>] error_code+0x4f/0x54
2007-08-21T05:28:41+07:00 saturn [<c012d04f>] find_get_pages+0x39/0x5b
2007-08-21T05:28:41+07:00 saturn [<c013668d>] pagevec_lookup+0x2b/0x32
2007-08-21T05:28:41+07:00 saturn [<c01367f8>] truncate_inode_pages+0x60/0x237
2007-08-21T05:28:41+07:00 saturn [<c02192ed>] linvfs_clear_inode+0x52/0x67
2007-08-21T05:28:41+07:00 saturn [<c015ec9b>] dispose_list+0xb2/0xc5
2007-08-21T05:28:41+07:00 saturn [<c015ed7e>] invalidate_inodes+0x3a/0x4e
2007-08-21T05:28:41+07:00 saturn [<c014e07b>] generic_shutdown_super+0x70/0x11a
2007-08-21T05:28:41+07:00 saturn [<c014ea87>] kill_block_super+0x27/0x3d
2007-08-21T05:28:41+07:00 saturn [<c014df93>] deactivate_super+0x67/0x80
2007-08-21T05:28:41+07:00 saturn [<c016188b>] sys_umount+0x39/0x82
2007-08-21T05:28:41+07:00 saturn [<c010e48a>] do_page_fault+0x3b2/0x618
2007-08-21T05:28:41+07:00 saturn [<c01618eb>] sys_oldumount+0x17/0x1b
2007-08-21T05:28:41+07:00 saturn [<c0102945>] syscall_call+0x7/0xb 

Если твое ядро раньше работало стабильно, а сейчас начало валиться с такой ошибкой, то проверять надо железо (почти все): блок питания, память, диски/кабели, ...

P.S. В дистрибутиве нормальное ядро. была ли веская причина компилировать самому, да еще ванильное?

sdio ★★★★★
()
Ответ на: комментарий от sdio

Ну у меня сервак более 2-3 месяцев без перезагрузки не работал (так получалось), поэтому oops были если он долго без перезагрузки поработает. А если так случается, что я его перзагружу, до того как это случится - то вроде как и даже беспокоиться не о чем. Зачастило это последний год. Но раньше может не вылазило не потому что железо не глючило, а потому что я чаще пперезагружал. Хз - вот сам в непонятках. Но зависимость четкая - чем дольше без перезагрузки - тем выше веротняоть что глюкнет. Глюков вот прям сходу, сразу после перезагрузки не бывает.

А ядро своё: чтобы модули нельзя было загрузить (руткиты там всякие и пр). Я сконфигурил под свое железо и скомпилил монолитное ядро - без возможности загрузки других. В основном в целях безопасности. Ну и другие приемущества у него есть. USB и соответсвенно udev/hotplug не использую вообще.

ga

gapsf2
() автор топика
Ответ на: комментарий от gapsf2

> А ядро своё: чтобы модули нельзя было загрузить (руткиты там всякие и пр). Я сконфигурил под свое железо и скомпилил монолитное ядро - без возможности загрузки других

Если я получил возможность на некоторой системе загрузить в ядро свой модуль, то это значит что я имею на ней рута. И поверь, пересобрать на этой системе свое ядро из твоих исходников мне также труда не составит :-) Так что всякая чушь вида "чтоб не было руткита" и прочие "прадвинутые настройки для риальнай сикурности" чушь полная.

Поверь старшему товарищу :-)

no-dashi ★★★★★
()
Ответ на: комментарий от gapsf2

Загружаться с дистрибутивным ядром и сравнивать поведение.

sdio ★★★★★
()
Ответ на: комментарий от no-dashi

Для дискуссии.

Да, я в курсе доступности /dev/mem, /dev/kmem на запись root. Помнится читал в Phrack "Abuse of the Linux Kernel for Fun and Profit" и "Linux on-the-fly kernel patching without LKM". Для кардинального лечения этого можно юзать RSBAC (альтернатива SELinux) и запретить запись всем и любым процессам. Я баловался с RSBAC, когда мучал годик LFS. Конечно, ограничиваться только этим, недостаточно поэтому в RSBAC надо настраивать комплексно, что трудоемкая задача. Ну в SELinux тоже не так просто. Может это и в grsecurity есть. Так что это не проблема. В RSBAC такие "очевидные дыры" там закрыты в конфигурации по умолчанию и контроль смены uid/gid поцессов там реализовать очень легко.

Еще + монолитного ядра - его удобно использовать на всяких сменных носителях.

gapsf2
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.