HtibiA legfrissebb kernellel (3.1) sem megy, csak a 2.6.x-ekkel. Egyébként igen, teljesen igazad van fölösleges IDE (na jó ez gonosz volt sry) :D többször leírni. ;-) ma jelentem launchpadon a "hibát" aztán javításig, vagy LTS-ig mard a Debian. Ott ugyanezzel a kernellel tökéletesen működik a rendszer. Elnézést kérek ha egy picit ingerült vagyok/voltam, de mást nem olvasok itt az oldalon mint: "hogy nem frissül a rendszer mi lehet a gond" holott már 100000-szer le lett írja a megoldás persze rá sem keres, én meg a rendszer legmélységesebb bugyrából rántom elő a lehető legtöbb információt, csak hogy rájöjjek miért is nem használhatom majd a legfrissebb kiadást.

      AlucardA Debianon 3-as kernellel megy? Ha valami nem hajlandó működni, akkor az ember minimum ingerültebb, mint máskor. Ezzel semmi gond. Szintén "örülök" mikor látom az általad is emlegetett frissítési gondot, átlépek rajtuk (akad mindig egy válaszoló :-) ). Most én leszek gonosz. Első alkalommal, mikor itt elsírtad, és nem kaptál választ, de még ötletet se, már kellett volna "bugjelentsél". Nekem is omladozott eleget, mindent nem jelentettem, meg sokszor (legtöbbször :-) ) mások gyorsabbak voltak, csak ismételni tudtam volna.

        Ennyivel később: 14 nap

        uname -r | 3.1.0-030100-generic | több szálas feldolgozás (HT) viszont továbbra sincs... :-/ Launchpad-en már van riport, (Kernel 3.0) de állítólag ez upstream bug, és a bugzilla.kernel.org-on kellene jelenteni a problémát, de sajnos nem tölti be az oldalt... Most kíváncsiságból megpróbálom 2.6.39-el, mivel 2.6.38 alatt még működött.

          AlucardA "bugzilla.kernel.org" mellett azt írja, hogy csak a 2.6-os kernelbajokkal foglalkozik. Currently this is for reporting kernel version 2.6 bugs only Viszont stabilan nem tölt be. :-)

              Bocsi, hol és mit kell nézni, hogy nálam működik-e?

              HtibiŐ pedig 404: http://www.kernel.org/pub/linux/docs/lkml/reporting-bugs.html Nos akkor hol is kellene jelentenem ezt a bitang nagy BUG-ot? :-)

                  AlucardLáttam ezt is. :-( Ha jól emlékszem, a nyár végén volt valami probléma (feltörték a kernel.org szervereit), és sokáig le volt állítva. Lehet, hogy még mindig nem sikerült mindent kipofozni. De egyébként fogalmam sincs.

                    Na közben fordul a 2.6.38.8-as kernel... arra gondoltam összehasonlítom egy még működő kernel konfigját, az utána közvetlen kiadott nem működőével. Este megírom mire jutottam. Kis helyesbítés: Korábban azt írtam, hogy a 2.6.x sorozattal még nem volt probléma. Nos ez nem igaz, mint kiderült a 2.6.39-essel sincs több szálas feldolgozás!

                    Introduction Modern advances in system architectures have introduced advanced error reporting and correction capabilities in processors. CPU architectures permit partitioning support, where compute resources of a single CPU could be made available to virtual machine environments. There are couple OEMS that support NUMA hardware which are hot pluggable as well, where physical node insertion and removal require support for CPU hotplug. Such advances require CPUs available to a kernel to be removed either for provisioning reasons, or for RAS purposes to keep an offending CPU off system execution path. Hence the need for CPU hotplug support in the Linux kernel. A more novel use of CPU-hotplug support is its use today in suspend resume support for SMP. Dual-core and HT support makes even a laptop run SMP kernels which didn't support these methods. SMP support for suspend/resume is a work in progress. General Stuff about CPU Hotplug

                    Ennyivel később: 3 hónap

                    Újra elővettem a témát mivel azóta többen is tapasztalták a problémát, készültek reportok és kiadtak egy patch-et is. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/874436 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/876359 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/807164 Ami már biztos: A szokásos kernel paraméterek, (acpi=ht, pci=noacpi, acpi=noirq, pnpacpi=off, noapic) 2.6.39+ kernel verziók, forgatások nem értek semmit. A kernel panic elkerülhető egy egyszerű BIOS HT disabled-re állítással is, így persze kapsz egy működő rendszert, de ez félmegoldás, mivel a CPU csak egy szálon fog üzemelni. Elég sokat kutakodtam a témában, így "nemhivatalos" források arra engednek következtetni, hogy a 8xx chipkészlet már túl régi ahhoz, hogy továbbra is helyet kapjon a kernelben. Persze ez nem törvényszerű, mivel egyes esetekben (lásd Intel 875) működik. Egyelőre... Ez valahol rettentően bosszantó, de ha jobban belegondolok, végül is teljesen normális. De a minap... http://marc.info/?l=linux-kernel&m=132372776923731&w=2 ...szóval jött egy patch :-) Persze ehhez egy kis segítségre lesz szükségem, szóval ma este, de legkésőbb holnap kiderül működik-e a többszálas feldolgozás 8xx lapkakészlettettel és 2.6.39 feletti kernellel. ps.: A 3.2-es kernel sem támogatja a fentebb leírtakat! Kernel 

                    alucard@desktop:~$ uname -a
Linux desktop 3.2.0-030200-generic #201201042035 SMP Thu Jan 5 01:44:33 UTC 2012 i686 i686 i386 GNU/Linux
                    Processor 
                    alucard@desktop:~$ cat /proc/cpuinfo
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 15
model		: 3
model name	: Intel(R) Pentium(R) 4 CPU 3.00GHz
stepping	: 4
microcode	: 0x14
cpu MHz		: 2992.534
cache size	: 1024 KB
physical id	: 0
siblings	: 1
core id		: 0
cpu cores	: 1
apicid		: 0
initial apicid	: 0
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe constant_tsc up pebs bts pni dtes64 monitor ds_cpl cid xtpr
bogomips	: 5985.06
clflush size	: 64
cache_alignment	: 128
address sizes	: 36 bits physical, 32 bits virtual
power management:

                      Ennyivel később: 2 hónap

                      AlucardNekem is ez a problémám van, egészen 3.3-as kernelig. Mivelhogy D865PERL alaplapom van. Így aztán egyetlen Ubunutu alapú disztró sem ment nekem, egészen addig amíg rá nem leltem a megoldásra: a rendszerindítási kernelparaméterek közé fel kell venni a "processor.nocst=1" paramétert. Ez a grub.cfg fájlban van, de valójában az /etc/default/grub fájlt kell szerkeszteni, abban is az GRUB_CMDLINE_LINUX_DEFAULT részt. Nekem így fest: GRUB_CMDLINE_LINUX_DEFAULT="processor.nocst=1". Ha ez megvan, menteni kell a fájlt, majd kiadni az update-grub parancsot, ami beépíti a grub.cfg-be, és megcsinálja a szokásos grubos dolgokat. Ezekután már be lehet kapcsolni a hyperthreading-et a BIOS-ban, és máris megy a linux-szekér.

                          konstantinKözben mint látod disztrót, DE-t váltottam, de azért köszi! :) Egyébként mind a két VT mag működik, vagy szimplán "csak" működik?

                              AlucardEgyébként te tudtál érzékelni teljesítményelőnyt HT-vel? Mert mi méricskéltünk sokat, főleg FPU-intenzív számításokkal (elvileg ebben jó a HT), és csak rontott a teljesítményen a bekapcsolása. (Persze ettől még bootolnia kéne :))

                                  maatNem méricskéltem, azt hittem növeli az átlagos teljesítményt, vagy legalábbis nem csökkenti.

                                    Ennyivel később: 4 hónap

                                    Mindezt tapasztaltam: jómagam egy általános felhasználó vagyok, de eddig két gépre nem tudtam telepíteni az új Ubuntu 12.04, illetve a Mint 13-at. ezeknek a kernele ugyebár a 3.2-es, és minden olyan rendszert kipróbáltam ami szintén tartalmazta a 3.2-est: ezek az Ubuntu UE 3.4, Magyarubi 12.07, és mindegyik esetében ugyanazok a telepítési hibák jelentkeztek, hogy vagy lefagyott, vagy el se indult, vagy be se fejezte a telepítést. Egyszóval használhatatlanok az új rendszerek. Viszont a korábbi Ubuntu 10.04.2, Mint 9, Kiwi Linux 10.08, Magyarubi 10.08, mindegyike a 2.6.32-es kernelt használja és azokkal ez idáig semmi baj nincs. Mivel olvastam hogy feltörték a kernel.org rendszerét, ezért az a gyanúm támadtt hogy a 3.2-es kernelekbe jól belepiszkálhattak, így használhatatlanná váltak. Az eddig felhasznált gépek: Minix M1200 - erre a Mint 13 MATE és Cinnamon ment fel, aminek a végeredménye hogy két nap után a MATE összeomlott, a Cinnamon pedig be fagyasztotta a gép merevlemezét. A másik egy eMachines E525 - azon semelyik se volt képes elstartolni, és amelyik véletlen elstartolt, akkor kialudt a kép telepítés közben, és a végén persze az is le is állt. Az ASUS P5KPL-AM EPU alaplapnál Pentium Dual Core E5400, 2 GB DDR2 mellet pedig ugyan elindult a Mint 13 MATE telepítés, és minden jól ment, de a telepítést NEM akarta befejezni.... Úgyhogy reset és végül visszakerült rá a Mint 9. Nem akarok más rendszert használni, mert ezekhez hozzászoktam, és nagyon hiányolnám őket, de ennek utána kellene néznie a kernel fejlesztőiknek....

                                    Ennyivel később: 10 év