Всем привет!Господа, у кого система FreeBSD 4.7-RELEASE-p2 и сетевухи
Intel Pro/100 Ethernet (может в них дело?)я уже задолбалась
при большой нагрузке и нескольких переводах сетевухи в promiscuous mode и обратно (trafshow, tcpdump) вываливает fatal trap 12:
интересно то, что instruction pointer, stack pointer и frame pointer в двух случаях идентичны (больше случаев пока не было).еще симптом - squid незадолго до этого возвращает бразеру ошибку: broken pipe
при этом panic нет - переходим в отладчик, так что даже дампа не поиметь с ядра (точнее я видимо не знаю как его оттуда поиметь)...кто-нибудь с этим сталкивался?
вот сам trap:
Jan 23 09:56:22 mail /kernel: fxp0: promiscuous mode enabled
Jan 23 09:56:34 mail /kernel: fxp0: promiscuous mode disabled
Jan 23 09:56:51 mail /kernel: fxp0: promiscuous mode enabled
Jan 23 09:56:51 mail /kernel: fxp0: promiscuous mode disabled
Jan 23 09:57:47 mail /kernel: fxp0: promiscuous mode enabled
Jan 23 10:22:01 mail /kernel:
Jan 23 10:22:01 mail /kernel:
Jan 23 10:22:01 mail /kernel: Fatal trap 12: page fault while in kernel mode
Jan 23 10:22:01 mail /kernel: fault virtual address = 0xa022e000
Jan 23 10:22:01 mail /kernel: fault code = supervisor read, page
not present
Jan 23 10:22:01 mail /kernel: instruction pointer = 0x8:0xc0174438
Jan 23 10:22:01 mail /kernel: stack pointer = 0x10:0xc024f6b4
Jan 23 10:22:01 mail /kernel: frame pointer = 0x10:0xc024f6c8
Jan 23 10:22:01 mail /kernel: code segment = base 0x0, limit 0xffff
f, type 0x1b
Jan 23 10:22:01 mail /kernel: = DPL 0, pres 1, def32 1, gran 1
Jan 23 10:22:01 mail /kernel: processor eflags = interrupt enabled, resume, IOP
L = 0
Jan 23 10:22:01 mail /kernel: current process = Idle
Jan 23 10:22:01 mail /kernel: interrupt mask = net
>при этом panic нет - переходим в отладчик, так что даже дампа
>не поиметь с ядра (точнее я видимо не знаю как его
>оттуда поиметь)...написать в отладчике волшебное слово panic
>>при этом panic нет - переходим в отладчик, так что даже дампа
>>не поиметь с ядра (точнее я видимо не знаю как его
>>оттуда поиметь)...
>
>написать в отладчике волшебное слово panicага
делала я такоеhttp://www.freebsd.org.ua/faq/advanced.html#KERNEL-PANIC-TRO...
"[Билл (Bill) добавил: "Я забыл обратить ваше внимание на одну вещь: если у вас включена поддержка DDB и ядро переходит в режим отладки, вы можете намеренно вызвать аварийный останов (и создание аварийного дампа), набрав 'panic' в командной строке ddb. Этот процесс может снова вызвать отладчик. В этом случае наберите 'continue' и процесс будет завершён созданием аварийного дампа." -ed]"
НИФИГА
fatal trap 12 до бесконечностискажу больше (instruction pointer = 0x8:0xc0174438)
root@mail# nm -n /kernel| grep 0174438
root@mail# nm -n /kernel | grep 017443
root@mail# nm -n /kernel | grep 01744
c01744c4 T m_getmЕСТЕССТВЕННО:
root@mail# cat /etc/rc.conf.local |grep dump
dumpdev="/dev/ad0s1b"
dumpdir="/usr/local/var/crash"root@mail# ls -l /usr/local/var/
total 8
drwxr-xr-x 2 root wheel 512 Dec 2 11:04 crash
drwxr-xr-x 2 root wheel 512 Sep 5 20:32 log
drwxr-xr-x 5 netsaint netsaint 512 Jan 23 13:25 netsaint
drwxr-xr-x 2 root wheel 512 Sep 5 20:32 trafdв ядре:
options DDB
makeoptions DEBUG=-gи при загрузке - no coredump
млин :(
>>>при этом panic нет - переходим в отладчик, так что даже дампа
>>>не поиметь с ядра (точнее я видимо не знаю как его
>>>оттуда поиметь)...
>>
>>написать в отладчике волшебное слово panic
>
>ага
>делала я такое
>
>http://www.freebsd.org.ua/faq/advanced.html#KERNEL-PANIC-TRO...
>
>"[Билл (Bill) добавил: "Я забыл обратить ваше внимание на одну вещь: если
>у вас включена поддержка DDB и ядро переходит в режим отладки,
>вы можете намеренно вызвать аварийный останов (и создание аварийного дампа), набрав
>'panic' в командной строке ddb. Этот процесс может снова вызвать отладчик.
>В этом случае наберите 'continue' и процесс будет завершён созданием аварийного
>дампа." -ed]"
>
>НИФИГА
>fatal trap 12 до бесконечности
>
>скажу больше (instruction pointer = 0x8:0xc0174438)
>
>root@mail# nm -n /kernel| grep 0174438
>root@mail# nm -n /kernel | grep 017443
>root@mail# nm -n /kernel | grep 01744
>c01744c4 T m_getm
>
>ЕСТЕССТВЕННО:
>root@mail# cat /etc/rc.conf.local |grep dump
>dumpdev="/dev/ad0s1b"
>dumpdir="/usr/local/var/crash"
>
>root@mail# ls -l /usr/local/var/
>total 8
>drwxr-xr-x 2 root wheel
> 512 Dec 2 11:04 crash
>drwxr-xr-x 2 root wheel
> 512 Sep 5 20:32 log
>drwxr-xr-x 5 netsaint netsaint 512 Jan 23 13:25 netsaint
>
>drwxr-xr-x 2 root wheel
> 512 Sep 5 20:32 trafd
>
>в ядре:
>options DDB
>makeoptions DEBUG=-g
>
>и при загрузке - no coredump
>
>млин :(тогда избегать вышеописанной ситуации (включение-выключение promisc несколько раз) и man send-pr.
даже если кто-то в этом форуме может помочь, все же и разработчикам будет совсем не вредно знать о проблеме.
>тогда избегать вышеописанной ситуации (включение-выключение promisc несколько раз) и man send-pr.
>даже если кто-то в этом форуме может помочь, все же и разработчикам
>будет совсем не вредно знать о проблеме.совет конечно хороший :)
я вот как раз собираюсь вечером поступить наоборот - повторить ситуацию еще пару раз. Если все будет также - send-pr, НО: как дамп ядра то получить...?и может кто-то все же имел/имеет схожую проблему...
PS: на 4.5-STABLE при прочих равных этого не было...
>я вот как раз собираюсь вечером поступить наоборот - повторить ситуацию еще
>пару раз. Если все будет также - send-pr, НО: как дамп
>ядра то получить...?send-pr по поводу невозможности получить дамп или вопрос в один из листов рассылки.
>
>>я вот как раз собираюсь вечером поступить наоборот - повторить ситуацию еще
>>пару раз. Если все будет также - send-pr, НО: как дамп
>>ядра то получить...?
>
>send-pr по поводу невозможности получить дамп или вопрос в один из листов
>рассылки.ок спасиб за ответ
и все же если кто-то знает....
>>тогда избегать вышеописанной ситуации (включение-выключение promisc несколько раз) и man send-pr.
>>даже если кто-то в этом форуме может помочь, все же и разработчикам
>>будет совсем не вредно знать о проблеме.
>
>совет конечно хороший :)
>я вот как раз собираюсь вечером поступить наоборот - повторить ситуацию еще
>пару раз. Если все будет также - send-pr, НО: как дамп
>ядра то получить...?
>
>и может кто-то все же имел/имеет схожую проблему...
>
>PS: на 4.5-STABLE при прочих равных этого не было...наблюдал нечто похожее на 4.7-RELEASE-p1, а именно:
есть машина с 4.6.2-RELEASE (PIII, 6 сетевух Intel PRO/100) используется в качестве DHCP сервера, цвсапнул ее до 4.7-RELEASE-p1,
при скачивании большого файла по фтп система вылетает в panic, т.к. сервер боевой времени разбираться не было, спешно вернулся на 4.6.2 все зажило как раньше. При этом имеем другую машину 4.7-RELEASE (PI, 4 сетевухи Intel PRO/100) используется в качестве моста, через интерфейсы проходит огромное количество трафика но все работает как часы.
>>>тогда избегать вышеописанной ситуации (включение-выключение promisc несколько раз) и man send-pr.
>>>даже если кто-то в этом форуме может помочь, все же и разработчикам
>>>будет совсем не вредно знать о проблеме.
>>
>>совет конечно хороший :)
>>я вот как раз собираюсь вечером поступить наоборот - повторить ситуацию еще
>>пару раз. Если все будет также - send-pr, НО: как дамп
>>ядра то получить...?
>>
>>и может кто-то все же имел/имеет схожую проблему...
>>
>>PS: на 4.5-STABLE при прочих равных этого не было...
>
>наблюдал нечто похожее на 4.7-RELEASE-p1, а именно:
>есть машина с 4.6.2-RELEASE (PIII, 6 сетевух Intel PRO/100) используется в качестве
>DHCP сервера, цвсапнул ее до 4.7-RELEASE-p1,
>при скачивании большого файла по фтп система вылетает в panic, т.к. серверхм
у меня при копировании большого (больше чем оперативки) файла по scp все в той же 4.7-RELEASE-p2 куда-то утекала память (система свопилась и зависала, точнее, может и не зависала, но я не ждала особо - время реакции было огромным). после замены (и увеличения) памяти зависание прекратилось... panic не было...>боевой времени разбираться не было, спешно вернулся на 4.6.2 все зажило
>как раньше. При этом имеем другую машину 4.7-RELEASE (PI, 4 сетевухи
>Intel PRO/100) используется в качестве моста, через интерфейсы проходит огромное
>количество трафика но все работает как часы.ага...
а на дамп не смотрел?
или nm -n на ядро?
>ага...
>а на дамп не смотрел?
>или nm -n на ядро?к сожалению нет, срочно нужно было восстановить работу сервера
>>ага...
>>а на дамп не смотрел?
>>или nm -n на ядро?
>
>к сожалению нет, срочно нужно было восстановить работу сервераок
спасибо за откликпо крайней мере не только у меня такое бывает :)
>>>ага...
>>>а на дамп не смотрел?
>>>или nm -n на ядро?
>>
>>к сожалению нет, срочно нужно было восстановить работу сервера
>
>ок
>спасибо за отклик
>
>по крайней мере не только у меня такое бывает :)такое было при сочетании некоторого железа, при интегрированных на материнке intel карт и на некоторых SMP мамках с intel картами, время
от времени исправляли, но иногда вылезало. Утверждают что драйвер fxp
якобы существенно вылизали...
>>>>ага...
>>>>а на дамп не смотрел?
>>>>или nm -n на ядро?
>>>
>>>к сожалению нет, срочно нужно было восстановить работу сервера
>>
>>ок
>>спасибо за отклик
>>
>>по крайней мере не только у меня такое бывает :)
>
>такое было при сочетании некоторого железа, при интегрированных на материнке intel карт
>и на некоторых SMP мамках с intel картами, время
>от времени исправляли, но иногда вылезало. Утверждают что драйвер fxp
>якобы существенно вылизали...сейчас я с примерно 75% уверенностью могу локализовать проблему (надо бы еще потестить):
имеем сетевуху Intel и RELEASE-4.7-p2 (тесты проводятся на тестовой машине, те я могу сказать, что уже на двух машинах такое наблюдаю...)
запускаем на этой машине trafshow -i fxp0 -n -r1идем на вторую машину и говорим там:
scp big.file linas@problem.host:
password:не успеваем дойти (даже переключиться) до первой машины - на ней уже fatal trap 12
trafshow можно запускать как до так и во время - в 3-х из 4-х случаев срабатывает. При этом если не запускать ничего такого, что переводит в прослушивающий режим (trafshow например), система живет спокойно...
и еще (дальше все срисовывала вручную - могла и ошибиться):Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xc0c2b017
<skipped>
Stopped at m_getcl+0x203: incb 0(Йx, Мx, 1)db> trace
m_getcl(1,1,2,x0b0d200,c0a9c802) at m_getcl+0x203
fxp_add_rfabuf(ceaaec00,c0b0d200) at fxp-add_rfabuf+0x17
fxp_intr_body(ccaaec00,40,ffffffff) at fxp_intr_body+0xdc
fxp_intr(ccaaec00,660820,94,b27d404e,40001000) at fxp_intr+0x65
intr_mux(c0a63880,0,2f,2f,2f) at intr_mux+0x1d
Xresume11() at Xresume11+0x2b
---interrupted, eip=0x280d59ce, esp=0xe667dfe0, ebp=0x4000100---db> panic
panic: from debugger
Debugger ("panic")Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8: 0xc01fe4d0
<skipped>
Stopped at m_getcl+0x203: incb 0(Йx, Мx, 1)db> continue
Fatal trap 12: page fault while in kernel mode
<skipped>ну и тыды до бесконечности...
и дампа по прежнему нет...
PS: попыталась проделать то же самое на 3Com сетевухе - не получилось...такая вот бяка
всем большущее спасибо за советы и участие.
буду осваивать send-pr
добрый день,може быть как вариант - заменить существующие Intel на 3COM карточки
(конечно если нет проблем с наличием железок и/или $)
br,
Oleg
>добрый день,
>
>може быть как вариант - заменить существующие Intel на 3COM карточки
>
>(конечно если нет проблем с наличием железок и/или $)
>
>br,
>Olegеще вариант (смешной) - заменить на compex карточки на rl чипах :)
>>добрый день,
>>
>>може быть как вариант - заменить существующие Intel на 3COM карточки
>>
>>(конечно если нет проблем с наличием железок и/или $)
>>
>>br,
>>Oleg
>
>еще вариант (смешной) - заменить на compex карточки на rl чипах :)
>:)
не, господа, 11 сетевух поменять не реально :)))
и потом - это не РЕШЕНИЕ проблемы, а УХОД от нее ...