Хм, всъщност се сещам за един вариант как това може да се случи...ако е пуснато от X и X server-a бъде убит...
Но не виждам начин при logout от конзолата ядрото да забие защото няма tty на което да прати IOCTL-то. Всъщност дори и да се пробва да го прави на несъществуващ терминал би следвало да се върне грешка, а не да забие цялото ядро..
Поне при мен като тест-вам нямам проблеми със затваряне на "активната" (fg_console) конзола, естествено това звучи малко като "при мен работи, за вас не ми дреме" :)
Според мен причината вероятно е някъде другаде. С какво ядро го тестваш? Клавиатурата USB или PS/2 е?
Ако все пак това се окаже проблема, предполагам ще стигне просто да се замени fg_console с 1)...
Ще се радвам все пак ако можеш да пейстнеш какво точно изписква ядрото като се паникьосва..
[Отговори на този коментар]
Към: Към: Spek
От: kmakaron
На: 22-09-2006@9:52 GMT+2
Оценка: 1/НеутраленТака, пробвах го съвсем набързо на работа, а сега съм в къщи. Ядрото е 2.6.16.16, слак 10.2.
Първо го заредих в конзола на Х, и като видях че проработи, го махнах, превключих на чиста конзола без да изключвам Х-а, заредих ледс, и натиснах Ctrl-D. Ядрото ми направи dump, на регистрите и стека и отдолу се мъдреше Kernel Panic:.....Не си направих труда да прочета какво точно гласеше. Надявам се че това ще помогне. От друга страна машината беше 29 дни уп, и имаше проблеми с мтаб-а. Може просто да и е било време:))
[Отговори на този коментар]
Към: Към: Към: Spek
От: gat3way
На: 22-09-2006@12:42 GMT+2
Оценка: 1/НеутраленХм, mtab-a не би трябвало да има някаква връзка..
Всъщност, първата "версия" на тая глупост я бях правил с add_timer() а не mod_timer()...при което всяка секунда се дефинираха 35 callback функции...при което в един прекрасен момент производителността приятно деградираше докато не забие ядрото..
Другият експеримент беше че го бях реализирал при всеки получен пакет да се прави mod_timer()...при което при повечко входящ трафик ставаха малко странни случки..
Във всеки случай нямам никаква идея защо се е случило така. Може би ако го тестват повече хора при които се случи същия проблем..и дадат feedback ще загрея какво става...иначе при мен засега няма проблем, работи вече няколко дена и не забелязвам проблеми от сорта на leaks или някаква деградация на производителността...но ще е интересно повече хора да го тестват..
[Отговори на този коментар]
Към: Към: Към: Към: Spek
От: lubo <lmateev (a) mail[ точка ]bg>
На: 23-09-2006@17:38 GMT+2
Оценка: 1/НеутраленСлед 4 часа работа и при мен грумна с kernel panic
root@router:~# cat /etc/slackware-version
Slackware 11.0.0
root@router:~# uname -a
Linux router 2.6.11.12 #3 Sun Jul 23 19:38:50 EEST 2006 i686 pentium2 i386 GNU/Linux
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 6
model name : Celeron (Mendocino)
stepping : 5
cpu MHz : 367.631
cache size : 128 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr
bogomips : 722.94
root@router:~# free
total used free shared buffers cached
Mem: 158016 152428 5588 0 7556 66388
-/+ buffers/cache: 78484 79532
Swap: 514040 0 514040
[Отговори на този коментар]
Към: Към: Към: Към: Към: Spek
От: gat3way
На: 28-09-2006@10:23 GMT+2
Оценка: 1/НеутраленХм, май имам някакво обяснение за това.
Според мен става следното: поради някаква причина (натоварен процесор/бавна система), моята timer функция отнема прекалено много време...достатъчно за да може докато още се изпълнява, да се вдигне следващият timer interrupt и да настане лоша мацаница..
Също така, доколкото съм чел при някои платформи (IA64), прекъсването на таймера се вдигало доста по-често (нямам лични впечатления обаче). При такава машина, това нещо би трябвало скоростно да изгърми :)
Ще ви пиша като го оправя, не е кой знае каква работа, и ще се радвам някой да се навие да го тест-ва...
[Отговори на този коментар]
Към: Към: Към: Към: Към: Към: Spek
От: kmakaron
На: 28-09-2006@14:00 GMT+2
Оценка: 1/НеутраленМожеби тук е мястото да вметна, че съм с А64, работещ в 32бит режим.
[Отговори на този коментар]
Към: Към: Към: Към: Към: Към: Spek
От: gat3way
На: 28-09-2006@16:23 GMT+2
Оценка: 1/НеутраленТъй...вече таймер функцията е "обезопасена" с spin_lock_irqsave()/spin_unlock_irqrestore()
Надявам се това да разреши проблемът със стабилността.
Извинявам се на тези, чиито kernel съм забил :)
[Отговори на този коментар]