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

• #47 tocsa senior tag Adi #46

  Új Válasz 2002-04-14 00:24:11 #47

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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!
  

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