おいマジか勘弁してくれ事案発生
ある日アクセスしようとしたところですね、サーバが固まってるんすよ。こんなログ吐いて。
ERROR CRITICAL: Xe has declared device 0000:03:00.0 as wedged.ゲー、ﾏｼﾞか！？と思い、電プチ再起動してみたらまた普通に動き出した。( ´･ω･)y-~ ｴﾄ…何故だろう
とか考えるのだけど、今のところは何ともワカランのでそのまま使おう！と思って使ってみると翌日これが出力されるなど(´･ω･`)
2026-09-08T17:20:43.596656+09:00 dproto02 kernel: xe 0000:03:00.0: [drm] GT0: Schedule disable failed to respond, guc_id=2
2026-09-08T17:20:43.596680+09:00 dproto02 kernel: xe 0000:03:00.0: [drm] *ERROR* GT0: Force wake domain 0: wake. MMIO unreliable (forcewake register returns 0xFFFFFFFF)!
2026-09-08T17:20:43.596682+09:00 dproto02 kernel: xe 0000:03:00.0: [drm] *ERROR* GT0: Force wake domain 1: wake. MMIO unreliable (forcewake register returns 0xFFFFFFFF)!
2026-09-08T17:20:43.596684+09:00 dproto02 kernel: xe 0000:03:00.0: [drm] GT0: Forcewake domains 0x3 failed to acknowledge awake request
2026-09-08T17:20:43.596687+09:00 dproto02 kernel: Modules linked in: tls nvidia_uvm(POE) nf_conntrack_netlink xt_nat xt_tcpudp veth xt_conntrack......e
2026-09-08T17:20:43.617591+09:00 dproto02 kernel: xe 0000:03:00.0: [drm] *ERROR* GT0: Force wake domain 0: wake. MMIO unreliable (forcewake register returns 0xFFFFFFFF)!
2026-09-08T17:20:43.617600+09:00 dproto02 kernel: xe 0000:03:00.0: [drm] GT0: Forcewake domain 0x1 failed to acknowledge awake request
2026-09-08T17:20:43.617602+09:00 dproto02 kernel: Modules linked in: tls nvidia_uvm(POE) nf_conntrack_netlink xt_nat xt_tcpudp veth xt_conntrack se_keymap intel_cstate platform_profile......
2026-09-08T17:20:43.621866+09:00 dproto02 kernel: xe 0000:03:00.0: [drm] Xe device coredump has been created
2026-09-08T17:20:43.621871+09:00 dproto02 kernel: xe 0000:03:00.0: [drm] Check your /sys/class/drm/card0/device/devcoredump/data
2026-09-08T17:20:43.621872+09:00 dproto02 kernel: xe 0000:03:00.0: [drm] GT0: trying reset from xe_guc_exec_queue_lr_cleanup [xe]
2026-09-08T17:20:43.621872+09:00 dproto02 kernel: xe 0000:03:00.0: [drm] GT0: reset queued
2026-09-08T17:20:43.621873+09:00 dproto02 kernel: xe 0000:03:00.0: [drm] GT0: reset started
2026-09-08T17:20:43.621873+09:00 dproto02 kernel: xe 0000:03:00.0: [drm] *ERROR* GT0: Force wake domain 0: wake. MMIO unreliable (forcewake register returns 0xFFFFFFFF)!
2026-09-08T17:20:43.621874+09:00 dproto02 kernel: xe 0000:03:00.0: [drm] *ERROR* GT0: Force wake domain 1: wake. MMIO unreliable (forcewake register returns 0xFFFFFFFF)!
2026-09-08T17:20:43.621875+09:00 dproto02 kernel: xe 0000:03:00.0: [drm] GT0: Forcewake domains 0x3 failed to acknowledge awake request
2026-09-08T17:20:43.621875+09:00 dproto02 kernel: xe 0000:03:00.0: [drm] *ERROR* GT0: Force wake domain 0: wake. MMIO unreliable (forcewake register returns 0xFFFFFFFF)!
2026-09-08T17:20:43.621877+09:00 dproto02 kernel: xe 0000:03:00.0: [drm] *ERROR* GT0: Force wake domain 1: wake. MMIO unreliable (forcewake register returns 0xFFFFFFFF)!
2026-09-08T17:20:43.621878+09:00 dproto02 kernel: xe 0000:03:00.0: [drm] GT0: Forcewake domains 0x3 failed to acknowledge awake request
2026-09-08T17:20:43.621881+09:00 dproto02 kernel: stp llc xfrm_user xfrm_algo xt_set ip_set nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defra .....
2026-09-08T17:20:43.623480+09:00 dproto02 kernel: xe 0000:03:00.0: [drm] *ERROR* GT0: reset failed (-ETIMEDOUT)よくよく振り返ってみるとこんなことはあったんすよ。
- やたらめったらファンがON/OFFを細かく送ってる感じの挙動があった
- 推論が終わってもずーっとファンが一定の速度で動き続けてた
で、ファンが止まったと思ったらこのログですよ。最後に推論して2時間ほど経過したところで問題が起きてるようにみえました。なお、OS巻き込んで停止しちゃったようなので、これもう電プチ再起動しかないんすよ・・・(´；ω；｀)ﾌﾞﾜｯ
原因を追及してみる
まず、ARCを動かすのを一旦やめて、GPT-5.6-Lunaに渋々聞きに行く。するとこんな作用機序になってるんじゃないかとのご指摘を頂戴しました。
GuCのスケジュール停止に応答しない
↓
GTのMMIOアクセスが 0xFFFFFFFF を返す
↓
Force Wakeに失敗する
↓
GTリセットを実行できない
↓
reset failed (-ETIMEDOUT)
↓
Xeデバイスをwedgedとして宣言するうーむむ、GuCが送り込む制御信号をデバイスがうまく受け取れてないっぽい。
まず、デバイスコアダンプの採取に挑むが「あ、OS再起動したらファイル内やん」で断念。とは言えOSも固まってるんじゃこの場合どうしようもない(´･ω･`)
で、ログ整理のためにショボーンとSyslogを見てみたところ、こんなログがあったので取り急ぎLunaさんに聞いてみる。発見したのは /var/log/Syslog 上。
2026-09-08T17:20:43.596684+09:00 dproto02 kernel: ------------[ cut here ]------------
2026-09-08T17:20:43.596684+09:00 dproto02 kernel: xe 0000:03:00.0: [drm] GT0: Forcewake domains 0x3 failed to acknowledge awake request
2026-09-08T17:20:43.596685+09:00 dproto02 kernel: WARNING: CPU: 1 PID: 21767 at drivers/gpu/drm/xe/xe_force_wake.c:205 xe_force_wake_get+0x2e5/0x310 [xe]
2026-09-08T17:20:43.596687+09:00 dproto02 kernel: Modules linked in: tls nvidia_uvm(POE) nf_conntrack_netlink xt_nat xt_tcpudp veth xt_conntrack..... platform_profile
2026-09-08T17:20:43.596688+09:00 dproto02 kernel: wmi_bmof .....i aesni_intel
2026-09-08T17:20:43.596689+09:00 dproto02 kernel: CPU: 1 UID: 0 PID: 21767 Comm: kworker/u32:1 Tainted: P W IOE 6.17.0-42-generic #42-Ubuntu PREEMPT(voluntary)
2026-09-08T17:20:43.596690+09:00 dproto02 kernel: Tainted: [P]=PROPRIETARY_MODULE, [W]=WARN, [I]=FIRMWARE_WORKAROUND, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
2026-09-08T17:20:43.596691+09:00 dproto02 kernel: Hardware name: ASUS System Product Name/ROG STRIX H370-F GAMING, BIOS 3101 09/07/2021
2026-09-08T17:20:43.596691+09:00 dproto02 kernel: Workqueue: gt-ordered-wq xe_guc_exec_queue_lr_cleanup [xe]
2026-09-08T17:20:43.597588+09:00 dproto02 kernel: RIP: 0010:xe_force_wake_get+0x2e5/0x310 [xe]
2026-09-08T17:20:43.597595+09:00 dproto02 kernel: Code: 4c 8b 3f 44 89 55 c8 89 4d d0 e8 66 a3 cf fb 8b 4d d0 41 89 d9 4d 89 e0 48 89 c6 4c 89 fa 48 c7 c7 70 db b4 c1 e8 ab d5 16 fb <0f> 0b 44 8b 55 c8 e9 3d ff ff ff 48 8b 75 c0 48 8b 7d b8 44 89 55
2026-09-08T17:20:43.597596+09:00 dproto02 kernel: RSP: 0018:ffffcf0fe14bbca0 EFLAGS: 00010246
2026-09-08T17:20:43.597597+09:00 dproto02 kernel: RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000
2026-09-08T17:20:43.597598+09:00 dproto02 kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
2026-09-08T17:20:43.597599+09:00 dproto02 kernel: RBP: ffffcf0fe14bbcf8 R08: 0000000000000000 R09: 0000000000000000
2026-09-08T17:20:43.597599+09:00 dproto02 kernel: R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffc1bc0ab2
2026-09-08T17:20:43.597600+09:00 dproto02 kernel: R13: ffff88b7a2570098 R14: 0000000000010000 R15: ffff88b782999240
2026-09-08T17:20:43.597601+09:00 dproto02 kernel: FS: 0000000000000000(0000) GS:ffff88c31f4e2000(0000) knlGS:0000000000000000
2026-09-08T17:20:43.597601+09:00 dproto02 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
2026-09-08T17:20:43.597602+09:00 dproto02 kernel: CR2: 00002c543699e000 CR3: 000000072b440003 CR4: 00000000003726f0
2026-09-08T17:20:43.597603+09:00 dproto02 kernel: Call Trace:
2026-09-08T17:20:43.597603+09:00 dproto02 kernel: <TASK>
2026-09-08T17:20:43.597604+09:00 dproto02 kernel: devcoredump_snapshot+0xe9/0x1c0 [xe]
2026-09-08T17:20:43.597604+09:00 dproto02 kernel: xe_devcoredump+0x128/0x190 [xe]
2026-09-08T17:20:43.597605+09:00 dproto02 kernel: xe_guc_exec_queue_lr_cleanup+0x1bf/0x310 [xe]
2026-09-08T17:20:43.597606+09:00 dproto02 kernel: ? __pfx_autoremove_wake_function+0x10/0x10
2026-09-08T17:20:43.597606+09:00 dproto02 kernel: process_one_work+0x191/0x3e0
2026-09-08T17:20:43.597607+09:00 dproto02 kernel: worker_thread+0x2e3/0x420
2026-09-08T17:20:43.597608+09:00 dproto02 kernel: ? _raw_spin_lock_irqsave+0xe/0x20
2026-09-08T17:20:43.597608+09:00 dproto02 kernel: ? __pfx_worker_thread+0x10/0x10
2026-09-08T17:20:43.597609+09:00 dproto02 kernel: kthread+0x10a/0x230
2026-09-08T17:20:43.597610+09:00 dproto02 kernel: ? __pfx_kthread+0x10/0x10
2026-09-08T17:20:43.597610+09:00 dproto02 kernel: ret_from_fork+0x121/0x140
2026-09-08T17:20:43.597611+09:00 dproto02 kernel: ? __pfx_kthread+0x10/0x10
2026-09-08T17:20:43.597611+09:00 dproto02 kernel: ret_from_fork_asm+0x1a/0x30
2026-09-08T17:20:43.597612+09:00 dproto02 kernel: </TASK>
2026-09-08T17:20:43.597613+09:00 dproto02 kernel: ---[ end trace 0000000000000000 ]---
2026-09-08T17:20:43.617591+09:00 dproto02 kernel: xe 0000:03:00.0: [drm] *ERROR* GT0: Force wake domain 0: wake. MMIO unreliable (forcewake register returns 0xFFFFFFFF)!
2026-09-08T17:20:43.617599+09:00 dproto02 kernel: ------------[ cut here ]------------そしたら、実はこれはdevtracedumpではなかったようで、コアダンプ作成時のsyslogとカーネルWARNのスタックトレースだったご様子。あ、そうだよね。最初の取得方法で/var/tmp上に見つからなかったもんね(´・ω・｀)
代わりに、このスタックとレースで取れなかった理由も考えるとそもそもデバイスコアダンプの取得自体が無理だったことをLunaが教えてくださりました。
最初に確認できる重大な症状は次です。
Text--------------------
GT0: Schedule disable failed to respond, guc_id=2
--------------------
これは、XeがGuCに対して実行キューの停止を要求したものの、GuCから応答が返らなかったことを示します。
その直後に、GTとRenderのForce Wakeが失敗しています。
Text--------------------
Force wake domain 0: wake. MMIO unreliable
Force wake domain 1: wake. MMIO unreliable
GT0: Forcewake domains 0x3 failed to acknowledge awake request
--------------------
Xeの定義では、次の対応です。
Text--------------------
domain 0: GT
domain 1: Render
--------------------
つまり、Renderだけではなく、GT側も含めてGPU内部のMMIO応答が成立していません。
Xeのソースコードでは、Force Wakeの応答レジスターが0xFFFFFFFFを返すと、MMIOを信頼できない状態として扱い、-EIOを返します。
この結果、リセット処理が継続できず、最終的に次の状態になります。
Text--------------------
CRITICAL: Xe has declared device 0000:03:00.0 as wedged.
device wedged, needs recovery
--------------------要はこういうことのようです。
完全にデバイスが何らかの原因で沈黙してしまったようです。
結果的にはハードウェア側の論理障害・・なのかな。
じゃぁそれってなんだろ？ということでLunaが調べてくれたのがですね・・以下の２つです。24810はCloseされていますが、24946はまだオープン状態です。
日本語に起きた事象を翻訳するとこんな感じです。
発生事象
Intel Arc Pro B70グラフィックスカード（Battlemage世代、ドライババージョンxe）上でSYCLバックエンドを使用してllama-serverを実行した場合、-cb（連続バッチ処理）フラグを設定すると、GPUが常にアクティブなgt-c0電力状態に固定され、クロック周波数がブーストモード（2800 MHz）に維持されます。この状態はリクエスト間でも継続し、カードはgt-c6ディープスリープ状態に移行しません。モデルをロードした状態で8日間連続稼働させ、不定期なリクエストを処理した結果、GTアイドル状態の累積時間は約691,200秒中197秒（全体の0.03%）でした。カードのアイドル時消費電力は約50Wを維持し、ファンは継続的に回転音を発し、VRAM温度は約72°Cで安定していました。
/slotsはリクエスト間でis_processing: falseを正しく報告していました。CPU使用率は0%でした。実際の推論処理は行われておらず、GPUの電力状態が単に固定されていた状態でした。-cbフラグを無効化する（その他の設定は変更なし）ことで問題は解決します：リクエスト完了から約2秒以内にGTはgt-c6状態に移行します。次のリクエストに対するウェイクアップ遅延は約600msです（推論ワークロードでは気にならない程度の遅延）。VRAM温度は72°Cから42°Cに低下し、ファンは停止、アイドル時消費電力は15W未満に減少します。
再現手順
source /opt/intel/oneapi/setvars.sh./build-sycl/bin/llama-server
-m Qwen3.6-35B-A3B-UD-Q4_K_M.gguf
-ngl 99 –host 0.0.0.0 –port 8080
-c 524288 –parallel 2 -cb
–mlock –no-warmup
-ctk q4_0 -ctv q4_0
チャットの完了リクエストを1回送信してください。30秒待機した後、以下の項目を確認してください：-cbフラグなしの場合の期待結果：gt-c6 / 0 MHz / ファン停止
-cbフラグありの場合の観測結果：gt-c0 / 2800 MHz / ファン稼働中cat /sys/class/drm/card0/device/tile0/gt0/gtidle/idle_status
cat /sys/class/drm/card0/device/tile0/gt0/freq0/act_freq
sensors xe-pci-0300 | grep -E ‘^(pkg|vram|fan)’
/sys/…/gtidle/下のidle_residency_msの値から確認できます：-cbフラグありではわずかしか進まず、-cbフラグなしでは秒単位で累積していきます。システム構成
GPU：Intel Arc Pro B70（Battlemage G31、[8086:e223]）
ドライバ：xe（カーネル6.11以降ではBattlemage用にi915ドライバを置き換え）
ディストリビューション：Fedora Server、カーネル6.x
llama.cpp：最新のmasterブランチ、build-syclビルド
バックエンド：Intel Level Zero経由のSYCL、oneAPI 2026.0
モデル：Qwen3.6-35B-A3BをQ4_K_M設定で使用、全レイヤーをGPU上で実行根本原因（現時点での推定）
-cbフラグはリクエスト間でSYCLコマンドキューをアクティブ状態に保持するため、新しいリクエストが実行中のバッチにシームレスに統合され、リソース割り当てオーバーヘッドがゼロになります – これがこのフラグの本来の目的です。古いi915ドライバでは、この動作は無害でした。電力状態の遷移が実際にカーネルが実行されているかどうかに依存していたためです。新しいxeドライバでは、GT-c状態の遷移はキューが空になっているかどうかに依存するため、アクティブ状態でアイドル状態のキューがあると、GTはgt-c0状態に無期限に固定されてしまいます。-cbフラグの動作は単体では正しいものです。xeドライバの動作も単体では正当化可能です。問題はこの相互作用部分にあり、llama.cppの視点だけではsysfsの調査なしに検出することはできません。
推奨する解決策（これらのいずれかを実施すれば改善が見込めます）
作業量の多い順に：SYCLバックエンドのREADMEにドキュメント記載を追加：xeドライバ（Battlemage以降）において-cbフラグを設定していると現在アイドル時の電力節約が無効になります。低スループットのシングルテナント環境ではこのGPUで-cbフラグを無効にすることを推奨します。
ランタイム警告：/sys/bus/pci/drivers/xeが存在する状態で-cbフラグが有効になっている場合、起動時に1行の警告メッセージをログに記録します。i915ドライバを使用しているユーザーにはこの警告は表示されません。
アイドルキューの強制空化：新規リクエストがN秒間ない場合、明示的にSYCLキューを空にして破棄し、次のリクエスト時に再確立します。私のテスト環境では、起動コストは約600msでしたが、このドライバ経路におけるアイドル時電力削減効果を考慮すれば許容範囲内です。
オプション1だけでも昨日の診断作業で約3時間の節約になりました。症状（nvtopで100%使用率を示しているのに/slotsではアイドル状態、高い温度にもかかわらずCPU使用率ゼロ）から、私は誤った方向に何度も迷い込みましたが、/sys/class/drmまで調査してGT-c状態の証拠を発見するまで解決できませんでした。回避策
-cbフラグを無効にしてください。–parallel 2以上の設定でも並行リクエスト処理は可能ですが、リクエスト間のデコードステップ融合は行われなくなります。スループットへの影響は、持続的に10件以上の並行リクエストがある場合にのみ顕著になります。xeドライバを使用するシングルテナント環境や低並行環境では、-cbフラグを無効にする方が明確に有利です。関連事項 — upstreamのxeドライバについて
根本的な修正はxeカーネルドライバ側に実装されるべきです。カーネルが積極的に実行されていない場合、キューの使用状況にかかわらず、GTを低電力状態に移行させる必要があります。これはi915ドライバの動作と整合します。別途、xeドライバのトラッカーに別件として報告する予定です。現時点では、ドキュメント/警告メッセージの修正の方が迅速に実施可能であり、ユーザーにも即時的なメリットがあるため、こちらの問題として報告しておきます。
この内容にあるように、llama.cppの中で動くContinuous Batch機能とIntel ARC PRO側のドライバ・あるいはComputing Runtimeの愛称があまりよろしくないようで、それが原因でGPU側の内部ファームがハングアップするようだということがわかりました。
なので、今は以下のように実行オプションを追加しています。Continuous Batchはデフォルト設定で有効となっているため、今回の場合は -nocb オプションを付与します。また、60秒以上アイドルが継続した場合は Sleep させるようにしています。
#!/usr/bin/bash
source /opt/intel/oneapi/setvars.sh
export ONEAPI_DEVICE_SELECTOR="level_zero:0"
/opt/llama-sycl/bin/llama-server --model /opt/llama-sycl/models/Muse-Glimmer-30B-UD-Q4_K_XL.gguf -t 20 \
-np 1 --prio 2 --temp 1.0 --top-p 0.95 --top-k 64 --host 0.0.0.0 --port 8051 --device SYCL0 -mg 0 -sm layer \
--fit off --no-warmup --no-cache-prompt -fa on --cache-ram 0 -c 131072 -b 2048 -ub 512 --reasoning on --log_verbosity 4 \
--model-draft /opt/llama/models/Muse-Glimmer-30B-DFlash2-Q4_K_M.gguf \
--spec-type draft-dflash --spec-draft-n-max 4 \
-nocb --sleep-idle-seconds 60 \
--mmproj /opt/llama/models/mmproj-MuseGlimmer-kquant.gguf実は電源ステータスについてちゃんと理解できていなくて。こうやって確認できるんですね。試しに実行してみます。一度推論させた後、ファンが静かになったタイミングで以下コマンドで確認したら無事ディープスリープにステータス移行していました。
cat /sys/class/drm/card0/device/tile0/gt0/gtidle/idle_status
cat /sys/class/drm/card0/device/tile0/gt0/freq0/act_freq
------------------------以下が結果
gt-c6
0逆にアクティブになったらgt-c0というステータスになります。これは、NVIDIAでいえばP0に相当します。
消費電力やファン回転数に関しては、xpu-smiで表示できるので・・・実行してみるとこんな風。アイドルモードであってもあまり消費電力を低減できてないように見えますね。こうした部分の制御に、Intelは苦慮しているのかもしれません。
$ xpu-smi
+----------------------------------------------+----------------------------+------------------------+
| Intel XPU-SMI v2.0 Driver: 64290D8E349F41730D761F4 Level Zero: 1.28.6 |
+----------------------------------------------+----------------------------+------------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
+----------------------------------------------+----------------------------+------------------------+
| 0 Intel(R) Arc(TM) Pro B Off | 0000:03:00.0 Off | Disabled |
| 70 Graphics | | |
| N/A 51C 51W / 275W | 143MiB / 32656MiB | 0% Default |
+----------------------------------------------+----------------------------+------------------------+
+-------+-----------+--------+------------------------------------+----------------------------------+
| Processes: |
| GPU PID Type Process Name GPU Memory Usage |
+-------+-----------+--------+------------------------------------+----------------------------------+
| 0 1096747 C /opt/llama-sycl/bin/llama-server 116 MiB |
+-------+-----------+--------+------------------------------------+----------------------------------+ちなみにフルパワー出してる時はこんな感じ。意外とGPU Utilsが出てないのが悲しい感じ。
# xpu-smi
+----------------------------------------------+----------------------------+------------------------+
| Intel XPU-SMI v2.0 Driver: 64290D8E349F41730D761F4 Level Zero: 1.28.6 |
+----------------------------------------------+----------------------------+------------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
+----------------------------------------------+----------------------------+------------------------+
| 0 Intel(R) Arc(TM) Pro B Off | 0000:03:00.0 Off | Disabled |
| 70 Graphics | | |
| 0% 73C 303W / 275W | 21077MiB / 32656MiB | 22% Default |
+----------------------------------------------+----------------------------+------------------------+
+-------+---------+--------+------------------------------------+------------------------------------+
| Processes: |
| GPU PID Type Process Name GPU Memory Usage |
+-------+---------+--------+------------------------------------+------------------------------------+
| 0 28017 C /opt/llama-sycl/bin/llama-server 21050 MiB |
+-------+---------+--------+------------------------------------+------------------------------------+ほかにも気を付けるべきこと
どうもIntel ARC自体が少し癖があり、BIOS上で認識させる際に結構長い時間待たされることがわかりました。
また、そのせいで下手にFast bootなどを有効にしていると、SSDが認識しないうちにOS読み出しを試みてしまうのか、OSカーネルをうまく読みだせずにエラー終了してGRUBの画面に引き戻されます。
一応Fast bootを無効化する、Reboot はせずに poweroff で落として電源を再投入するということで事なきを得ていますが、もう BIOS 更新が望めないものに関しては、古いマザーボードは使わないほうが良いのかもしれません。今回、古いマザーボードを使用した機種を選んだことで様々な地雷を踏む羽目になりました。世代にはその世代相応のハードをそろえないとなと認識を改めて持ちました・・・が、何もかも高い今の時代、フリーでやるにも限界があるなぁとも感じ始めてはいます。とはいえ、今更この年齢で、一日働ける時間を考慮すると難しいのが現状なので、なんだかんだ言いながらもなし崩し的に今の仕事を続けることになりそうです。
コメント