Сразу оговорюсь: речь идёт о встраиваемом 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-х мегабайтного файла?
Последние комментарии
-
OlegL, 17 декабря 2023 года в 15:00 →
Перекличка
21
-
REDkiy, 8 июня 2023 года в 9:09 →
Как «замокать» файл для юниттеста в Python?
2
-
fhunter, 29 ноября 2022 года в 2:09 →
Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt?
6
-
Иванн, 9 апреля 2022 года в 8:31 →
Ассоциация РАСПО провела первое учредительное собрание
1
-
Kiri11.ADV1, 7 марта 2021 года в 12:01 →
Логи catalina.out в TomCat 9 в формате JSON
1
DevOps as a Service from Palark
Не пробовал использовать ksymoops?
Забыл. Ядро 2.6.17.
Documentation/oops-tracing.txt говорит:
NOTE: ksymoops is useless on 2.6
Меня вот это смущает, stack превышает stack_limit.
Может, надо как-то этот лимит увеличить?
Я, честно, мало что понимаю в происходящем. Сейчас попробовал остановить всех демонов — файл нормально обработался, распаковался и даже md5 сошлось. Т.е. дело, видимо, в объеме оперативы. Непонятно то, что перед падением top показывал 37Мб свободных. После остановки демонов этот параметр не опускался ниже 40.
Как раз для тебя ссылка:) http://infocenter.arm.com/help/topic/com.arm.doc.dui0203f/DUI0203.pdf Думаю дело в размере стека, тут вроде что-то есть об этом. c3731e9c — fp больше stack_limit.
Я тут посмотрел на ARM стек вниз растет, значит это значение в пределах нормы.
А документик интересный, спасибо
После множества экспериментов подобрал более-менее рабочую конфигурацию:
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)Никак не понимаю, почему такого количества ОЗУ не достаточно…
Это вообще не нормально, что kernel падает из-за userspace. Это или баг железа или ядра. Попробуй более свежее ядро и как насчет ulimit?
Похоже, так и есть. Если сказать ядру mem=32M и не останавливать демонов, то в процессе загрузки файла оперативы остаётся 4-6М, но ничего не падает. Видимо, проблема в старших 32 мегабайтах. Теперь осталось выяснить причину…