タグ付けされた質問 「kernel」

UNIXカーネルに関するすべて:開発、構成、コンパイル、設計など

5
別のプロセスのスタックを読みますか?
子プロセスのスタックを読み取ろうとしていますが、運がありません。を使用してそれが可能であることはわかっていますptraceが、ptraceのインターフェイスでは一度に1単語しか読み取ることができず、スタックの大部分をスキャンしようとしています。 また、最初にptraceを使用して添付した後/proc/$pid/memに/proc/$pid/mapsファイルから抽出されたスタックの境界から読み取りを試みました(ここで提案されています)が、読み取りが失敗し続けますプロセスのさまざまな部分(ヒープなど)から読み取ります。 何が間違っていますか?他のオプションはありますか?
16 linux  kernel  memory  proc 

2
「serial8250:irq4には作業が多すぎる」カーネルメッセージを理解する
dmesg serial8250からの多くのメッセージを示します。 $ dmesg | grep -i serial [ 0.884481] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled [ 6.584431] systemd[1]: Created slice system-serial\x2dgetty.slice. [633232.317222] serial8250: too much work for irq4 [633232.453355] serial8250: too much work for irq4 [633248.378343] serial8250: too much work for irq4 ... このメッセージを見たことがありません。一般的にはどういう意味ですか?心配する必要がありますか? (私の調査では、ディストリビューション固有ではありませんが、関連がある場合は、Ubuntu 16.04を実行しているEC2インスタンスでメッセージが表示されます。)
16 kernel  dmesg 

3
古いLinuxカーネルがプリエンプティブでない理由は何ですか?
最初のLinux開発者は、なぜプリエンプティブでないカーネルの実装を選択したのですか?同期を保存するためですか? 私の知る限り、Linuxは90年代前半に開発されました。PCには単一のプロセッサが搭載されていました。そのようなPCにおいて、プリエンプティブでないカーネルはどのような利点がありますか?しかし、マルチコアプロセッサによって利点が減るのはなぜですか?

4
CentOS 7で古いカーネルバージョンを安全に削除するにはどうすればよいですか?
CentOS 7で競合するカーネルに起因する奇妙な症状に遭遇する可能性があります。それでは、古いカーネルを安全に削除するにはどうすればよいですか?そして、どのカーネルが最新のものであるかをどのようにして知ることができますか? 以下は、問題のサーバーでこれを調査するときに得られる端末出力です。パッケージのクリーンアップを試みましたが、同じ2つのカーネルが残っていることに注意してください。 このチュートリアルの手順では、次の2つのコマンドの出力は一致するはずですが、再起動後でも一致しないことがわかります。 [root@localhost ~]# rpm -qa kernel |sort -V |tail -n 1 kernel-3.10.0-229.el7.x86_64 [root@localhost ~]# uname -r 3.10.0-229.14.1.el7.x86_64 残りのコマンドは、2つのカーネルがあることを確認し、古いカーネルを削除する試みを示しています。 [root@localhost ~]# cd /usr/src/kernels [root@localhost kernels]# ls -al total 16 drwxr-xr-x. 4 root root 4096 Oct 2 12:55 . drwxr-xr-x. 4 root root 4096 Oct 2 13:15 .. drwxr-xr-x. …

4
/ procおよび/ sysでできることを知るにはどうすればよいですか[非公開]
閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか? 質問を更新して、 UnixおよびLinux Stack Exchangeで話題になるようにします。 2年前に閉店。 /procと/sys仮想ファイルシステムの高度な使用法についてもっと知りたいのですが、どこから始めればいいのかわかりません。誰もが学ぶための良いソースを提案できますか?また、sysには定期的に追加されると思うので、新しいカーネルがリリースされたときに最新の知識を維持するための最良の方法は何でしょうか。
15 linux  kernel  proc  sysfs 


7
Unixのシステム/マシンに関する情報を見つける方法
Unixでシステム自体に関する情報を見つけることは、それがそうであるかどうかにかかわらず、常に難しいと感じています どのOSを使用していますか(バージョン番号と、最新の利用可能なビルドと比較するため)。 どのデスクトップ環境を使用していますか?KDEを使用している場合、ほとんどのプログラムはKで始まり、KDEを使用していると言うことができますが、これを照会するには、スクリプトなどから何らかの方法が必要です。 どのカーネルバージョンを使用していますか?(たとえば、私はFedoraを使用していますが、使用しているLinuxカーネルのバージョンを知りたいです) 基本的に、私が見逃しているのは、このすべての情報を取得できる単一のポイント/ユーティリティです。ほとんどの場合、上記のソリューションはそれ自体がOS固有です。その後、あなたは立ち往生しています。

1
エラータによりTSC_DEADLINEが無効になりました
私は診断のためにコンピューターをメーカーに送り、ビデオ出力の問題を解決しました。彼らはBIOSを更新しました。それ以来、私は [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x20 (or later) 私は持っていなかったマイクロコードまたはucodeの前にインストールされたパッケージを、私はこのメッセージを取得するために使用されていませんでした。 メーカーに問い合わせたところ、「チケット番号を覚えていないがBIOSを更新したのではないか」と答えたため、あまり役に立ちません。 起動して動作しますが、TSC_DEADLINEは重要ですか? 私が見つけることができるのはこれだけです:https : //git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=73b866d89bf7c9a895d5445faad03fa3d56c8af8 しかし、それはVirtualBoxにのみ適用されるようで、いずれにせよ、すでにカーネル4.14を実行しているので、そのコミットが既に持っている問題を修正するかどうかを考えます。 ryan@pocketwee:~$ uname -a Linux pocketwee 4.14.0-1-amd64 #1 SMP Debian 4.14.2-1 (2017-11-30) x86_64 GNU/Linux

5
ルートファイルシステムが機能していない場合、SSH経由でLinuxマシンを再起動する方法はありますか?
好奇心のように。Linuxマシンで何か問題が発生し、ルートファイルシステムが「64Z」として表示されました。いくつかのコマンドの作業などtop、dfとkillのような、他はreboot(それがルートファイルシステムを読み取ることができないので)「コマンドが見つかりません」と出てくる、とchmodセグメンテーションフォールトを思い付きます。 とにかく、つまりrebootプログラムなしでシステムを再起動する方法はありますか?試しましたkill -PWR 1(SIGPWRをinitに送信)が、これは何もしないようでした。 それは主に学問的な好奇心です。障害の原因となった大規模なデータベース作業を行っていたラボメートは、すぐに物理的にマシンを再起動します。
15 kernel  kill 

3
isolcpusがアクティブ化されているかどうかを検出する方法
isolcpusがアクティブで、どのcpusであるかを検出する方法。たとえば、サーバーに初めて接続したとき。条件: 移行先を確認するプロセスを生成しません。 ユースケースはisolcpus=1-7、6コアi7で、ブート時にisolcpusをアクティブ化しないようです。isolcpusのアクティブ化の明確なステータスを提供するために、から/proc/、/sysまたはユーザー空間で読み取ることができるカーネル内部が可能かどうかを知りたいです。どのCPUが関係しているか。または、isolcpusが最初に懸念するスケジューラのアクティブ設定を読み取ることもできます。 稼働時間は非常に大きいためdmesg、起動時にエラーを検出するための起動ログを表示しないことを考慮してください。「カーネルコマンドラインを見てください」のような基本的な答えは受け入れられません:)
15 linux  kernel 


3
ブート時にカーネル全体がメモリにロードされていますか?
初期のRAMディスクの機能について説明しているこの人気のあるIBM文書(Webでかなり頻繁に参照されています)を読みます。 しかし、これがどのように機能するかを概念化する際に壁にぶつかりました。 ドキュメントでは、それは言います GRUBなどのブートローダーは、ロードされるカーネルを特定し、このカーネルイメージと関連するinitrdをメモリにコピーします 私はすでに混乱しています:カーネル全体をメモリにコピーしますか、それともその一部ですか?カーネル全体がメモリ内にある場合、なぜ初期RAMディスクが必要なのでしょうか? initrdの目的は、小さな汎用カーネルイメージを作成できるようにすることであり、カーネルイメージがロードされる前にinitrdが正しいモジュールをインストールすることだと思いました。しかし、カーネル全体がすでにメモリにある場合、なぜinitrdが必要なのでしょうか? それは私を混乱させる別のことももたらします-カーネルにロードされるモジュールはどこにありますか?すべてのカーネルモジュールはinitrd内に格納されていますか?

2
Linuxカーネルの複数のバージョンを使用するのは良いですか?
かつて、いくつかのカーネルパッチをインストールしていましたが、数百のクライアントがいるライブサーバーで何かがおかしくなりました。システムにはカーネルが1つしかありませんでした。そのため、サーバーはしばらく停止していました。ライブCDを使用して、システムを起動して実行し、さらに修復作業を行いました。 さて、私の質問:カーネルのバージョンが2つあることをお勧めします。そうすれば、カーネルが破損した場合に別の利用可能なカーネルでいつでも再起動できますか?私にお知らせください。 また、同じカーネルの2つのバージョンを使用することはできますか?カーネルが破損しているときに別のカーネルを選択できるようにするには? Edited: My Server Details: 2.6.32-431.el6.x86_64 CentOS release 6.5 (Final) カーネルが破損したときにバックアップカーネルを起動できるように、このカーネルの同じコピーを取得するにはどうすればよいですか?
14 linux  centos  kernel 

5
プログラミング言語での実装ではない場合、「システムコール」とはどういう意味ですか?
「システムコール」という用語を理解したいと思います。システムコールは、ユーザー空間アプリケーションからカーネルサービスを取得するために使用されることをよく知っています。 明確にする必要があるのは、「システムコール」と「システムコールのC実装」の違いです。 これは私を混乱させる引用です: Unixライクなシステムでは、そのAPIは通常、システム呼び出しにラッパー関数を提供するglibcなどのCライブラリ(libc)の実装の一部であり、多くの場合、呼び出し元のシステム呼び出しと同じ名前が付けられます。 「彼らが呼ぶシステムコール」とは何ですか?それらのソースはどこですか?コードに直接含めることはできますか? 一般的な意味での「システムコール」はPOSIX定義のインターフェイスにすぎませんが、実際に実装を確認するにはCソースを調べ、実際のユーザー空間からカーネルへの通信が実際にどのように行われるかを確認しますか? 背景メモ:最終的に、各c関数がからのデバイスと対話するかどうかを理解しようとしています/dev。
14 kernel  c  posix  system-calls 

6
Busyboxのping IPは機能しますが、ホスト名nslookupが「bad address」で失敗します
独自の3.14カーネルをコンパイルしています。DNSを機能させるための重要なネットワーク機能を省略したのではないかと心配しています。 ドメイン名を解決できません。DNSサーバーにpingできます。他のマシンでそのDNSを使用して解決できるため、サーバーではないことがわかります。 ~ # cat /etc/resolv.conf nameserver 192.168.13.5 ~ # nslookup google.com Server: 192.168.13.5 Address 1: 192.168.13.5 nslookup: can't resolve 'google.com' ~ # ping -c 1 google.com ping: bad address 'google.com' ~ # ping -c 1 192.168.13.5 PING 192.168.13.5 (192.168.13.5): 56 data bytes 64 bytes from 192.168.13.5: seq=0 ttl=128 time=0.382 …

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.