Страница 1 из 1
kernel panic после апгрейда с 9.2 до 10.3
Добавлено: 2017-01-04 17:35:36
dm07
Всем привет. В предыдущем посте писал про обновление с 9.2 Release до 10.3-RELEASE-p15. Имею ситуацию паники ядра при высокой сетевой нагрузки, в частности rsync'ом тяну бекапы на локальную машину с сервера, при этом возникает эта паника:
Код: Выделить всё
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x59
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff80dae53c
stack pointer = 0x28:0xfffffe04e7117570
frame pointer = 0x28:0xfffffe04e7117580
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 12 (irq256: re0)
trap number = 12
panic: page fault
cpuid = 1
KDB: stack backtrace:
#0 0xffffffff809dc210 at kdb_backtrace+0x60
#1 0xffffffff8099eee6 at vpanic+0x126
#2 0xffffffff8099edb3 at panic+0x43
#3 0xffffffff80db091b at trap_fatal+0x36b
#4 0xffffffff80db0c1d at trap_pfault+0x2ed
#5 0xffffffff80db029a at trap+0x47a
#6 0xffffffff80d96262 at calltrap+0x8
#7 0xffffffff80369771 at ipf_frag_lookup+0x111
#8 0xffffffff803699e4 at ipf_frag_known+0x54
#9 0xffffffff8035ad3d at ipf_check+0x2fd
#10 0xffffffff80a72dd4 at pfil_run_hooks+0x84
#11 0xffffffff80adf3ae at ip_input+0x2fe
#12 0xffffffff80a71f12 at netisr_dispatch_src+0x62
#13 0xffffffff80a692d6 at ether_demux+0x126
#14 0xffffffff80a69f7e at ether_nh_input+0x35e
#15 0xffffffff80a71f12 at netisr_dispatch_src+0x62
#16 0xffffffff807144ee at re_rxeof+0x4ce
#17 0xffffffff8071572b at re_intr_msi+0x10b
Вторая часть:
Код: Выделить всё
#0 doadump (textdump=<value optimized out>) at pcpu.h:219
#1 0xffffffff8099eb42 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:486
#2 0xffffffff8099ef25 in vpanic (fmt=<value optimized out>, ap=<value optimized out>)
at /usr/src/sys/kern/kern_shutdown.c:889
#3 0xffffffff8099edb3 in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:818
#4 0xffffffff80db091b in trap_fatal (frame=<value optimized out>, eva=<value optimized out>)
at /usr/src/sys/amd64/amd64/trap.c:858
#5 0xffffffff80db0c1d in trap_pfault (frame=0xfffffe04e71174c0, usermode=<value optimized out>)
at /usr/src/sys/amd64/amd64/trap.c:681
#6 0xffffffff80db029a in trap (frame=0xfffffe04e71174c0) at /usr/src/sys/amd64/amd64/trap.c:447
#7 0xffffffff80d96262 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:236
#8 0xffffffff80dae53c in bcmp () at /usr/src/sys/amd64/amd64/support.S:87
#9 0xffffffff80369771 in ipf_frag_lookup () at /usr/src/sys/contrib/ipfilter/netinet/ip_frag.c:697
#10 0xffffffff803699e4 in ipf_frag_known (fin=0xfffffe04e71176d8, passp=0xfffffe04e71176d4)
at /usr/src/sys/contrib/ipfilter/netinet/ip_frag.c:895
#11 0xffffffff8035ad3d in ipf_check (ctx=0xffffffff81e85828, ip=<value optimized out>,
hlen=<value optimized out>, ifp=<value optimized out>, out=0, mp=0xfffffe04e7117838)
at /usr/src/sys/contrib/ipfilter/netinet/fil.c:3025
#12 0xffffffff80a72dd4 in pfil_run_hooks (ph=0xffffffff81e9f918, mp=0xfffffe04e71178c0, ifp=0xfffff80005a36000,
dir=1, inp=0x0) at /usr/src/sys/net/pfil.c:82
#13 0xffffffff80adf3ae in ip_input (m=0xfffff8006c59a500) at /usr/src/sys/netinet/ip_input.c:488
#14 0xffffffff80a71f12 in netisr_dispatch_src (proto=<value optimized out>, source=<value optimized out>, m=0x1)
at /usr/src/sys/net/netisr.c:976
#15 0xffffffff80a692d6 in ether_demux (ifp=<value optimized out>, m=0xfffff8006c59a500)
at /usr/src/sys/net/if_ethersubr.c:851
#16 0xffffffff80a69f7e in ether_nh_input (m=<value optimized out>) at /usr/src/sys/net/if_ethersubr.c:646
#17 0xffffffff80a71f12 in netisr_dispatch_src (proto=<value optimized out>, source=<value optimized out>, m=0x1)
at /usr/src/sys/net/netisr.c:976
#18 0xffffffff807144ee in re_rxeof (sc=0xfffffe0000b98000, rx_npktsp=0x0) at /usr/src/sys/dev/re/if_re.c:2369
#19 0xffffffff8071572b in re_intr_msi (xsc=0xfffffe0000b98000) at /usr/src/sys/dev/re/if_re.c:2665
#20 0xffffffff80969b2b in intr_event_execute_handlers (p=<value optimized out>, ie=0xfffff80005a64e00)
at /usr/src/sys/kern/kern_intr.c:1264
#21 0xffffffff80969f76 in ithread_loop (arg=0xfffff80005a072a0) at /usr/src/sys/kern/kern_intr.c:1277
#22 0xffffffff8096767a in fork_exit (callout=0xffffffff80969ee0 <ithread_loop>, arg=0xfffff80005a072a0,
frame=0xfffffe04e7117c00) at /usr/src/sys/kern/kern_fork.c:1027
#23 0xffffffff80d9679e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:611
#24 0x0000000000000000 in ?? ()
Насколько понял, проблема возникает где-то на уровне драйвера сетевой карты (if_re.c:2665):
Код: Выделить всё
re0: <RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet> port 0xe800-0xe8ff mem 0xfbeff000-0xfbefffff,0xf6ff0000-0xf6ffffff irq 16 at device 0.0 on pci6
либо где-то на уровне IPF.
Возможно еще, что на сбой влияют мои старые настройки sysctl с предыдущей сборки:
Код: Выделить всё
net.inet.ip.rtminexpire=2
net.inet.ip.rtmaxcache=1024
net.inet.tcp.sack.enable=1
net.inet.tcp.finwait2_timeout=10000
net.inet.ip.intr_queue_maxlen=4096
kern.ipc.somaxconn=32768
net.inet.tcp.maxtcptw=200000
Есть смысл собраться до ближайшего Stable?
kernel panic после апгрейда с 9.2 до 10.3
Добавлено: 2017-01-04 20:32:30
guest
dm07 писал(а):Всем привет. В предыдущем посте писал про обновление с 9.2 Release до 10.3-RELEASE-p15. Имею ситуацию паники ядра при высокой сетевой нагрузки, в частности rsync'ом тяну бекапы на локальную машину с сервера, при этом возникает эта паника:
Код: Выделить всё
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x59
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff80dae53c
stack pointer = 0x28:0xfffffe04e7117570
frame pointer = 0x28:0xfffffe04e7117580
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 12 (irq256: re0)
trap number = 12
panic: page fault
cpuid = 1
KDB: stack backtrace:
#0 0xffffffff809dc210 at kdb_backtrace+0x60
#1 0xffffffff8099eee6 at vpanic+0x126
#2 0xffffffff8099edb3 at panic+0x43
#3 0xffffffff80db091b at trap_fatal+0x36b
#4 0xffffffff80db0c1d at trap_pfault+0x2ed
#5 0xffffffff80db029a at trap+0x47a
#6 0xffffffff80d96262 at calltrap+0x8
#7 0xffffffff80369771 at ipf_frag_lookup+0x111
#8 0xffffffff803699e4 at ipf_frag_known+0x54
#9 0xffffffff8035ad3d at ipf_check+0x2fd
#10 0xffffffff80a72dd4 at pfil_run_hooks+0x84
#11 0xffffffff80adf3ae at ip_input+0x2fe
#12 0xffffffff80a71f12 at netisr_dispatch_src+0x62
#13 0xffffffff80a692d6 at ether_demux+0x126
#14 0xffffffff80a69f7e at ether_nh_input+0x35e
#15 0xffffffff80a71f12 at netisr_dispatch_src+0x62
#16 0xffffffff807144ee at re_rxeof+0x4ce
#17 0xffffffff8071572b at re_intr_msi+0x10b
Вторая часть:
Код: Выделить всё
#0 doadump (textdump=<value optimized out>) at pcpu.h:219
#1 0xffffffff8099eb42 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:486
#2 0xffffffff8099ef25 in vpanic (fmt=<value optimized out>, ap=<value optimized out>)
at /usr/src/sys/kern/kern_shutdown.c:889
#3 0xffffffff8099edb3 in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:818
#4 0xffffffff80db091b in trap_fatal (frame=<value optimized out>, eva=<value optimized out>)
at /usr/src/sys/amd64/amd64/trap.c:858
#5 0xffffffff80db0c1d in trap_pfault (frame=0xfffffe04e71174c0, usermode=<value optimized out>)
at /usr/src/sys/amd64/amd64/trap.c:681
#6 0xffffffff80db029a in trap (frame=0xfffffe04e71174c0) at /usr/src/sys/amd64/amd64/trap.c:447
#7 0xffffffff80d96262 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:236
#8 0xffffffff80dae53c in bcmp () at /usr/src/sys/amd64/amd64/support.S:87
#9 0xffffffff80369771 in ipf_frag_lookup () at /usr/src/sys/contrib/ipfilter/netinet/ip_frag.c:697
#10 0xffffffff803699e4 in ipf_frag_known (fin=0xfffffe04e71176d8, passp=0xfffffe04e71176d4)
at /usr/src/sys/contrib/ipfilter/netinet/ip_frag.c:895
#11 0xffffffff8035ad3d in ipf_check (ctx=0xffffffff81e85828, ip=<value optimized out>,
hlen=<value optimized out>, ifp=<value optimized out>, out=0, mp=0xfffffe04e7117838)
at /usr/src/sys/contrib/ipfilter/netinet/fil.c:3025
#12 0xffffffff80a72dd4 in pfil_run_hooks (ph=0xffffffff81e9f918, mp=0xfffffe04e71178c0, ifp=0xfffff80005a36000,
dir=1, inp=0x0) at /usr/src/sys/net/pfil.c:82
#13 0xffffffff80adf3ae in ip_input (m=0xfffff8006c59a500) at /usr/src/sys/netinet/ip_input.c:488
#14 0xffffffff80a71f12 in netisr_dispatch_src (proto=<value optimized out>, source=<value optimized out>, m=0x1)
at /usr/src/sys/net/netisr.c:976
#15 0xffffffff80a692d6 in ether_demux (ifp=<value optimized out>, m=0xfffff8006c59a500)
at /usr/src/sys/net/if_ethersubr.c:851
#16 0xffffffff80a69f7e in ether_nh_input (m=<value optimized out>) at /usr/src/sys/net/if_ethersubr.c:646
#17 0xffffffff80a71f12 in netisr_dispatch_src (proto=<value optimized out>, source=<value optimized out>, m=0x1)
at /usr/src/sys/net/netisr.c:976
#18 0xffffffff807144ee in re_rxeof (sc=0xfffffe0000b98000, rx_npktsp=0x0) at /usr/src/sys/dev/re/if_re.c:2369
#19 0xffffffff8071572b in re_intr_msi (xsc=0xfffffe0000b98000) at /usr/src/sys/dev/re/if_re.c:2665
#20 0xffffffff80969b2b in intr_event_execute_handlers (p=<value optimized out>, ie=0xfffff80005a64e00)
at /usr/src/sys/kern/kern_intr.c:1264
#21 0xffffffff80969f76 in ithread_loop (arg=0xfffff80005a072a0) at /usr/src/sys/kern/kern_intr.c:1277
#22 0xffffffff8096767a in fork_exit (callout=0xffffffff80969ee0 <ithread_loop>, arg=0xfffff80005a072a0,
frame=0xfffffe04e7117c00) at /usr/src/sys/kern/kern_fork.c:1027
#23 0xffffffff80d9679e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:611
#24 0x0000000000000000 in ?? ()
Насколько понял, проблема возникает где-то на уровне драйвера сетевой карты (if_re.c:2665):
Код: Выделить всё
re0: <RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet> port 0xe800-0xe8ff mem 0xfbeff000-0xfbefffff,0xf6ff0000-0xf6ffffff irq 16 at device 0.0 on pci6
либо где-то на уровне IPF.
Возможно еще, что на сбой влияют мои старые настройки sysctl с предыдущей сборки:
Код: Выделить всё
net.inet.ip.rtminexpire=2
net.inet.ip.rtmaxcache=1024
net.inet.tcp.sack.enable=1
net.inet.tcp.finwait2_timeout=10000
net.inet.ip.intr_queue_maxlen=4096
kern.ipc.somaxconn=32768
net.inet.tcp.maxtcptw=200000
Есть смысл собраться до ближайшего Stable?
У Вас какой-то Windoze-style подход...
- можете и до Stable и до Current обновиться...
закомментарьте ваш тюнинг sysctl в /etc/sysctl.conf и /boot/loader.conf,
и посмотрите результат.
Если все ok, начинайте тюнить но осмысленно.
ps. А креш - где-то в стыке ipfilter с re драйвером, посмотрите man 4 re и настройки ipfilter
kernel panic после апгрейда с 9.2 до 10.3
Добавлено: 2017-02-15 14:50:03
dm07
Всем привет. Kernel panic вызывает ipfilter. Если включить "разрешить все", то паники не происходит.
Также на сервере наблюдаются какие-то затыки с производительностью дисковой подсистемы (все в зеркале zfs).
Всегда обновлялся до Stable, и не было никаких проблем, а в последний раз обновился до Releng и повылазило кучу проблем. С отключенным фаерволлом попан в бан у провайдера из-за множественных атак на DNS.
Надо что-то делать, т.к. сервер рабочий. Есть смысл обновиться до Stable 10.3 или попробоваться обновиться до актуального Releng 10.3?
kernel panic после апгрейда с 9.2 до 10.3
Добавлено: 2017-02-15 16:00:21
Neus
dm07 писал(а): Kernel panic вызывает ipfilter
а вместо него заюзать ipfw или pf низя?
dm07 писал(а): Также на сервере наблюдаются какие-то затыки с производительностью дисковой подсистемы (все в зеркале zfs).
покажи:
zpool status
zpool list
и в sysctl чего нить тюнил ?
dm07 писал(а): Есть смысл обновиться до Stable 10.3 или попробоваться обновиться до актуального Releng 10.3?
до releng/11.0
kernel panic после апгрейда с 9.2 до 10.3
Добавлено: 2017-02-15 16:17:42
dm07
Neus писал(а): zpool list
Код: Выделить всё
# zpool list
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
tank 1.80T 1.40T 410G - - 77% 1.00x ONLINE -
Neus писал(а): zpool status
Код: Выделить всё
# zpool status
pool: tank
state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
the pool may no longer be accessible by software that does not support
the features. See zpool-features(7) for details.
scan: resilvered 103G in 2h48m with 0 errors on Mon Jul 21 03:13:47 2014
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
gpt/disk0 ONLINE 0 0 0
gpt/disk1 ONLINE 0 0 0
Neus писал(а): и в sysctl чего нить тюнил ?
практически все тюнинговые опции с 9 ветки отключил.
Neus писал(а): а вместо него заюзать ipfw или pf низя?
К ipfilter привык, правила под него написаны.
kernel panic после апгрейда с 9.2 до 10.3
Добавлено: 2017-02-15 20:18:51
Neus
Хм… чего-то фрагментацию не показывает… ниасилил что ли
А это почему не сделал?
status: Some supported features are not enabled on the pool. The pool can
still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'.
Помониторь gstat'ом диски во время операций io, если один из дисков подтупливает там видно будет.
kernel panic после апгрейда с 9.2 до 10.3
Добавлено: 2017-02-16 9:36:56
dm07
Neus писал(а): Помониторь gstat'ом диски во время операций io
Делал быстрый тест дисков по-отдельности:
Код: Выделить всё
# diskinfo -tv ada0
ada0
512 # sectorsize
2000398934016 # mediasize in bytes (1.8T)
3907029168 # mediasize in sectors
0 # stripesize
0 # stripeoffset
3876021 # Cylinders according to firmware.
16 # Heads according to firmware.
63 # Sectors according to firmware.
MN3220FA066SYE # Disk ident.
Seek times:
Full stroke: 250 iter in 7.753970 sec = 31.016 msec
Half stroke: 250 iter in 6.116325 sec = 24.465 msec
Quarter stroke: 500 iter in 9.813912 sec = 19.628 msec
Short forward: 400 iter in 2.432638 sec = 6.082 msec
Short backward: 400 iter in 2.486185 sec = 6.215 msec
Seq outer: 2048 iter in 0.146179 sec = 0.071 msec
Seq inner: 2048 iter in 0.140998 sec = 0.069 msec
Transfer rates:
outside: 102400 kbytes in 0.808882 sec = 126594 kbytes/sec
middle: 102400 kbytes in 1.060431 sec = 96565 kbytes/sec
inside: 102400 kbytes in 1.642970 sec = 62326 kbytes/sec
Код: Выделить всё
ada1
ada1
512 # sectorsize
2000398934016 # mediasize in bytes (1.8T)
3907029168 # mediasize in sectors
0 # stripesize
0 # stripeoffset
3876021 # Cylinders according to firmware.
16 # Heads according to firmware.
63 # Sectors according to firmware.
MN3220FA0ATW3E # Disk ident.
Seek times:
Full stroke: 250 iter in 7.385146 sec = 29.541 msec
Half stroke: 250 iter in 5.806017 sec = 23.224 msec
Quarter stroke: 500 iter in 9.688018 sec = 19.376 msec
Short forward: 400 iter in 2.761604 sec = 6.904 msec
Short backward: 400 iter in 3.074476 sec = 7.686 msec
Seq outer: 2048 iter in 0.170537 sec = 0.083 msec
Seq inner: 2048 iter in 0.178372 sec = 0.087 msec
Transfer rates:
outside: 102400 kbytes in 0.801126 sec = 127820 kbytes/sec
middle: 102400 kbytes in 0.966824 sec = 105914 kbytes/sec
inside: 102400 kbytes in 1.300311 sec = 78750 kbytes/sec
Затык идет именно где-то на уровне логики работы zfs.
kernel panic после апгрейда с 9.2 до 10.3
Добавлено: 2017-02-16 10:33:41
snorlov
Вы все-таки
сделайте, как никак, а версия zfs изменилась...
kernel panic после апгрейда с 9.2 до 10.3
Добавлено: 2017-02-16 10:54:41
Neus
dm07 писал(а): Делал быстрый тест дисков по-отдельности:
так себе "тест".
dm07 писал(а): Затык идет именно где-то на уровне логики работы zfs.
открой две консоли рядом, zpool iostat 1 в одной, gstat в другой.
и лови момент затыков.
kernel panic после апгрейда с 9.2 до 10.3
Добавлено: 2017-02-20 15:28:45
Гость
Посмотри аналогичный параметр в твоей сетевой карте.
Код: Выделить всё
sysctl -a | grep num_que
hw.ix.num_queues: 0
hw.igb.num_queues: 3
ee /boot/loader.conf
Код: Выделить всё
# if num_queues > 3 = были проблемы передачи по сети на больших файлах
# уменьшил до 3 все стало нормально.
hw.igb.num_queues=3
Может оттуда ноги растут?
kernel panic после апгрейда с 9.2 до 10.3
Добавлено: 2017-03-15 14:32:42
iles
Была такая же хрень...
Вариантов два..
1. Убираете из ядра все упоминания про ALTQ, пересборка - и все будет норм.
2. Проводите патч драйвера igb как сказано здесь:
https://bugs.freebsd.org/bugzilla/show_ ... ?id=213257
Все вышесказанное касается только драйвером IGB, на EM драйверах такой проблемы нет...
kernel panic после апгрейда с 9.2 до 10.3
Добавлено: 2017-03-15 14:37:08
dm07
Пантку ядра вызывает ipfilter и возможно совместно с картой realtek. Развернул freebsd 10.3 на новом сервере, при даже незначительных нагрузках происходит паника... Отключаю все правила ipfilter, паники нет.начинаю изучать pf и пересобирать ядро с ним.
kernel panic после апгрейда с 9.2 до 10.3
Добавлено: 2017-05-16 11:36:19
Visionman
Аналогичное случалось на сервере HP ProLiant ML150 Gen9 E5-2620v3 Hot Plug TOWER (5U)
Индекс модели - 780852-425
При высокой дисковой нагрузке, передача больших объёмов используя rsync, через 33 - 34 секунды, в системе возникала паника.
Виновником был контроллер RAID HP Dynamic Smart Array B140i
После отключения дисков от контроллера и подключения дисков на контроллер материнской платы, проблема исчезла.
kernel panic после апгрейда с 9.2 до 10.3
Добавлено: 2017-05-16 11:39:24
dm07
В моем случае панику вызывала связка realtek + ipfilter, backtrace четко показывал проблему в драйверах карты и ipf. Переход на pf избавил от этой напасти.
kernel panic после апгрейда с 9.2 до 10.3
Добавлено: 2017-08-08 13:39:08
ultimo