пересобрал ядро с makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols makeoptions WITH_CTF=1 # Run ctfconvert(1) for DTrace support

ну, попробуй указать теперь дебаговый файл вторым аргументом к kgdb и снова

# kgdb -c vmcore.9 kgdb: couldn't find a suitable kernel image

> вторым аргументом.

или первым, если без -c

# kgdb vmcore.9 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...vmcore.9: No such file or directory. (kgdb) bt No stack. (kgdb)

в третий раз повторяю: найди собранный с дебагом файл ядра (это будет длинный путь) и укажи ЕЩЕ ОДНИМ аргументом командной строки (заглянув в ман)

еще раз, прочти свои рекомендации, и сам загляни в ман

ядро с дебагом тоже проблематично собрать добавление тех двух опций тоже не дало эффекта

SYNOPSIS kgdb [-a | -f | -fullname] [-b rate] [-q | -quiet] [-v] [-w] [-d crashdir] [-c core | -n dumpnr | -r device] [kernel [core]] чо, неужели додуматься до kgdb /bla/bla/kernel.debug vmcore.9 - это ТАК сложно ?

не быть тебе троллем

что такое квадратные скобки понятно?

это необязательные условия

я начинаю понимать слоника в домене

действительно, соображающих админов чот хер найти щас

ага, программисов, которые НЕ пишут нестабильный код, с актуальной документации тоже надо найти

Смотря что писать и для кого, наверное

А, ну и за сколько :)

вот-вот

в этом месте я начинаю понимать Севку Стахова, который чуть что, начинает материться как гопник

сколько у меня висят баг репортами с корками и трассами

годами висят

и только после полного переписывания модуля, эти баги уходят

а уж что в закрытом проприетарном коде с платной поддержкой творится...

Ну дык)

Оно ж ведь как... Залатай сам)

ну там ты и сам залатать не можешь

наличие открытого кода не гарантирует мгновенного решения проблемы

оно единствнно зачем нужно - прикрыть жопу перед начальством "платный суппорт не помог"

вот очередное чудо. # ll /usr/bin/ztest -r-xr-xr-x 1 root wheel 137440 29 сент. 18:54 /usr/bin/ztest* # man ztest No manual entry for ztest на сайте вообще ман к другой утилите https://www.freebsd.org/cgi/man.cgi?query=ztest

вот очередное чудо. # ll /usr/bin/ztest -r-xr-xr-x 1 root wheel 137440 29 сент. 18:54 /usr/bin/ztest* # man ztest No manual entry for ztest на сайте вообще ман к другой утилите https://www.freebsd.org/cgi/man.cgi?query=ztest

это zfs test suite который интересен главным образом разработчикам zfs, видимо по этом поленились man написать

судя по -h интересная штука для тестирования ZFS пулов

а с какой примерно версии дебаг символы укладываются в отдельную диреткорию? /usr/lib/debug/boot/kernel

# kgdb /usr/lib/debug/boot/kernel/kernel.debug /var/crash/vmcore.9 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Cannot access memory at address 0x0 (kgdb) bt #0 0x0000000000000000 in ?? () Cannot access memory at address 0x0

все равно непонятно, кто виноват

а с какой примерно версии дебаг символы укладываются в отдельную диреткорию? /usr/lib/debug/boot/kernel

less /usr/src/UPDATING /20150924

ох ты ж ё

# kgdb /usr/lib/debug/boot/kernel/kernel.debug /var/crash/vmcore.9 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Cannot access memory at address 0x0 (kgdb) bt #0 0x0000000000000000 in ?? () Cannot access memory at address 0x0

отладочные символы от того же ядра что отложило vmcore.9? если символы свежее, то нужно ждать свежей корки и изучать её.

это мелочи

щас опять паник будет

еще можно включить textdumps - добавить ddb_enable="YES" в /etc/rc.conf (остальное в дефолтном /etc/ddb.conf)

Обновился на 11.2, иксы перестали запускаться. Дрова nvidia собрал из портов, сейчас xorg из портов пересобираю, потомк что в pkg лезет собранный для 11.1

У кого было такое? Или иксы 11.1 должны работать?

обычно после смены версии системы, нужно пересобирать софт

Да я pkg-static upgrade -f

И всегда норм было

есть дебаг

# kgdb /usr/lib/debug/boot/kernel/kernel.debug /var/crash/vmcore.2 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 02 fault virtual address = 0x28 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff808e080b stack pointer = 0x28:0xfffffe00003c67b0 frame pointer = 0x28:0xfffffe00003c6800 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 (swi4: clock (0)) trap number = 12 panic: page fault cpuid = 2 KDB: stack backtrace: #0 0xffffffff806fa647 at kdb_backtrace+0x67 #1 0xffffffff806b9867 at vpanic+0x177 #2 0xffffffff806b96e3 at panic+0x43 #3 0xffffffff80a9f28f at trap_fatal+0x35f #4 0xffffffff80a9f2e9 at trap_pfault+0x49 #5 0xffffffff80a9ea02 at trap+0x2a2 #6 0xffffffff80a80e2e at calltrap+0x8 #7 0xffffffff806cf39c at softclock_call_cc+0x11c #8 0xffffffff806cf739 at softclock+0x79 #9 0xffffffff806846ef at intr_event_execute_handlers+0xdf #10 0xffffffff80684977 at ithread_loop+0xb7 #11 0xffffffff80681b26 at fork_exit+0x76 #12 0xffffffff80a81dee at fork_trampoline+0xe Uptime: 2m3s Dumping 1338 out of 32527 MB:..2%..11%..21%..32%..41%..51%..61%..71%..81%..91% Reading symbols from /usr/lib/debug/boot/kernel/zfs.ko.debug...done. Loaded symbols for /usr/lib/debug/boot/kernel/zfs.ko.debug Reading symbols from /usr/lib/debug/boot/kernel/opensolaris.ko.debug...done. Loaded symbols for /usr/lib/debug/boot/kernel/opensolaris.ko.debug Reading symbols from /usr/lib/debug/boot/kernel/cc_htcp.ko.debug...done. Loaded symbols for /usr/lib/debug/boot/kernel/cc_htcp.ko.debug #0 doadump (textdump=<value optimized out>) at pcpu.h:230 230 pcpu.h: No such file or directory. in pcpu.h (kgdb)

(kgdb) bt #0 doadump (textdump=<value optimized out>) at pcpu.h:230 #1 0xffffffff806b94d6 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:383 #2 0xffffffff806b98a1 in vpanic (fmt=<value optimized out>, ap=<value optimized out>) at /usr/src/sys/kern/kern_shutdown.c:776 #3 0xffffffff806b96e3 in panic (fmt=<value optimized out>) at /usr/src/sys/kern/kern_shutdown.c:707 #4 0xffffffff80a9f28f in trap_fatal (frame=0xfffffe00003c66f0, eva=40) at /usr/src/sys/amd64/amd64/trap.c:910 #5 0xffffffff80a9f2e9 in trap_pfault (frame=0xfffffe00003c66f0, usermode=0) at pcpu.h:230 #6 0xffffffff80a9ea02 in trap (frame=0xfffffe00003c66f0) at /usr/src/sys/amd64/amd64/trap.c:438 #7 0xffffffff80a80e2e in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #8 0xffffffff808e080b in tcp_fastopen_autokey_callout (arg=0xfffffe0000dd1b10) at /usr/src/sys/netinet/tcp_fastopen.c:246 #9 0xffffffff806cf39c in softclock_call_cc (c=0xfffffe0000dd1b10, cc=0xffffffff81281e00, direct=0) at /usr/src/sys/kern/kern_timeout.c:729 #10 0xffffffff806cf739 in softclock (arg=0xffffffff81281e00) at /usr/src/sys/kern/kern_timeout.c:867 #11 0xffffffff806846ef in intr_event_execute_handlers (p=<value optimized out>, ie=0xfffff80006008d00) at /usr/src/sys/kern/kern_intr.c:1336 #12 0xffffffff80684977 in ithread_loop (arg=0xfffff80005fdb540) at /usr/src/sys/kern/kern_intr.c:1349 #13 0xffffffff80681b26 in fork_exit (callout=0xffffffff806848c0 <ithread_loop>, arg=0xfffff80005fdb540, frame=0xfffffe00003c69c0) at /usr/src/sys/kern/kern_fork.c:1072 #14 0xffffffff80a81dee in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:975 #15 0x0000000000000000 in ?? () Current language: auto; currently minimal

есть еще core.txt.2

имхо, опция tcp_fastopen виновата в паниках

# options TCP_RFC7413 # /sys/netinet/tcp_fastopen.c net.inet.tcp.fastopen.enabled=1

есть дебаг

https://svnweb.freebsd.org/base?view=revision&revision=313168

есть VIMAGE у тебя?

нет

дедик

11.2-STABLE #0 r339016: Sat Sep 29 20:01:28 EEST 2018

а, не

в опциях таки есть VIMAGE

вырубать options VIMAGE ? или кто-то будет разбираться подробнее в проблеме?

ну выглядит как тоже самое что вот тут https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216613

можно либо отключить VIMAGE, либо запатчить патчем из r313168

ERROR: S client not available

а может, вы добавите патч в 11-ую ветку?

ну вот вы попробуйте его, если скомпилится и поможет, то в принципе можно и добавить

проще выключить опцию

Аппаратное тегирование vlan'нов на igb ломает udp. Что-то за последние 2 недели я узнал о багах в очевидных местах FreeBSD больше чем хотелось бы.

Часа пытался понять почему AP не видит dhcp offer хотя ей посылают

Пользователей мало, некому баги тестировать и репортить. Да и что зарепорчены некому фиксить порой. FreeBSD в не очень удачном позиции - много кода и много сложных фич, но мало людей. В Net/Open людей меньше, но там и кода сильно меньше (и фич меньше и с производительностью хуже).

Аппаратное тегирование vlan'нов на igb ломает udp. Что-то за последние 2 недели я узнал о багах в очевидных местах FreeBSD больше чем хотелось бы.

бывают такие сезоны наплывов, да

Пользователей мало, некому баги тестировать и репортить. Да и что зарепорчены некому фиксить порой. FreeBSD в не очень удачном позиции - много кода и много сложных фич, но мало людей. В Net/Open людей меньше, но там и кода сильно меньше (и фич меньше и с производительностью хуже).

ну интеловский драйвер!

ну интеловский драйвер!

умвр

10.2-S

?

ну интеловский драйвер!

и на старуху бывает порнуха :)

ну качество кода который сотрудники Intel самбитят во Фрю не очень высокое. Даже в Linux они не очень хороший код сабмитят AFAIK.

прошли времена, когда можно было рекомендовать интеловые карты

сейчас мелланокс и челсия рулят

прошли времена, когда можно было рекомендовать интеловые карты

ixgbe норм работает. а igb во временя 7.х был довольно косячным

да и пока что интел на 10Г остановились, 40Г у них полный отстой

у ixgbe тоже есть проблемы, особенно с новыми драйверами

сейчас мелланокс и челсия рулят

интересно работает ли на них Intel DPDK? На нём сильно больше опенсурсных проектов чем на Netmap.

работает

нетмап тоже страдает болезнью поделок от Луиджи

студенты чего-то там налабали для лабораторных и презентаций, а в реальности это использовать нельзя

прошли времена, когда можно было рекомендовать интеловые карты

ну я вот специально искал коробку с интелом а не реалтеком. челсия и мелланокс это другая лига

студенты чего-то там налабали для лабораторных и презентаций, а в реальности это использовать нельзя

ну ipfw2 и libalias таки довели :)

и вот https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231416

про libalias и dummynet выкинуть бы давно пора

эээ

про libalias и dummynet выкинуть бы давно пора

и что вместо? пф?

предложите замену dummynet

а в ipfw уже от их кода мало чего осталось

то что нет альтернативы, не делает этот код прекрасным

чтоб и трубу делать и в ней заданные задержки-потери пакетов