اللابتوب بتاعي بقى بطيء: الـ CPU كان مثبت على 800 ميجاهرتز

اللابتوب بتاعي بقى استخدامه متعب. Chrome بقى بطيء، والتنقل بين التابات بيتقطع، حتى فتح الـ terminal بقى تقيل. فعملت اللي كان لازم أعمله من أول يوم: بطلت تخمين وقست. والإجابة مالهاش أي علاقة بالـ RAM ولا الـ disk ولا Chrome.

الأعراض

المشتبه فيهم المعتادين كان سهل فحصهم، وكلهم كانوا أبرياء:

• RAM:‏ 30 جيجا مركبة، و26 جيجا فاضية، وصفر بايت في الـ swap.
• disk:‏ SSD ونسبة الانتظار بتاع الإدخال/الإخراج حوالي 0%.
• load:‏ كام أداة تطوير شغالة، بس الجهاز خامل أكتر من 80% من الوقت.

مكانش فيه عطل واضح. الرقم الوحيد اللي مافحصتوش هو اللي يفسر كل حاجة: الـ CPU شغال بسرعة قد إيه فعلًا.

الخطوة 1: اقرا السرعة الحالية

أمرين كفاية على أي جهاز لينكس:

grep MHz /proc/cpuinfo
lscpu | grep -E 'Model name|MHz'

الإجابة عندي كانت 800 MHz على الـ 12 thread كلهم. الـ CPU هو Intel Core i7-9750H: أساسي 2.6 جيجاهرتز وبيوصل لـ 4.5 جيجاهرتز. يعني كان شغال على حوالي تلت سرعته الأساسية.

الـ CPU وهو خامل على 800 ميجاهرتز ده طبيعي خالص، ده توفير طاقة. الخلل بيبان بس لما تحمله.

الخطوة 2: اعرف السقف المسموح للـ CPU

قبل ما تلوم الـ hardware، استبعد الـ OS. لينكس بيوضح حدود الـ hardware والحدود اللي هو مفعلها حاليًا:

# أقصى سرعة بيدعمها الـ CPU (بالكيلوهرتز)
cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
# أقصى سرعة الـ OS بيسمح بيها دلوقتي
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
# حدود Intel P-state كنسبة من الأقصى
cat /sys/devices/system/cpu/intel_pstate/{min_perf_pct,max_perf_pct,no_turbo}

كلهم ردوا بـاتفضل: سقف 4,500,000 كيلوهرتز، وmax_perf_pct=100، والـ Turbo مش متعطل. على الورق الـ CPU كان حر يشتغل بأقصى سرعة.

الخطوة 3: أثبتها تحت الحمل

حمل كل الـ cores كام ثانية وبعدين اقرا السرعة تاني. ده الاختبار اللي بيفرق بين وهم توفير الطاقة والعطل الحقيقي:

for i in $(seq 1 $(nproc)); do yes > /dev/null & done
sleep 5
grep MHz /proc/cpuinfo
pkill yes

عندي فضلت ثابتة على 800 ميجاهرتز مع استخدام 100% للـ CPU وload average = 11، وفي نفس الوقت حرارة الـ package كانت 52 °C بس.

الخلطة دي هي التشخيص كله: أقصى حمل، وأقل سرعة، وحرارة منخفضة. الـ CPU السخان فعلًا بيتخنق عشان قريب من 100 °C. إنما ده كان بارد وبرضه رافض يشتغل. حاجة بره الـ scheduler كانت ماسكاه.

الخطوة 4: اسأل الـ CPU عن السبب

الـ CPUs بتاعة Intel بتنشر سبب الـ throttling في register خاص بالموديل (MSR). ثبت msr-tools واقراها:

sudo apt install msr-tools        # rdmsr / wrmsr
sudo modprobe msr

sudo rdmsr -p 0 0x64F   # PERF_LIMIT_REASONS: أنا متقيد ليه؟
sudo rdmsr -p 0 0x1FC   # POWER_CTL:          بسمع إشارة PROCHOT؟
sudo rdmsr -p 0 0x198   # PERF_STATUS:        شغال على أي ratio؟
sudo rdmsr -p 0 0x199   # PERF_CTL:           مطلوب مني أي ratio؟

الإجابة كانت:

مطلوب 4.5 جيجاهرتز، واللي اتسلم 0.8 جيجاهرتز. والـ CPU نفسه قال السبب: PROCHOT.

إيه هو PROCHOT أصلًا؟

PROCHOT# (Processor Hot) ده pin كهربائي حقيقي على الـ CPU package. لما يتسحب للأرضي، الـ CPU بينزل لأقل حالة طاقة (P-state) على طول، من غير تفاوض ومن غير أي تدخل من الـ OS. وIntel كمان مطبقة حاجة اسمها Bi-Directional PROCHOT (BD PROCHOT): يعني الـ CPU بيسمع الـ pin ده مش بس لحرارته، كمان لإشارات من مكونات تانية، زي الـ voltage regulators، والـ embedded controller، والبطارية.

في الأصل دي ميزة أمان كويسة: لو الـ power delivery مش قادر يتحمل الـ CPU، لازم حاجة تبطأه. بس بتبقى خلل لما الإشارة تفضل مسحوبة ومافيش حاجة سخنة.

الخطوة 5: استبعد الأسباب الرخيصة

قبل ما تلجأ لحل ترقيعي، اعرف ليه الإشارة مسحوبة. بترتيب الاحتمالات تقريبًا:

1. الشاحن أو البطاريةفي لابتوبات كتير، بطارية ضعيفة أو شاحن أقل من المطلوب بيخلوا الـ embedded controller يسحب إشارة PROCHOT عشان يحمي الـ voltage regulators. الاختبار: كرر تحميل الـ CPU بعد ما تفصل الشاحن.
2. الحرارة الحقيقيةشغل sensors. حرارة الـ package المفروض تبقى أقل بكتير من حرارة الخطر. لو بتقرا من 95 لـ 100 °C يبقى الـ CPU سخان بجد، نظف المراوح وغير الـ thermal paste بدل كده.
3. وضع الطاقة أو الـ governorبص على powerprofilesctl أو cpupower frequency-info. ممكن يكون governor من نوع powersave ومعاه max_perf_pct واطي، فتبان زي نفس الحالة، بس ده هيستجيب للحمل.
4. embedded controller معلقpower drain كامل بيرجعه: اقفل الجهاز خالص، افصل الشاحن، دوس على زرار الباور من 30 لـ 60 ثانية، وبعدين وصل الشاحن وشغله.
5. الـ firmwareBIOS/EC قديم جدًا سبب شائع جدًا لإشارات PROCHOT الكدابة في لابتوبات الجيمنج. بص على صفحة دعم الشركة على إصدار أحدث من اللي عندك.

في حالتي الإشارة فضلت مسحوبة على الكهرباء وعلى البطارية، والبطارية كانت بتقول صحة 97% و83 دورة شحن، والـ BIOS كان عنده سبع سنين. ده بيرجح الـ embedded controller والـ firmware مش خلية بطارية تالفة.

الخطوة 6: الحل اللي رجعلي السرعة

بعد ما استبعدت الأعطال الحقيقية، لو الإشارة لسه شغالة، تقدر تقول للـ CPU ما يسمعش BD PROCHOT بأنك تصفر الـ bit 0 من MSR 0x1FC. كل core عندها نسختها، فاكتب في كلهم:

sudo rdmsr -a 0x1FC              # اقرا، غالبًا بينتهي بـ 5d أو 5b
sudo wrmsr -a 0x1FC 0x2c005c    # صفر الـ bit 0، يعني ...5d تبقى ...5c

التغيير بيتطبق على طول بس مش بيفضل بعد restart، فخليه دايم بوحدة systemd صغيرة:

sudo tee /usr/local/bin/fix-bd-prochot.sh >/dev/null <<'EOF'
#!/bin/bash
modprobe msr 2>/dev/null || true
for i in $(seq 0 $(( $(nproc) - 1 ))); do
  cur=$(rdmsr -p "$i" 0x1FC 2>/dev/null) || continue
  if (( 0x$cur & 1 )); then
    wrmsr -p "$i" 0x1FC "$(printf '0x%x' $(( 0x$cur & ~1 )))"
  fi
done
EOF
sudo chmod 755 /usr/local/bin/fix-bd-prochot.sh

[Unit]
Description=Disable BD PROCHOT (workaround: CPU pinned at 800MHz)
After=multi-user.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/fix-bd-prochot.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now bd-prochot-fix.service

النتيجة

على طول بعد تصفير الـ bit، نفس اختبار الحمل الكامل أدى 3.1 جيجاهرتز على الـ 12 thread كلهم عند 94 °C، والشغل المكتبي العادي بقى يسرع لحدود 4 جيجاهرتز. Chrome بطل بيتقطع. وفي الخمول لسه بينزل لـ 800 ميجاهرتز، فتوفير الطاقة سليم. اللي اختفى هو السقف المصطنع بس.

لو أنت على ويندوز

• ThrottleStop: شيل علامة BD PROCHOT من النافذة الرئيسية. ده نفس الـ bit بس بواجهة رسومية.
• HWiNFO64: راقب Core Clocks وCPU Package Power ومؤشر PROCHOT.
• powercfg /qh بيوريك حدود أداء الـ CPU اللي ويندوز مفعلها.
• أجهزة AMD بتستخدم registers مختلفة. بص على Ryzen Master أو ryzen_monitor لمؤشرات PROCHOT/HTC.

قائمة مختصرة

1. اقرا السرعة الحالية: grep MHz /proc/cpuinfo.
2. حمل كل الـ cores خمس ثواني واقراها تاني. النزول في الخمول طبيعي، إنما في الحمل مش طبيعي.
3. افحص السقف المسموح: cpuinfo_max_freq وscaling_max_freq وmax_perf_pct.
4. لو الـ OS بيسمح بالسرعة الكاملة والسرعة مش بتتحرك، اقرا rdmsr 0x64F. الـ CPU هيقولك السبب.
5. لو السبب PROCHOT مع حرارة منخفضة: اختبر الشاحن والبطارية، وبعدين اعمل power drain على الـ embedded controller، وبعدين حدث الـ BIOS.
6. وبعد كده بس فكر تصفر BD PROCHOT (الـ bit 0 من 0x1FC) كحل ترقيعي.