Ang post na ito ay upang ipakita kung paano "ayusin" ang halos problema ng mga startup na may mga error Arch Linux. Tulad ng sumusunod na imahe:
Tulad ng nakikita, nakikita natin na ito ay isa sa maraming mga "kumbinasyon" ng mga error na lilitaw nang sapalaran kapag nagsisimula ng isang operating system na may ganitong problema. Tulad ng sinasabi nito sa error na iyon, ipinapahiwatig nito na maaaring may isang problema sa "Hardware", gayunpaman, tulad ng alam nating lahat sa operating system na ito, kahit na ang mga masasamang trick ng hindi kabilang sa OS ay maaaring malutas.
Kaya, ilalarawan ko ang aking karanasan sa problemang ito. Sa naranasan ko, ang problema ay sa akin lamang Arch Linux o ibang distro na sinubukan ko sa panlabas, dahil sa anumang mga ubuntu na na-install o nasubukan ko, nagsimula ito nang walang mga problema. Ngunit kung sinubukan kong ripahin ang Arch Linux naka-install sa hard drive, mayroon itong problema na kailangan itong mag-reboot ng halos 50 beses upang ang OS ay mag-boot nang normal at magagamit ito.
Mayroon na itong mali sa akin dahil magagamit ko lang ang ubuntu na na-install ko upang subukan ito at hindi ko magawa kahit ang kalahati ng mga bagay na magagawa ko sa Arch Linux. Kaya't napagpasyahan kong malutas ang problemang ito at nagsimulang mag-imbestiga, na naghahanap ng mga thread ng forum na may parehong problema, nabanggit din nila na ito ay isang error sa hardware at ito talaga ang CPU, kaya nagsimula akong magalala sa akin, kaya't napunta ako sa buksan ang PC at i-verify kung ano ang nangyayari, gayunpaman, hindi ito nakatulong.
Ngunit isang bagay na nagpakita sa akin, na hindi ko dapat isuko ay iyon kung Ubuntu Kaya ko kasi Arch Linux hindi (marahil Ubuntu ay mas mahusay kaysa sa Arko…?). Kaya't nagsimula akong magsulat ng mga parameter ng boot sa kernel ng Arch Linux, mga bagay tulad ng: lapic, nomce, intel_idle.max_cstate = 0, huwag paganahin ang _cpu_apic, acpi_skip_timer_override, acpi = stric, clk, apm, noapic, acpi = oldboot, acpi-cpufreq, intel_pstate = huwag paganahin, i8042.noacpi = 1, apdt = apm = copyds, acdtpi = 0, apm = copyds pci = nocrs, rhgb, acpi = force, pnpacpi = XNUMXff at iba pa ... Ang lahat ng ito ay inirekomenda sa mga forum na nabasa ko.
Hanggang sa kailangan kong pumunta sa dokumentasyon para sa mga parameter ng kernel, na inirerekumenda ko sa pamamagitan ng paraan: https://www.kernel.org/doc/Documentation/kernel-parameters.txt
At natagpuan ko ang isang kagiliw-giliw na parameter na sa sandaling ito ay nagawa kong mag-boot Arch Linux Walang problema:
linux /boot/vmlinuz-linux root=UUID=fbefe36c-1712-4f3b-b3e3-3eac759d71c9 notsc nomce maxcpus = 0
Tulad ng ipinahiwatig doon, kung ano ang ginagawa ng parameter na ito ay limitahan ang paggamit sa isang cpu nang hindi inaaktibo ang simetriko mode ng pagproseso. Sa una ay gumana ito nang maayos hanggang sa noong ginamit ko ang utos pacman-Syyu; tinapon ako a core itinapon o pagkakasala sa pagkakahiwalay.
Kaya't awtomatiko kong napansin na may kakaibang nangyayari, kaya't nagsimula akong magpatakbo ng iba pang mga proseso hanggang sa biglang ganap na nagyelo ang system at hindi na gumana, hanggang sa muli ko itong boot. Kaya't ginawa ko ang parehong operasyon, ngunit sa pagkakataong ito ay nakapagpatupad ako htop at ipinakita nito sa akin ang sumusunod:
Tulad ng inaasahan, ipinakita lamang nito ang isang CPU, dahil hindi ito pinagana ng iba, subalit, tila napaka-kakaiba sa akin kung bakit itinapon ang mga programa segfault, at hindi man masimulan ang grapikong kapaligiran; kaya ito ay isang bagay na hindi bababa sa nagbigay sa akin ng higit na pag-asa na kung itatakda ko ang mga parameter ng kernel sa isang paraan ito ay mag-boot sa aking Arch Linux gaya ng dati.
Kaya't patuloy kong sinusubukan ang iba pang mga parameter na isinulat ko sa listahan hanggang sa natagpuan ko ang isang ito, na kung saan ay ang pinakamahusay na solusyon sa kasalukuyan:
linux /boot/vmlinuz-linux root=UUID=fbefe36c-1712-4f3b-b3e3-3eac759d71c9 notsc nomce isolcpus = 1
Ang parameter na ito ay gumagawa ng isang bagay na kasing simple ng paghihiwalay (hindi pagdi-deactivate) ang pangalawang core ng CPU sa simetriko na pagpoproseso, iyon ay, ang pagproseso ng karga ay ibinibigay sa isang solong core habang ang iba pa ay pantulong lamang. Ito, bagaman tila magkasalungat, ay hindi nakakaapekto sa pagganap nang labis, dahil ang mahusay na OS na ito ay nakapagpatakbo ng mga application sa ganitong paraan:
Kaya sa ito, ang nag-iisang problema na naobserbahan ko na nangyayari sa oras ng pag-boot, ay isa o dalawang pannel ng kernel o oops; ngunit kung ihahambing sa 50 beses na kinailangan kong mag-reboot dati, maaari kong isaalang-alang ito bilang isang "workaround". Para sa natitira, sa ngayon ay pinapayagan akong gamitin ang OS at isulat ang post na iyong binabasa ngayon :-).
Sana tulungan ka nila, at huwag makawala GNU / Linux, na kung saan ay ang pinakamahusay na operating system na kanilang naimbento. Sigurado kong sinasabi ito.
Napakainteresadong impormasyon. Hindi pa ako nakakaranas ng mga kernel panic na iyon sa ArchLinux sa mga nakaraang taon na ginamit ko ito, ngunit magandang malaman kung ano ang gagawin kung sa anumang puntong nangyayari ang problema. Salamat!
Gayunpaman, matagal ko nang ginagamit ang Arch (para akong 1 taon nang walang Arch) at walang kernel panic.
Salamat sa tip.
Malamang, tulad ng nabanggit ko sa post, ang problema ay nangyayari dahil sa hardware, dahil sa kung ano ang ginagamit kong arko, hindi rin ito binigyan ng anumang problema ng ganitong uri.
Isa pa na may mahusay na mga resulta sa Arch. Hindi pa ako nagkaroon ng Kernel Panic
Mahigit sa 2 taon sa GNU / Linux ... 2 taon na sa ArchLinux, hindi kailanman isang gulat ng kernel .. 😉
Sa palagay ko ang mga kernel panic ay sanhi ng higit pa sa hardware kaysa sa distro mismo. Hindi pa ako nakakakita ng isang panic kernel sa laptop na ginagamit ko ngayon maliban sa sandaling inilagay ko ito sa isang Ubuntu alpha (at ang Arch Linux ay narito rin sa loob ng dalawang taon). Sa kabilang banda, sa isa pang laptop na mayroon ako, ang anumang distro na inilalagay ko ay palaging nagbibigay ng kernel panic at isang iba't ibang mga error para sa lahat ng panlasa.
Sa kernel 3.14 sa Debian, nasagasaan ko ang kernel panic problem, bukod sa tuwing binubuksan ko ang aking PC, nakakakuha ako ng isang mensahe na "kumonekta / idiskonekta ang pag-timeout" (at pati na rin kapag pinapatay ko ito).
Napaka nangyari sa akin sa Fedora tulad ng sa Arch, ngunit hindi ko alam kung bakit, at kung paano hindi ako nakakakita ng pagkakaiba sapagkat hindi ako gumugol ng oras sa pagsisiyasat o paglutas nito (kung ito ay isang problema).
Sa palagay ko ang dahilan ay naipon sila ng gcc 4.9
http://libuntu.com/linus-torvalds-considera-que-la-version-4-9-de-gcc-es-una-pura-y-absoluta-mierda/
Maraming salamat sa impormasyon. Ang ilan sa maraming mga bagay na maaari nating ipagyabang ay ang ganitong uri ng forum
Bakit nangyari ito sa Arch Linux? Marahil ay hindi ito sapat sa mga problema na madalas na lumilitaw sa kabagalan o pag-hang ng system na umabot sa punto ng pagkahagis ng system sa fret.
Huy? Ano pinagsasabi mo o_O
Ang Arch ay isang pamamahagi ng KISS na mai-configure mula sa base ng operating system mismo, sa ilang mga salita, kung mabigat ang system ito ay dahil itinayo mo ito sa ganoong paraan, kung ang mga system ay may mga pagkakamali ito ay dahil nabuo mo ang mga ito o dahil hindi mo i-configure nang tama ang isang bagay. Ang Arch wiki ay kumpleto na, ilang taon na ang nakalilipas ay walang maraming mahahalagang paksa sa Espanyol, iyon at ang proseso ng pag-install ay mas masahol at medyo mahirap, ngayon ang lahat ay medyo na-automate.
Ang pagsisi sa distro para sa mga error ng gumagamit ay ganon ... Windows (?).
Ang pagsisi sa distro para sa mga error ay pare-pareho, dahil lamang sa ito ang totoo. Matapos magkaroon ng katulad na problema sa Manjaro, sinubukan ko si Arch, Antergos at isa pang hindi kilalang pamamahagi (hindi ko matandaan ang pangalan ngayon, paumanhin) na inirekomenda sa akin ng isang tao na hindi ito nagbigay ng mga problema, ngunit wala; lahat sila nagbibigay. Sa OpenSuse, Fedora, Mint, Mageia at lahat ng mga sinubukan ko pagkatapos, hindi ito nangyayari. Kaya, hanggang sa alalahanin ko, naiwan akong walang pagpipilian ngunit isiping ito ang kasalanan ng distro. Ngunit, hey, hindi ko ito nilalabasan o anupaman, higit pa, nakakainis ito sa akin na hindi magamit ang anumang batay sa Arch, dahil gusto ko ito ng marami, ngunit pinipigilan ako ng problemang iyon. Hindi rin sa tingin ko ito ay tungkol sa hardware, dahil marami sa atin na nangyari sa atin ay hindi nangyari bago gamitin ang parehong pakikipagtalik. Sa totoo lang, ito ay dapat na isang bagay na nauugnay sa hardware, ngunit, babalik sa parehong bagay, kung wala akong mga pagbabago at mayroon akong mga problema sa parehong kagamitan na wala ako sa kanila dati, malinaw na ito ay dahil sa isang pagbabagong ginawa ni Arch na kinaloko ako.
"Ang pagsisi sa distro para sa mga error ng gumagamit ay kaya ... Windows (?)."
Sasabihin ko sa iyo na ang pagsisi sa mga gumagamit ng mga error sa produkto ay talagang Apple. Totoong naisip ko ito tungkol sa isang libong beses ngunit hindi ko nakikita ang kalamangan ng paggamit ng isang bagay na ang mga tagapangalaga ay karaniwang naghuhugas ng kanilang mga kamay, para sa anumang seryosong layunin. At sinasabi ko na isinasaalang-alang na ang GPL software ay dumating nang walang warranty.
Maaari mong sabihin ayon sa gusto mo ngunit kung ito ay ang parehong kaso ng mga ulat ng kakulangan ng signal sa iPhone at ang tugon ng Apple "ay nagkakamali ka" mula maraming taon na ang nakakalipas. Kung gumawa ka ng isang distro karaniwang gusto mong magbigay ng ilang kalidad, at kaunting suporta, at ang totoo ay ang Arch ay karaniwang isang hobbyist system, kung saan nakikita mo na ang mga tagabuo nito ay may kasiyahan na magbalot ng mga bagong bagay, ngunit may kaunting interes na mag-alok ng isang totoong suporta . Sa tuwing nakikita ko ang ganitong uri ng post mas pinahahalagahan ko ang gawain sa likod ng distro na ginagamit ko.
At oo, ito ay isang problema sa software kung hindi ito gumagana, kung tumitigil ito sa isang pag-update, o kung may isang bagay sa hardware na nasira. Ang isang distro na iyon ng kernel panic habang ang isa pa ay hindi… mabuti oo, malinaw na mayroong isang distro na gumagawa ng mga bagay nang tama at isa pang mali. Ngayon kung kasiyahan mo na gamitin ang Linux sa istilo ng dekada 90 kung saan kinailangan naming muling pagsamahin ang kernel tuwing nag-plug kami sa isang bagong printer ... doon ka.
Ang kernel ba ay naipon ng mga developer? o sarili mo?
Ang mga panernong kernel ay nabuo sa pamamagitan ng hindi napiling (AT) ilang mga bahagi kapag nag-iipon, o sa hindi pag-aktibo ng ilang mga module upang suportahan ang ilang mga hardware. Sa pagsasanay at kaalaman ng iyong hardware (kailangan mong buksan ang pc at makita kung anong mga tatak ng chips ang mayroon ito), maaari kang bumuo ng isang pasadyang kernel (sa pamamagitan ng chrooting). Kung ang ubuntu at ang CD ng pag-install ng Arch ay nasa iyong computer, mayroong isang bagay sa compilation na hindi naaktibo.
Ito ang stock kernel mula sa archlinux mismo, mula sa mga repository.
Ang kernel na ginagamit mo, may natitirang bagay na hindi gusto ng iyong hardware, dapat mayroon kang isang bihirang bersyon ng isang chip sa iyong motherboard o kahit isang bug sa isang maliit na tilad (karaniwang nangyayari ito).
Maaaring ito ay isang sira na talahanayan sa iyong bios acpi, normal na ang Intsik na naka-duty ay hindi rin kinakalkula nang maayos ang tsekum ng bawat mesa, ang mga mensaheng ito ay karaniwang lilitaw na may $ dmesg -human sa simula ng boot.
Dapat mo ring subukan ang isa pang supply ng kuryente, kapag nabigo ang pag-filter, ang ripple ay may gawi na ganoong uri ng kabiguan.
Una, subukang baguhin ang font at tingnan kung ano ang mangyayari, kung mananatili itong pareho, subukang i-configure ang isang kernel na pinasadya sa iyong hardware, sa pamamagitan ng paraan na mas makikilala mo ang iyong pc sa proseso.
Salamat sa mga tip. Sa pamamagitan ng paraan ito ay isang laptop, sa palagay ko dapat kong palitan ang baterya. Ngunit nakikita ko ang sinabi mo sa akin na makakatulong sa akin.
Ang isang takot sa kernel na nagpapabaliw sa akin ay bahagyang kasalanan ng nouveau guys at ng aking luma, luma na at napaka-alikabok na nVidia 6150 SE integrated card (Ibig kong sabihin dahil sa; nagawa nila ang isang mahusay na trabaho na sumusuporta sa isang uniberso ng mga graphics chips tulad ng mga mayroon ang nVidia, at lahat ng ito, gamit lamang ang reverse engineering, kasama ang problema ay nangyayari lamang para sa ilang mga kard na may NV4E chipset).
Simulan lamang ang Openbox + Firefox at mga welga ng sakuna (walang mas maganda kaysa sa nakikita ang isang ganap na random na itim at puting mosaic sa iyong screen). At kinakanta ko ito mula pa noong kernel 3.6 sa Debian, Fedora, Archlinux, Slackware at ngayon ay muling napatunayan muli sa Gentoo (na-install lang sa kernel 3.12), hindi na ako nag-abala na kumuha ng isang log, sa kernel o bigyan ito ng oras sa sumulat ng isang bagay na hindi isang napakalaki na walang katuturang mga character.
Ibinibigay ko sa iyo ang solusyon, isang pc na mayroon ako sa gentoo at integrated nvidia video ay pareho sa nouveau driver, kaya wala akong pagpipilian kundi gamitin ang saradong driver ng nvidia, dapat gamitin ng aking maliit na tilad ang 304.123 driver
00: 0d.0 VGA compatible Controller [0300]: NVIDIA Corporation C61 [GeForce 7025 / nForce 630a] [10de: 03d6] (rev a2) (prog-if 00 [VGA controller])
Kailangan mong i-patch ang isang file ng kernel bago i-compile ito, kung hindi na-patch ang graphics mode ay tatanggi na magsimula.
Ang mga hakbang ay:
# nano -w /usr/src/linux-3.15.7-gentoo/drivers/acpi/osl.c
Maghanap sa ctrl + w sa loob ng nano para sa tekstong ito, dadalhin ka ng acpi_os_wait_events_complete at nano sa bahaging ito:
walang bisa acpi_os_wait_events_complete (walang bisa)
{
flush_workqueue (kacpid_wq);
flush_workqueue (kacpi_notify_wq);
}
EXPORT_SYMBOL (acpi_os_wait_events_complete);
Ang patch na dapat mong idagdag ay ang huling linya na ito na nagsisimula sa EXPORT, ctrl + o ctrl + x
Pagkatapos ay isulat mo ang kernel, i-install ang mga module, i-install ang kernel, bumuo ng mga initramf kung kailangan mo ito, idagdag ang splash sa initramfs kung gumagamit ka ng splash, muling buhayin ang mga entry para sa grub at sa wakas at napakahalaga, dapat mong muling itayo ang mga module na ay hindi mula sa kernel, iyon ay, ang pagmamay-ari na module ng nvidia, nang hindi ginagawa ito ang graphic mode ay hindi gagana.
# listahan ng kernel na eselect
#eselect kernel set x
# cd / usr / src / linux
# gawing
# gumawa ng modules_install
# mount / boot
# gumawa ng pag-install
# dracut –hostonly »3.15.7-gentoo –force
# splash_geninitramfs –verbose –res 1400 × 1050 –append /boot/initramfs-3.15.7-gentoo.img emerge-world
# grub-mkconfig -o /boot/grub/grub.cfg
# umusbong @ module-muling itayo
# umount / boot
# shutdown -r ngayon
Kung gumagamit ka ng genkernel i-patch mo lang ang file na iyon at naiintindihan ko na ang genkernel ay nag-aayos mismo.
Bilang karagdagan, dapat mong alisin ang suporta ng drm at mga driver ng nvidia at iba pang mga video chip mula sa kernel upang hindi sila mabangga nang nakasara ang driver ng nvidia na naka-install bilang isang nvidia module.
Sa kaso ng paggamit ng bootsplash, dapat mong isama ang uvesa driver sa kernel upang suportahan nito ang mga resolusyon ng mataas na screen dahil ang saradong driver ng nvidia (kung naaalala kong tama) ay hindi sumusuporta sa higit sa 800 × 600 sa terminal tty1 «F1» ng ang bota.
Hindi ko alam ang tungkol sa iba pang mga distrito, ngunit sa palagay ko dapat itong gumana sa anumang distro kung ang mga hakbang na ito ay tapos na, na-save ang lumitaw na pagbabago para sa kung ano man.
Ito ang mga alituntunin na dapat mong sundin, para sa nvidia at uvesa:
http://wiki.gentoo.org/wiki/NVidia/nvidia-drivers/es
http://wiki.gentoo.org/wiki/Uvesafb
Salamat sa impormasyon, ngunit nalutas ko nang tumpak ang problema sa pamamagitan ng pagbabago sa mga pagmamay-ari. Naaalala ko na ang nakaraang nVidia driver (304.121) ay kinailangan ding i-patch kapag pupunta sa 3.13 dahil mayroon itong problema sa pagtitipon ng module (walang mga error, ngunit tumanggi na gumana ang module) at lahat dahil din sa ACPI handler ng kaganapan. Sa Debian nakuha ko ang problema at nahanap ko rin ang solusyon.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740097
Ginamit ko ang Manjaro bilang isang halimbawa, ngunit nabanggit ko na dati na ang parehong bagay ang nangyari sa akin kay Arch at iba pang mga derivatives. Samakatuwid naniniwala ako na ang problema ay higit sa kanila kaysa sa mga apektado.
Pd: Hindi ako nakasagot nang direkta sa may-katuturang mensahe dahil ang pagpipiliang tumugon ay hindi lilitaw ...
Tiyak na nagpunta ako mula sa Manjaro patungo sa Linux Mint dahil mai-freeze ito kapag nag-boot pagkatapos mag-update sa isang bersyon pagkatapos ng 0.8.9 (Hindi ko matandaan kung alin). Sa nabasa ko, karaniwang nangyayari ito sa mga laptop. Ang pinag-uusapan kong problema ay hindi pareho sa nasa post na ito, sa palagay ko napagpasyahan kong maaari itong maiugnay sa pamamahala ng enerhiya. May mga tao na hindi nag-freeze kung sinimulan nila ang laptop habang hindi naka-plug. Sa ngayon ay hindi ko naalala kung pinapayagan akong palaging magsimula nang walang mga problema, ngunit syempre nagawa kong gawin ito nang maraming beses sa halagang mas matagal upang gawin ito.
Gayunpaman, sa huli sumuko ako at lumipat sa Fedora at Linux Mint.
Nagkataon, sinubukan kong suspindihin ito nang wala ang charger at nang ipagpatuloy ito ay nag-hang at kailangan kong mag-restart.
Ito ay medyo nakakatawa, nakasama ko si Arch ng ilang buwan at wala akong solong Kernel Panic! Ito ay nangyari sa akin kasama ang Antergos (Arch na may isang idinagdag na imbakan) mula sa live na kapaligiran, ngunit doon ko isinasaalang-alang na mas nauunawaan ito. Maaari bang maging isang problema sa motherboard ng ina o isang may sira na module ng RAM? Naaalala ko mga 2 taon na ang nakalilipas ang isang module ng RAM ang nagdulot sa akin ng maraming mga asul na screen sa Windows at maraming mga Kernel Panics din! kay Mandriva. Kailangan kong subukan ang bawat memorya nang paisa-isa sa pagitan ng pag-reboot at pag-reboot.
Ito ay isang problema sa Arko (na kung saan ay nag-drag ng lahat ng mga derivatives nito), dahil sa iba pang mga distrito ay walang mga problema ng ganitong uri. Ang nakikita kong nakakahiya ay sa puntong ito hindi nila ito malulutas. Ilang taon na lang sila! Nabasa ko ang mga katulad na problema mula noong 2011. Malinaw ko na ito ay isang bagay na darating at pupunta sa pag-update nila, dahil ang paggamit ng mga bersyon 0.8.7, 0.8.8 at 0.8.9 nang hindi ina-update ang mga ito, walang nangyari. Mula noon ang lahat ay napupunta sa tae, at tiyak na sa mga lumang bersyon nangyari rin ito. Bakit sa ilan lamang sa atin ito nangyayari? Hindi ko alam, ngunit sa palagay ko hindi ito ang aming problema, ngunit ang Arch, sapagkat, tulad ng nasabi na, ang iba pang mga pamamahagi ay perpekto. Nasira ko na ang aking mga sungay sa kanyang araw upang makahanap ng solusyon, ngunit napagod ako. Kaya, hangga't humihingi ako ng paumanhin, hindi ako gagamit ng Arch.
Arko 0.8.7, 0.8.8 at 0.8.9? Nalaman kong ginagamit ng Arch ang nomenclature ng bersyon na iyon.
Hindi ba't gumagamit ka ng Manjaro?
Ok sinasagot ko ang aking sarili na binabasa ang iyong nakaraang puna, at isang bagay ang Manjaro at isa pa ang Arch.
Ang pagsisi sa isang distro para sa isang tiyak na problema ay hindi pare-pareho (hindi talaga pare-pareho), kahit papaano hindi ko masisisi kung gaano karaming distro ang sinusubukan ko para sa problema sa nouveau at sa aking nVidia 6150SE card, dahil ang problema ay ang MMIO paghawak ng driver at card (malalaman ng nVidia kung ano ang aayusin at mga nakatutuwang bagay na kakailanganin nilang ayusin ang detalyeng iyon). Ang hardware ay maaari ding maging problema, at makikita mo iyon sa anumang OS na ginagamit mo (Windows, Linux, BSD), at sa aking karanasan sa pag-aayos ng mga computer nakita ko ang mga kakaibang problema sa hardware (tulad ng isang PC na tumangging mag-boot maliban kung magbago ka ang lokasyon ng memorya, at kapag isinara kailangan mong ulitin ang proseso), at hindi ko masisisi ang Windows at Debian para doon.
Nagkaroon ako ng kernel panic na may live na Ubuntu 12.04
Mayroon akong frenetic sa aking Secure HP pavilion dm4 Notebook PC, 8 GB ng RAM, 500 ng hard drive, mayroon itong higit sa 5 taong paggamit. Hindi ko naaalala ang bilis ng microprocessor, isang Intel core i5, sa palagay ko higit sa 2 mhz.
Wala akong maisulat sa screen ng terminal. Patuloy akong maghanap ng karagdagang impormasyon, upang malutas ang problemang ito.