See postitus näitab, kuidas peaaegu vigadega idufirmade probleemi "lahendada" Arch Linux. Midagi järgmise pildi taolist:
Nagu näha, näeme, et see on üks paljudest vigade "kombinatsioonidest", mis ilmnevad juhuslikult selle probleemiga opsüsteemi käivitamisel. Nagu selles veas öeldakse, viitab see sellele, et "Riistvaras" võib olla probleem, kuid nagu me kõik selles operatsioonisüsteemis teame, on võimalik lahendada ka halvad nipid, mis OS-ile ei kuulu.
Niisiis kirjeldan oma kogemust selle probleemiga. Sellest, mida sain kogeda, oli probleem ainult selles Arch Linux või mõni muu distro, mida testisin väliselt, kuna mis tahes installitud või testitud ubuntu puhul algas see probleemideta. Aga kui ta prooviks Arch Linux kõvakettale installitud, oli tal probleem, et ta pidi taaskäivituma umbes 50 korda, et OS normaalselt käivituks ja saaks seda kasutada.
Sellel oli juba midagi valesti, sest testimiseks sain kasutada ainult installitud ubuntu ja ma ei suutnud teha isegi pooli asju, millega sain hakkama Arch Linux. Otsustasin selle probleemi lahendada ja hakkasin uurima, otsides sama probleemiga foorumilõike. Nad mainisid ka, et see oli riistvaraline viga ja et see oli täpselt protsessor, nii et see hakkas mind muretsema, nii et jõudsin avage arvuti ja kontrollige, mis toimub, kuid see ei aidanud.
Kuid midagi, mis näitas mulle, et ma ei tohiks alla anda, oli nii, kui Ubuntu Ma võiksin sellepärast Arch Linux ei (võib-olla Ubuntu on parem kui Kaar…?). Nii hakkasin kirjutama alglaadimisparameetreid faili kernelile Arch Linux, asjad nagu: lapic, nomce, intel_idle.max_cstate = 0, disable_cpu_apic, acpi_skip_timer_override, acpi = stric, clk, apm, noapic, acpi = oldboot, acpi-cpufreq, intel_pstate = keelata, i8042.noacpi = 1, apm = copyd, ac = copd, ac = copd, ac = copd, ac = copd, ac = copd, ac = =yd = acd = copds pci = nocrs, rhgb, acpi = jõud, pnpacpi = 0jj ja teised veel ... Kõike seda soovitati foorumites, mida ma lugesin.
Kuni pidin sisestama kerneli parameetrite dokumentatsiooni, mida ma muide soovitan: https://www.kernel.org/doc/Documentation/kernel-parameters.txt
Ja leidsin üsna huvitava parameetri, mis mul hetkel õnnestus käivitada Arch Linux Pole probleemi:
linux /boot/vmlinuz-linux root=UUID=fbefe36c-1712-4f3b-b3e3-3eac759d71c9 notsc nomce maxcpus = 0
Nagu seal näidatud, piirdub selle parameetriga protsessori kasutamine ilma sümmeetrilise töötlemisrežiimi aktiveerimiseta. Alguses töötas see üsna hästi, kuni kasutasin käsku pacman-Syyu; viskas mulle a tuum visatud o segmenteerimisviga.
Niisiis märkasin automaatselt, et midagi imelikku toimub, nii et hakkasin käivitama muid protsesse, kuni järsku süsteem täielikult külmus ja enam ei töötanud, kuni taaskäivitasin. Nii et ma tegin sama operatsiooni, kuid seekord õnnestus mul see läbi viia htop ja see näitas mulle järgmist:
Ootuspäraselt näitas see ainult ühte protsessorit, kuna teine oli selle keelanud, aga mulle tundus väga imelik, miks programmid viskasid segment, ega suutnud isegi graafilist keskkonda käivitada; nii et see oli midagi, mis vähemalt andis mulle rohkem lootust, et kui ma määraksin kerneli parameetrid ühel viisil, käivitaks see minu Arch Linux nagu alati
Nii et proovisin muud nimekirja kirjutatud parameetrid, kuni leidsin selle, mis on hetkel parim lahendus:
linux /boot/vmlinuz-linux root=UUID=fbefe36c-1712-4f3b-b3e3-3eac759d71c9 notsc nomce isolcpus = 1
See parameeter teeb midagi nii lihtsat kui protsessori teise tuuma eraldamine (mitte deaktiveerimine) sümmeetrilises töötlemises, see tähendab, et töötluskoormus antakse ühele südamikule, samas kui teine on ainult täiendav. Kuigi see tundub vastuoluline, ei mõjuta see jõudlust niivõrd, kuna see suurepärane OS suutis rakendusi käitada nii:
Nii et ainus probleem, mida täheldasin ja mis esines käivitamise ajal, on üks või kaks tuumapaanikat või oops; kuid võrreldes selle 50 korraga, kui ma pidin varem taaskäivitama, võin seda pidada "lahenduseks". Ülejäänud osas on see seni lubanud mul kasutada operatsioonisüsteemi ja kirjutada see postitus, mida praegu loete :-).
Loodan, et nad aitavad teid ja ei pääse välja GNU / Linux, mis on nende seni parim leiutatud operatsioonisüsteem. Ma ütlen seda kindlalt.
Väga huvitav info. Mul pole ArchLinuxis aastate jooksul kunagi olnud nii tuumapaanikat, et oleksin seda kasutanud, kuid on hea teada, mida teha, kui probleem mingil hetkel ilmneb. Aitäh!
Igatahes olen ma Archi kasutanud pikka aega (ma olin nagu 1 aasta ilma Archita) ja ilma tuumapaanikata.
Tänan vihje eest.
Tõenäoliselt, nagu ma postituses mainisin, juhtub probleem just riistvara tõttu, sest ka selles, mida ma arhi kasutan, polnud see mulle ühtegi sellist tüüpi probleemi tekitanud.
Teine Archi suurepäraste tulemustega. Mul pole kunagi olnud tuumapaanikat
Üle 2 aasta GNU / Linuxiga ... 2 aastat juba ArchLinuxiga, kunagi pole tuuma paanikat .. ic
Ma arvan, et tuumapaanikad on tingitud pigem riistvarast kui distroost endast. Ma pole kunagi näinud praegu kasutataval sülearvutil paanikatuumi, välja arvatud siis, kui panin sinna Ubuntu alfa (ja Arch Linux oli siin ka kaks aastat). Teisest küljest, minu käes olevas sülearvutis, annab iga pandud pistik alati tuuma paanikat ja mitmesuguseid vigu igale maitsele.
Debiani tuuma 3.14 korral olen sattunud kerneli paanikaprobleemi peale selle, et iga kord, kui arvuti sisse lülitan, kuvatakse teade "ühenda / katkesta ajalõpp" (ja ka siis, kui selle välja lülitan).
Minuga on seda juhtunud nii Fedoras kui Archis, kuid ma ei tea, miks ja kuidas ma ei näe erinevust, kuna ma pole kulutanud aega selle uurimisele või lahendamisele (kui see on probleem).
Ma arvan, et põhjus on selles, et need on kompileeritud gcc 4.9-ga
http://libuntu.com/linus-torvalds-considera-que-la-version-4-9-de-gcc-es-una-pura-y-absoluta-mierda/
Suur aitäh info eest. Mõned paljudest asjadest, millega saame kiidelda, on seda tüüpi foorumid
Miks see juhtub Arch Linuxiga? Võib-olla ei piisa probleemidest, mis sageli ilmnevad, kui süsteemi aeglus või üles riputamine jõuavad süsteemi ärrituseni.
Hei? Millest sa räägid? o_O
Arch on KISS-i jaotis, mis on konfigureeritav opsüsteemi enda baasil, mõne sõnaga, kui süsteem on raske, siis sellepärast, et olete selle niimoodi ehitanud, kui süsteemis on vigu, siis sellepärast, et olete need loonud või et te pole seda teinud seadistage midagi õigesti. Archi wiki on üsna täielik, mõni aasta tagasi ei olnud hispaania keeles palju olulisi teemasid, ja installiprotsess oli palju karmim ja mõnevõrra keeruline, nüüd on kõik veidi automatiseeritud.
Distro süüdistamine kasutajavigade pärast on nii ... Windows (?).
Vigade levitamise süüdistamine on järjekindel, lihtsalt sellepärast, et see on tõde. Pärast Manjaroga sarnase probleemi tekkimist proovisin Archi, Antergost ja mõnda muud tundmatut jaotust (ma ei mäleta seda nime nüüd, vabandust), mida keegi soovitas mulle kinnitada, et see ei tekita probleeme, kuid mitte midagi; nad kõik annavad selle. OpenSuse'is Fedora, Mint, Mageia ja kõik, mida olen pärast proovinud, ei läbi. Niisiis, mis mind puudutab, ei jää mul muud üle, kui arvata, et see on distro süü. Aga, hei, ma ei demoniseeri seda ega midagi, veelgi enam, see häirib mind, et ma ei saa Archi põhjal midagi kasutada, sest see meeldib mulle väga, kuid see neetud probleem takistab mind. Ma ei arva, et see oleks seotud riistvaraga, sest paljud meist, kes meiega juhtuvad, ei juhtunud enne sama kuradi kasutamist. Noh, tegelikult peab see olema midagi riistvaraga seotud, kuid kui minna tagasi sama asja juurde, siis kui ma pole muudatusi teinud ja mul on probleeme sama seadmega, millega mul neid varem polnud, siis ilmselt see tuleneb muutusele, mille tegi Arch, kes on mind kruvinud.
"Distro süüdistamine kasutajate vigade eest on nii ... Windows (?)."
Ma ütleksin teile, et kasutajate süüdistamine tootevigades on nii Apple. Ma olen selle peale ausalt mõelnud tuhat korda, kuid ma ei näe eelist, kui kasutaksin asja, mille hooldajad põhimõtteliselt käsi pesevad, mingil tõsisel eesmärgil. Ja ma ütlen, et kui arvestada, et GPL tarkvara on ilma garantiita.
Võite öelda nii, nagu soovite, kuid kui see on sama juhtum, kui teated iPhone'i signaali puudumisest ja Apple'i vastus on mitu aastat tagasi "on see, et te eksite". Kui teete distrooni, soovite tavaliselt pakkuda kvaliteetset ja minimaalset tuge ning tõsi on see, et Arch on põhimõtteliselt harrastussüsteem, kus näete, et selle arendajatel on lõbus uusi asju pakkida, kuid tegeliku toe pakkumise vastu pole suurt huvi. . Iga kord, kui ma seda tüüpi postitust näen, hindan rohkem kasutatava distro taga olevat tööd.
Ja jah, see on tarkvaraprobleem, kui see ei tööta, kui see värskenduses töötamise lõpetab või kui mõni riistvara puruneb. See ühe tuuma paanikahäire, samas kui teine seda ei tee ... noh, jah, selgelt on üks distro, mis teeb asju õigesti ja teine valesti. Kui teil on nüüd hea meel kasutada Linuxit 90ndate stiilis, kus me pidime tuuma uuesti kompileerima iga kord, kui ühendasime uue printeri ... seal olete.
Kas kerneli on koostanud arendajad? või enda oma?
Tuuma paanika tekib siis, kui teatud komponente pole kompileerimisel valitud (AND) või kui mõnda moodulit pole teatud riistvara toetamiseks aktiveeritud. Harjutades oma riistvara ja teadmisi (peate arvuti avama ja nägema, mis marki kiibid sellel on), saate ehitada kohandatud tuuma (chrootimisega). Kui teie arvutis olid ubuntu ja Archi installi-CD, on kompileerimises midagi, mis pole aktiveeritud.
See oli arhlinuxi enda, hoidlate varude tuum.
Teie kasutatav kernel on jäänud midagi, mis teie riistvarale ei meeldi, emaplaadil peab olema haruldane kiibi versioon või isegi kiip viga (see juhtub tavaliselt).
See võib olla teie bios acpi rikutud tabel, on normaalne, et valves olevad hiinlased ei arvuta isegi iga tabeli kontrollsummat hästi, need teated ilmuvad tavaliselt käivitamise alguses tähega $ dmesg -human.
Peaksite proovima ka mõnda muud toiteallikat, kui filtreerimine ebaõnnestub, kipub pulsatsioon just selliseid rikkeid tegema.
Kõigepealt proovige muuta allikat ja vaadake, mis juhtub. Kui see jääb samaks, proovige seadistada tuum oma riistvarale sobivaks, muide saate selle käigus oma arvutit paremini tundma õppida.
Täname näpunäidete eest. Muide, see on sülearvuti, arvan, et peaksin patarei vahetama. Kuid ma näen, et see, mida te mulle ütlesite, võib mind aidata.
Ühe tuumapaanika, mis mind ikka hulluks ajab, on osaliselt süüdi nouveau kutid ja minu vana, aegunud ja väga tolmune nVidia 6150 SE integreeritud kaart (ma mõtlen osaliselt seetõttu; nad on teinud suurepärast tööd graafikakiipide universumi toetamisel nagu need, mis nVidial on, ja seda kõike kasutades ainult pöördtehnoloogiat ning probleem ilmneb ainult mõnel NV4E kiibistikuga kaardil).
Kõik, mida peate tegema, on käivitada Openbox + Firefox ja katastroofirünnakud (pole midagi ilusamat kui ekraanil täiesti juhusliku mustvalge mosaiigi nägemine). Ja ma olen seda laulnud alates kernel 3.6-st Debianis, Fedoras, Archlinuxis, Slackware'is ja nüüd uuesti Gentoo's (uuesti installitud kernel 3.12-ga), ma ei viitsi enam logi viia, kernelisse ega anda talle aega midagi kirjutada, ärge olge ilmatu jama tegelased.
Ma pakun teile lahenduse, pc, mis mul on koos gentoo ja integreeritud nvidia videoga, on sama uus versiooniga draiveriga, nii et mul ei jäänud muud üle kui kasutada suletud nvidia draiverit, peab minu kiip kasutama 304.123 draiverit
00: 0d.0 VGA-ga ühilduv kontroller [0300]: NVIDIA Corporation C61 [GeForce 7025 / nForce 630a] [10de: 03d6] (rev a2) (prog-if 00 [VGA kontroller])
Enne selle kompileerimist peate lappima kerneli faili, kui seda pole lappitud, keeldub graafikarežiim käivitamast.
Sammud on:
# nano -w /usr/src/linux-3.15.7-gentoo/drivers/acpi/osl.c
Otsige selle teksti jaoks klahvidega Ctrl + w nano sees, acpi_os_wait_events_complete ja nano viib teid sellesse ossa:
void acpi_os_wait_events_complete (tühine)
{
flush_workqueue (kacpid_wq);
flush_workqueue (kacpi_notify_wq);
}
EXPORT_SYMBOL (acpi_os_wait_events_complete);
Plaaster, mille peate lisama, on see viimane rida, mis algab tähtedega EXPORT, ctrl + või ctrl + x
Seejärel kompileerite kerneli, installite moodulid, installite kerneli, genereerite vajadusel initramf-id, lisate splash'i kasutamisel pritsmete initramfs-i, taastate grubi kirjed ja lõpuks peate väga uuesti üles ehitama moodulid, mis pole kernel, see tähendab patenteeritud nvidia moodul, ilma seda tegemata ei tööta graafiline režiim teie jaoks.
# eselect kerneli loend
#vali kerneli komplekt x
# cd / usr / src / linux
# tegema
# tee moodulid_install
# mount / boot
# tee install
# dracut –hostonly »3.15.7-gentoo –jõud
# splash_geninitramfs –verbose –res 1400 × 1050 –append /boot/initramfs-3.15.7-gentoo.img emerge-world
# grub -mkconfig -o /boot/grub/grub.cfg
# emerge @ moodul-taastada
# arv / alglaadimine
# väljalülitamine -r nüüd
Kui kasutate genkernelit, siis lihtsalt parandate selle faili ja saan aru, et genkernel parandab ennast.
Lisaks peate eemaldama tuumalt drm-tugi ja nvidia draiverid ning muud videokiibid, et need ei põrkaks kokku suletud nvidia draiveriga, mis on installitud nvidia moodulina.
Bootplashi kasutamise korral peate uvesa draiveri lisama kernelisse, et see toetaks kõrge ekraani eraldusvõime, kuna suletud nvidia draiver (kui ma õigesti mäletan) ei toeta terminali tty800 «F600» rohkem kui 1 × 1 saabas.
Ma ei tea teiste distrode kohta, kuid eeldan, et see peaks toimima mis tahes distroos, kui need sammud oleksid tehtud, säästes tekkivat muudatust ükskõik milliseks.
Nvidia ja uvesa puhul peate järgima neid juhiseid:
http://wiki.gentoo.org/wiki/NVidia/nvidia-drivers/es
http://wiki.gentoo.org/wiki/Uvesafb
Täname teabe eest, kuid lahendasin probleemi just nimelt varalistele. Mäletan, et ka eelmine nVidia draiver (304.121) tuli 3.13-le minnes lappida, kuna sellel oli probleeme mooduli kompileerimisel (vigu ei olnud, kuid moodul keeldus töötamast) ja kõike ka ACPI sündmuste käitleja tõttu . Debianis sain probleemi üles ja leidsin ka lahenduse.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740097
Olen näitena kasutanud Manjarot, kuid olen juba varem maininud, et sama juhtus minuga Archi ja muude derivaatidega. Seetõttu usun, et probleem on rohkem nende kui puudutatud inimeste käes.
Pd: Ma ei ole saanud asjakohasele sõnumile otse vastata, kuna vastust ei kuvata ...
Läksin täpselt Manjaro juurest Linux Mint'i, sest see külmub käivitamisel pärast värskendamist versioonile pärast 0.8.9 (ma ei mäleta, milline neist). Sellest, mida ma lugesin, juhtub see tavaliselt sülearvutites. Minu kõnesolev probleem ei olnud sama mis selles postituses, arvasin, et jõudsin järeldusele, et see võib olla seotud võimuhaldusega. Oli inimesi, kes ei külmunud, kui nad sülearvuti vooluvõrgust lahti ühendades käivitasid. Praegu ma ei mäleta, kas see võimaldas mul alati probleemideta alustada, kuid loomulikult suutsin seda teha mitu korda selle hinnaga, et selle tegemine võtab kauem aega.
Igatahes lõpuks loobusin ja läksin üle Fedora ja Linux Mintile.
Juhuslikult üritasin eile seda ilma laadijata peatada ja jätkamisel see rippus ning pidin taaskäivitama.
See on üsna naljakas, olen Archiga koos olnud paar kuud ja mul pole olnud ühtegi Kerneli paanikat! Minuga on juhtunud elukeskkonnast pärit Antergosega (Arch koos lisatud hoidlaga), kuid seal pean seda arusaadavamaks. Kas see võib olla probleem emaplaadi või vigase RAM-mooduliga? Mäletan, et umbes 2 aastat tagasi põhjustas RAM-moodul mulle mitu Windowsi sinist ekraani ja ka mitu Kernel Panics'i! Mandriva peal. Pidin iga mälu taaskäivitamise ja taaskäivitamise vahel korraga testima.
See on Archi probleem (mis kannab kõiki oma tuletisi), sest teistes distros selliseid probleeme pole. Piinlik on see, et nad pole seda hetkel lahendanud. See on olnud just nemad aastaid! Olen lugenud sarnaseid probleeme aastast 2011. Ma olen selge, et see tuleb ja läheb, kui neid värskendatakse, sest kasutades versioone 0.8.7, 0.8.8 ja 0.8.9 ilma neid värskendamata, ei juhtu midagi. Sealt edasi läheb kõik jama ja kindlasti juhtus ka vanades versioonides. Miks see juhtub ainult vähestel meist? Ma ei tea, aga ma arvan, et see pole mitte meie, vaid Archi probleem, sest nagu juba öeldud, töötavad muud jaotused suurepäraselt. Ma murdsin juba tema ajal sarved, et lahendust leida, kuid ma väsisin ära. Nii palju kui mul on kahju, ei hakka ma Archi kasutama.
Kaar 0.8.7, 0.8.8 ja 0.8.9? Saan teada, et Arch kasutab seda versiooninomenklatuuri.
Kas võib juhtuda, et kasutate Manjarot?
Ok, vastan ise teie eelmist kommentaari lugedes ja üks asi on Manjaro ja teine Arch.
See, et distro süüdistamine teatud probleemis pole ka järjekindel (pole tegelikult järjepidev), vähemalt ei saa ma minu puhul süüdistada seda, kui palju distro proovisin uue ja minu nVidia 6150SE kaardi probleemis, sest probleem on selles, et Juhi ja kaardi MMIO-käsitsemine (nVidia teab, mida parandada, ja pöörased asjad, mida nad selle detaili parandama peavad). Samuti võib probleemiks olla riistvara ja näete, et ükskõik millises operatsioonisüsteemis kasutate (Windows, Linux, BSD) ja oma arvutite parandamise kogemuse põhjal olen näinud väga kummalisi riistvaraprobleeme (näiteks arvuti, mis keeldub käivitage, kui te ei muuda mälu asukohta ja sulgemisel peate protsessi kordama) ja ma ei saa selles süüdistada Windowsi ja Debiani.
Mul oli tuuma paanika otseülekandes oleva ubuntu 12.04 abil
Mul on meeletu oma Secure HP pavilion dm4 sülearvuti, 8 GB RAM-i, 500 kõvaketast, seda on rohkem kui 5 aastat kasutatud. Ma ei mäleta mikroprotsessori kiirust, Inteli tuum i5, ma arvan, et rohkem kui 2 mhz.
Ma ei saa terminali ekraanile midagi kirjutada. Otsin selle probleemi lahendamiseks lisateavet.