元スレSGI KDBを使ったカーネルデバッグスレ

kernel覧

前へ 1 2 3 4 5 6 7 8 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

151 = :

>>148
1必死だな。

152 = :

>>138
ほれ、出てきてやったぞ。どうすんだ。

153 = :

本物かどうか試験してやろう
jiffies が10倍早く回るようにする為にはどうすればいい？

154 = :

>>152
やった！空けたな。

155 = :

なかなか面白いな。このスレ。
>オリジナルスレの1
煽りはほっといて質問
プロセステーブルが一杯になったからと言ってシステムの動作がおかしくなるのは何故だ？
psやkillが上がらないのは当然として、kernelの挙動には影響無いはずだが。
デバッグの格好の対象だと思うがどうだ。

あと、プロセスを上げず(killコマンドじゃなくて)にシステムを正常に戻す方法はないのか？

>エセLin注
プロセステーブル一杯でプロセスが上がらなくなるのはLinuxだけじゃないぞ。

156 = :

うん、もうやめようよ。
1の自作自演はもう限りなく有力ではあるが、
これ以上ひっぱるのはやめよう。
優しく1を見守ってやろう。
「>>115　1発見！」とかもなしな。
言いたいのはわかるが、おさえろ。
本来の趣旨に戻してやってくれ。

157 = :

>>155
デーモンとかが新規プロセスを立ち上げられないからじゃないの？
inetdもフォーク出来ないっしょ。多分。
もとから動いてたプロセスは死なずに生きつづけてるよ。
こうなったときに正常に戻す方法はオレも>>1に聞きたい。

158 = :

>>156
ゲキウザ

159 = :

>>153
まあ、答える義理はないけど、一応な。
timer.c のdo_timer関数をみましょう。すぐわかるよ。

160 = :

>>157
デーモンはforkに失敗して死ぬことはあると思う。
ただ、inetdが死んだからってkernelには影響ないと思う。
inetdもユーザプロセスだからな。

initがプロセス作ろうとして失敗するからか？

>オリジナルスレの1
本物かどうかのチェックなんてどうでも良いからこっちやろうぜ。

161 = :

>>155
うーん、俺のところではそういう状況になってないからはっきりとした
ことは言えないが、2.2系ではプロセステーブルが一杯になっても
確かにカーネルの挙動には影響ないはず。
2.4系ではforkが落ちる=メモリ確保失敗だから、他のカーネルモードドライバ/
ファイルシステムもメモリ確保できないはずだから挙動はおかしくなるはず。
こうなったらもう、どうにもならない。仕様だね。

162 = :

>>161
こらこら適当に回答するんじゃない。なんだか投げやりだぞ。頑張れ

if (atomic_read(&p->user->processes) >= p->rlim[RLIMIT_NPROC].rlim_cur)
　　　　goto bad_fork_free;
これでなんでメモリ確保のエラーなのだ？
メモリは空いてるはずだが。

おれもカーネルソース見てみるかな。ちと興味が湧いた 藁
　　

164 = :

ちょっと補足すると。俺の環境ではRLIMIT_NPROCがちゃんと働いてメモリを
使い切らない程度にしかプロセスは立ち上がらない。この時にはすでに
立ち上がってるデーモンや、カーネル/カーネルモードドライバにはなにも
影響がなくおかしな挙動もない。
もし、RLIMIT_NPROCを非常に大きな値に設定した場合はforkが落ちるのは
メモリ確保失敗だから他のメモリ確保も失敗する。そうなったら挙動は
当然おかしくなる。

165 = :

2.2系ではお手上げってことか

168 = :

まとめ
>>3-8
カーネルデバックの方法
>>26
なぜか荒しがこのスレの自作自演に反論。
>>88
結構良いことを言ってる。
>>115
良いことも言ってるが煽り入り。
>>127
自作自演を認めるような発言。

169 = :

36,37に迷惑がかかるのは嫌なので言っておく。
俺は最近この板に書き込むときにはちゃんと"オリジナルスレの1"を使ってる。
だから 36も37も全く別の人。他の人に噛み付くのは止めてくれ。

170 = :

もう結論が出たネタに間隔をおいて反論してみる１。
>>123,>>126,>>130
このあたりが結論でしょう。
限りなく黒に使いグレー

171 = :

Linux板にはカーネルデバッグを嫌う奴がいるみたいだな。
人それぞれだから、それはそれで良いとしても、
オープンソースを掲げるLinuxの板がこれではなぁ...

172 = :

>>171
カーネルデバックがダメって主張してるのは一人ぽい。
他の人はオリジナルスレの１がうざいとか、
おもしろい素材だから煽って遊んでるってな感じじゃないの？
前科なくこのスレを建てていたら好意を持って迎えられていたでしょう。

173 = :

前科ねえ(笑。そういう俺が何かレスしたら煽るって粘着っていうんじゃないの？

174 = :

>>173
雑音は気にせず頑張ってください。
あと、2.2系でプロセスいっぱいになった時の対処も教えてください。

175 = :

>>35-37
これは凄い気持ち悪いと思う・・・
粘着厨房は私も嫌いだったけど・・・
ある意味それより嫌な人間性・・・
粘着より粘着してるよ・・・
傍から見てても。

176 = :

某所の「オリジナルスレの1 うぉっちスレ」も盛り上がってきました。

177 = :

いまちゃんと2.2系のソースを見てみたら、こんな風になってる。
static inline struct task_struct ** find_empty_process(void)
{
　　struct task_struct **tslot = NULL;

　　if ((nr_tasks < NR_TASKS - MIN_TASKS_LEFT_FOR_ROOT) || !current->uid)
　　　　tslot = get_free_taskslot();
　　return tslot;
}
MIN_TASKS_LEFT_FOR_ROOTはtasks.hで#define MIN_TASKS_LEFT_FOR_ROOT 4
と定義されてるから、4つのプロセスだけROOTのメンテ用に残されてる。
だから、ちゃんと動くはず。
これでも動かないとなると、搭載物理メモリ量に対して起動できるプロセスが
多すぎるんだね。メモリアロケーションで失敗するよりも、
　　retval = -EAGAIN;
　　if (p->user) {
　　　　if (atomic_read(&p->user->count) >= p->rlim[RLIMIT_NPROC].rlim_cur)
　　　　　　goto bad_fork_free;
　　　　atomic_inc(&p->user->count);
　　}
こっちのチェックで失敗するようにNR_TASKSを小さな値にして再構築するべきだね。
2.4系ではNR_TASKSは搭載物理メモリ(MB)*64になってる。例えば32MB積んでるなら
32*64で2048個。
でも512個って8MBのメモリのマシン用の設定なんだよね。55がそんな少ないメモリの
マシンを使ってるとは思えないんだよなあ。または既に増やして再構築済みとか？

178 = :

自作自演疑惑の煽りとかコピペの煽りじゃなくて、もうちっと技術的な煽りは
出来ないんかい？ちょっと難しい題材提示するとかさあ。
これじゃあ技術的な話に付いてこれないって言うのを認めてるようなもんだぞ。
でもjiffiesの増分を変えるとかいう、ソースサーバーの電源を立ち上げて
3分で分かるような簡単な質問はやめてくれよな。つまんないし勉強にもならない。
あと、全く情報がないのとか不可能な題材も勘弁な。

179 = :

>>178
3分でわかる って思ったからこそ出題したんだよ。
ここに来てるヤツの８０パーセントはちんぷんかんぷんだったと思うよ。

180 = :

>>オリ１ 殿
デバイスドライバ作りにおいて、カーネルスレッドを起こしたとき
rmmodするときはまず先に殺しとかないと文句垂れられるけど
あれってシグナル受け取るか共有メモリ使うかとかする必要が
あってけっこうめんどくさいよね。
かといって手を抜くわけにもいかないし。

なんかいいスケルトンとか、サンプルになるソースってある？

181 = :

>>180
とりあえず、サンプルは探してみる、ちょっとまってな。
なかったら自分でこさえてみるよ。
でもそこまで分かってるんなら、多分それ以外の方法はないし、自分で
出来るんじゃないか?(笑
ところでLinuxってNT/W2KでいうWaitForMultipleObjectsみたいな
関数はないの？これがあれば、カーネルスレッドのWorkItemでの待ちと
終了用のイベントの待ちを同時に行えてエレガントなコードに出来ると
思うんだけど。

183 = :

>>181
一応自分でも作ったんだよね～。
でもジュウザなみに我流なんで、何とかしたいなあと。

今使ってる方法は共通エリアに終了フラグを作っといて、
終わりたいときはcleanupモジュールでそのフラグ立てて
インたら_sleep_onですぐ寝ると。で、カーネルスレッド側で
ループの先頭でそのフラグを見たら適当に終了処理して
cleanupで寝てる人を起こす。

なんか危なっかしい（正常ルートしか考慮してないし）ので
上手い方法ご教示プリーズ

184 = :

>>178
そうやって反応するからまた煽られるのですよ。
少し１擁護派だったけどやっぱり馬鹿厨房だな。

185 = :

>>183
それで正しいと思うよ。多分100人中80人くらいがその方法をとるだろうね。

186 = :

>>185
ループの最中に必ずスケジューラを呼ぶついでに
そのへんの終了プロセスを一手に引き受けてくれるような
便利な仕組みがあったら欲しいんだよね。
そういう便利ルーチンが用意されてないとなると、自分で
適当に作るしかないってことかな？　・・・なんで用意してないんだろ。

余談だけどRT-Linuxはその辺が標準でサポートされてて、
ブッ殺すって心の中で思ったならッ！
その時スデにプロセスは終わっているんだッ！
って感じで便利だったよ。

187 = :

まだやってんのか（ﾌﾟﾌﾟ

188 = :

>>187
うるせえよ、ヴァカ。

189 = :

>>187
煽りを装って上げてみたチキンな１に萌え～
自分はsageで自作自演キャラで上げるチキン野郎DEATH!

190 = :

今見たけど、きもいね1。
真・粘着厨房と呼ぼう。

191 = :

粘着対粘着
この勝負いかに！？

192 = :

さらなるネタ希望age

タスク切り替えのコストとか解説が欲しい今日この頃

193 = :

１は大阪の事件で・・・
だからあまり追い込むなと・・・

194 = :

>>192
うーん、こんな所に書き込んでもなんか粘着ばかりでウザイくて馬鹿らしく
なってきたんで、止めますわ。

195 = :

うん。その方が良いと思うぞ。
どっか別な場所に情報上げたら教えてくれ。

粘着も良くかも知れないが 藁

196 = :

自作自演に疲れました。探さないでください。
スレが伸びるのは自作自演と煽りばかり、虚しくなりました。

198 = :

>>194
やめないでくれよ
せめて>>192の問いに答えてくれ。
2.2系と2.4系で差はあるの？

199 = :

おいおい、とんでもないオナニースレだな。
自分で気持ち悪い粘着ぶり晒しといて
「粘着がいるから」ﾊｧ？
ｲﾀ過ぎて笑うしかないねこりゃ。

じゃ、ここを代表して最後に
＞スレが伸びるのは自作自演と煽りばかり
オマエノナー

200 = :

>>194
"こんな所"にスレを二つも立てて、自己顕示欲を満たそうとしていたのは誰？
きっと実社会でも人の輪に入っていくのが苦手なんだろうね。
2ちゃんでも輪に入れないなんて、かわいそうだよ。

感嘆詞、文章
という書き出しも１の特徴だね。
>>19-20の自作自演でも見られます。

前へ 1 2 3 4 5 6 7 8 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / kernel一覧へ

類似してるかもしれないスレッド

• あなたのカーネルパッチを教えろやゴルァ！ (300) - [30%] - 2009/12/12 11:32
• 【Linux】カーネル総合7【Kernel】 (247) - [25%] - 2022/12/17 20:30
• 【Linux】カーネル総合6【Kernel】 (980) - [25%] - 2015/4/13 16:30