Keresés

Új hozzászólás Aktív témák

  • tocsa

    senior tag

    válasz Adi #46 üzenetére

    Sziasztok!

    ''Az Abit lapoknak van tudtommal híresen renegát BIOS-a, ami szereti az összes PCI eszközt egy IRQ-ra rakni.''

    Ezt cáfolhatom eddigi tapasztalataim alapján. Személyesen van egy ZM6-om, ill. egy BP6-om. Ezek mindegyike jól meghatározott módon sharel PCI slot-okat (AGP sharel a mellette levő PCI-al, a 3-as PCI az USB-vel, es az alsó kettoőPCI egymással). A BIOS persze Non-PnP OS-en van, tehat ő elrendez mindenkit a BIOS boot procedure alatt. Ami a problémát okozza (legalábbis Win2K alatt) az a Win2K ACPI HAL.

    Amitől föláll a szőr a hátamon azok az Intel alaplapok BIOS-ai. Mégcsak véletlenül se Del gombbal lépsz be! F2. Az igen. Vagy yesname gépeknek szokott még egzotikus BIOS-a lenni. Abit BIOS tök jó, jól érthető, minden állítható, látható.

    ''Ha egy egyszerű, APIC nélküli lapon 4-nél több PCI slot van (az AGP is annak számít!), akkor mindenképpen lesz IRQ-ütközés.''

    Itt majdnem egyet értünk. De nem az APIC-tól függ a dolog. Szerintem kevés Pentiumos chipkészlet van, amiben nincs APIC. Inkább a PCI buszok számától függ. És nem szerver alaplapokon nem szokott 1 PCI busznál több lenni. Na _ekkor_ (tehát az esetek többségében) ütköznek a PCI slotok.

    ''Viszont az alapból egy IRQ-n osztozó eszközök a felpakolás után is osztoztak az IRQ-n. A probléma a PC architektúra őskorból származó IRQ-vezérlőiből ered és nem a BIOS-ok vagy a Linux az oka.''

    Így igaz. Így igaz.

    ''Az mga_vid-nek ne örülj annyira, kiszedtem. Ahogy észrevettem, nem SMP-safe és csontmerevre fagyasztotta párszor a gépemet.''

    Határozottan cáfolom. Régóta mplayer-ezek. Az említett Abit BP6-ban dual 333-as cerkával 2.2.19-es, 2,4,7-es, és jelenleg 2.4.19-es (pre4-ac3) SMP-s kernelekkel is tudom használni az mplayert mga_vid-el Matrox G200-al. Királyul megy. Pont ma néztünk tesómmal filmet, és lepetéztem, hogy -vo ffdivx dekóderrel vitte a gép a 320x240-es filmet _full_ postprocessinggel (értsd: x és y irányú deblocking és deringing mind chroma, mind luma tartományban, auto brightness controllal).
    Szóval azonnal rakd vissza az mga_vid-et! :)))))

    ''A PC timer 18Hz-es frekijét meg rosszul tudod. Emlékeim szerint valami 1,9MHz-es kvarcon volt eredetileg és a 18,3Hz úgy jött ki, hogy a legnagyobb leosztást használták. Tehát tud ennél sűrűbben is IRQ-t nyomni, amit tesz is - hiszen x86 platformon a Linux ütemező 100Hz-es megszakítást használ.''

    Öööö. Valóban. Elnézést a téves infó miatt. Egyébként az APIC timer-e a CLK-ra van kötve (ami valószínűleg az FSB-t jelenti).

    ''ReiserFS-t meg nem szívesen használnék, mert
    1) még mindig olvasok róla híreket, hogy gáz lehet vele
    ...
    Tudom, hogy sok kicsi file-nál rettentő gyors''

    Kár. Én csak jót mondhatok. Ma fagyott a kernel, mert próbálgatjuk a packet writert (CD-RW UDF írás) és sajna fagyott a kernel. De rebootnál tök gyorsan reply-olta a logokat, mindössze 3 truncated transaction volt. A fagyás a mi hibánk, túl van patch-elve a kernel, a cdrom részekbe nyúlt bele timeout szempontjából az ac3, a cdrom, az udf, a packet patch is.

    ReiserFS-hez pedig még lennének tippjeim. Pl. -noatime-al mountolva gyorsabb lesz. Csak ilyenkor access time-ot használó programok (pl. mutt) tévedhetnek. Én fenyőfát (pine) használok.

    Később azonban mi is áttérünk ext3-ra. Főleg azért, mert lehet ext2-ként is mountolni.

    Üdv!

  • tocsa

    senior tag

    válasz Adi #22 üzenetére

    Bocsánat még egy észrevétel a dmesg logból:

    ''Matrox MGA G200/G400/G450 YUV Video interface v2.01 (c) Aaron Holtzman & A'rpi
    mga_vid: Found MGA G400/G450
    mga_vid: MMIO at 0xd285f000 IRQ: 11 framebuffer: 0xF8000000
    mga_vid: OPTION word: 0x40141560 mem: 0x05 SDRAM
    mga_vid: hard-coded RAMSIZE is 32 MB
    syncfb (mga): IRQ disabled in mga_vid.c''

    Yeeeaaah. mplayer rullz.

    Üdv!

  • tocsa

    senior tag

    válasz tocsa #36 üzenetére

    Elnézést minden ''fórumni vágyó''-tól az előbbi monstre hozzászólások miatt. Mint észrevehető, szájmenésem volt.

    Azért remélem konstruktív voltam (legalábbis úgy álltam a dologhoz).

  • tocsa

    senior tag

    válasz Adi #22 üzenetére

    Part 2.

    Lássuk az APM-et:

    [I] Advanced Power Management BIOS support
    CONFIG_APM:

    ...
    If you select Y here, you can disable actual use of the APM BIOS by passing the apm=off option to the kernel at boot time.

    Note that the APM support is almost completely disabled for machines with more than one CPU.
    ...
    Generally, if you dont have a battery in your machine, there isnt much point in using this driver and you should say N. If you get random kernel OOPSes or reboots that dont seem to be related to anything, try disabling/enabling this option (or disabling/enabling APM in your BIOS). [/i]

    Random kernel OOPS-ot tapasztalhatunk egyes esetekben. Mit tehetünk?

    I Some other things you should try when experiencing seemingly random,
    ''weird'' problems:
    ...
    6) make sure that the CPU is not over clocked.
    ...
    9) install a fan for the video card or exchange video RAM
    10) install a better fan for the CPU
    11) exchange RAM chips
    ... /I

    Magyarul overclock-olt rendszernél nem tanácsos. A 14-es linux chiptárban a 20 oldalas kernel konfig cikkben (amiben 2.2-es kernelt konfigolnak) azt tapasztalták, hogy az APM funkciók közül az ''Enable PM at boot time'' és a PM Shutdown opciók biztonságosak. A többit instabilnak találták.

    Látható, hogy az APM-et nem tartják annyira biztonságosnak, hogy SMP rendszer esetén aktív legyen. Az ACPI egy újabb dolog, a linux kernelben még ennél is újabban jelent meg, ebből már követeztethetünk a válaszomra. De nézzük mit mond a help.

    I ACPI support
    CONFIG_ACPI:

    ACPI/OSPM support for Linux is currently under development. As such, this support is preliminary and EXPERIMENTAL. Configuring ACPI support enables kernel interfaces that allow higher level software (OSPM) to manipulate ACPI defined hardware and software interfaces, including the evaluation of ACPI control methods. If unsure, choose N here. Note, this option will enlarge your kernel by about 120K.
    .../I
    No comment...de egyébként is, 120K-val megnövelné a kernel méretét :))). És még valami:
    ...
    I This code DOES NOT currently provide a complete OSPM implementation -- it has not yet reached APM's level of functionality. When fully implemented, Linux ACPI/OSPM will provide a more robust functional replacement for legacy configuration and power management interfaces, including the Plug-and-Play BIOS specification (PnP BIOS), the Multi-Processor Specification (MPS), and the Advanced Power Management specification (APM).
    .../I
    Én azt mondom: attól mentsen meg minket az ég, hogy mindent az ACPI rendez el, és én nem szólhatok bele.

    I Character devices
    <*> Enhanced Real Time Clock Support
    CONFIG_RTC:

    If you say Y here and create a character special file /dev/rtc with major number 10 and minor number 135 using mknod (''man mknod''), you will get access to the real time clock (or hardware clock) built into your computer.

    Every PC has such a clock built in. It can be used to generate signals from as low as 1Hz up to 8192Hz, and can also be used as a 24 hour alarm. It reports status information via the file /proc/driver/rtc and its behaviour is set by various ioctls on /dev/rtc. /I

    Az APIC tulajdonképpen az i82489 chip, mely a korábbi i8259 interrput vezérlőket (PIC) váltja fel. Természetesen az APIC képes úgy viselkedni, mint egy régi PIC, bootnál ezt emulálja (PIC mode). A PC rendszereknek a nagy rákfenéje az Interrupt rendszere, ebben biztosan egyet értünk. Két szintű interrput rendszer (NMI és IRQ). Nagyon kevés az IRQ, számszerint 15 darab. De ebből a 2-es a cascade (amivel az egyik PIC a másikra csatlakozik, régen XT-kben ugyanis csak 8 IRQ volt), meg egy csomó IRQ foglalt alapban. Ezt a helyzetet próbálja javítani az APIC. 16-nál jóval több IRQ-t kezelhet, ha nem PIC módban fut, hanem Virtual Wire vagy Symmetric IO módban. Az utóbbi csak high-end PC-ken bukkanhat fel szerintem, a kernel bootból is látszik, hogy Virtual Wire módba megy a kernel.
    Az APIC segítségével valósulhat csak meg az MP működés, tudniillik az IRQ-k lekezelését el kell osztani a procik között és ez csak HW támogatással sikerülhet. Az i82489-nél ez elég jól, dinamikusan van megoldva. A prociknak kell tudni egymásnak IRQ-t küldeni, ez az IPI (Inter Processzor Interrupt). Ezeket mind-mind témogatja az APIC. Minden processzorban található egyébként egy APIC, és ezen kívül még a chipsetben is van belőle. (Egy vagy több, attól függően, hogy hány busz van, pl. több PCI busz esetén midegyikhez van egy-egy. Tipikus mondjuk, hogy 2*4 db PCI slot van a server alaplapon, két darab PCI buszra elosztva.) A chipsetben lévőket IO-APIC-ként tünteti fel a kernel.
    Egy rákfenéje a régi PIC-nek, hogy alacsony felbontású az timer-e. 18Hz-es ugye a timer interrupt felbontása. Az APIC-ba került a régi timer-en kívül egy jóval nagyobb felbontású is. Valószínűleg az Enhanced Real Time clock opció ezt használja fel.

    I If you run Linux on a multiprocessor machine and said Y to ''Symmetric Multi Processing'' above, you should say Y here to read and set the RTC in an SMP compatible fashion. /I

    Csak az a kérdés, hogy ez a konfig opció mindössze erről a /dev/rtc és /proc/driver/rtc-ről, illetve annak kezeléséről szól-e, vagy más ettől viszonylag független, de az i82489-es high performance interval timer-ével kapcsolatos kódot is aktivál. Ahhoz kevés vagyok, hogy ezt megmondjam, de bele szoktam fordítani, egyrészt mert ezt ajánlják, másrészt meg nem lesz bajom tőle, ha ott van parlagon ez a két fájl.

    Adi írta: ''Ennek tükrében most már megértheti bárki, hogy miért nem nevezhettem ezt a deszkát stabilnak...''

    Én azt mondom: ennek tükrében ne jelentsük ki egy deszkáról hogy instabil. Ez csak fokozza az a tévhiedelmet, miszerint az AMD-s rendszerek instabilak. Egyes emberek ezt vallják sajnos. Nem említek neveket.

    Egy tipp a köv. csoportos SMP teszthez: ReiserFS gyorsabb, mint az ext3, ext2, ez nagyon jól kijönne kernelfordításkor.

    Üdv!

  • tocsa

    senior tag

    válasz Adi #22 üzenetére

    Part 1.

    Kíváncsi lennék mások tapasztalataira is SMP-s rendszerek és a linux használatakor.

    Most Adi üzenetére reagálnék.
    Előző hozzászólásomban nem mondtam, hogy általában tetszett a kernel konfigurációd. Okosan voltak elhelyezve a megfelelő dolgok modulba. Nagyrészt az én szájam íze szerint csináltad.

    Az IRQ ütközésről. Sajnálatos, hogy BIOS MP v1.4-el nem bootolt be a kernel. És azt mondod, hogy IRQ rerouting az v1.1-esnél még nincs. De ettől függetlenül még lehetséges, hogy el lehetett volna osztani az IRQ-kat úgy hogy ne ütközzenek. Ez valószínűleg az ACPI miatt nem sikerült neked. Ugyanis ha az aktív, akkor még kártya cserével sem (sőt, ha a BIOS-ban direkt meg lehet adni a PIRQ-kat, akkor azzal sem) lehet lebeszélni az ACPI-t hogy egy adott eszközhöz egy adott IRQ-t rendeljen. Ez személyes tapasztalat.
    Egyébként valaki mondta itt, hogy BIOS frissítéssel már megy az MP v1.4.

    Most egyszerre szeretnék beszélni az SMP az APM és az ACPI ről. Előljáróban csak annyit, hogy az APM kizárólag Power Management funkciókkal foglalkozik, míg az ACPI minden Hardware Management kérdéssel: power managementen kívül erőforráslefoglalással (mint pl. IRQ elosztás), hardver monitoringgal, stb. Sajnos én az a típus vagyok, aki szereti befolyásolni, esetleg maga meghatározni a dolgok működését. Ezért az ACPI-től feláll a szőr a hátamon. Sajnos az ACPI-vel és az APM-mel is az a nagy gond, hogy nemcsak az operációs rendszer szoftverhibáinak van kitéve, hanem a BIOS szoftver hibáinak is, fokozott módon. Nem is beszélve a hardver implementációs bugokról.

    Lehet, hogy majd indítok egy külön topic-ot, amely a Win2000 operációs rendszer és az ACPI kapcsolatával foglalkozik. Te is használtál már Win2K-t és minden a 9-es IRQ-n van a hangkártya+hálókártya+VGA kártya+... ? Nem is tudod állítani az IRQ-kat, mint Win9x-ben? Én is így jártam. Ez azért van, mert a Win2K alapban ACPI HAL (hardware abstraction layer) kernelt rak fel. A topicban majd leírom, hogy pontosan miről is beszélek, és hogy hogyan lehet ''Standard PC HAL''-os kernellel felrakni a Win2K-t, hogy ne sharel-jen mindent kétpofára, és tudjad állítani a dolgokat.

    Na de mi a helyzet a linux kernellel SMP-ben? Nem kellett sokáig keresgélnem. Elővettem a kernel konfig help-et. Részleteket fogok ebből közölni. Tehát először is bekapcsoljuk az SMP-t:

    [I]Processor type and features
    [*] Symmetric multi-processing support
    CONFIG_SMP:

    ...
    People using multiprocessor machines who say Y here should also say Y to ''Enhanced Real Time Clock Support'', below. The ''Advanced Power Management'' code will be disabled if you say Y here.
    ...[/I]

    Aha. Nézelődjünk tovább. Mi a helyzet a PM-el? APM esetén már látjuk az előző üzenetből: ha befordítjuk a kernelbe, akkor sem fog aktiválódni SMP esetén ez a feature.

    [I]General setup
    [*] Power Management support
    CONFIG_PM:

    ''Power Management'' means that parts of your computer are shut off or put into a power conserving ''sleep'' mode if they are not being used. There are two competing standards for doing this: APM and ACPI. If you want to use either one, say Y here and then also to the requisite support below.
    ...
    Note that, even if you say N here, Linux on the x86 architecture will issue the hlt instruction if nothing is to be done, thereby sending the processor to sleep and saving power.
    ...[/I]

    Offtopic korrekció. Ha nem csinál semmit éppen a proci, akkor az ún. idle kernel threadet futtatja. Non-SMP kernel esetén ez valóban HLT utasításokból áll. Ez két okból fontos: mert egyrészt pihen a hardware, másrészt az APM BIOS innen érzékeli, hogy a rendszer nyugalomban van, lehet teljesítményt csökkenteni, laptopoknál ez nagyon fontos.
    SMP kernel esetén azonban egy HLT loopban processzor folyamatosan kernel módban futna és a spinlock-ot lefogva tartaná, ez deadlock-hoz vezetne. Ezt úgy oldották meg (legalábbis régebben), hogy SMP esetén aprocesszorok idle thread-je folyamatos reschedule-inget végez, és visszatér user módba. Ezért pl. laptopokon (uniprocesszoros rendszerekhez) kifejezetten nem érdemes SMP kernelt futtatni. A kernel ezen része lehet hogy fejlődött, majd megnézem.

  • tocsa

    senior tag

    válasz Adi #26 üzenetére

    Hi!

    ''A GCC-ben meg meg merek bízni, mert ha eddig nekem kernelfordításnál hasalt, arról minden esetben kiderült, hogy valami hardware-probléma volt.''

    Azért vigyázz mert vannak kivételek. Ez alatt a RedHat által elcseszett 2.96-os, meg 3.0-ás GCC-t értem. Azokkal nehogy valaha is fordíts bármit. Ha még nem hallotál erről, akkor STFN. Illetve használjunk Debiant.

    Üdv!

  • tocsa

    senior tag

    válasz Adi #2 üzenetére

    Sziasztok!

    Először is csodálatomat szeretném kifejezni a tesztelt rendszerrel kapcsolatban. Nekem eszméletlen bejött: Athlon, MP, G400, ...
    Jó fejek vagytok a prohardvernél!

    Adi írta:
    ''Szerintem Asus v. egyedi hiba lesz''

    Nem kell egyből a hardverre gyanakodni. Nézegetemn itt a kernel konfigot.

    1. Miért kell egy ilyen gépbe ACPI? Régebben nem nagyon ajánlottak semmiféle Power Management funkciót SMP több processzroros rendszerekhez. Biztos, hogy már stabilabb ez a része a kernelnek, de én akkor sem tenném be SMP kernelbe, rendszerbe.

    megj.: vigyázat! ACPI (Advanced Configuration and Power management Interface) != APIC (Advanced Programmable Interrupt Controller) != APM (Advanced Power Management)...

    2. Azonos IRQ-n van a hálókártya és a SCSI kártya. Pedig lenne elég IRQ a gépben, pláne, hogy APIC enabled rendszerben tud assign-olni a kernel 16, 17, 18, ... IRQ-ra dolgokat. Szóval ezt nem kellett volna, hanyag dolognak minősítem. Lehet, hogy voltak más ütközések is. Ez az ACPI hibája lehet talán. Szeretnék látni egy 'cat /proc/interrupts'-ot, 'cat /proc/dma'-t.

    3. Nem tudom kibogarászni a kernel konfigból fejből, de nagyon remélem, hogy az Enhanced Real-Time Clock be van forgatva a kernelbe.

    4. A RAM-ok stabilitásáról: ha memtest86 nem jelez velük hibát a beállított körülmények között, akkor azok stabilaknak mondhatók. Pont.

    Első olvasatra ennyit vettem észre. Megnézem majd még 1x, meg tesómmal is, több szem többet lát.

    Amíg ezeket a dolgokat nem fixelitek, addig szerintem nem érdemes a rendszer (ezáltal az alaplap) stabilitásáról bármiféle kijelentést tenni. Még annyi kijelentést se, hogy nem érdemes kijelentést tenni.

    Üdv!

Új hozzászólás Aktív témák

Hirdetés