kernel panic после апгрейда с 9.2 до 10.3

Проблемы установки, настройки и работы Правильной Операционной Системы

Модератор: terminus

Правила форума
Убедительная просьба юзать теги [code] при оформлении листингов.
Сообщения не оформленные должным образом имеют все шансы быть незамеченными.
dm07
сержант
Сообщения: 222
Зарегистрирован: 2008-07-27 19:58:25
Откуда: Уфа
Контактная информация:

kernel panic после апгрейда с 9.2 до 10.3

Непрочитанное сообщение dm07 » 2017-01-04 17:35:36

Всем привет. В предыдущем посте писал про обновление с 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?

guest
проходил мимо

kernel panic после апгрейда с 9.2 до 10.3

Непрочитанное сообщение guest » 2017-01-04 20:32:30

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

dm07
сержант
Сообщения: 222
Зарегистрирован: 2008-07-27 19:58:25
Откуда: Уфа
Контактная информация:

kernel panic после апгрейда с 9.2 до 10.3

Непрочитанное сообщение dm07 » 2017-02-15 14:50:03

Всем привет. Kernel panic вызывает ipfilter. Если включить "разрешить все", то паники не происходит.
Также на сервере наблюдаются какие-то затыки с производительностью дисковой подсистемы (все в зеркале zfs).
Всегда обновлялся до Stable, и не было никаких проблем, а в последний раз обновился до Releng и повылазило кучу проблем. С отключенным фаерволлом попан в бан у провайдера из-за множественных атак на DNS.
Надо что-то делать, т.к. сервер рабочий. Есть смысл обновиться до Stable 10.3 или попробоваться обновиться до актуального Releng 10.3?

Neus
капитан
Сообщения: 1718
Зарегистрирован: 2008-09-08 21:59:56

kernel panic после апгрейда с 9.2 до 10.3

Непрочитанное сообщение Neus » 2017-02-15 16:00:21

dm07 писал(а):Источник цитаты Kernel panic вызывает ipfilter

а вместо него заюзать ipfw или pf низя?
dm07 писал(а):Источник цитаты Также на сервере наблюдаются какие-то затыки с производительностью дисковой подсистемы (все в зеркале zfs).

покажи:
zpool status
zpool list
и в sysctl чего нить тюнил ?
dm07 писал(а):Источник цитаты Есть смысл обновиться до Stable 10.3 или попробоваться обновиться до актуального Releng 10.3?

до releng/11.0
«Вы никогда не сумеете решить возникшую проблему,
если сохраните то же мышление и тот же подход,
который привёл вас к этой проблеме.»
© Альберт Эйнштейн

dm07
сержант
Сообщения: 222
Зарегистрирован: 2008-07-27 19:58:25
Откуда: Уфа
Контактная информация:

kernel panic после апгрейда с 9.2 до 10.3

Непрочитанное сообщение dm07 » 2017-02-15 16:17:42

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 привык, правила под него написаны.

Neus
капитан
Сообщения: 1718
Зарегистрирован: 2008-09-08 21:59:56

kernel panic после апгрейда с 9.2 до 10.3

Непрочитанное сообщение Neus » 2017-02-15 20:18:51

Хм… чего-то фрагментацию не показывает… ниасилил что ли :)
А это почему не сделал?
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, если один из дисков подтупливает там видно будет.
«Вы никогда не сумеете решить возникшую проблему,
если сохраните то же мышление и тот же подход,
который привёл вас к этой проблеме.»
© Альберт Эйнштейн

dm07
сержант
Сообщения: 222
Зарегистрирован: 2008-07-27 19:58:25
Откуда: Уфа
Контактная информация:

kernel panic после апгрейда с 9.2 до 10.3

Непрочитанное сообщение dm07 » 2017-02-16 9:36:56

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.

snorlov
подполковник
Сообщения: 3565
Зарегистрирован: 2008-09-04 11:51:25
Откуда: Санкт-Петербург

kernel panic после апгрейда с 9.2 до 10.3

Непрочитанное сообщение snorlov » 2017-02-16 10:33:41

Вы все-таки

Код: Выделить всё

zpool upgrade
сделайте, как никак, а версия zfs изменилась...

Neus
капитан
Сообщения: 1718
Зарегистрирован: 2008-09-08 21:59:56

kernel panic после апгрейда с 9.2 до 10.3

Непрочитанное сообщение Neus » 2017-02-16 10:54:41

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

Может оттуда ноги растут?

iles
проходил мимо
Сообщения: 1
Зарегистрирован: 2017-03-15 14:26:05

kernel panic после апгрейда с 9.2 до 10.3

Непрочитанное сообщение iles » 2017-03-15 14:32:42

Была такая же хрень...
Вариантов два..

1. Убираете из ядра все упоминания про ALTQ, пересборка - и все будет норм.

2. Проводите патч драйвера igb как сказано здесь:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213257

Все вышесказанное касается только драйвером IGB, на EM драйверах такой проблемы нет...

dm07
сержант
Сообщения: 222
Зарегистрирован: 2008-07-27 19:58:25
Откуда: Уфа
Контактная информация:

kernel panic после апгрейда с 9.2 до 10.3

Непрочитанное сообщение dm07 » 2017-03-15 14:37:08

Пантку ядра вызывает ipfilter и возможно совместно с картой realtek. Развернул freebsd 10.3 на новом сервере, при даже незначительных нагрузках происходит паника... Отключаю все правила ipfilter, паники нет.начинаю изучать pf и пересобирать ядро с ним.

Visionman
рядовой
Сообщения: 20
Зарегистрирован: 2015-10-06 22:28:29

kernel panic после апгрейда с 9.2 до 10.3

Непрочитанное сообщение Visionman » 2017-05-16 11:36:19

Аналогичное случалось на сервере HP ProLiant ML150 Gen9 E5-2620v3 Hot Plug TOWER (5U)
Индекс модели - 780852-425
При высокой дисковой нагрузке, передача больших объёмов используя rsync, через 33 - 34 секунды, в системе возникала паника.

Виновником был контроллер RAID HP Dynamic Smart Array B140i
После отключения дисков от контроллера и подключения дисков на контроллер материнской платы, проблема исчезла.

dm07
сержант
Сообщения: 222
Зарегистрирован: 2008-07-27 19:58:25
Откуда: Уфа
Контактная информация:

kernel panic после апгрейда с 9.2 до 10.3

Непрочитанное сообщение dm07 » 2017-05-16 11:39:24

В моем случае панику вызывала связка realtek + ipfilter, backtrace четко показывал проблему в драйверах карты и ipf. Переход на pf избавил от этой напасти.



Вернуться в «FreeBSD»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 5 гостей