[freebsd] server reboots, как детектировать проблему?

104 views
Skip to first unread message

Sergej Kandyla

unread,
May 15, 2009, 4:52:14 AM5/15/09
to fre...@uafug.org.ua

Господа, есть очень странные глюки с сервером.
Работал себе сервак в течении пары лет без особых проблем, а с месяц
назад сервак начал спонтанно ребутится.

Обновился до послдней фри 6.4p3 (мир само собой), обновил порты, которые
светились в portaudit.
Не помогло.

Заменили железо: винты со сбойного сервера переставили в сосдений
сервер, работающий без сбоев. (т.е. поменяли винты на серверах местами)
Тоже не помогло.

Решил что глюки в винтах. По смарту из подозрительного было только
некоторое колличество pending sectors. (так полагаю что было вызвано
ребутами...)
Заменили винты. Систему переносили на новый винт при помощи стандартного
dump\restore.
Т.е. получается что полностью заменили железо.

Не помогло. Сервер в ребуты как уходил так и уходит.

Вопрос, какого собсно х ?

Собрал ядро с makeoptions DEBUG=-g
в rc.conf прописал

dumpdev="AUTO"
dumpdir="/var/crash"
savecore_flags="-v"

Но балалайка,
messages:
May 15 07:02:47 srv savecore: no dumps found

ipkvma нет - сам взглянуть не могу. А Саппорт путает fsck с
"дефрагментацией"......


Текущее железо:
#-------------------

hw.model: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+
hw.physmem: 2120581120

ad8: 476940MB <SAMSUNG HD501LJ CR100-12> at ata4-master SATA300
ad10: 476940MB <SAMSUNG HD501LJ CR100-12> at ata5-master SATA300

nve0: <NVIDIA nForce MCP13 Networking Adapter> port 0xc800-0xc807 mem
0xfe02b000-0xfe02bfff irq 23 at device 20.0 on pci0


OS specific:
#-------------------
6.4-RELEASE-p4 i386


## loader.conf:

kern.maxusers="1024"
net.inet.tcp.syncache.hashsize="1024"
net.inet.tcp.syncache.bucketlimit="100"
net.inet.tcp.tcbhashsize="4096"
kern.ipc.nmbclusters="32768"

geom_mirror_load="YES" # осталось от старого железа, где винты
были в gmirror
verbose_loading="YES"


## KERNCONF:

makeoptions DEBUG=-g # Build kernel with gdb(1) debug
symbols

options DEVICE_POLLING
options HZ=1000

options MROUTING
options IPFIREWALL
options IPFIREWALL_DEFAULT_TO_ACCEPT
options IPSTEALTH
options TCP_DROP_SYNFIN
options DUMMYNET

options ACCEPT_FILTER_DATA
options ACCEPT_FILTER_HTTP

device pf
device pflog

options QUOTA
options SMP # Symmetric MultiProcessor Kernel

Все остальное стандартный GENERIC с выкидыванием ненужного.


## make.conf:
NO_CPU_CFLAGS=true
CFLAGS=-O -pipe -march=i686 -mtune=i686


## rc.conf
fsck_y_enable="YES"
background_fsck="NO"

dumpdev="AUTO"
dumpdir="/var/crash"
savecore_flags="-v"

root@srv~: smartctl -A /dev/ad8 # текущий рабочий винт
smartctl version 5.37 [i386-portbld-freebsd6.1] Copyright (C) 2002-6
Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE
UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 100 100 051 Pre-fail
Always - 1
3 Spin_Up_Time 0x0007 100 100 015 Pre-fail
Always - 4608
4 Start_Stop_Count 0x0032 100 100 000 Old_age
Always - 16
5 Reallocated_Sector_Ct 0x0033 253 253 010 Pre-fail
Always - 0
7 Seek_Error_Rate 0x000f 253 253 051 Pre-fail
Always - 0
8 Seek_Time_Performance 0x0025 253 253 015 Pre-fail
Offline - 0
9 Power_On_Hours 0x0032 100 100 000 Old_age
Always - 4088
10 Spin_Retry_Count 0x0033 253 253 051 Pre-fail
Always - 0
11 Calibration_Retry_Count 0x0012 253 253 000 Old_age
Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age
Always - 16
13 Read_Soft_Error_Rate 0x000e 100 100 000 Old_age
Always - 20645502
187 Unknown_Attribute 0x0032 253 253 000 Old_age
Always - 0
188 Unknown_Attribute 0x0032 253 253 000 Old_age
Always - 0
190 Temperature_Celsius 0x0022 077 060 000 Old_age
Always - 23
194 Temperature_Celsius 0x0022 169 118 000 Old_age
Always - 23
195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age
Always - 20645502
196 Reallocated_Event_Count 0x0032 253 253 000 Old_age
Always - 0
197 Current_Pending_Sector 0x0012 253 253 000 Old_age
Always - 0
198 Offline_Uncorrectable 0x0030 253 253 000 Old_age
Offline - 0
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age
Always - 3
200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age
Always - 0
201 Soft_Read_Error_Rate 0x000a 100 100 000 Old_age
Always - 0
202 TA_Increase_Count 0x0032 253 253 000 Old_age
Always - 0


root@srv~: portaudit
0 problem(s) in your installed packages found.


Некоторые могут увидеть nve, и сказать что при условно большом трафике
nve приводит к гарантированным кернел паникам.
Я сам на это натыкался именно на этом железе.

Во избежание влияния данного фактора с nve, ограничил полосу к серверу:
##

$fw pipe 10 config bw 10Mbit/s
$fw queue 10 config pipe 10 weight 50 mask dst-ip 0xffffffff
$fw add 910 queue 10 tcp from me not 22 to any via $ext_if out


$fw pipe 20 config bw 10Mbit/s
$fw queue 20 config pipe 20 weight 50 mask dst-ip 0xffffffff
$fw add 920 queue 20 tcp from any to me not 22 via $ext_if in

(по ссш данных не гоняю)
По личной практике 6ка с nve уходит в ребут при трафике >= 20Mbit\s

Но данный сервак уходил в ребут без какой-либо сетевой нагрузки (по
mrtg трафик около 4 часов ночи перед ребутом был порядка 2мбит.)

Куда ж копать то...?

Осталась одна идея, это обновится с 6.4 на 7.2
уже мир и ядро собрал, но всеже 6.4 все таки актуальная система.....
(какието нюнсы при таком апдейте могут быть?)


Еще правильно ли я понимаю, что никакие глюки и баги портов, не могут и
не должны вызывать кернел паник на актуальной системе?

--
Best wishes, Sergej Kandyla

Alexander Shikoff

unread,
May 15, 2009, 6:57:48 AM5/15/09
to Sergej Kandyla, fre...@uafug.org.ua
On Fri, May 15, 2009 at 11:52:14AM +0300, Sergej Kandyla wrote:
>
> Господа, есть очень странные глюки с сервером.
> Работал себе сервак в течении пары лет без особых проблем, а с месяц
> назад сервак начал спонтанно ребутится.

Память memtestом прогнать. Если виновата память - то будет ребутиться при
тесте.

Второй вариант - блок питания.

--
MINO-RIPE

Andrey Voitenkov

unread,
May 15, 2009, 7:38:07 AM5/15/09
to fre...@uafug.org.ua
Sergej Kandyla wrote:
[...]

> Но балалайка,
> messages:
> May 15 07:02:47 srv savecore: no dumps found
>
> ipkvma нет - сам взглянуть не могу. А Саппорт путает fsck с
> "дефрагментацией"......
>
Дампа нет, саппорт "странный". Там точно нет тети Маши со шваброй,
которая пинает плохо прикрученную розетку, от которой питается сервер?
Или дяди Васи со сварочным аппаратом? Я бы в первую очередь питание
проверял после полной замены железа.

[...]


>
> Еще правильно ли я понимаю, что никакие глюки и баги портов, не могут и
> не должны вызывать кернел паник на актуальной системе?
>

Насчет паник никаких доказательств нет пока что.


--
mccloud@

Sergej Kandyla

unread,
May 15, 2009, 8:21:07 AM5/15/09
to UaFUG
Andrey Voitenkov пишет:

> Sergej Kandyla wrote:
> [...]
>> Но балалайка,
>> messages:
>> May 15 07:02:47 srv savecore: no dumps found
>>
>> ipkvma нет - сам взглянуть не могу. А Саппорт путает fsck с
>> "дефрагментацией"......
>>
> Дампа нет, саппорт "странный". Там точно нет тети Маши со шваброй,
> которая пинает плохо прикрученную розетку, от которой питается сервер?
> Или дяди Васи со сварочным аппаратом? Я бы в первую очередь питание
> проверял после полной замены железа.


в 11 вечера и 4 утра тети маши в гермозоне быть никак не должно.
не хочу дескридитировать контору, но имя ей wnet.


На счет железа....
винт с OS был переставлен на соседний сервер (который уже год как стоял
в стойке и работал без сбоев)
после этого OS еще и была перенесена на почти новый винт (смарт я приводил).

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

>
> [...]
>>
>> Еще правильно ли я понимаю, что никакие глюки и баги портов, не могут
>> и не должны вызывать кернел паник на актуальной системе?
>>
> Насчет паник никаких доказательств нет пока что.
>
>


--
Best wishes, Sergej Kandyla

Andrey Voitenkov

unread,
May 15, 2009, 9:00:17 AM5/15/09
to UaFUG
Sergej Kandyla wrote:
>>> Но балалайка,
>>> messages:
>>> May 15 07:02:47 srv savecore: no dumps found
>>>
>>> ipkvma нет - сам взглянуть не могу. А Саппорт путает fsck с
>>> "дефрагментацией"......
>>>
>> Дампа нет, саппорт "странный". Там точно нет тети Маши со шваброй,
>> которая пинает плохо прикрученную розетку, от которой питается сервер?
>> Или дяди Васи со сварочным аппаратом? Я бы в первую очередь питание
>> проверял после полной замены железа.
>
>
> в 11 вечера и 4 утра тети маши в гермозоне быть никак не должно.
> не хочу дескридитировать контору, но имя ей wnet.
>
гыгыгы.
Извините :)

Моя железка там перегружалась раз 1-2 недели, проблема решилась
переездом. У Wnet'а проблемы даже не технические, к технарям как раз
претензий не было, там где-то глубоко в менеджменте что-то не то (моё
субъективное мнение как бывшего клиента). Остальное - следствие.


> На счет железа....
> винт с OS был переставлен на соседний сервер (который уже год как стоял
> в стойке и работал без сбоев)
> после этого OS еще и была перенесена на почти новый винт (смарт я
> приводил).
>
> ну не может одна и таже система сбоить на двух вполне исправных
> серверах,...
>

Теория вероятностей этого не исключает. Но лучше начните с переезда,
в Киеве выбор ДЦ достаточно хороший.


p.s. полный оффтопик пошел, надо заканчивать.


--
mccloud@

Sergej Kandyla

unread,
May 18, 2009, 4:24:45 AM5/18/09
to UaFUG
Sergej Kandyla пишет:

>>>
>>> ipkvma нет - сам взглянуть не могу. А Саппорт путает fsck с
>>> "дефрагментацией"......
>
> На счет железа....
> винт с OS был переставлен на соседний сервер (который уже год как
> стоял в стойке и работал без сбоев)
> после этого OS еще и была перенесена на почти новый винт (смарт я
> приводил).
>


Напоминаю предисторию.
глюки начались спонтанно. Серв (6.2p8 i386) стал ребутится
(приблизительно с 0409 ). (до этого работал нормально продолжительное
время.)
накатились до 6.4p3 - не помогло.
поменяли железо (переставили винт с OS в другой рабочий серв, в другом
месте в стойке) - не помогло.
перенесли (dump\restore) OS на новый винт - не помогло.
еще раз накатились до 6.4p4 - не помогло.

накатился до 7.2 (стандартным способом)
(порты пока не пересобирал, работают на старых либах от 6ки)

Пока что словил только один кернелпаник. Бектрейс ниже.

|May 16 17:16:13 srv savecore: reboot after panic: page fault
May 16 17:16:13 srv savecore: writing core to vmcore.0

# cd /var/crashe
# kgdb -q /boot/kernel/kernel vmcore.0 | tee backtrace1.txt
Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/acpi.ko
Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from /boot/kernel/nullfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/nullfs.ko
Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from /boot/kernel/fdescfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/fdescfs.ko
#0 doadump () at pcpu.h:196
in pcpu.h

(kgdb) bt
#0 doadump () at pcpu.h:196
#1 0xc0814467 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
#2 0xc0814739 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:574
#3 0xc0b2af4c in trap_fatal (frame=0xc78698d8, eva=11) at /usr/src/sys/i386/i386/trap.c:939
#4 0xc0b2b1d0 in trap_pfault (frame=0xc78698d8, usermode=0, eva=11) at /usr/src/sys/i386/i386/trap.c:852
#5 0xc0b2bb7c in trap (frame=0xc78698d8) at /usr/src/sys/i386/i386/trap.c:530
#6 0xc0b1028b in calltrap () at /usr/src/sys/i386/i386/exception.s:159
#7 0xc08bed67 in rn_match (v_arg=0xc0ccd06c, head=0xc8165e00) at /usr/src/sys/net/radix.c:262
#8 0xc04ba003 in pfr_match_addr (kt=0xc83554d8, a=0xcc69601c, af=2 '\002') at /usr/src/sys/contrib/pf/net/pf_table.c:2104
#9 0xc04a3feb in pf_test_udp (rm=0xc7869ae8, sm=0xc7869ae4, direction=1, kif=0xc7ebfe00, m=0xccf39b00, off=20, h=0xcc696010, pd=0xc7869a80,
am=0xc7869aec, rsm=0xc7869ae0, ifq=0x0, inp=0x0) at /usr/src/sys/contrib/pf/net/pf.c:3729
#10 0xc04a85ff in pf_test (dir=1, ifp=0xc7e78800, m0=0xc7869b44, eh=0x0, inp=0x0) at /usr/src/sys/contrib/pf/net/pf.c:6941
#11 0xc04ad996 in pf_check_in (arg=0x0, m=0xc7869b44, ifp=0xc7e78800, dir=1, inp=0x0) at /usr/src/sys/contrib/pf/net/pf_ioctl.c:3647
#12 0xc08be3a8 in pfil_run_hooks (ph=0xc0d0da40, mp=0xc7869ba0, ifp=0xc7e78800, dir=1, inp=0x0) at /usr/src/sys/net/pfil.c:78
#13 0xc09036aa in ip_input (m=0xccf39b00) at /usr/src/sys/netinet/ip_input.c:416
#14 0xc08bcb25 in netisr_dispatch (num=2, m=0xccf39b00) at /usr/src/sys/net/netisr.c:185
#15 0xc08b2ac1 in ether_demux (ifp=0xc7e78800, m=0xccf39b00) at /usr/src/sys/net/if_ethersubr.c:834
#16 0xc08b2eb3 in ether_input (ifp=0xc7e78800, m=0xccf39b00) at /usr/src/sys/net/if_ethersubr.c:692
#17 0xc0afda0b in nfe_rxeof (sc=0xc7e90000, count=3) at /usr/src/sys/dev/nfe/if_nfe.c:2116
#18 0xc0afdff2 in nfe_poll (ifp=0xc7e78800, cmd=POLL_ONLY, count=5) at /usr/src/sys/dev/nfe/if_nfe.c:1570
#19 0xc080777b in netisr_poll () at /usr/src/sys/kern/kern_poll.c:432
#20 0xc08bcd92 in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:254
#21 0xc07f130b in ithread_loop (arg=0xc7c9a260) at /usr/src/sys/kern/kern_intr.c:1088
#22 0xc07ede59 in fork_exit (callout=0xc07f1150 <ithread_loop>, arg=0xc7c9a260, frame=0xc7869d38) at /usr/src/sys/kern/kern_fork.c:810
#23 0xc0b10300 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264

(kgdb) bt full
#0 doadump () at pcpu.h:196
No locals.
#1 0xc0814467 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
_giantcnt = (kgdb) quit

(kgdb) printf "%s", (char *)msgbufp->msg_ptr
Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.2-RELEASE #0: Fri May 15 09:19:22 EEST 2009
root@srv:/usr/obj/usr/src/sys/srv7
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2204.61-MHz 686-class CPU)
Origin = "AuthenticAMD" Id = 0x40fb2 Stepping = 2
Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
Features2=0x2001<SSE3,CX16>
AMD Features=0xea500800<SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow!>
AMD Features2=0x1f<LAHF,CMP,SVM,ExtAPIC,CR8>
Cores per package: 2
real memory = 2129526784 (2030 MB)
avail memory = 2072993792 (1976 MB)
ACPI APIC Table: <Nvidia ASUSACPI>
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
cpu0 (BSP): APIC ID: 0
cpu1 (AP): APIC ID: 1
ioapic0: Changing APIC ID to 2
ioapic0 <Version 1.1> irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0: <Nvidia ASUSACPI> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of 7eee0000, 20000 (3) failed
acpi0: reservation of 0, a0000 (3) failed
acpi0: reservation of 100000, 7ede0000 (3) failed
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0
acpi_hpet0: <High Precision Event Timer> iomem 0xfefff000-0xfefff3ff on acpi0
Timecounter "HPET" frequency 25000000 Hz quality 900
acpi_button0: <Power Button> on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pci0: <memory, RAM> at device 0.0 (no driver attached)
pci0: <memory, RAM> at device 0.1 (no driver attached)
pci0: <memory, RAM> at device 0.2 (no driver attached)
pci0: <memory, RAM> at device 0.3 (no driver attached)
pci0: <memory, RAM> at device 0.4 (no driver attached)
pci0: <memory, RAM> at device 0.5 (no driver attached)
pci0: <memory, RAM> at device 0.6 (no driver attached)
pci0: <memory, RAM> at device 0.7 (no driver attached)
pcib1: <ACPI PCI-PCI bridge> at device 2.0 on pci0
pci1: <ACPI PCI bus> on pcib1
pcib2: <ACPI PCI-PCI bridge> at device 3.0 on pci0
pci2: <ACPI PCI bus> on pcib2
pcib3: <ACPI PCI-PCI bridge> at device 4.0 on pci0
pci3: <ACPI PCI bus> on pcib3
vgapci0: <VGA-compatible display> mem 0xfb000000-0xfbffffff,0xd0000000-0xdfffffff,0xfc000000-0xfcffffff irq 16 at device 5.0 on pci0
pci0: <memory, RAM> at device 9.0 (no driver attached)
isab0: <PCI-ISA bridge> at device 10.0 on pci0
isa0: <ISA bus> on isab0
pci0: <serial bus, SMBus> at device 10.1 (no driver attached)
pci0: <memory, RAM> at device 10.2 (no driver attached)
atapci0: <nVidia nForce MCP51 UDMA133 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf400-0xf40f at device 13.0 on pci0
ata0: <ATA channel 0> on atapci0
ata0: [ITHREAD]
ata1: <ATA channel 1> on atapci0
ata1: [ITHREAD]
atapci1: <nVidia nForce MCP51 SATA300 controller> port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xe000-0xe00f mem 0xfe02d000-0xfe02dfff irq 21 at device 14.0 on pci0
atapci1: [ITHREAD]
ata2: <ATA channel 0> on atapci1
ata2: [ITHREAD]
ata3: <ATA channel 1> on atapci1
ata3: [ITHREAD]
atapci2: <nVidia nForce MCP51 SATA300 controller> port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xcc00-0xcc0f mem 0xfe02c000-0xfe02cfff irq 22 at device 15.0 on pci0
atapci2: [ITHREAD]
ata4: <ATA channel 0> on atapci2
ata4: [ITHREAD]
ata5: <ATA channel 1> on atapci2
ata5: [ITHREAD]
pcib4: <ACPI PCI-PCI bridge> at device 16.0 on pci0
pci4: <ACPI PCI bus> on pcib4
nfe0: <NVIDIA nForce 430 MCP13 Networking Adapter> port 0xc800-0xc807 mem 0xfe02b000-0xfe02bfff irq 23 at device 20.0 on pci0
miibus0: <MII bus> on nfe0
e1000phy0: <Marvell 88E1116 Gigabit PHY> PHY 1 on miibus0
e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto
nfe0: Ethernet address: 00:1b:fc:c3:02:fc
nfe0: [FILTER]
acpi_tz0: <Thermal Zone> on acpi0
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
sio0: type 16550A
sio0: [FILTER]
sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
sio1: [FILTER]
cpu0: <ACPI CPU> on acpi0
powernow0: <PowerNow! K8> on cpu0
cpu1: <ACPI CPU> on acpi0
powernow1: <PowerNow! K8> on cpu1
pmtimer0 on isa0
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0
ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode
ppbus0: <Parallel port bus> on ppc0
ppbus0: [ITHREAD]
plip0: <PLIP network interface> on ppbus0
plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag
lpt0: <Printer> on ppbus0
lpt0: Interrupt-driven port
ppi0: <Parallel I/O> on ppbus0
ppc0: [GIANT-LOCKED]
ppc0: [ITHREAD]
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
Timecounters tick every 1.000 msec
ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based forwarding disabled, default to accept, logging disabled


ad8: 476940MB <SAMSUNG HD501LJ CR100-12> at ata4-master SATA300
ad10: 476940MB <SAMSUNG HD501LJ CR100-12> at ata5-master SATA300

SMP: AP CPU #1 Launched!
......
......
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0xb
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc08bed67
stack pointer = 0x28:0xc7869918
frame pointer = 0x28:0xc7869944
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 13 (swi1: net)
trap number = 12
panic: page fault
cpuid = 1
Uptime: 23h58m22s
Physical memory: 2018 MB
Dumping 326 MB: 311 295 279 263 247 231 215 199 183 167 151 135 119 103 87 71 55 39 23 7(kgdb)

(kgdb) list *0xc08bed67
0xc08bed67 is in rn_match (/usr/src/sys/net/radix.c:266).
261 caddr_t v = v_arg;
262 register struct radix_node *t = head->rnh_treetop, *x;
263 register caddr_t cp = v, cp2;
264 caddr_t cplim;
265 struct radix_node *saved_t, *top = t;
266 int off = t->rn_offset, vlen = LEN(cp), matched_off;
267 register int test, b, rn_bit;
268
269 /*
270 * Open code rn_search(v, top) to avoid overhead of extra
(kgdb) quit|

Сделал
|kern.polling.enable=0|

После этого аптайм почти под два дня, но я не уверен что это последняя
точка в этой истории.
Какие будут еще идеи ?

Sergey A. Kobzar

unread,
May 18, 2009, 4:56:05 AM5/18/09
to UaFUG

> Сделал
> |kern.polling.enable=0|

У меня подобные симптомы были, на Dell'овском сервере на 6-ке.
Несколько раз получилось поймать kernel panic. Отключение pooling'а
перманентно решило проблему.


--
Sergey

Sergej Kandyla

unread,
May 18, 2009, 8:59:24 AM5/18/09
to UaFUG
Sergey A. Kobzar пишет:

>> Пока что словил только один кернелпаник. Бектрейс ниже.
>>
> У меня подобные симптомы были, на Dell'овском сервере на 6-ке.
> Несколько раз получилось поймать kernel panic. Отключение pooling'а
> перманентно решило проблему.
>
>
>

новый бектрейс (с отключенным поллингом)

# backtrace1.txt


Reading symbols from /boot/kernel/acpi.ko...Reading symbols from
/boot/kernel/acpi.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/acpi.ko
Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from
/boot/kernel/nullfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/nullfs.ko
Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from
/boot/kernel/fdescfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/fdescfs.ko
#0 doadump () at pcpu.h:196
in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:196
#1 0xc0814467 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
#2 0xc0814739 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:574

#3 0xc0b2af4c in trap_fatal (frame=0xc7931908, eva=12) at
/usr/src/sys/i386/i386/trap.c:939
#4 0xc0b2b1d0 in trap_pfault (frame=0xc7931908, usermode=0, eva=12) at
/usr/src/sys/i386/i386/trap.c:852
#5 0xc0b2bb7c in trap (frame=0xc7931908) at

/usr/src/sys/i386/i386/trap.c:530
#6 0xc0b1028b in calltrap () at /usr/src/sys/i386/i386/exception.s:159

#7 0xc08bed67 in rn_match (v_arg=0xc0ccd06c, head=0xc81f7d00) at
/usr/src/sys/net/radix.c:262
#8 0xc04ba003 in pfr_match_addr (kt=0xc837a4d8, a=0xce81281c, af=2

'\002') at /usr/src/sys/contrib/pf/net/pf_table.c:2104

#9 0xc04a3feb in pf_test_udp (rm=0xc7931b18, sm=0xc7931b14,
direction=1, kif=0xc7ebfe00, m=0xceb01600, off=20, h=0xce812810,
pd=0xc7931ab0, am=0xc7931b1c, rsm=0xc7931b10, ifq=0x0, inp=0x0)
at /usr/src/sys/contrib/pf/net/pf.c:3729
#10 0xc04a85ff in pf_test (dir=1, ifp=0xc7e78800, m0=0xc7931b74, eh=0x0,
inp=0x0) at /usr/src/sys/contrib/pf/net/pf.c:6941
#11 0xc04ad996 in pf_check_in (arg=0x0, m=0xc7931b74, ifp=0xc7e78800,

dir=1, inp=0x0) at /usr/src/sys/contrib/pf/net/pf_ioctl.c:3647

#12 0xc08be3a8 in pfil_run_hooks (ph=0xc0d0da40, mp=0xc7931bd0,

ifp=0xc7e78800, dir=1, inp=0x0) at /usr/src/sys/net/pfil.c:78

#13 0xc09036aa in ip_input (m=0xceb01600) at
/usr/src/sys/netinet/ip_input.c:416
#14 0xc08bcb25 in netisr_dispatch (num=2, m=0xceb01600) at
/usr/src/sys/net/netisr.c:185
#15 0xc08b2ac1 in ether_demux (ifp=0xc7e78800, m=0xceb01600) at
/usr/src/sys/net/if_ethersubr.c:834
#16 0xc08b2eb3 in ether_input (ifp=0xc7e78800, m=0xceb01600) at
/usr/src/sys/net/if_ethersubr.c:692
#17 0xc0afda0b in nfe_rxeof (sc=0xc7e90000, count=191) at
/usr/src/sys/dev/nfe/if_nfe.c:2116
#18 0xc0affb1f in nfe_int_task (arg=0xc7e90000, pending=1) at
/usr/src/sys/dev/nfe/if_nfe.c:1831
#19 0xc08496f5 in taskqueue_run (queue=0xc7e6d780) at
/usr/src/sys/kern/subr_taskqueue.c:282
#20 0xc0849908 in taskqueue_thread_loop (arg=0xc7e90130) at
/usr/src/sys/kern/subr_taskqueue.c:401
#21 0xc07ede59 in fork_exit (callout=0xc0849840 <taskqueue_thread_loop>,
arg=0xc7e90130, frame=0xc7931d38) at /usr/src/sys/kern/kern_fork.c:810
#22 0xc0b10300 in fork_trampoline () at

/usr/src/sys/i386/i386/exception.s:264
(kgdb) bt full
#0 doadump () at pcpu.h:196
No locals.
#1 0xc0814467 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
_giantcnt = (kgdb) quit


(kgdb) printf "%s", (char *)msgbufp->msg_ptr

.....

Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01

fault virtual address = 0xc


fault code = supervisor read, page not present
instruction pointer = 0x20:0xc08bed67

stack pointer = 0x28:0xc7931948
frame pointer = 0x28:0xc7931974


code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0

current process = 27 (nfe0 taskq)


trap number = 12
panic: page fault
cpuid = 1

Uptime: 1d22h0m35s
Physical memory: 2018 MB
Dumping 336 MB: 321 305 289 273 257 241 225 209 193 177 161 145 129 113
97 81 65 49 33 17 1ux0


сетевая нагрузка низка, в среднем порядка 4мбит\с out и около 200
established connections, в пиках 16-20 мбит\с
в pf - ничего партийного, парочка таблиц, парочка редиректов...

я понимаю, что сетевуха, конечно, не фонтан, но вполне себе рабочая.
Есть ряд серверов на аналогичном железе. Да и на этом же тазике, до
этого работал винт с OS fbsd 7.0, и на которую временами приходилась
значительно большая нагрузка (~80мбит\с).....

Alexander Shikoff

unread,
May 18, 2009, 9:23:37 AM5/18/09
to Sergej Kandyla, UaFUG

Мне кажется, что это Ваша сетевуха имени nVidia.
Попробуйте выбросить nfe из ядра и поставить другую сетевуху.
Если с другой заведется и проработает нормально - то send-pr.

yongari@, который поддерживает nfe-драйвер, достаточно резво реагирует на
сообщения о паниках/багах etc.

--
MINO-RIPE

Sergej Kandyla

unread,
May 18, 2009, 9:28:59 AM5/18/09
to UaFUG
Sergej Kandyla пишет:

>
> накатился до 7.2 (стандартным способом)
> (порты пока не пересобирал, работают на старых либах от 6ки)

После обновления с 6.4 на 7.2 наблюдаю значительный рост loadaverage

http://paix.org.ua/tmp/loadavg-week-after-update-6.4-to-7.2.png

из изменений, это SCHED_ULE в 7ке.

поидее, так не должно быть.

Alexander Shikoff

unread,
May 18, 2009, 9:32:52 AM5/18/09
to Sergej Kandyla, UaFUG

Так у Вас в ядре включены ведь отладочные опции сейчас? Может, из-за
этого LA поднялся.

--
MINO-RIPE

Sergej Kandyla

unread,
May 18, 2009, 9:39:15 AM5/18/09
to UAFUG
Alexander Shikoff пишет:

я бы тоже на это грешил.
Но еще раз повторюсь, именно на этой железке больше года работала другая
система совершенно без проблем.
А текущая, глючная система уходила в ребуты и на прошлой железке с em
(железка кстати сейчас работает тоже без вопросов). К сожаленью
бектрейсов за тот период нет.

Кроме всего прочего....там корпус 1U.....


Может быть какойто софт валит систему?


> Если с другой заведется и проработает нормально - то send-pr.
>
> yongari@, который поддерживает nfe-драйвер, достаточно резво реагирует на
> сообщения о паниках/багах etc.
>
>


--
Best wishes, Sergej Kandyla

Sergej Kandyla

unread,
May 18, 2009, 9:50:18 AM5/18/09
to UAFUG
Alexander Shikoff пишет:
ну вообщето

makeoptions DEBUG=-g # Build kernel with gdb(1) debug
symbols

это в GENERIC, и насколько я знаю на производительность это не влияет.
По крайней мере не настолько, чтобы было заметно.

Ключников А.С.

unread,
May 18, 2009, 11:15:58 AM5/18/09
to UaFUG
* Sergej Kandyla <sk....@gmail.com> [2009-05-18 11:24:45 +0300]:

Чудес то не бывает!
У меня была история упах ксорг и вальнул на рут дамп под 200метров
в результате чего рут переполнился,
потом я компилил и ставил дрова для сетевой карты, они скопировались но
криво, этот момент я промаргал.
Система стала падать после определения hostname.
Зашел в сингмоде увидел что рут переполнен, стер курку ксорнга.
Не грузится.
После дня ковыряния выяснилось что при инсталяции модуля ядра,
инсталяционный скрипт перегенерировал файл linker.hints, а из за нехватки
места попросту попортил его.
Помогло перегенирирование linker.hints

Короче мораль :)
Дело скорее всего в ядре либо в модулях ядра, так как ядро вы
перекомпилили, возможно у вас со старой системц переполз какой то модуль?
в любом случае бопробуйте скопировать католог /boot с рабочей системы и
посмотреть что будет.

--
С уважением,
Ключников А.С.
Инженер ПРП "Аналитприбор"
432030 г.Ульяновск, а/я 3117
тел./факс +7 (8422) 43-44-78

Mikolaj Golub

unread,
May 18, 2009, 5:06:06 PM5/18/09
to Sergej Kandyla, UaFUG

SK> новый бектрейс (с отключенным поллингом)

SK> # backtrace1.txt
SK> Reading symbols from /boot/kernel/acpi.ko...Reading symbols from
SK> /boot/kernel/acpi.ko.symbols...done.
SK> done.
SK> Loaded symbols for /boot/kernel/acpi.ko
SK> Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from
SK> /boot/kernel/nullfs.ko.symbols...done.
SK> done.
SK> Loaded symbols for /boot/kernel/nullfs.ko
SK> Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from
SK> /boot/kernel/fdescfs.ko.symbols...done.
SK> done.
SK> Loaded symbols for /boot/kernel/fdescfs.ko
SK> #0 doadump () at pcpu.h:196
SK> in pcpu.h
SK> (kgdb) bt
SK> #0 doadump () at pcpu.h:196
SK> #1 0xc0814467 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
SK> #2 0xc0814739 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:574
SK> #3 0xc0b2af4c in trap_fatal (frame=0xc7931908, eva=12) at
SK> /usr/src/sys/i386/i386/trap.c:939
SK> #4 0xc0b2b1d0 in trap_pfault (frame=0xc7931908, usermode=0, eva=12)
SK> at /usr/src/sys/i386/i386/trap.c:852
SK> #5 0xc0b2bb7c in trap (frame=0xc7931908) at
SK> /usr/src/sys/i386/i386/trap.c:530
SK> #6 0xc0b1028b in calltrap () at /usr/src/sys/i386/i386/exception.s:159
SK> #7 0xc08bed67 in rn_match (v_arg=0xc0ccd06c, head=0xc81f7d00) at
SK> /usr/src/sys/net/radix.c:262
SK> #8 0xc04ba003 in pfr_match_addr (kt=0xc837a4d8, a=0xce81281c, af=2
SK> \002') at /usr/src/sys/contrib/pf/net/pf_table.c:2104

А можно еще сделать

fr 8
p *kt
p *kt->pfrkt_ip4
p *pfr_sin
p pfr_sin.sin_addr.s_addr

?

Похоже падает когда pf при проверке пришедшего udp пакета ищет его айпи в
какой-то таблице. Есть подозрение что в это время таблица модифицируется
какой-то другой кернельной нитью.

Можно еще пробежать по все другим тредам и поглядеть нету ли чего pf
специфического...

thr 1
bt

thr 2
bt

...

Но это долговато :-). К сожалению thr apply all bt не сработает чтоб все
одном махом высести.

SK> сетевая нагрузка низка, в среднем порядка 4мбит\с out и около 200
SK> established connections, в пиках 16-20 мбит\с в pf - ничего
SK> партийного, парочка таблиц, парочка редиректов...

SK> я понимаю, что сетевуха, конечно, не фонтан, но вполне себе
SK> рабочая. Есть ряд серверов на аналогичном железе. Да и на этом же
SK> тазике, до этого работал винт с OS fbsd 7.0, и на которую временами
SK> приходилась значительно большая нагрузка (~80мбит\с).....

А что из софта сетвого спецефического еще? Нету какого-то автоматического
блокера на основе pf? Что за udp трафик? Может tun/tap интерфейсы создаются
кем-то? mpd?

--
Mikolaj Golub

Sergej Kandyla

unread,
May 19, 2009, 5:39:14 AM5/19/09
to UaFUG
Mikolaj Golub пишет:

(kgdb) p *kt
$1 = {pfrkt_ts = {pfrts_t = {pfrt_anchor = '\0' <repeats 1023 times>,
pfrt_name = "ssh-bruteforce", '\0' <repeats 17 times>, pfrt_flags = 20,
pfrt_fback = 0 '\0'}, pfrts_packets = {{30, 0, 0}, {0, 0, 0}},
pfrts_bytes = {{1560, 0, 0}, {0, 0, 0}}, pfrts_match = 30,
pfrts_nomatch = 915288, pfrts_tzero = 1242483372, pfrts_cnt = 1,
pfrts_refcnt = {0, 0}}, pfrkt_tree = {rbe_left = 0xc837a000,
rbe_right = 0x0, rbe_parent = 0xc837d000, rbe_color = 0},
pfrkt_workq = {sle_next = 0x0}, pfrkt_ip4 = 0xc81f7d00, pfrkt_ip6 =
0xc826c400, pfrkt_shadow = 0x0, pfrkt_root = 0x0, pfrkt_rs = 0xc0ccce88,
pfrkt_larg = 0, pfrkt_nflags = 0}
(kgdb) p *kt->pfrkt_ip4
$2 = {rnh_treetop = 0x0, rnh_addrsize = 1005, rnh_pktsize = 1005,
rnh_addaddr = 0, rnh_addpkt = 0x2, rnh_deladdr = 0x3ed, rnh_delpkt =
0x3ed, rnh_matchaddr = 0x5, rnh_lookup = 0, rnh_matchpkt = 0,
rnh_walktree = 0, rnh_walktree_from = 0, rnh_close = 0, rnh_nodes =
{{rn_mklist = 0x0, rn_parent = 0x0, rn_bit = 0, rn_bmask = 0 '\0',
rn_flags = 0 '\0', rn_u = {rn_leaf = {rn_Key = 0x0, rn_Mask = 0x0,
rn_Dupedkey = 0x0}, rn_node = {rn_Off = 0, rn_L = 0x0, rn_R =
0x0}}}, {rn_mklist = 0x0, rn_parent = 0x0, rn_bit = 1005, rn_bmask = 0
'\0', rn_flags = 0 '\0', rn_u = {rn_leaf = {
rn_Key = 0x3ed <Address 0x3ed out of bounds>, rn_Mask =
0xc7c95ca0 "", rn_Dupedkey = 0xcb707380}, rn_node = {rn_Off = 1005, rn_L
= 0xc7c95ca0, rn_R = 0xcb707380}}}, {rn_mklist = 0x0,
rn_parent = 0x0, rn_bit = 0, rn_bmask = 0 '\0', rn_flags = 0 '\0',
rn_u = {rn_leaf = {rn_Key = 0x0, rn_Mask = 0x0, rn_Dupedkey =
0xffffffff}, rn_node = {rn_Off = 0, rn_L = 0x0,
rn_R = 0xffffffff}}}}, rnh_mtx = {lock_object = {lo_name =
0x0, lo_type = 0x0, lo_flags = 0, lo_witness_data = {lod_list =
{stqe_next = 0x4}, lod_witness = 0x4}}, mtx_lock = 0, mtx_recurse = 0}}
(kgdb) p *pfr_sin
Structure has no component named operator*.
(kgdb) p pfr_sin.sin_addr.s_addr
$3 = 74300762

> Похоже падает когда pf при проверке пришедшего udp пакета ищет его айпи в
> какой-то таблице. Есть подозрение что в это время таблица модифицируется
> какой-то другой кернельной нитью.
>
> Можно еще пробежать по все другим тредам и поглядеть нету ли чего pf
> специфического...
>
> thr 1
> bt
>
> thr 2
> bt
>
>

(kgdb) thr 1
[Switching to thread 1 (Thread 0)]#0 sched_switch (td=0xc0cfc360,
newtd=Variable "newtd" is not available.
) at /usr/src/sys/kern/sched_ule.c:1944
1944 cpuid = PCPU_GET(cpuid);
(kgdb) bt
#0 sched_switch (td=0xc0cfc360, newtd=Variable "newtd" is not available.
) at /usr/src/sys/kern/sched_ule.c:1944
#1 0xc081c4f6 in mi_switch (flags=Variable "flags" is not available.
) at /usr/src/sys/kern/kern_synch.c:444
#2 0xc0847a6b in sleepq_switch (wchan=Variable "wchan" is not available.
) at /usr/src/sys/kern/subr_sleepqueue.c:497
#3 0xc08485e7 in sleepq_timedwait (wchan=0xc0cfc0a0) at
/usr/src/sys/kern/subr_sleepqueue.c:615
#4 0xc081c958 in _sleep (ident=0xc0cfc0a0, lock=0x0, priority=68,
wmesg=0xc0bd1f75 "sched", timo=10000) at /usr/src/sys/kern/kern_synch.c:226
#5 0xc0a6290d in scheduler (dummy=0x0) at /usr/src/sys/vm/vm_glue.c:733
#6 0xc07d11b6 in mi_startup () at /usr/src/sys/kern/init_main.c:251
#7 0xc0464c95 in begin () at /usr/src/sys/i386/i386/locore.s:328

(kgdb) thr 2
Variable "newtd" is not available.
[Switching to thread 2 (Thread 100000)]#0 sched_switch (td=0xc7c9f000,
newtd=) at /usr/src/sys/kern/sched_ule.c:1944
1944 cpuid = PCPU_GET(cpuid);
(kgdb) bt
Variable "newtd" is not available.#0 sched_switch (td=0xc7c9f000, newtd=
) at /usr/src/sys/kern/sched_ule.c:1944
Variable "flags" is not available.#1 0xc081c4f6 in mi_switch (flags=
) at /usr/src/sys/kern/kern_synch.c:444
#2 0xc0847a6b in sleepq_switch (wchan=Variable "wchan" is not available.
) at /usr/src/sys/kern/subr_sleepqueue.c:497
#3 0xc08480b6 in sleepq_wait (wchan=0xc0d1d804) at
/usr/src/sys/kern/subr_sleepqueue.c:580
#4 0xc07d4511 in _cv_wait (cvp=0xc0d1d804, lock=0xc0d1d7e4) at
/usr/src/sys/kern/kern_condvar.c:137
#5 0xc0a1d6ff in audit_worker (arg=0x0) at
/usr/src/sys/security/audit/audit_worker.c:410
#6 0xc07ede59 in fork_exit (callout=0xc0a1d690 <audit_worker>, arg=0x0,
frame=0xc785bd38) at /usr/src/sys/kern/kern_fork.c:810
#7 0xc0b10300 in fork_trampoline () at
/usr/src/sys/i386/i386/exception.s:264
(kgdb)

(kgdb) thr 3
[Switching to thread 3 (Thread 100001)]#0 sched_switch (td=0xc7c9dd20,
newtd=Variable "newtd" is not available.
) at /usr/src/sys/kern/sched_ule.c:1944
1944 cpuid = PCPU_GET(cpuid);
(kgdb) bt
Variable "newtd" is not available.#0 sched_switch (td=0xc7c9dd20, newtd=
) at /usr/src/sys/kern/sched_ule.c:1944
Variable "flags" is not available.#1 0xc081c4f6 in mi_switch (flags=
) at /usr/src/sys/kern/kern_synch.c:444
Variable "wchan" is not available.#2 0xc0847a6b in sleepq_switch (wchan=
) at /usr/src/sys/kern/subr_sleepqueue.c:497
#3 0xc0847d7c in sleepq_catch_signals (wchan=0xc7c9bae0) at
/usr/src/sys/kern/subr_sleepqueue.c:417
#4 0xc084862d in sleepq_wait_sig (wchan=0xc7c9bae0) at
/usr/src/sys/kern/subr_sleepqueue.c:594
#5 0xc081c96b in _sleep (ident=0xc7c9bae0, lock=0xc7c9bb70,
priority=348, wmesg=0xc0bd0b75 "wait", timo=0) at
/usr/src/sys/kern/kern_synch.c:228
Variable "options" is not available.#6 0xc07ec138 in kern_wait
(td=0xc7c9dd20, pid=-1, status=0xc785ec2c, options=
) at /usr/src/sys/kern/kern_exit.c:902
#7 0xc07ec1db in wait4 (td=0xc7c9dd20, uap=0xc785ecfc) at
/usr/src/sys/kern/kern_exit.c:688
#8 0xc0b2b525 in syscall (frame=0xc785ed38) at
/usr/src/sys/i386/i386/trap.c:1090
#9 0xc0b102f0 in Xint0x80_syscall () at
/usr/src/sys/i386/i386/exception.s:255
#10 0x00000033 in ?? ()
Previous frame inner to this frame (corrupt stack?)

(kgdb) thr 4
[Switching to thread 4 (Thread 100002)]#0 sched_switch (td=0xc7c9daf0,
newtd=Variable "newtd" is not available.
) at /usr/src/sys/kern/sched_ule.c:1944
1944 cpuid = PCPU_GET(cpuid);
(kgdb) bt
#0 sched_switch (td=0xc7c9daf0, newtd=Variable "newtd" is not available.
) at /usr/src/sys/kern/sched_ule.c:1944
#1 0xc081c4f6 in mi_switch (flags=Variable "flags" is not available.
) at /usr/src/sys/kern/kern_synch.c:444
#2 0xc0b1f2a2 in ipi_bitmap_handler (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = 3, tf_esi = 15,
tf_ebp = -947508032, tf_isp = -947508056, tf_ebx = -943072528, tf_edx =
16, tf_ecx = 16, tf_eax = 582, tf_trapno = 0, tf_err = 0, tf_eip =
-1062102037, tf_cs = 32, tf_eflags = 582, tf_esp = -1060099328, tf_ss =
-947507980}) at /usr/src/sys/i386/i386/mp_machdep.c:1179
#3 0xc0b1097e in Xipi_intr_bitmap_handler () at apic_vector.s:284
#4 0xc0b19beb in spinlock_exit () at cpufunc.h:365
#5 0xc0835ea8 in sched_idletd (dummy=0x0) at
/usr/src/sys/kern/sched_ule.c:806
#6 0xc07ede59 in fork_exit (callout=0xc0835c80 <sched_idletd>, arg=0x0,
frame=0xc7862d38) at /usr/src/sys/kern/kern_fork.c:810
#7 0xc0b10300 in fork_trampoline () at
/usr/src/sys/i386/i386/exception.s:264

(kgdb) thr 5
Variable "newtd" is not available.[Switching to thread 5 (Thread
100003)]#0 sched_switch (td=0xc7c9d8c0, newtd=
) at /usr/src/sys/kern/sched_ule.c:1944
1944 cpuid = PCPU_GET(cpuid);
(kgdb) bt
#0 sched_switch (td=0xc7c9d8c0, newtd=Variable "newtd" is not available.
) at /usr/src/sys/kern/sched_ule.c:1944
#1 0xc081c4f6 in mi_switch (flags=Variable "flags" is not available.
) at /usr/src/sys/kern/kern_synch.c:444
#2 0xc0835efb in sched_idletd (dummy=0x0) at
/usr/src/sys/kern/sched_ule.c:812
#3 0xc07ede59 in fork_exit (callout=0xc0835c80 <sched_idletd>, arg=0x0,
frame=0xc7865d38) at /usr/src/sys/kern/kern_fork.c:810
#4 0xc0b10300 in fork_trampoline () at
/usr/src/sys/i386/i386/exception.s:264
(kgdb)


похожее оно какоето....


На счет pf, еще вчера упростил все правила до минимума, сейчас pf
выглядит так:

#pfctl -sr
No ALTQ support in kernel
ALTQ related functions disabled
scrub in all fragment reassemble
block drop all
pass quick on lo0 all flags S/SA keep state
pass out quick inet from xxx.xxx.xxx.xxx to any flags S/SA keep state
pass out quick inet from 127.0.0.1 to any flags S/SA keep state
pass quick inet proto icmp all icmp-type echoreq code 0 keep state
pass in quick from <servers> to (nfe0) flags S/SA keep state
block drop in log quick on nfe0 from <ssh-bruteforce> to any
pass in log quick on nfe0 proto tcp from any to (nfe0) port = ssh flags
S/SA keep state (source-track rule, max-src-conn-rate 5/50, overload
<ssh-bruteforce> flush global, src.track 50)
pass in quick on nfe0 proto tcp from any to (nfe0) port = http flags
S/SA keep state
pass in quick on nfe0 proto tcp from any to (nfe0) port = hosts2-ns
flags S/SA keep state
pass in quick on nfe0 proto tcp from any to (nfe0) port = https flags
S/SA keep state
pass in quick on nfe0 proto tcp from any to (nfe0) port = 8443 flags
S/SA keep state
pass in quick on nfe0 proto tcp from any to (nfe0) port = ftp flags S/SA
keep state
pass in quick on nfe0 proto tcp from any to (nfe0) port = smtp flags
S/SA keep state (source-track rule, max-src-conn 3)
pass in quick on nfe0 proto tcp from any to (nfe0) port = domain flags
S/SA keep state
pass in quick on nfe0 proto tcp from any to (nfe0) port = pop3 flags
S/SA keep state
pass in quick on nfe0 proto tcp from any to (nfe0) port = imap flags
S/SA keep state
pass in quick on nfe0 proto tcp from any to (nfe0) port = pop3s flags
S/SA keep state
pass in quick on nfe0 proto tcp from any to (nfe0) port = imaps flags
S/SA keep state
pass in quick on nfe0 proto tcp from any to (nfe0) port = 2222 flags
S/SA keep state
pass in quick on nfe0 proto udp from any to (nfe0) port = domain keep state
pass in proto tcp from any to (nfe0) port > 49151 flags S/SA keep state

#pfctl -sn
No ALTQ support in kernel
ALTQ related functions disabled
rdr on nfe0 inet proto tcp from any to xxx.xxx.xxx.xxx port = http ->
xxx.xxx.xxx.xxx port 81

До этого он выглядел чуть сложнее, но принципиально не отличался.
Из специфики еще было
/usr/local/sbin/expiretable -t 3600 ssh-bruteforce
и скрипт антиддоса, который переодически передергивал фаер
/sbin/pfctl -f /etc/pf.fw

больше ничего.
Да и то, никаких больших тоблиц небыло, а уж темболее обрабатывающих udp.

Во времена ddos сумарно по таблицам было порядка 50к айпишников, особых
проблем не наблюдалось

> ...
>
> Но это долговато :-). К сожалению thr apply all bt не сработает чтоб все
> одном махом высести.
>
> SK> сетевая нагрузка низка, в среднем порядка 4мбит\с out и около 200
> SK> established connections, в пиках 16-20 мбит\с в pf - ничего
> SK> партийного, парочка таблиц, парочка редиректов...
>
> SK> я понимаю, что сетевуха, конечно, не фонтан, но вполне себе
> SK> рабочая. Есть ряд серверов на аналогичном железе. Да и на этом же
> SK> тазике, до этого работал винт с OS fbsd 7.0, и на которую временами
> SK> приходилась значительно большая нагрузка (~80мбит\с).....
>
> А что из софта сетвого спецефического еще? Нету какого-то автоматического
> блокера на основе pf? Что за udp трафик? Может tun/tap интерфейсы создаются
> кем-то? mpd?
>
>

специфического - ничего.

Стандартный хостинг.

named
exim
nginx
apache
mysql
proftpd
dovecot
nrpe

из udp, только named (BIND 9.3.6-P1)

Автоматические блокеры были (ssh-bruteforce, www-ddos)
pass in quick on $ext_if proto tcp to {$me } port {80,81,443} flags
S/SA keep state \
( max-src-nodes 400, max-src-states 60,
max-src-conn-rate 40/1, overload <www-ddos> flush global)

подобная схема работала уже давно. Сейчас убрал и ее.

Mikolaj Golub

unread,
May 19, 2009, 8:43:23 AM5/19/09
to UaFUG
On Tue, 19 May 2009 12:39:14 +0300 Sergej Kandyla wrote:

> (kgdb) p *kt
> $1 = {pfrkt_ts = {pfrts_t = {pfrt_anchor = '\0' <repeats 1023 times>,
> pfrt_name = "ssh-bruteforce", '\0' <repeats 17 times>, pfrt_flags =

ага, ну вот он, ssh-bruteforce. Повидимому модифицировал в это время таблицу.
Можно еще первый бектрейс так же проверить, чтобы убедиться что на той же
таблице упал.

> 20, pfrt_fback = 0 '\0'}, pfrts_packets = {{30, 0, 0}, {0, 0, 0}},
> pfrts_bytes = {{1560, 0, 0}, {0, 0, 0}}, pfrts_match = 30,
> pfrts_nomatch = 915288, pfrts_tzero = 1242483372, pfrts_cnt = 1,
> pfrts_refcnt = {0, 0}}, pfrkt_tree = {rbe_left = 0xc837a000,
> rbe_right = 0x0, rbe_parent = 0xc837d000, rbe_color = 0},
> pfrkt_workq = {sle_next = 0x0}, pfrkt_ip4 = 0xc81f7d00, pfrkt_ip6 =
> 0xc826c400, pfrkt_shadow = 0x0, pfrkt_root = 0x0, pfrkt_rs =
> 0xc0ccce88,
> pfrkt_larg = 0, pfrkt_nflags = 0}
> (kgdb) p *kt->pfrkt_ip4
> $2 = {rnh_treetop = 0x0, rnh_addrsize = 1005, rnh_pktsize = 1005,

А упало собственно из-за того что rnh_treetop на момент проверки NULL.

> похожее оно какоето....

Ну там похоже надо искать как раз с реди больших номеров тредов. Найти бы
процесс ssh-bruteforce и поглядеть чего он там делает. Можно еще утилиту
crashinfo запустить, она там попытается сама вытащить всевозможную инфу из
корки. Вывод ps может оказаться полезным.

> специфического - ничего.
>
> Стандартный хостинг.
>
> named
> exim
> nginx
> apache
> mysql
> proftpd
> dovecot
> nrpe
>
> из udp, только named (BIND 9.3.6-P1)
>
> Автоматические блокеры были (ssh-bruteforce, www-ddos)
> pass in quick on $ext_if proto tcp to {$me } port {80,81,443} flags
> S/SA keep state \
> ( max-src-nodes 400, max-src-states 60,
> max-src-conn-rate 40/1, overload <www-ddos> flush global)
>
> подобная схема работала уже давно. Сейчас убрал и ее.

В семерке меняли очень много на счет блокировок. Подозреваю в этом районе
чего-то сломали, либо начали вылазить проблемы которые раньше не всплывали. В
общем, хорошо было бы PR закомитить со всей этой дебужной инфой. Я если будет
час та натхнення попробую воспроизвести.

--
Mikolaj Golub

Sergej Kandyla

unread,
May 19, 2009, 10:27:18 AM5/19/09
to UaFUG
Mikolaj Golub пишет:

> On Tue, 19 May 2009 12:39:14 +0300 Sergej Kandyla wrote:
>
>
>> (kgdb) p *kt
>> $1 = {pfrkt_ts = {pfrts_t = {pfrt_anchor = '\0' <repeats 1023 times>,
>> pfrt_name = "ssh-bruteforce", '\0' <repeats 17 times>, pfrt_flags =
>>
>
> ага, ну вот он, ssh-bruteforce. Повидимому модифицировал в это время таблицу.
> Можно еще первый бектрейс так же проверить, чтобы убедиться что на той же
> таблице упал.
>
>

с первого бектрейса:

(kgdb) fr 8


#8 0xc04ba003 in pfr_match_addr (kt=0xc83554d8, a=0xcc69601c, af=2

'\002') at /usr/src/sys/contrib/pf/net/pf_table.c:2104
2104 ke = (struct pfr_kentry *)rn_match(&pfr_sin, kt->pfrkt_ip4);


(kgdb) p *kt
$1 = {pfrkt_ts = {pfrts_t = {pfrt_anchor = '\0' <repeats 1023 times>,

pfrt_name = "ssh-bruteforce", '\0' <repeats 17 times>, pfrt_flags = 20,
pfrt_fback = 0 '\0'}, pfrts_packets = {{26, 0, 0}, {0, 0, 0}},
pfrts_bytes = {{1352, 0, 0}, {0, 0, 0}}, pfrts_match = 26, pfrts_nomatch
= 494666, pfrts_tzero = 1242396496, pfrts_cnt = 1, pfrts_refcnt = {0,
0}}, pfrkt_tree = {rbe_left = 0xc8355000,
rbe_right = 0x0, rbe_parent = 0xc8358000, rbe_color = 0}, pfrkt_workq =
{sle_next = 0x0}, pfrkt_ip4 = 0xc8165e00, pfrkt_ip6 = 0xc8165d00,

pfrkt_shadow = 0x0, pfrkt_root = 0x0, pfrkt_rs = 0xc0ccce88,
pfrkt_larg = 0, pfrkt_nflags = 0}
(kgdb) p *kt->pfrkt_ip4

$2 = {rnh_treetop = 0xffffffff, rnh_addrsize = 2147483647, rnh_pktsize =
-1, rnh_addaddr = 0x7fffffff, rnh_addpkt = 0xffffffff, rnh_deladdr =
0x7fffffff, rnh_delpkt = 0xffffffff,
rnh_matchaddr = 0x7fffffff, rnh_lookup = 0x20000000, rnh_matchpkt = 0,
rnh_walktree = 0x20000000, rnh_walktree_from = 0, rnh_close = 0x4000000,
rnh_nodes = {{rn_mklist = 0x0, rn_parent = 0x4000000,


rn_bit = 0, rn_bmask = 0 '\0', rn_flags = 0 '\0', rn_u = {rn_leaf =

{rn_Key = 0xffffffff <Address 0xffffffff out of bounds>, rn_Mask =
0x7fffffff <Address 0x7fffffff out of bounds>,
rn_Dupedkey = 0xffffffff}, rn_node = {rn_Off = -1, rn_L = 0x7fffffff,
rn_R = 0xffffffff}}}, {rn_mklist = 0x7fffffff, rn_parent = 0xffffffff,
rn_bit = -1, rn_bmask = -1 '�',
rn_flags = 127 '\177', rn_u = {rn_leaf = {rn_Key = 0xffffffff <Address
0xffffffff out of bounds>, rn_Mask = 0x7fffffff <Address 0x7fffffff out
of bounds>, rn_Dupedkey = 0xffffffff}, rn_node = {
rn_Off = -1, rn_L = 0x7fffffff, rn_R = 0xffffffff}}}, {rn_mklist =
0x7fffffff, rn_parent = 0xffffffff, rn_bit = -1, rn_bmask = -1 '�',
rn_flags = 127 '\177', rn_u = {rn_leaf = {
rn_Key = 0x39ab <Address 0x39ab out of bounds>, rn_Mask = 0x0,
rn_Dupedkey = 0x39ab}, rn_node = {rn_Off = 14763, rn_L = 0x0, rn_R =
0x39ab}}}}, rnh_mtx = {lock_object = {lo_name = 0x0,
lo_type = 0x38400 <Address 0x38400 out of bounds>, lo_flags = 0,
lo_witness_data = {lod_list = {stqe_next = 0x38400}, lod_witness =
0x38400}}, mtx_lock = 0, mtx_recurse = 4294967295}}


(kgdb) p *pfr_sin
Structure has no component named operator*.
(kgdb) p pfr_sin.sin_addr.s_addr

$3 = 1142767197
(kgdb)


Имете в виду, что
когда сработало правило
pass in quick log on $ext_if proto tcp from any to ($ext_if) port ssh
flags S/SA keep state (max-src-conn-rate 5/50, overload <ssh-bruteforce>
flush global)

и заносило айпишник в таблицу, в это время запустился expiretable (*/5 *
* * * /usr/local/sbin/expiretable -t 3600 ssh-bruteforce) и оно рухнуло?
(сейчас expiretable по крону отключен.)

>> 20, pfrt_fback = 0 '\0'}, pfrts_packets = {{30, 0, 0}, {0, 0, 0}},
>> pfrts_bytes = {{1560, 0, 0}, {0, 0, 0}}, pfrts_match = 30,
>> pfrts_nomatch = 915288, pfrts_tzero = 1242483372, pfrts_cnt = 1,
>> pfrts_refcnt = {0, 0}}, pfrkt_tree = {rbe_left = 0xc837a000,
>> rbe_right = 0x0, rbe_parent = 0xc837d000, rbe_color = 0},
>> pfrkt_workq = {sle_next = 0x0}, pfrkt_ip4 = 0xc81f7d00, pfrkt_ip6 =
>> 0xc826c400, pfrkt_shadow = 0x0, pfrkt_root = 0x0, pfrkt_rs =
>> 0xc0ccce88,
>> pfrkt_larg = 0, pfrkt_nflags = 0}
>> (kgdb) p *kt->pfrkt_ip4
>> $2 = {rnh_treetop = 0x0, rnh_addrsize = 1005, rnh_pktsize = 1005,
>>
>
> А упало собственно из-за того что rnh_treetop на момент проверки NULL.
>

Все таки не пойму как такая ситуация могла сложиться...
Из-за чего rnh_treetop мог быть NULL ? и если на пальцах, как он
задействован? (из /usr/src/sys/net/radix.c я так толком и не понял....)

>
>> похожее оно какоето....
>>
>
> Ну там похоже надо искать как раз с реди больших номеров тредов. Найти бы
> процесс ssh-bruteforce и поглядеть чего он там делает. Можно еще утилиту
> crashinfo запустить, она там попытается сама вытащить всевозможную инфу из
> корки. Вывод ps может оказаться полезным.
>
>

пролистал остальные номера тредов, ничего подозрительного (вроде)
ssh-bruteforce это ведь не процесс, это таблица в pf

если интересно, crashinfo по двум коркам

http://paix.org.ua/tmp/core.txt.0
http://paix.org.ua/tmp/core.txt.1
(около 3мб. кажд.)

Если кому интересно, могу выложить и сами корки.


Еще хотелось бы лучше понять бектрейс.
Ниже видем 23 треда, непосредственно к панику они все имеют отношение (и
условно произошли в один момент времени) или нет?

Ведь по факту ошибку вычислили в

instruction pointer = 0x20:0xc08bed67

(kgdb) list *0xc08bed67
0xc08bed67 is in rn_match (/usr/src/sys/net/radix.c:266).

а это в 7ом треде...

т.е. как следует толковать собственно сам '(kgdb) bt' ?


(kgdb) bt


#0 doadump () at pcpu.h:196

#1 0xc0814467 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:418

#2 0xc0814739 in panic (fmt=) at
/usr/src/sys/kern/kern_shutdown.c:574

#3 0xc0b2af4c in trap_fatal (frame=0xc78698d8, eva=11) at
/usr/src/sys/i386/i386/trap.c:939
#4 0xc0b2b1d0 in trap_pfault (frame=0xc78698d8, usermode=0,
eva=11) at /usr/src/sys/i386/i386/trap.c:852
#5 0xc0b2bb7c in trap (frame=0xc78698d8) at
/usr/src/sys/i386/i386/trap.c:530

#6 0xc0b1028b in calltrap () at
/usr/src/sys/i386/i386/exception.s:159

#23 0xc0b10300 in fork_trampoline () at
/usr/src/sys/i386/i386/exception.s:264

>> специфического - ничего.


>>
>> Стандартный хостинг.
>>
>> named
>> exim
>> nginx
>> apache
>> mysql
>> proftpd
>> dovecot
>> nrpe
>>
>> из udp, только named (BIND 9.3.6-P1)
>>
>> Автоматические блокеры были (ssh-bruteforce, www-ddos)
>> pass in quick on $ext_if proto tcp to {$me } port {80,81,443} flags
>> S/SA keep state \
>> ( max-src-nodes 400, max-src-states 60,
>> max-src-conn-rate 40/1, overload <www-ddos> flush global)
>>
>> подобная схема работала уже давно. Сейчас убрал и ее.
>>
>
> В семерке меняли очень много на счет блокировок. Подозреваю в этом районе
> чего-то сломали, либо начали вылазить проблемы которые раньше не всплывали. В
> общем, хорошо было бы PR закомитить со всей этой дебужной инфой. Я если будет
> час та натхнення попробую воспроизвести.
>
>

может что-то и сломали.
Но проблема началась на 6.2, апдейтом на 6.4 не решилась...

апдейт на 7.2 был как мера попробовать "еще что-нибудь", ибо железо уже
поменяли....

В целом, пока работает стабильней, чем на 6ке, но аптайм еще слишком
мал, чтобы о чем-то говорить серьезно.


Спасибо!

Mikolaj Golub

unread,
May 19, 2009, 10:58:59 AM5/19/09
to Sergej Kandyla, UaFUG
On Tue, 19 May 2009 17:27:18 +0300 Sergej Kandyla wrote:
> с первого бектрейса:
>
> (kgdb) fr 8
> #8 0xc04ba003 in pfr_match_addr (kt=0xc83554d8, a=0xcc69601c, af=2
> \002') at /usr/src/sys/contrib/pf/net/pf_table.c:2104
> 2104 ke = (struct pfr_kentry *)rn_match(&pfr_sin, kt->pfrkt_ip4);
> (kgdb) p *kt
> $1 = {pfrkt_ts = {pfrts_t = {pfrt_anchor = '\0' <repeats 1023 times>,
> pfrt_name = "ssh-bruteforce", '\0' <repeats 17 times>, pfrt_flags =

то же самое

> Имете в виду, что
> когда сработало правило
> pass in quick log on $ext_if proto tcp from any to ($ext_if) port ssh
> flags S/SA keep state (max-src-conn-rate 5/50, overload
> <ssh-bruteforce> flush global)
>
> и заносило айпишник в таблицу, в это время запустился expiretable (*/5
> * * * * /usr/local/sbin/expiretable -t 3600 ssh-bruteforce) и оно
> рухнуло?
> (сейчас expiretable по крону отключен.)

Угу, тока не заносило в таблицу, а искало в таблице, а в это время какой-то
адрес из таблицы уже был проэкспарен и ssh-bruteforce его удалял.

> Все таки не пойму как такая ситуация могла сложиться...
> Из-за чего rnh_treetop мог быть NULL ? и если на пальцах, как он
> задействован? (из /usr/src/sys/net/radix.c я так толком и не
> понял....)

radix.c -- это набор утилит для для поиска по набору айпи адресов. Адреса
хранаятся в дереве по которому потом производят поиск. Первоначально
использовалось только кодом раутинга, но позже и другие подсистемы начали
использовать.

А NULL мог быть из-за того что когда pf обратился к таблице (собственно radix
дереву), в это время адрес удалялся из таблицы процессом expiretable. Такие
вещи должны быть защищены блокировками, но в данном случае похоже не.

>>
>>> похожее оно какоето....
>>>
>>
>> Ну там похоже надо искать как раз с реди больших номеров тредов. Найти бы
>> процесс ssh-bruteforce и поглядеть чего он там делает. Можно еще утилиту
>> crashinfo запустить, она там попытается сама вытащить всевозможную инфу из
>> корки. Вывод ps может оказаться полезным.
>>
>>
> пролистал остальные номера тредов, ничего подозрительного (вроде)
> ssh-bruteforce это ведь не процесс, это таблица в pf

ну я имел в виду expiretable.

> если интересно, crashinfo по двум коркам
>
> http://paix.org.ua/tmp/core.txt.0
> http://paix.org.ua/tmp/core.txt.1
> (около 3мб. кажд.)
>
> Если кому интересно, могу выложить и сами корки.

Сами корки не имеют смысла без бинарников и исходного кода. А во вторых это не
очень секюрно, т.к. есть теоретическая возможность вытящить приватные данные
из корки (например пароль или ключ).

> Еще хотелось бы лучше понять бектрейс.
> Ниже видем 23 треда, непосредственно к панику они все имеют отношение
> (и условно произошли в один момент времени) или нет?

Это не треды, это все один тред (именно этот тред в выводе ps будет в
называться типа [swi1: net]) и его бектрейс :-) т.е. какие функции он вызывал
одна за другой пока не дошел до паники.

--------------------^^^^^^^


> #21 0xc07f130b in ithread_loop (arg=0xc7c9a260) at
> /usr/src/sys/kern/kern_intr.c:1088
> #22 0xc07ede59 in fork_exit (callout=0xc07f1150 <ithread_loop>,
> arg=0xc7c9a260, frame=0xc7869d38) at /usr/src/sys/kern/kern_fork.c:810
> #23 0xc0b10300 in fork_trampoline () at
> /usr/src/sys/i386/i386/exception.s:264

...

> может что-то и сломали.
> Но проблема началась на 6.2, апдейтом на 6.4 не решилась...

Подозреваю то были другие проблемы.

> апдейт на 7.2 был как мера попробовать "еще что-нибудь", ибо железо
> уже поменяли....
>
> В целом, пока работает стабильней, чем на 6ке, но аптайм еще слишком
> мал, чтобы о чем-то говорить серьезно.
>
>
> Спасибо!

--
Mikolaj Golub

Sergej Kandyla

unread,
May 19, 2009, 11:32:29 AM5/19/09
to UaFUG
Mikolaj Golub пишет:

>> Имете в виду, что
>> когда сработало правило
>> pass in quick log on $ext_if proto tcp from any to ($ext_if) port ssh
>> flags S/SA keep state (max-src-conn-rate 5/50, overload
>> <ssh-bruteforce> flush global)
>>
>> и заносило айпишник в таблицу, в это время запустился expiretable (*/5
>> * * * * /usr/local/sbin/expiretable -t 3600 ssh-bruteforce) и оно
>> рухнуло?
>> (сейчас expiretable по крону отключен.)
>>
>
> Угу, тока не заносило в таблицу, а искало в таблице, а в это время какой-то
> адрес из таблицы уже был проэкспарен и ssh-bruteforce его удалял.
>
>
>> Все таки не пойму как такая ситуация могла сложиться...
>> Из-за чего rnh_treetop мог быть NULL ? и если на пальцах, как он
>> задействован? (из /usr/src/sys/net/radix.c я так толком и не
>> понял....)
>>
>
> radix.c -- это набор утилит для для поиска по набору айпи адресов. Адреса
> хранаятся в дереве по которому потом производят поиск. Первоначально
> использовалось только кодом раутинга, но позже и другие подсистемы начали
> использовать.
>
> А NULL мог быть из-за того что когда pf обратился к таблице (собственно radix
> дереву), в это время адрес удалялся из таблицы процессом expiretable. Такие
> вещи должны быть защищены блокировками, но в данном случае похоже не.
>
>
>> Если кому интересно, могу выложить и сами корки.
>>
>
> Сами корки не имеют смысла без бинарников и исходного кода. А во вторых это не
> очень секюрно, т.к. есть теоретическая возможность вытящить приватные данные
> из корки (например пароль или ключ).
>

хм, спасибо за предостережение.

>
>> Еще хотелось бы лучше понять бектрейс.
>> Ниже видем 23 треда, непосредственно к панику они все имеют отношение
>> (и условно произошли в один момент времени) или нет?
>>
>
> Это не треды, это все один тред (именно этот тред в выводе ps будет в
> называться типа [swi1: net]) и его бектрейс :-) т.е. какие функции он вызывал
> одна за другой пока не дошел до паники.
>
>

т.е. при этом, в 7м, 8м фрейме

fr 8
p *kt->pfrkt_ip4

произошла та самая непоправимая ошибка
rnh_treetop = 0x0

в результате которой все пошло наперкосяк и всдествие случился паник.
(если я правильно понял...)

>> Ведь по факту ошибку вычислили в
>>
>> instruction pointer = 0x20:0xc08bed67
>> (kgdb) list *0xc08bed67
>> 0xc08bed67 is in rn_match (/usr/src/sys/net/radix.c:266).
>> а это в 7ом треде...
>>
>> т.е. как следует толковать собственно сам '(kgdb) bt' ?
>>
>>

>> #20 0xc08bcd92 in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:254
>>
> --------------------^^^^^^^
>
>

>> может что-то и сломали.
>> Но проблема началась на 6.2, апдейтом на 6.4 не решилась...
>>
>
> Подозреваю то были другие проблемы.
>

Чинил одни кастыли, получил другие ;)

Большое спасибо за обьяснения.
Наблюдаю за полетом дальше.

Sergej Kandyla

unread,
May 19, 2009, 11:46:27 AM5/19/09
to UaFUG
Sergej Kandyla пишет:

> После обновления с 6.4 на 7.2 наблюдаю значительный рост loadaverage
> http://paix.org.ua/tmp/loadavg-week-after-update-6.4-to-7.2.png
>
>
после портапгрейда софта и, в частности, mysql, проблема решилась.
http://paix.org.ua/tmp/loadavg-week-after-update-mysql.png

показатели даже лучше чем были на 6ке. La в районе 0.7

т.е. высокий LA создавал мускиль, собранный прежде на 6ке и работающий
на старых либах, после апдейта 6х->7x.

Mikolaj Golub

unread,
May 19, 2009, 2:58:51 PM5/19/09
to Sergej Kandyla, UaFUG

On Tue, 19 May 2009 18:32:29 +0300 Sergej Kandyla wrote:

SK> т.е. при этом, в 7м, 8м фрейме

SK> fr 8
SK> p *kt->pfrkt_ip4

SK> произошла та самая непоправимая ошибка
SK> rnh_treetop = 0x0

SK> в результате которой все пошло наперкосяк и всдествие случился паник.
SK> (если я правильно понял...)

Угу. Собственно тогда паник и случился, а все что выше (фреймы 6-0) --
обработка этого эксепшина системой и сброс дампа.

--
Mikolaj Golub

Mikolaj Golub

unread,
May 19, 2009, 3:26:12 PM5/19/09
to Sergej Kandyla, UaFUG

On Tue, 19 May 2009 18:46:27 +0300 Sergej Kandyla wrote:

SK> Sergej Kandyla пишет:


>> После обновления с 6.4 на 7.2 наблюдаю значительный рост loadaverage
>> http://paix.org.ua/tmp/loadavg-week-after-update-6.4-to-7.2.png
>>
>>

SK> после портапгрейда софта и, в частности, mysql, проблема решилась.
SK> http://paix.org.ua/tmp/loadavg-week-after-update-mysql.png

SK> показатели даже лучше чем были на 6ке. La в районе 0.7

SK> т.е. высокий LA создавал мускиль, собранный прежде на 6ке и работающий
SK> на старых либах, после апдейта 6х->7x.

Думаю в основном из-за смены либы с libpthread (kse) (которая была по
умолчанию на 6-ке), а на libthr

--
Mikolaj Golub

Sergej Kandyla

unread,
May 20, 2009, 2:33:08 AM5/20/09
to UaFUG
Mikolaj Golub пишет:

ух, до меня только дошло что back trace нужно наоборот читать....

т.е. фреймы 23-9 - системные вызовы предшествующие панику
фрейм 8-7 - сам паник
фрейм 6-0 - обработка эксепшина и сборос дампа.

спасибо ;)

#20 0xc08bcd92 in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:254

#21 0xc07f130b in ithread_loop (arg=0xc7c9a260) at
/usr/src/sys/kern/kern_intr.c:1088
#22 0xc07ede59 in fork_exit (callout=0xc07f1150 <ithread_loop>,
arg=0xc7c9a260, frame=0xc7869d38) at /usr/src/sys/kern/kern_fork.c:810
#23 0xc0b10300 in fork_trampoline () at
/usr/src/sys/i386/i386/exception.s:264

--
Best wishes, Sergej Kandyla

Sergej Kandyla

unread,
May 20, 2009, 2:43:56 AM5/20/09
to UaFUG
Mikolaj Golub пишет:

> SK> после портапгрейда софта и, в частности, mysql, проблема решилась.
> SK> http://paix.org.ua/tmp/loadavg-week-after-update-mysql.png
> SK> т.е. высокий LA создавал мускиль, собранный прежде на 6ке и работающий
> SK> на старых либах, после апдейта 6х->7x.
>
> Думаю в основном из-за смены либы с libpthread (kse) (которая была по
> умолчанию на 6-ке), а на libthr
>
>
улучшения в этом плане в 7ке очень значительны.
http://wiki.freebsd.org/MySQL
"No special tuning for MySQL on FreeBSD is required as of 7.0-RELEASE"

особенно по сравнению с кастылями оптимизации в 6ке:
http://wiki.freebsd.org/MySQL?action=recall&rev=10

(у меня, правда mysql был собран на 6ке стандартно, без каких-либо
оптимизаций.)

Но это все не дает ответа на вопрос о performance degradation после
апдейта на 7ку.
Разве что, SHED_ULE работает как-то неэфективно с libpthread.... (т.е. с
мускилем, собранным и работающим на старой libpthread)

Sergey A. Kobzar

unread,
May 20, 2009, 4:00:13 AM5/20/09
to UaFUG


Попробуйте включить кэширование запросов в MySQL. Мне оно помогло
увеличить производительность до 5-6 раз.

Конечно же все зависит от конкретных условий, насколько запросы
повторяются.

--
Sergey

Sergej Kandyla

unread,
May 20, 2009, 4:14:28 AM5/20/09
to UaFUG
Sergey A. Kobzar пишет:

> Попробуйте включить кэширование запросов в MySQL. Мне оно помогло
> увеличить производительность до 5-6 раз.
>
> Конечно же все зависит от конкретных условий, насколько запросы
> повторяются.
>
>
Да, собственно, стоит уже

query_cache_limit = 1M
query_cache_size = 16M
query_cache_type = 1


значения, правда, не большие....

При каких значаниях вы добились лучших результатов?
Оценка прироста производительности, визуально по системе, или бенчмарки
типа sysbench ?

Интересно что у Krisа
http://people.freebsd.org/~kris/scaling/mysql.html
вообще
query_cache_size=0

;)

--
Best wishes, Sergej Kandyla

Всегда улыбайтесь жизни и жизнь всегда улыбнется вам!

Mikolaj Golub

unread,
May 20, 2009, 5:31:01 AM5/20/09
to Sergej Kandyla, UaFUG

Это как раз "дает ответ". Дальше по ссылкам:

# Comparison of FreeBSD 5.5, 6.3 and 7.0. In 6.3 there are two userland
thread libraries (libkse and libthr; the former does not have good
performance). libthr is the default in 7.0. In 7.0 there are two
schedulers (SCHED_4BSD, the traditional scheduler, and SCHED_ULE).
SCHED_ULE has significantly better performance on most workloads.

http://people.freebsd.org/~kris/scaling/mysql-freebsd.png

libpthread это собственно kse, которая реализует N:M тредовую модель, на
которую покладались большие надежды, но в результате оказалось что реализация
намного сложнее чем 1:1 и на практике то что получилось работает хуже чем
libthr (1:1). В 8-ке N:M убрали совсем, хотя бродили мысли вернуть опять.

--
Mikolaj Golub

Reply all
Reply to author
Forward
0 new messages