nixp.ru v3.0

24 января 2017,
вторник,
18:12:27 MSK

DevOps с компанией «Флант»
Аватар пользователя DimkaS
DimkaS написал 27 мая 2008 года в 12:30 (1182 просмотра) Ведет себя как мужчина; открыл 84 темы в форуме, оставил 922 комментария на сайте.

Сразу оговорюсь: речь идёт о встраиваемом ARM устройстве, но, думаю, ядро везде одинаково работает.

Железо: AT91RM9200, 64Мб ОЗУ, 8 Мб флэш. Загрузка происходит так: загрузчик вытаскивает из флэша образ ядра и initrd в оперативку. Ядро использует initrd как rootfs. Т.е. как на обычных компах, но нету последующего монтирования фс с жёсткого диска из-за отсутствия такового. Всё размещается в ОЗУ. Есть 2 рам-диска по 8 Мб. Один — initrd, как я понимаю, другой — /var/tmp. Система работает стабильно, после загрузки состояние оперативки такое:

# cat /proc/meminfo
MemTotal:        62284 kB
MemFree:         47344 kB
Buffers:          8548 kB
Cached:           2820 kB
SwapCached:          0 kB
Active:           3132 kB
Inactive:         9068 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:        62284 kB
LowFree:         47344 kB
SwapTotal:           0 kB
SwapFree:            0 kB
Dirty:             560 kB
Writeback:           0 kB
Mapped:           2112 kB
Slab:             1756 kB
CommitLimit:     31140 kB
Committed_AS:     4180 kB
PageTables:        128 kB
VmallocTotal:   956416 kB
VmallocUsed:      9688 kB
VmallocChunk:   946172 kB

Файловые системы:

# mount
rootfs on / type rootfs (rw)
/dev/root on / type ext2 (rw)
proc on /proc type proc (rw)
sys on /sys type sysfs (rw)
/dev/ram1 on /var/tmp type ext2 (rw)
/dev/loop0 on /mnt/settings type ext2 (rw)
# df -h /var/tmp
Filesystem                Size      Used Available Use% Mounted on
/dev/ram1                 7.7M    464.0k      6.9M   6% /var/tmp

Т.е. оперативы достаточно.

Далее, загружаю файл через httpd+POST. Заголовки, добавленные httpd в файл вырезаются так:

tee|sed '1,4d'|sed '$d'|sed '$d'|sed '$d'|sed '$d'|sed '$d'|sed '$d' > /tmp/update.tar.gz

Далее, ядро падает:

Unable to handle kernel paging request at virtual address 7a29ca23
pgd = c36bc000
[7a29ca23] *pgd=00000000
Internal error: Oops: 3 [#1]
Modules linked in:
CPU: 0
PC is at schedule+0x358/0x768
LR is at 0x15cc5b
pc : []    lr : [<0015cc5b>]    Not tainted
sp : c3731e60  ip : 7a29c8cb  fp : c3731e9c
r10: c0d20a80  r9 : c3730000  r8 : c0c120a0
r7 : 00001000  r6 : c027ed08  r5 : c027ed08  r4 : c3346ca0
r3 : 0000022c  r2 : 30000013  r1 : 30000093  r0 : a5b56e00
Flags: nzCV  IRQs off  FIQs on  Mode SVC_32  Segment user
Control: 317F  Table: 236BC000  DAC: 00000015
Process sed (pid: 877, stack limit = 0xc3730198)
Stack: (0xc3731e60 to 0xc3732000)
....

Не могу понять, почему 40 свободных мегабайт не хватает для обработки 4-х мегабайтного файла?

metal

Не пробовал использовать ksymoops?

DimkaS

Забыл. Ядро 2.6.17.

Documentation/oops-tracing.txt говорит:

NOTE: ksymoops is useless on 2.6

metal
DimkaS

Process sed (pid: 877, stack limit = 0xc3730198)
Stack: (0xc3731e60 to 0xc3732000)
....

Меня вот это смущает, stack превышает stack_limit.

DimkaS

Может, надо как-то этот лимит увеличить?

Я, честно, мало что понимаю в происходящем. Сейчас попробовал остановить всех демонов — файл нормально обработался, распаковался и даже md5 сошлось. Т.е. дело, видимо, в объеме оперативы. Непонятно то, что перед падением top показывал 37Мб свободных. После остановки демонов этот параметр не опускался ниже 40.

metal

Как раз для тебя ссылка:) http://infocenter.arm.com/help/topic/com.arm.doc.dui0203f/DUI0203.pdf Думаю дело в размере стека, тут вроде что-то есть об этом. c3731e9c — fp больше stack_limit.

metal

Я тут посмотрел на ARM стек вниз растет, значит это значение в пределах нормы.

DimkaS

А документик интересный, спасибо

DimkaS

После множества экспериментов подобрал более-менее рабочую конфигурацию:

ramdisk_size=8192

перед обработкой файла останавливаются все демоны

загружаемый файл не более 4Мб

Если в процессе загрузки-распаковки свободно более 37Мб оперативы, то всё нормально.

Попытка загрузить 6Мб:

Mem: 25344K used, 36940K free, 0K shrd, 13252K buff, 8160K cached
CPU:  66% usr  23% sys   0% nice   0% idle   0% io   1% irq   7% softirq
Load average: 0.15 0.03 0.01
  PID  PPID USER     STAT   VSZ %MEM %CPU COMMAND
1022  1002 root     R     2104   3%  73% sed 1,4d;$d;$d;$d;$d;$d;$d; -
1001   752 root     S     2096   3%  15% httpd -u root:root -h /home/httpd -r
1023  1002 root     S     2096   3%  11% tar xf - -C /tmp
1021   792 root     R     2100   3%   2% top -d 1
  719     1 root     S     3108   5%   0% /bin/ext/gme920/wdogd
    1     0 root     S     2348   4%   0% /sbin/init
  792     1 root     S     2100   3%   0% /bin/sh
1002  1001 root     S     2100   3%   0% /bin/sh /home/httpd/cgi-bin/update_ex
  793     1 root     S     2096   3%   0% /sbin/syslogd -n
  752     1 root     S     2096   3%   0% httpd -u root:root -h /home/httpd -r
  794     1 root     S     1516   2%   0% /bin/inetd
   68     6 root     SW       0   0%   0% [pdflush]
    5     1 root     SW<      0   0%   0% [khelper]
    2     1 root     SWN      0   0%   0% [ksoftirqd/0]
    3     1 root     SW       0   0%   0% [watchdog/0]
    4     1 root     SW<      0   0%   0% [events/0]
    6     1 root     SW<      0   0%   0% [kthread]
   17     6 root     SW<      0   0%   0% [kblockd/0]
   21     6 root     SW<      0   0%   0% [khubd]
Unable to handle kernel paging request at virtual address c562362a
pgd = c3104000
[c562362a] *pgd=00000000
Internal error: Oops: 3 [#1]
Modules linked in:
CPU: 0
PC is at __inode_dir_notify+0x28/0xa0
LR is at dnotify_parent+0x70/0x80
pc : []    lr : []    Not tainted
sp : c30fff18  ip : c30fff3c  fp : c30fff38
r10: c30fff78  r9 : c30fe000  r8 : 00000000
r7 : c0c149f0  r6 : 00000001  r5 : c0c14af4  r4 : c5623626
r3 : 00000006  r2 : 20000013  r1 : 00000001  r0 : c0c149f0
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  Segment user
Control: C000317F  Table: 23104000  DAC: 00000015
Process sed (pid: 1022, stack limit = 0xc30fe198)
Stack: (0xc30fff18 to 0xc3100000)

Никак не понимаю, почему такого количества ОЗУ не достаточно…

metal

Это вообще не нормально, что kernel падает из-за userspace. Это или баг железа или ядра. Попробуй более свежее ядро и как насчет ulimit?

DimkaS
metal
Это вообще не нормально, что kernel падает из-за userspace. Это или баг железа или ядра.

Похоже, так и есть. Если сказать ядру mem=32M и не останавливать демонов, то в процессе загрузки файла оперативы остаётся 4-6М, но ничего не падает. Видимо, проблема в старших 32 мегабайтах. Теперь осталось выяснить причину…

ecobeingecobeing.ru
Экология и вегетарианство на благо всем живым существам Планеты.