A tesztkeretrendszer az fwts névre hallgat és jelenleg több mint 30 tesztet foglal magában. A fejlesztő azt tervezi, hogy bővíteni fogja a tesztek számát minden egyes alkalommal, ha újabb firmware hibába ütközik és arra a hibára lehetséges automatizált tesztet írni.
A tesztek futtathatók kötegelve, de egyes tesztek interaktív közreműködést igényelnek. A fwts-t a fejlesztő a Maverick 2.6.35-ös kerneléhez szánta, de szerinte működnie kellene szépen a Lucid kernelével is.
OS nélküli gépek teszteléséhez a tool futtatható akár egy bootolható USB pendrive-ról is.
Az eszköz PPA tárolójának elérhetősége, egyéb információk stb. megtalálhatók itt.
- A hozzászóláshoz be kell jelentkezni
- 3151 megtekintés
Hozzászólások
Javaslom azoknak, akiknek problémájuk van például a suspend-del és még sosem hallottak arról, hogy a bugos BIOS fura, másoknál nem jelentkező hibákat tud okozni. Bár, mintha már ezt említettem volna.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
ha tudnátok, hogy mennyi hardveres tervezési hibát workaroundolnak firmware-ből, mély kussolással...amik persze később összeakadnak egy másik alkatrész workaroundjával...
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
- A hozzászóláshoz be kell jelentkezni
Miért nem gondolt erre valaki hamarabb? :) Ez egy hasznos eszköz lesz.. De ez programozóknak jön jól, vagy usereknek?
- A hozzászóláshoz be kell jelentkezni
Is-is. Felhasználóknak is jól jöhet, ha bugot jelentenek be és információkkal akarnak szolgálni a bugreport-hoz.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Jó dolog. Felírtam a jegyzeteim közé, hogy a következő gép vásárláskor
ne felejtsem el.
A mostani gépem:
description: Motherboard
product: DG43NB
vendor: Intel Corporation
Bezzeg n+1 (min 10) bios upgrade után sem hajlandó a suspendre.
- A hozzászóláshoz be kell jelentkezni
Nem feltétlen bugos BIOS-tól nem megy. Ez csak az egyik ok lehet. Ha rákeresve az interneten azt látod, hogy másnak ugyanez a lap működik, akkor joggal kezdhetsz el gyanakodni arra, hogy a BIOS a ludas.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Ha a kedvenc rokonommal találkozom, akkor kipróbálom az Albacomp notebookján. Bár a hibajelentésnek nem sok értelme lesz, mert a BIOS frissítés nem divat az Albacompnál.
-----
"Fontosabb egy jó szomszéd, mint egy távoli rokon." (Árvízkárosult, 2010)
- A hozzászóláshoz be kell jelentkezni
Keress frissítést a Clevo-hoz, a matricázást nem feltétlenül követi hazánkban a support tevékenység is.
- A hozzászóláshoz be kell jelentkezni
A Clevonál dettó..
Nekem úgy indul a linux hogy már boot legelején pampogás van a hibás bios miatt. Bios persze sehol se nincs :(
- A hozzászóláshoz be kell jelentkezni
Értem én hogy gőzgép, csak nem tom mi hajcsa...
test lefuttat -> kiderül a BIOS a ludas... és???? Én csóró lúzer ráveszem a gyártót hogy frissítsen? Persze... és akkor felébredek mert a bilibe lóg a kezem. Arra jó hogy megtudhassam de akkoris csak a gyártóban reménykedhetek... A frissítést meg már rég feltettem magamtól is...
Rövid sor: Dell, Asus, Fusi... na ezekhez 1 év után az életben sem láttam bios frissítést vagy éppen soha... ellenben láttam win patch-et ami megoldotta win-en a problámát. Pl a Dellnél divat 4 év után is nyugdíjba küldeni a gépet A01-es bios-szal.
- A hozzászóláshoz be kell jelentkezni
Az hajtsa, hogy bugos BIOS-okra lehet workaround-ot írni, ha nagyon gáz, akkor lehet blacklist-elni illetve ha egy BIOS ismerten bugos, akkor a fejlesztőnek nem kell azzal időt töltenie, hogy a saját kódjában keresse a hibát, ha az ismerten a gépedben van.
Egyébként nekem úgy rémlik, hogy ismert bug esetén már nem egy alkalommal volt példa arra, hogy internetes blogok, fórumok nyomására a gyártó vette a fáradságot és javította a problémát.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
"Rövid sor: Dell, Asus, Fusi... na ezekhez 1 év után az életben sem láttam bios frissítést vagy éppen soha... ellenben láttam win patch-et ami megoldotta win-en a problámát. Pl a Dellnél divat 4 év után is nyugdíjba küldeni a gépet A01-es bios-szal."
Nekem Dell-es tapasztalatom van, ettől eltérő.
Dell Latitude D630, én valamikor 2007-ben vettem
support.dell.com, nóta kiválaszt, driver és sw letöltés, BIOS:
Release Date: 1/22/2010
Version: A17
Download Type: BIOS
Level of Importance: Optional
Fixes/Enhancements
------------------
1. Added support for Remote TPM Activation.
2. Removed HDD Acoustic support.
Szóval még csak nem is olyat javítottak, hogy a seven nem megy rajta rendesen, vagy ilyesmi.
- A hozzászóláshoz be kell jelentkezni
2. Removed HDD Acoustic support.
szóval kezdik visszabutítani? Ha figyelmetlen vagy és mindig telepíted a legújabb BIOS-t utánaolvasás nélkül, lassacskán minden funkció eltűnik a gépedből --> muszáj leszel új vasat venni.
- A hozzászóláshoz be kell jelentkezni
Köszönöm, meglesem, van egy gyanúm, hogy nálam sikítani fog a drága :)
- A hozzászóláshoz be kell jelentkezni
Na ez végre valami hasznos dolognak tűnik.
Egyébként gondolom ha kiderül, hogy adott gép adott biosa bugos, azzal nem feltétlenül kell a gyártónál kopogtatni. Ha a microsoft meg tudja oldani, hogy minden* buggy biost támogasson, akkor csak hozzáállás kérdése, hogy ez a linuxnak is sikerüljön.
*: Ésszerű keretek közt, persze. Nyilván a gyártók érdeke is, hogy a windows jól működjön a gépeikkel, ezért valószínűleg a bios workaroundjaikat lejelentik a microsoftnak.
--
Don't be an Ubuntard!
- A hozzászóláshoz be kell jelentkezni
"Ha a microsoft meg tudja oldani, hogy minden* buggy biost"
Ez a valóságban úgy néz ki inkább, hogy a hardvergyártók támogatják a Microsoft operciós rendszereit. Hint: "Designed for Microsoft Windows" és társai certifikációk. Elég komoly Microsoft által biztosított tesztprogramoknak kell alávetni a hardvereket a gyártóknak és az OEM-eknek, hogy az általuk gyártott gépek megkaphassák a minősítést. Ezt onnan tudom, hogy a szervizünkben a srácok minden ilyen minősítéskor kemény problémákba szoktak ütközni. Ilyenkor megy a BIOS vadászat, vagy a levél írása a gyártónak, aki reszel egy megfelelő BIOS-t a Windows-hoz. Te - végfelhasználó - ebből annyit látsz, hogy "jé a Microsoft ezt is megoldotta". Én inkább azt mondom, hogy "jé, az OEM ezt is végigszívta, és kijavíttatta". Ja és hogy miért kell ezt végigcsinálni? Mert a közbesz-ben és hasonlókban enélkül nem lehet elindulni.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Régebben azt láttam, hogy kétféle DSDT fordító van: az egyik az Inteles, ami elég szigorúan ellenőrzi, hogy a specifikációnak megfelel-e, a másik a Microsoft-os, ami sok szempontból megengedőbb. Mivel a WHQL minősítés megszerzéséhez az alaplapgyártóknak célravezetőbb, ha a Microsoft-féle DSDT validátort használja, ezért gyakorlatilag mindenki ezzel dolgozik. Így az alaplap windows-zal általában viszonylag jól együttműködik, de az ACPI szabványt nem feltétlenül követi. Legalábbis elég sok alaplapból kiszedett DSDT táblázatra hibákat jelez az Intel validátora.
Gyakran vannak OS specifikus részfák is a DSDT-ben és több helyen is írnak olyan megoldást, hogy a LINUX ágat egyszerűen át kell írni a WinXP-s azonosítóra és viola, megjavul suspend.
Pl itt van egy ilyen leírás, hogy gyakorlatban is megfogható legyen, hogy kb miről is van szó: http://ubuntuforums.org/showthread.php?t=1036051
---
Internet Memetikai Tanszék
- A hozzászóláshoz be kell jelentkezni
" és viola,"
Viola? Ot ismernunk kene?
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
- A hozzászóláshoz be kell jelentkezni
Itt az eredménye az "fwts --interactive" futásnak az én notebookomról, amire semmilyen panaszom sincs. 38 napos uptime mellett most tartok kb. 60. suspend/resume ciklusnál (napi 2). Még ennél a látszólag jól működő gépnél is van egy rakat hiba:
http://hup.pastebin.com/Yxjm4PN1
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
nálam is az egyetlen fajta fail, error vagy warning üzenetek a syslog-ban csak ACPI-hez kötődnek, ebből van dögivel, viszont semmi gondom az altatással (intel-es noti).
- A hozzászóláshoz be kell jelentkezni
Na ennek az eredményére marha kíváncsi leszek. Este végig is futtatom a laposon.
- A hozzászóláshoz be kell jelentkezni
Lazán kapcsolódik:
Linux alól BIOS frissítés hogyan? Ha valaki csinált már ilyet írhatna egy How-to -t...
----------------
(:> )B
- A hozzászóláshoz be kell jelentkezni
Itt van több megoldás is.
-----
"Fontosabb egy jó szomszéd, mint egy távoli rokon." (Árvízkárosult, 2010)
- A hozzászóláshoz be kell jelentkezni
Kiírtam freedost cédére a dell biosfrissítő exéjével együtt, flottul működött. :) Sajna nem dokumentáltam akkor, de most úgy látom, a dellnek saját ilyen freedos-image építő programja is van, egy próbát megérhet.
- A hozzászóláshoz be kell jelentkezni
Hasonlóan, csak én pendrivera telepítettem freedost. Így nem kell mindig legyártani az iso-t, hanem elég rámásolni a megfelelő fileokat a pendrive fat partíciójára.
--
Don't be an Ubuntard!
- A hozzászóláshoz be kell jelentkezni
Lehet grubbal és memdiskkel is bútolni magáról a gépről.
Nekem is Dellem van, semmi gond vele.
- A hozzászóláshoz be kell jelentkezni
+1 régi dell notikban a BIOS-t a dell saját boot cd-jéval frissítettem.
- A hozzászóláshoz be kell jelentkezni
Gondoltam lefuttatom az interactive modeot, de mivel az ubuntu livecd már beállította a default actionöket az acpi eventekhez, ezért kétszer is megszakadt a teszt. Aztán beállítottam, hogy ne tegye suspendbe a gépet a lid lecsukására, de most nem akar végigfutni a teszt, egyik lépésnél fogja magát, és kilép.
Szerk: service acpid restart után fut a power button megnyomásáig, amire szépen leáll a script. Ez normális?
Szerk 2: ahogy látom, ugyanannyi teszt futott le, mint treynel, ezért gondolom igen. Eredmény: http://pastebin.ca/1915775
--
Don't be an Ubuntard!
- A hozzászóláshoz be kell jelentkezni
Jó-jó, de mi a kívánságuk? Küldjük el nekik valahová? Vagy az eredményt nyomtassuk ki és kereteztessük be?
KAMI | 神
--
Támogatás | OxygenOffice | Fordításaim és SeaMonkey
- A hozzászóláshoz be kell jelentkezni
Én annak örülnék, ha ez a progi tényleg meg tudná mondani, hogy milyen workaround-dal lehet az ilyen meg olyan BIOS/ACPI hibákat megkerülni. Sokszor olvastam már fórumokon mindenféle "anomáliák" gyógyíreként, hogy kernel paraméterben tiltsam le az acpi támogatást v. csak egy részét ... vagy ilyen-meg-olyan spec. kernel paramétert használjak és akkor minden jó lesz. Jól jönne egy progi, ami megkímélné az embert attól, hogy BIOS/ACPI guruvá váljon, ha nem muxik a suspend v. a hibernate v. időnként resetel a gép minden különösebb ok nélkül, stb.
- A hozzászóláshoz be kell jelentkezni
Nekem egy helyen ad tanácsot (mondjuk nem nagyon használhatót):
ADVICE: The VGA memory region does not have a MTRR configured by the BIOS. This means that
bootloaders rendering to a framebuffer will be rendering slowly and this will slow the boot
speed. It is probably worth asking the BIOS vendor to map in VGA write-combiningg region.
- A hozzászóláshoz be kell jelentkezni
Nekem szinte minden lemegy failed nélkül (alig van itt-ott egy kettő).
Viszont kettő tesztnél is elszáll segmentation fault-tal.
Az egyik a "dmesg_common", a másik az s3. A suspend/resumnál érdekes, mert elalszik, felébresztem, felébred jól és ezután száll el. Ami még érdekes itt, hogy hibát jelez, hogy túl gyorsan ébredt fel (30 sec.-en belül), így várnom kell egy kicsit, ha nem akarok hibát kapni (lagalábbis abban a részében, ami fut).
- A hozzászóláshoz be kell jelentkezni
Nekem is vicces ez az s3 teszt. Elindítom, "felfügg", majd az ébredés már nem megy... Sajnos emiatt a log is majdnem üres, ami benne van, az sem hasznos információ. s4-nél gond nélkül ébred, alszik.
- A hozzászóláshoz be kell jelentkezni