Vcore: +1.66 V (min = +1.48 V, max = +1.70 V)
VccSRAM: +0.35 V (min = +0.29 V, max = +0.38 V)
+3,3V: +3.40 V (min = +3.22 V, max = +3.54 V)
+5V: +4.99 V (min = +4.77 V, max = +5.26 V)
+12V: +12.52 V (min = +11.62 V, max = +12.64 V)
-------
A táp stabilan tartja ezeket az értékeket - nincsenek gyanús zajok sem,
kivéve, ha a macska rohan be a kaszni mögé -, úgyhogy eltekintek az új táptól.
(az ezzel járó kockázatot vállalom.). - de ha a fesz-ek kilépnek a zónából az init 0 azért marad.
OK, mar csak a 12V agat kell figyelni. Ez meg barmilyen erdemenyt leszamitva magasabb erteken volt.
Legoptimalisabb lenne itt is:
~ 11.90V - 12V - 12.10V hatarokon belul mozogna. Ennel nagyobb elteres 12V> iranyban szvsz nem jelent akkora gondot, mint modjuk a 12.20< irany.
Nagyon hasznos volt (revision3) (kvázi megnyugtatott, és a BIOS-ról lm-sensorra nevelt)
a Vcore 1,6 1,7 közé esik. 1,7-et nevezi max.nak, úgyhogy
a BIOS kapcs utáni 1,72 érték (belépek a BIOSba, várok 5 percet, akkor is 1,72, init után
lm-sensors 1,65-1,66). a vccsram -0,5 + 0,5 intervallum is megnyugtatott.
és a segítségével normálisan be tudtam lőni a reakció határokat
a feszültségfigyelés során.
Na alighogy elküldtem máris beléptem init0-ba, úgyhogy
ezt kicsit tényleg szorosra vettem,
töröltem a felszorzást, és ráküldtem a CPU-ra átmenetileg
egy jó átlagosan 84%-os terhelést, és tényleg kilépett a mederből:
az 5V leesett 5,04-ről 4,97-4,99 közé, és ezeket váltogatta.
a 12V pedig fellépett 12,46 és 12,52 értékeket váltogatta.
A terhelési teszt során a CPU használat 30-70-85-99% között váltakozott rendkívül gyakran (forrás:top).
úgyhogy ennek megfelelően szélesítettem a sávot, mindazonáltal ez
nem tűnt egetverően ingadozásnak...márpedig 99%-nál nagyobb terhelést nemnagyon
tudok ráereszteni...-D
arányaiban a mostanihoz képest ua. nagyságrenű eltérés
esetén nyomna be ALARM-ot (=léptetne a figyelőscript init0-ba), mivel
felszorzásnál a reakcióhatárok is felszorzásra kerülnek .
persze lehet hogy túl szűkre vettem a határokat, majd kiderül
az első nem várt init0-nál...-DDD
Jo de ez kozben siman valtozhat, ingadozhat. A multkor mar emlitettem, hogy a terheles viszonyaban ezek aze ertekek,(beleertve a tapegyseg 'minoseget is') valtoznak. Pl:
BIOS: 12V: 11.86V
lm_sensors: 11.77V ; ez benne lehet a kalapban.
...
Ha mar lehet igy mondani, akkor inkabb mar az indulas utanni lm_sensors ertekek a "megbizhatobbak". Egyebkent BIOS..
CPU FAN:6250 RPM-----CPU FAN:6250 RPM
SYS FAN:0 RPM--------p/S FAN 0 RPM
CPU Temp:42,8--------SYS TEMP:42,8
NINCS----------------CPU Temp:146,2 mindig
(nemláccik9------------SBr Temp:23,x-24 °C
Úgyhogy emiatt szoroztam fel az lmsensor configban a kimenetet a BIOS-hoz (illetve ignoráltam a psfan-t, és a cputempet.
---------------
a min, max értéket kézzel állítottam be az lm-sensors konfigban, hogy mikor
riadóztasson, igyekeztem szűkre szabni. (=init 0-ba léptet a script)
A BIOSban ez mindig ennyi volt, és így nézett ki.
a 12,78-12,84 szokott változni, ill. a VccSRAM 3,46-3,47. a többi
stabilan tartja magát nemrég néztem vagy 5 percen keresztül...
az lm-sensor nem mért pontosan a multkor, úgyhogy
most felszoroztattam az lmsensor konfigban, mert sz'tem a BIOSnak van igaza.
van 2 képtelen érték ami miatt ezt megléptem, úgyhogy utánaállítottam a többit is:
1. 2,5V (ilyen szenzor a BIOSban nincs, de valszeg a VccSRAM akart lenni): 0,36V, v. 0,35V (???)
2. temp3 (csak 2 hőmérő van, nincs 3.!!!): fixen 146,2 °C mindig (fúziós reaktor van a szobában???, ez azért feltűnt volna)
írtam a multkor hogy az alaplapi szenzorok nem igazán szabványosak, ezekre
céloztam. tehát az lm-sensor simán 1,66V-ot mér , de eközben BIOS 1,72-t, a két mérés között a BIOS, és az első lm-sensor mérés között alig 1 perc eltérés volt, úgyhogy valaki "hazudik"...-DDD
Úgyhogy a végét felszoroztam, hogy a BIOS (=valóság)-t mutassa...
szorzások:
persze hagyhattam volna alapon is, és lejjebb venni a min. max. szűrőt, de
ha már mutat, akkor mutasson igazat, végül is ez kaszni, nem pedig a Parlament..:-DD
Nono, ez sajna mar kezd sok lenni(multkor valamennyivel kevesebb volt=min). Szerintem ovatosan kell ezt mar kezelni.
Vcore: +1.72 V (min = +1.66 V, max = +1.76 V)
Ez is emlekedett valamit. De talan a default 1.6V ertekbe meg beleferhet. Az ujabb Morgan magos Duron(SSE) -nal 1.5V.
cat /proc/cpuinfo|grep 'model' : ez mit mond?
A proci, alaplap homerseklet tokeletesnek mondhato.
2.4.25-pre6
...persze aki ilyen bátor (vagy inkább vakmerő?? :-DD... (korabbiakkal is 2.4.22,2.4.23 is ue. volt az apm kapcsan, ez szertintem nem ezen mulik)
es mi lesz a tesztelessel, az esetleges bugreport- al? Egyebkent szvsz stabilnak mondhato, pedig nem szokott uresjaratban menni, es meg van tuzdelve(ALSA 1.0.1, NVidia, grsec,..) egy kis kiegeszitovel. ide-scsi mar egy jo ideje nem tokeletes, de 'meg' elviselheto.
Egyebkent mar kint van a pre7.
De ez mar nem fog menni akkor, ha fixen ACPI "van" a kernelbe(igy tudod)
2.4.20asban asszem lehetett modulba az ACPI Bus Managert is tenni,
és az apm ettől teszi függővé, hogy (overriden by acpi), vagy sem.
egyébként olyan biosom van, amiben az acpi-t, és az apm-et is ki/be kapcsolgathatom.
acpi 1.0-t tud(na). (mivel ugye 2000-es az alaplap.)
2.4.25-pre6
...persze aki ilyen bátor (vagy inkább vakmerő?? :-DD...
de tényleg ez legyen a legnagyobb baj...:-DD
-----
más. nagy nehezen sikerült belőni a fesz. sensorokat, hogy
azt mutassa mint a BIOS. (persze a hőmérséklet figyelő script, néhányszor
beléptetett init 0-ba...:-DD, mire sikerült eltalálni a megfelelő felszorzásokat.)
via686a-isa-6000
Adapter: ISA adapter
Algorithm: ISA algorithm
Vcore: +1.72 V (min = +1.66 V, max = +1.76 V)
VccSRAM: +3.46 V (min = +3.17 V, max = +3.66 V)
+3,3V: +3.47 V (min = +3.42 V, max = +3.51 V)
+5V: +5.15 V (min = +5.07 V, max = +5.20 V)
+12V: +12.78 V (min = +12.66 V, max = +12.85 V)
Proc. Hűtő:
6136 RPM (min = 5000 RPM, div = 2)
Rendszer Hőmérséklet:
+41.9°C (limit = +57°C, hysteresis = +52°C)
Alaplap Hőmérséklet:
+23.3°C (limit = +29°C, hysteresis = +25°C)
Ez se biztos, végül is nem windowsról beszélünk, amit holmi acpi ki/bekapcs miatt
újra kell telepíteni... Meg szerencse..
betöltöd az apm modulokat, etc/init.d/apmd -vel indítasz insmod apm-el..
indul az X, majd indításkor
De ez mar nem fog menni akkor, ha fixen ACPI "van" a kernelbe(igy tudod): ACPI support ->ACPI support y , .... utanna lehet modulba (Button,...), akkor erthetoen, nem fogja betolteni az APM modult. acpi != apm
Klog:
apm: BIOS not found.
Jan 23 23:34:03 local insmod: /lib/modules/2.4.25-pre6/kernel/arch/i386/kernel/apm.o: init_module: No such device
Jan 23 23:34:03 local insmod: Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters. You may find more information in syslog or the output from dmesg
Jan 23 23:34:03 local insmod: /lib/modules/2.4.25-pre6/kernel/arch/i386/kernel/apm.o: insmod char-major-10-134 failed
De nem tudom, nalad lehet, hogy 'regebbi BIOS -rol' van szo..(?)
Egy regi(~1999) Acorp 5ALI61.
BIOS beallitasok:
...
Power Management: ...
PM Control by APM
es engedelyezheted az ACPI(ATX Power Supply Mode)
.. IRQ 9
:) bar nem "elegans",meg egy "kis" ganyolassal de megoldhato
megoldható, de amikor nekem tök jó az apm is, akkor minek
kínlódjak?
végül is annyit nyerek az acpival, hogy a kikapcsológombra
leállítja a gépet (vagy más egyebet, amit mondtak neki, pl. lejácca a WAV filet, hogy ne nyomogasd a kikapcs gombot te barom...-DD, ami aztán marha nagy kaland.)
apm legalább elküldi csicsikálni standby-re.
acpivel tudtommal ilyet nem lehet. -)))
Ez se biztos, végül is nem windowsról beszélünk, amit holmi acpi ki/bekapcs miatt
újra kell telepíteni...
betöltöd az apm modulokat, etc/init.d/apmd -vel indítasz insmod apm-el..
indul az X, majd indításkor
at +1min-el elindítasz egy scriptet, ami
---------
/etc/init.d/apmd stop
rmmod apm
modprobe ospm_..., ospm_...button..stb...(acpi modulokat tölti be)
/etc/init.d/acpid start
---------
ha az X már fut, elindult apm-el, akkor talán nem nyivákol, nem veszi észre ha átkapcsolsz.
hátha...menet közben simán lehet így kapcsolgatni apm/acpi között
mert próbáltam (de ha agyonütnek se tudom milyen kernellel
talán vmilyen javított debian 2.4.20, de nem biztos, hogy jól rémlik.)
illetve azt is lehet, hogy végtelen ciklusú script, és csak akkor
kapcsol át, ha mondjuk tartósan nincs bejelentkezve
user...
Szerintem ezt X build elott lehetne valahol rakeresni, es a megfelelo modositasokkal forditani.
az hiányozna, az egész rendszer föl kéne burítanom hozzá, ha most
elkezdeném forrásból fordigatni, aztán majd anyáznék
apt-get dist-upgrade-nél (mer addigra már elfelejteném hogy ilyen szinten barmoltam bele a rencerbe...-))) (debian woody van most).
az Xnek egyébként van még egy hülyesége. (Open APM Failed), ha nem fut
az apmd daemon. érdekes hogy acpi-vel nem megy együtt az X, akkor is az apmet hiányolja.ez is (WW) szintű jelenség.
Igen, ezt mar tapasztaltam (es mar regota tart a jelenseg),es raadasul kb. 4.2(1?) XFree ota van.
(WW) Open APM failed (/dev/apm_bios) (No such device)
Szerintem ezt X build elott lehetne valahol rakeresni, es a megfelelo modositasokkal forditani.
Mert egyeb modon torteno manipulalassal tudtommal (pl. XF86Config-4) nem tudod megszuntetni.De kulonosebb problemat nem okoz, egy kis bug.
OFF:
NVidia hasznalatkor meg nem fordult elo effele gond. nvidia,agpgart modulban es kezeli az X(persze a megfelelo konfig utan). Es ezt lehet ellenorizni: cat /proc/driver/nvidia/agp/card (a graf. kartya altal tamogatott modok) ill. ../status (engedelyezett modok)...
ez erdekes. mar tobb helyen hallottam effele 'hiba'jelensegrol. meg (eddig) nem fordult ilyen elo, az agpgart -ot folyamatosan modulkent hasznalom. persze a megfelelo alias -ok hasznalataval, update-modules
nem itt van a gond, be is tölti (én is így használtam) a linux a modult.
Az X nem képes kezelni modulként, és "PCImódban" indul el.
hiába PCI:1:0.0-t adsz meg, és hiába vana modul betöltve, akkor sem ismeri fel.
hiába töltöd be még jóval az X indítása elött, akkor sem kezeli az X.
ha kernelben van, akkor sima ügy, mindig agp-ként kezeli.. a jelenség (WW) szintű.
fbHWdevakarmi r128.0 unresolved az Xfreelogban, és nem viccel, mert a kde is összerongyolja magát átlag úgy 2hetente egyszer (error 11 asszem). Ez valami module utkozes is okozhatja.
egyértelműen az aty128fb-t hiányolja, ha beforgatod, akkor
ezzel sincs baja,ha kiveszed, megint hiányolja, persze az r128 X device drivert (fbdev true)-val kell indítani.
itt valszeg az X r128.o drivere sáros egy kicsit. mindenesetre még (WW)-nek sem minősíti a log. és tényleg ritkán borul össze nélküle a kde errorr 11el.
persze ha beteszed, akkor lemondhatsz az svgalibről, sz'al valamit valamiért alapon működik. (bár az is igaz, hogy ahol X van, ott svgalib gyak. nem igazán kell, és fordítva)
az Xnek egyébként van még egy hülyesége. (Open APM Failed), ha nem fut
az apmd daemon. érdekes hogy acpi-vel nem megy együtt az X, akkor is az apmet hiányolja.ez is (WW) szintű jelenség.
nemigen, mert a mostaniban az EAPIC megint benne van, és most nincs semmi baja. -)
a 2.4.18-asban pedig még nincs machine check.
Igen abban meg nincs.
a kernelben levőnél. nincs gond vele, de nem szereti ha modulban van, és azt sem szereti, ha az agpgart van modulban, mert akkor az X nem mindig tölti be.
ez erdekes. mar tobb helyen hallottam effele 'hiba'jelensegrol. meg (eddig) nem fordult ilyen elo, az agpgart -ot folyamatosan modulkent hasznalom. persze a megfelelo alias -ok hasznalataval, update-modules
fbHWdevakarmi r128.0 unresolved az Xfreelogban, és nem viccel, mert a kde is összerongyolja magát átlag úgy 2hetente egyszer (error 11 asszem).
Ez valami module utkozes is okozhatja.
Tehat osszessegeben ugy tunik nem valami tokeletes.. De az ATI driver -i amugy sem voltak mindig (sajnos) a helyzet magaslatan.
Lehet hogy "a kernel hacking szekció" hiányzott neki, vagy a PnP OS No-t szereti, vagy a modemet nem bírta a hálókártyával, vagy ezek így együtt.
ez jogos; es egyebkent mennyire stabilak mostansag az ATI DRI driver-ek?
a kernelben levőt használom, egyszer régebben megpróbáltam
feltenni egy újabbat, de az X állandóan hanyattvágta magát és a hibaüzenet is annyira
videókártya spec. volt, hogy inkább maradtam
a kernelben levőnél. nincs gond vele, de nem szereti ha modulban van, és azt sem szereti, ha az agpgart van modulban, mert akkor az X nem mindig tölti be.
A framebufferr-el (experimental) már több a baj. egyszerűen konzolról
a nem lehet lekapcsolni a képernyőt se powerdown, se off, se semmi,
hiába állítod be setterm-el - nem kapcsol le framebuffernél.
a készenlétre (blank) még átkapcsol, de ki már nem.
apm -S is jó vicc, kinyomja a gépet standbyre csicsikálni,
de a képernyőt nem tudja lekapcsolni. (ezért kellett a scriptben trükközni, megvárni
amíg a képernyőt az X lekapcsolja, aztán nyomja ki apm -S-re, és mindenki jóllakik)
na meg persze nem is beszélve, arról, hogy az svgalib hogy néz ki vele konzolon.
a dosemu-ból próbáltam, lekicsinyítette az "anyagot" a felére minden svgalibes cucc, és a fennmaradó szabad képernyőre szépen kiírta ugyanazt mégeccer...
Úgyhogy fasza kettőslátás, de baromi röhelyes volt.
szóval nem véletlen experimental,hanem tényleg az.
viszont az X nyammog érte, főleg a kde.
fbHWdevakarmi r128.0 unresolved az Xfreelogban, és nem viccel, mert a kde is összerongyolja magát átlag úgy 2hetente egyszer (error 11 asszem).
X alatt viszont lekapcsolja rendesen a képernyőt az XF86Configban található beállításnak megfelelően.
és persze a aty128fb sem szeret modulban.
ez reszben magyarazatot is adhat a dologra
nemigen, mert a mostaniban az EAPIC megint benne van, és most nincs semmi baja. -)
a 2.4.18-asban pedig még nincs machine check.
cirka 4-5 éves lehet a táp.1 cd író van+1 vinyó, de írás közben még nem volt gond sohasem
ez ugyan nem nagy terheles, de a tapra szerintem azert nem arthat odafigyelni
kosz, hasznos ez.
meg 1-2 dolog(de remeljuk nem kell):
ezt már én is próbáltam, meg az E-APIC kilövését is,de nem használt, bár a random
freeze-ek ritkultak. kihúzta az első 24 órát uptimere, aztán megdöglött.
ez reszben magyarazatot is adhat a dologra
cirka 4-5 éves lehet a táp.1 cd író van+1 vinyó, de írás közben még nem volt gond sohasem
ez ugyan nem nagy terheles, de a tapra szerintem azert nem arthat odafigyelni
de sajna a 4.es Xfree,meg a vidókártyám megkívánja
ati rage128pro, úgyhogy nem mehetek el mellette.
ez jogos; es egyebkent mennyire stabilak mostansag az ATI DRI driver-ek?
