Šis ieraksts ir paredzēts, lai parādītu, kā gandrīz novērst jaunuzņēmumu problēmu ar kļūdām Arch Linux. Kaut kas līdzīgs šim attēlam:
Kā redzams, mēs redzam, ka šī ir viena no daudzajām kļūdu "kombinācijām", kas nejauši parādās, startējot operētājsistēmu ar šo problēmu. Kā teikts šajā kļūdā, tas norāda, ka "Aparatūrā" var būt problēma, tomēr, kā mēs visi zinām šajā operētājsistēmā, var atrisināt pat sliktos trikus par to, kas nepieder OS.
Tātad, es aprakstīšu savu pieredzi saistībā ar šo problēmu. Pēc tā, ko varēju piedzīvot, problēma bija tikai ar Arch Linux vai citu distro, kuru es testēju ārēji, jo ar jebkuru instalētu vai pārbaudītu ubuntu tas sākās bez problēmām. Bet, ja es mēģinātu noplēst Arch Linux instalēta cietajā diskā, tai bija problēma, ka tai bija jāpārstartē apmēram 50 reizes, lai OS varētu normāli palaist un varētu to izmantot.
Tam jau bija kaut kas nepareizs, jo es to testēšanai varēju izmantot tikai instalēto ubuntu, un es nevarēju izdarīt pat pusi no lietām, ar kurām es varētu nodarboties Arch Linux. Tāpēc es nolēmu atrisināt šo problēmu un sāku izmeklēt, meklējot foruma pavedienus, kuriem bija tāda pati problēma, viņi arī pieminēja, ka tā ir aparatūras kļūda un ka tieši CPU, tāpēc tas sāka mani uztraukt, tāpēc Man vajadzēja atvērt datoru un pārbaudīt, kas notiek, tomēr tas nepalīdzēja.
Bet kaut kas man parādīja, ka man nevajadzētu atteikties, tas bija, ja Ubuntu Es varētu tāpēc Arch Linux nē (varbūt Ubuntu ir labāks par Arka…?). Tāpēc es sāku rakstīt sāknēšanas parametrus Arch Linux, piemēram: 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 = atspējot, i8042.noacpi = 1, apm = copyds, ac = copyds, ac = copyds, ac = copyds, ac = copyds, apm = copyds, apm = copyds, apm = copyds, apm = copyds, apm = copyds, apm = copyds, apm = copyds, ac = copyds, ac = copyds, ac = copyds, ac = copyds, ac = copyds, ac = copyds, ac = copyds, ac pci = nocrs, rhgb, acpi = spēks, pnpacpi = 0ff un citi vairāk ... Tas viss tika ieteikts manis lasītajos forumos.
Līdz brīdim, kad man bija jāievada kodola parametru dokumentācija, kuru es iesaku, starp citu: https://www.kernel.org/doc/Documentation/kernel-parameters.txt
Un es atradu diezgan interesantu parametru, kuru šobrīd izdevās palaist Arch Linux Nekādu problēmu:
linux /boot/vmlinuz-linux root=UUID=fbefe36c-1712-4f3b-b3e3-3eac759d71c9 notsc nomce maxcpus = 0
Kā norādīts tur, šī parametra darbība ir tikai CPU izmantošana, neaktivizējot simetrisko apstrādes režīmu. Sākumā tas darbojās diezgan labi, līdz es izmantoju komandu pacmans -Syyu; iemeta man a kodols izgāzts o segmentācijas vaina.
Tāpēc es automātiski pamanīju, ka notiek kaut kas dīvains, tāpēc sāku palaist citus procesus, līdz pēkšņi sistēma pilnībā sastinga un vairs nedarbojās, līdz es to pārstartēju. Tāpēc es izdarīju to pašu operāciju, bet šoreiz man izdevās izpildīt htop un tas man parādīja sekojošo:
Kā jau bija paredzēts, tas parādīja tikai vienu CPU, jo otrs to bija atspējojis, tomēr man likās ļoti dīvaini, kāpēc programmas meta segfault, un pat nevarēja sākt grafisko vidi; tāpēc tas bija kaut kas, kas man vismaz deva vairāk cerību, ka, ja es iestatīšu kodola parametrus vienā veidā, tas palaiž manu Arch Linux kā vienmēr
Tāpēc es turpināju izmēģināt citus parametrus, kurus es uzrakstīju sarakstā, līdz nonācu pie šī, kas šobrīd ir labākais risinājums:
linux /boot/vmlinuz-linux root=UUID=fbefe36c-1712-4f3b-b3e3-3eac759d71c9 notsc nomce isolcpus = 1
Šis parametrs veic kaut ko tik vienkāršu kā centrālā procesora otrā kodola izolēšana (nedeaktivizēšana) simetriskā apstrādē, tas ir, apstrādes slodze tiek piešķirta vienam kodolam, bet otrs ir tikai papildinošs. Lai gan tas šķiet pretrunīgi, tas tik daudz neietekmē veiktspēju, jo šī lieliskā OS varēja palaist lietojumprogrammas šādā veidā:
Tāpēc vienīgā novērotā problēma, kas rodas sāknēšanas laikā, ir viena vai divas kodola panikas vai ops; Bet, salīdzinot ar 50 reizēm, kad man iepriekš bija jāpārstartē, es to varu uzskatīt par "risinājumu". Pārējā gadījumā līdz šim tas man ļāva izmantot OS un uzrakstīt šo ierakstu, kuru pašlaik lasāt :-).
Es ceru, ka viņi jums palīdzēs un neizkļūs GNU / Linux, kas ir labākā operētājsistēma, kādu viņi jebkad ir izgudrojuši. Es to saku droši.
Ļoti interesanta informācija. Man nekad nav bijušas šīs kodola panikas ArchLinux gadu laikā, kad to izmantoju, taču ir labi zināt, ko darīt, ja kādā brīdī rodas problēma. Paldies!
Jebkurā gadījumā es jau ilgu laiku lietoju Arch (man bija kā 1 gads bez Arch) un bez kodola panikas.
Paldies par padomu.
Visticamāk, kā jau minēju ierakstā, problēma rodas aparatūras dēļ, jo arī tajā, ko es izmantoju arkā, man nebija radušās šāda veida problēmas.
Vēl viens ar izciliem rezultātiem Arch. Man nekad nav bijusi kodola panika
Vairāk nekā 2 gadus ar GNU / Linux ... 2 gadus jau ar ArchLinux, nekad nav kodola panikas .. 😉
Es domāju, ka kodola panikas drīzāk ir saistītas ar aparatūru, nevis ar pašu traucējumu. Es nekad neesmu redzējis panikas kodolu klēpjdatorā, kuru tagad izmantoju, izņemot gadījumus, kad es tajā ievietoju Ubuntu alfa (un Arch Linux bija šeit arī divus gadus). No otras puses, citā man piederošajā klēpjdatorā jebkurš izplatītājs, ko es ievietoju, vienmēr rada kodola paniku un dažādas kļūdas visām gaumēm.
Ar Debian kodolu 3.14 esmu saskāries ar kodola panikas problēmu, turklāt ikreiz, kad ieslēdzu datoru, tiek parādīts ziņojums “Savienot / atvienot noildzi” (un arī tad, kad to izslēdzu).
Tas ir noticis ar mani tik daudz Fedorā kā Arch, bet es nezinu, kāpēc un kā es neredzu atšķirību, jo neesmu pavadījis laiku, lai to izmeklētu vai atrisinātu (ja tā ir problēma).
Es domāju, ka iemesls ir tas, ka tie ir apkopoti ar gcc 4.9
http://libuntu.com/linus-torvalds-considera-que-la-version-4-9-de-gcc-es-una-pura-y-absoluta-mierda/
Liels paldies par informāciju. Dažas no daudzajām lietām, ar kurām mēs varam lepoties, ir šāda veida forums
Kāpēc tas notiek ar Arch Linux? Varbūt nepietiek ar problēmām, kas bieži parādās, kad sistēmas lēnums vai pakāršana sasniedz punktu, kad sistēma tiek nomocīta.
Hei? Par ko tu runā? o_O
Arch ir KISS izplatījums, kuru var konfigurēt no pašas operētājsistēmas bāzes, dažos vārdos sakot, ja sistēma ir smaga, tas ir tāpēc, ka jūs to uzbūvējāt tādā veidā, ja sistēmā ir kļūdas, tas ir tāpēc, ka jūs tās ģenerējāt vai tāpēc, ka neesat to izveidojis. kaut ko pareizi konfigurēt Arch wiki ir diezgan pabeigta, pirms dažiem gadiem spāņu valodā nebija daudz svarīgu tēmu, un instalēšanas process bija daudz rupjāks un nedaudz grūts, tagad viss ir mazliet automatizētāks.
Pārmest vainu lietotāju kļūdām ir tik ... Windows (?).
Distro vainošana par kļūdām ir konsekventa tikai tāpēc, ka tā ir patiesība. Pēc tam, kad man bija līdzīga problēma ar Manjaro, es izmēģināju Arch, Antergos un citu nezināmu izplatīšanu (es tagad neatceros vārdu, atvainojiet), ko kāds man ieteica man apliecināt, ka tas nesniedz problēmas, bet neko; viņi visi to dod. OpenSuse, Fedora, Mint, Mageia un visos, kurus esmu izmēģinājis pēc tam, tas nepāriet. Tātad, kas attiecas uz mani, man neatliek nekas cits, kā domāt, ka tā ir distro vaina. Bet, hei, es to nedemonizēju vai neko citu, vēl vairāk, tas mani kaitina, ka es neko nevaru izmantot, pamatojoties uz Arch, jo man tas ļoti patīk, bet šī sasodītā problēma mani kavē. Es arī nedomāju, ka runa ir par aparatūru, jo daudzi no mums, kas notiek ar mums, nenotika pirms tās pašas fucking lietošanas. Nu, patiesībā tam jābūt kaut kam, kas saistīts ar aparatūru, bet, atgriežoties pie tā paša, ja es neesmu veicis izmaiņas un man ir problēmas ar to pašu aprīkojumu, ar kuru man to iepriekš nebija, acīmredzot, tas būs saistīts ar veiktajām izmaiņām arka, kurš mani ieskrūvēja.
"Pārmest vainu lietotāju kļūdām ir tik ... Windows (?)."
Es jums saku, ka vainot lietotājus produktu kļūdās ir tik Apple. Esmu godīgi par to domājis tūkstoš reižu, bet es neredzu priekšrocību, ja kaut ko nopietnu mērķi izmantotu kaut ko tādu, kura uzturētāji pamatā mazgā rokas. Un es saku, ka, ņemot vērā to, ka GPL programmatūrai nav garantijas.
Jūs varat teikt, kā vēlaties, bet, ja tas ir tas pats gadījums, kad ziņojumi par signāla trūkumu iPhone un Apple atbilde ir tāda, ka jūs to kļūdāties pirms vairākiem gadiem. Ja veicat distro, jūs parasti vēlaties nodrošināt kvalitatīvu un minimālu atbalstu, un patiesība ir tāda, ka Arch būtībā ir hobija sistēma, kurā redzat, ka tās izstrādātājiem ir jautri iesaiņot jaunas lietas, bet maz interesē piedāvāt patiess atbalsts. Katru reizi, kad redzu šāda veida ziņojumus, es vairāk vērtēju darbu, ko izmantoju distro, kuru izmantoju.
Jā, tā ir programmatūras problēma, ja tā nedarbojas, ja tā pārstāj darboties atjauninājumā vai ja kaut kas no aparatūras saplīst. Ka kodola panikas izjaukšana, kamēr cita nedara ... labi, jā, nepārprotami ir izplatītājs, kas dara lietas pareizi un cits nepareizi. Tagad, ja jums ir prieks izmantot Linux 90. gadu stilā, kad mums bija jākompilē kodols katru reizi, kad pievienojām jaunu printeri ... tur jūs.
Vai kodolu ir sastādījuši izstrādātāji? vai savu?
Kodola panika tiek ģenerēta, ja kompilēšanas laikā nav izvēlēti noteikti komponenti (AND) vai nav aktivizēti daži moduļi, lai atbalstītu noteiktu aparatūru. Izmantojot praksi un zināšanas par aparatūru (jums ir jāatver dators un jāpārbauda, kāda veida mikroshēmas tajā ir), jūs varat izveidot pielāgotu kodolu (ar chrooting). Ja datorā bija ubuntu un Arch instalācijas kompaktdisks, kompilācijā ir kaut kas tāds, kas nav aktivizēts.
Tas bija krājuma kodols no paša arhinola, no krātuvēm.
Jūsu izmantotais kodols ir palicis pāri, kas nepatīk jūsu aparatūrai, mātesplatē jābūt retai mikroshēmas versijai vai pat mikroshēmas kļūdai (tas parasti notiek).
Tā var būt korumpēta tabula jūsu BIOS acpi, tas ir normāli, ka dežurējošie ķīnieši pat labi neaprēķina katras tabulas kontrolsummu, šie ziņojumi sāknēšanas sākumā parasti parādās ar $ dmesg -human.
Jums vajadzētu izmēģināt arī citu barošanas avotu, kad filtrēšana neizdodas, pulsācija mēdz veikt tieši šādas kļūmes.
Vispirms mēģiniet mainīt avotu un uzziniet, kas notiek, ja tas paliek nemainīgs, mēģiniet konfigurēt kodolu, lai tas atbilstu jūsu aparatūrai, kā jūs šajā procesā labāk iepazīsit savu datoru.
Paldies par padomiem. Starp citu, tas ir klēpjdators, es domāju, ka man vajadzētu nomainīt akumulatoru. Bet es redzu, ka tas, ko jūs man teicāt, var man palīdzēt.
Viena kodola panika, kas mani joprojām padara traku, daļēji ir vainīga nouveau puišos un manā vecajā, novecojušajā un ļoti putekļainajā nVidia 6150 SE integrētajā kartē (es domāju daļēji tāpēc, ka viņi ir paveikuši lielisku darbu, atbalstot tādu grafisko mikroshēmu visumu kā: tie, kas ir nVidia, un tas viss, izmantojot tikai reverso inženieriju, turklāt problēma rodas tikai dažām kartēm ar NV4E mikroshēmojumu).
Vienkārši sāciet Openbox + Firefox un katastrofu streikus (nekas skaistāks par to, ka ekrānā redzat pilnīgi nejaušu melnbaltu mozaīku). Un es to dziedāju kopš 3.6 kodola Debian, Fedora, Archlinux, Slackware un tagad atkārtoti pārbaudīju Gentoo (tikko instalēts ar kodolu 3.12), es vairs neuztraucos paņemt žurnālu, uz kodolu vai dot laiku rakstīt kaut ko neesi milzīgs blēņu varonis.
Es jums dodu risinājumu. Dators, kas man ir ar gentoo un integrēto nvidia video, notiek tāpat kā ar nouveau draiveri, tāpēc man nekas cits neatlika, kā izmantot slēgto nvidia draiveri, manai mikroshēmai jāizmanto 304.123 draiveris
00: 0d.0 ar VGA saderīgs kontrolieris [0300]: NVIDIA Corporation C61 [GeForce 7025 / nForce 630a] [10de: 03d6] (rev a2) (prog-if 00 [VGA kontrolieris])
Pirms tā sastādīšanas jums ir jālāpo kodola fails, ja grafikas režīms netiks palaists, ja tas nav salāpīts.
Darbības ir šādas:
# nano -w /usr/src/linux-3.15.7-gentoo/drivers/acpi/osl.c
Meklēt ar ctrl + w nano šajā tekstā, acpi_os_wait_events_complete un nano novirza jūs uz šo daļu:
void acpi_os_wait_events_complete (anulēts)
{
flush_workqueue (kacpid_wq);
flush_workqueue (kacpi_notify_wq);
}
EXPORT_SYMBOL (acpi_os_wait_events_complete);
Plāksteris, kas jums jāpievieno, ir šī pēdējā rindiņa, kas sākas ar EXPORT, ctrl + vai ctrl + x
Tad jūs kompilējat kodolu, instalējat moduļus, instalējat kodolu, ģenerējat initramfs, ja jums tas nepieciešams, pievienojiet splash uz initramfs, ja izmantojat splash, atjaunojat ierakstus grub un, visbeidzot, un kas ir ļoti svarīgi, jums ir jāatjauno moduļi, kas nav no kodols vai patentētais nvidia modulis, bez tā grafiskais režīms nedarbosies.
# eselect kodola saraksts
# eselect kodola kopa x
# cd / usr / src / linux
# veidot
# make modules_install
# mount / boot
# make install
# dracut –hostonly »3.15.7-gentoo – spēks
# splash_geninitramfs –verbose –res 1400 × 1050 –append /boot/initramfs-3.15.7-gentoo.img emerge-world
# grub-mkconfig -o / boot /grub/grub.cfg
# emerge @ moduļa atjaunošana
# umount / boot
# shutdown-r tagad
Ja izmantojat genkernel, jūs vienkārši ielāpat šo failu, un es saprotu, ka genkernel pats salabo.
Turklāt no kodola ir jānoņem drm atbalsts, nvidia draiveri un citas video mikroshēmas, lai tie nesaskartos ar slēgto nvidia draiveri, kas ir instalēts kā nvidia modulis.
Gadījumā, ja tiek izmantots bootplash, kodolā jāiekļauj uvesa draiveris, lai tas atbalstītu augstas izšķirtspējas ekrānu, jo slēgtais nvidia draiveris (ja pareizi atceros) sāknēšanas tty800 «F600» terminālā neatbalsta vairāk nekā 1 × 1.
Es nezinu par citiem distros, bet es domāju, ka, ja šīs darbības tiktu veiktas, tam būtu jādarbojas ar jebkuru distro, saglabājot radušās izmaiņas jebkuram.
Šīs ir vadlīnijas, kas jums jāievēro attiecībā uz nvidia un uvesa:
http://wiki.gentoo.org/wiki/NVidia/nvidia-drivers/es
http://wiki.gentoo.org/wiki/Uvesafb
Paldies par informāciju, bet es precīzi atrisināju problēmu, pārejot uz patentētajām. Es atceros, ka arī iepriekšējais nVidia draiveris (304.121) bija jāatjauno, dodoties uz 3.13, jo tam bija problēmas moduļa sastādīšanā (nebija kļūdu, bet modulis atteicās strādāt) un viss arī ACPI notikumu apstrādātāja dēļ . Debianā es saņēmu problēmu un arī atradu risinājumu.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740097
Esmu izmantojis Manjaro kā piemēru, bet jau iepriekš minēju, ka tas pats notika ar mani ar Arch un citiem atvasinājumiem. Tāpēc es uzskatu, ka problēma ir vairāk viņu nekā skarto.
Pd: Es nevarēju atbildēt tieši uz attiecīgo ziņojumu, jo opcija atbildēt neparādās ...
Es precīzi devos no Manjaro uz Linux Mint, jo tas tiks iesaldēts, startējot pēc atjaunināšanas uz versiju pēc 0.8.9 (es neatceros, kura no tām). Pēc lasītā tas parasti notiek klēpjdatoros. Mana attiecīgā problēma nebija tāda pati kā šajā ierakstā, es domāju, ka es nonācu pie secinājuma, ka tā varētu būt saistīta ar enerģijas pārvaldību. Bija cilvēki, kas nesasalst, ja klēpjdatoru palaida, kamēr tas ir atvienots. Šobrīd es neatceros, vai tas man ļāva vienmēr startēt bez problēmām, bet, protams, es to varēju izdarīt vairāk reizes, rēķinot, ka tas ir vajadzīgs ilgāk.
Lai vai kā, beigās es atteicos un pārgāju uz Fedora un Linux Mint.
Nejaušība, vakar es mēģināju to apturēt bez lādētāja, un, atsākot, tas karājās, un man nācās restartēt.
Tas ir diezgan smieklīgi, es esmu bijis Arch pāris mēnešus un man nav bijusi neviena kodola panika! Man tas ir noticis ar Antergos (Arch ar pievienotu krātuvi) no dzīvās vides, bet tur es to uzskatu par saprotamāku. Vai tā varētu būt problēma ar mātesplatē vai bojātu RAM moduli? Es atceros, ka pirms aptuveni 2 gadiem RAM modulis man izraisīja vairākus zilos ekrānus sistēmā Windows un arī vairākas kodola panikas! uz Mandriva. Man bija jāpārbauda katra atmiņa vienlaikus starp pārstartēšanu un pārstartēšanu.
Tā ir Arch problēma (kas velk visus tās atvasinājumus), jo citos distros šāda veida problēmu nav. Man neērts ir tas, ka šajā brīdī viņi to nav atrisinājuši. Tas jau gadiem ir bijis tikai viņi! Esmu lasījis līdzīgas problēmas no 2011. gada. Man ir skaidrs, ka tas nāk un iet, kad tie tiek atjaunināti, jo, izmantojot versijas 0.8.7, 0.8.8 un 0.8.9, tās neatjauninot, nekas nenotiek. Turpmāk viss iet uz sūdiem, un noteikti vecajās versijās tas arī notika. Kāpēc tas notiek tikai dažiem no mums? Es nezinu, bet es nedomāju, ka tā ir mūsu problēma, bet gan Arch, jo, kā jau teicām, citi izplatījumi darbojas nevainojami. Es jau viņa dienā lauzu ragus, lai atrastu risinājumu, bet man apnika. Tāpēc, lai arī cik žēl, es neizmantošu Arch.
Loka 0.8.7, 0.8.8 un 0.8.9? Es uzzināju, ka Arch izmanto šo versiju nomenklatūru.
Vai varētu būt, ka jūs izmantojat Manjaro?
Labi, es atbildu sev, izlasot jūsu iepriekšējo komentāru, un viena lieta ir Manjaro, bet otra ir Arch.
Arī tas, ka vainoju distro par noteiktu problēmu, nav konsekventa (nav īsti konsekventa), vismaz manā gadījumā es nevaru vainot, cik daudz distro es mēģinu radīt ar nouveau un manu nVidia 6150SE karti saistītā problēma, jo problēma MMIO apstrāde ar vadītāju un karti (nVidia zinās, ko labot, un trakas lietas, kas viņiem būs jānovērš šī detaļa). Aparatūra var būt arī problēma, un jūs varat redzēt, ka jebkurā jūsu izmantotajā operētājsistēmā (Windows, Linux, BSD) un pēc savas pieredzes datoru labošanā esmu redzējis ļoti dīvainas aparatūras problēmas (piemēram, datoru, kas atsakās sāknēšanu, ja vien nemaināt atmiņas vietu, un, izslēdzot procesu, jums ir jāatkārto process), un es nevaru par to vainot Windows un Debian.
Man bija kodola panika ar tiešraides Ubuntu 12.04
Man ir satraukums par manu Secure HP pavilion dm4 piezīmjdatoru, 8 GB operatīvo atmiņu, 500 cieto disku, un tas ir izmantots vairāk nekā 5 gadus. Es neatceros mikroprocesora ātrumu, Intel core i5, es domāju, ka vairāk nekā 2 mhz.
Es neko nevaru uzrakstīt termināla ekrānā. Es turpināšu meklēt vairāk informācijas, lai atrisinātu šo problēmu.