A visszajelzések szerint a Samsung eddig garanciában cserélte az eltéglásított laptopok alaplapját. Mikor már a többedik bejelentés érkezett az Ubuntu-hoz, a Canonical felvette a kapcsolatot a Samsung fejlesztőkkel. A gyanú a samsung-laptop driverre vetődött. Közben belefolyt a hibakeresésbe az Intel alkalmazásában álló Matt Fleming is, aki két, témához kapcsolódó patchet is küldött az LKML-re megvitatásra a napokban.
A Canonical részéről Steve Langasek jelezte, hogy a Samsung fejlesztői néhány hete azon vannak, hogy egy firmware frissítést készítsenek, amely megakadályozná, hogy a gép használhatatlan állapotba kerüljön. Langasek azt tanácsolja az Ubuntu felhasználóknak, hogy a problémás Samsung laptopokon napi build image-ekkel álljanak neki az Ubuntu telepítésnek. Ezekben az image-ek már megtalálhatók azok az Ubuntu csapat által foganatosított intézkedések, amelyek hivatottak lennének a probléma bekövetkezését megelőzni. Azonban az még nem teljesen világos jelenleg, hogy ezek az intézkedések mennyire hatékonyak.
Részletek itt.
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
samsung-laptop: Disable on EFI hardware
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Érdekes, hogy az Apple saját Bootcamp-je ha nem is hivatalosan de támogatja a Linux-ot második rendszerként, de a többi pc gyártónál rengeteg szívás van az UEFI miatt Linuxon.
- A hozzászóláshoz be kell jelentkezni
Mert az UEFI egy nagyon jól átgondolt és előre megtervezett történet, mely előre le volt egyeztetve minden hw gyártóval....
[:)]
--
compaq n610c
"...és micsoda zajt csapott!"
- A hozzászóláshoz be kell jelentkezni
Ebben az esetben jobb lett volna maradni a BIOS-nál amíg nincs normális uefi és nem a vásárlókon folytatni a beta tesztet.
- A hozzászóláshoz be kell jelentkezni
Hát pedig a béta teszt definíció szerint a userekkel történik.
----
India delenda est.
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
Erre önként jelentkező userekkel és nem beta tesztről mit sem tudó vásárlókkal.
- A hozzászóláshoz be kell jelentkezni
Persze a Linux uefivel kapcsolatos részének ehhez semmi köze nincs, kizárólag az uefi átgondoltsága és tervezettsége. Szarul megírt driver azért elég sok hardverrel (elég sok oprendszeren) tud problémát okozni.
- A hozzászóláshoz be kell jelentkezni
Hanyag tervezés arányosan hozza magával a fejlesztési hibákat is.
Mi volt előbb, az UEFI feltalálása, vagy az ahhoz szükséges szoftveres fejlesztés akár linuxhoz is?
--
compaq n610c
"...és micsoda zajt csapott!"
- A hozzászóláshoz be kell jelentkezni
A problema, hogy Linux kernel eseteben ehhez semmi szukseg nincs a hanyag hardvertervezesre.
Szar driver mar az UEFI feltalalasa elott is volt a Linuxban, nem is keves.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Most ettől teljesen függetlenül, milyen hardver az, amit egy hibás program haza tud vágni?
- A hozzászóláshoz be kell jelentkezni
Például processzor, meg ACPI.
- A hozzászóláshoz be kell jelentkezni
Átfogalmazom.
Egy butuska felhasználónak szánt hardver ne dögöljön már meg, ha az imént említett esetleg beszed valami kártékony programot.
- A hozzászóláshoz be kell jelentkezni
Ehhez az kéne, hogy a CPU ne legyen Turing-teljes. Az viszont baj lenne.
- A hozzászóláshoz be kell jelentkezni
Nem feltétlenül látom, hogy miért kellene a kettőnek összefüggnie.
Ha az egyes alkatrészek működéséhez feltétlenül szükséges programokat egy abszolút csak olvasható memóriában tartod, illetve te vagy Németh Gábor és tervezel egy hibamentes processzort, ami mondjuk brainfuckot futtat, akkor azt a gépet szerintem képtelenség megölni.
Másképp: a Turing-teljesség szerintem olyan processzorral is megvalósítható, ami fizikailag képtelen maradandó változtatást okozni magán vagy a hozzá csatolt memória egy részén.
- A hozzászóláshoz be kell jelentkezni
Azt akartad irni, hogy keptelen maradando fizikai valtoztatast okozni magan, ugye? Mert amit most irtal, a nem mukodo processzor definicioja.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Nekem megfelel az is, ha a processzorban kizárólag nem fizikai maradandó változások történnek, amennyiben az asztrálsíkból semmilyen információ nem képes átlépni a mi világunkba.
- A hozzászóláshoz be kell jelentkezni
Ja, igen, mostanság nem nagyon megy ez a magyar nyelv...
- A hozzászóláshoz be kell jelentkezni
Igazad is van, de szerintem már ott baj van hogy akármilyen driver tud olyan kárt okozni ami téglásítja a hardvert.
- A hozzászóláshoz be kell jelentkezni
mindenki: pl. a lent kelemeng által (és általam is) is hivatkozott Fujitsu + uefi + problem esetében BIOS reset kell, azaz téglásításról szó nincs. Pedig nagy eséllyel ugyanaz a gond. Szóval finoman. Amúgy ha jól rémlik anno a már a C64 kapcsán is emlegették azt, hogy szoftveresen tönkre lehet tenni a hardvert. Itt erről még csak szó sincs.
- A hozzászóláshoz be kell jelentkezni
A VIC-20 biztosan serulekeny volt e szempontbol, 10 evesen egy 15 soros BASIC "programmal" sikerult megsutni a sajatomban a hang es magnovezerlo elektronikat.
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
Kíváncsi vagyok hogy mit állított el.
Bemásolod a BASIC "programot" amivel sikerült?
- A hozzászóláshoz be kell jelentkezni
Sajnos ez igy tobb mint ket evtizede tortent es mivel azonnal rebootolta a gepet igy a forras sem maradt meg. :( De eleg vicces random kod volt egy nemet nyelvu manualbol osszevadaszva ami egyszerre tartalmazott load es save parancsokat sok minden mas hulyeseggel egyutt. :)
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
Volt egy legenda, a Poke 1,0 állítólag téglásította, sosem mertük kipróbálni. Ugyanez valami SYS xxxx, már nem elmlékszem. Amit Trey írt lejjebb a floppy fejkiakasztásról szintén működött. Fejrángatással teljesen tönkre is lehetett tenni. Ha jól emlékszem a hangchipet olyannyira lehetett vezérelni, akár feszültségállításokal szoftveresen hogy kisülhetett. Nem vagyok már benne biztos, az is lehet bővítőkártyákkal nyírtuk ki mindig a hangot.
--
AGA@
Fork portal és az egyik logóm :)
- A hozzászóláshoz be kell jelentkezni
mirol beszelsz? most telepitettem linuxot uefi alaplapra, teljesen jol ment
FUD
--
NetBSD - Simplicity is prerequisite for reliability
- A hozzászóláshoz be kell jelentkezni
Talán olvasd el előbb a cikket és csak utána kommentelj.
- A hozzászóláshoz be kell jelentkezni
egy ket random helyre torteno irastol elromlik? ha a tobbi gyarto is hasonlo minosegu uefi-t szallit, akkor nem kell nagyon tartani a secure boot-tol...
I hate myself, because I'm not open-source.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Ezt meg lehet csinálni Fujitsu laptopokkal is :-)
Izé :-(
- A hozzászóláshoz be kell jelentkezni
Ezen cikk szerint nem téglásítja a hardvert, egy BIOS reset után megy tovább.
- A hozzászóláshoz be kell jelentkezni
Eddig a hozzá nem értő ismerőseim mindig azzal jöttek, hogy "nem nyúlok hozzá, mert biztos elrontom", ezzel fejezték ki felém, hogy nem éreznek bátorságot mondjuk egy programot, drivert, oprendszert (újra)telepíteni, beállításokat adjusztálni, stb.
Erre megvolt a sztenderd válaszom: "Nincs olyan szoftver, amivel tönkre lehet tenni a hardvert".
...
- A hozzászóláshoz be kell jelentkezni
Pedig az a sztori szerintem mindenkinek megvan (minimum 10 független helyről hallottam, én magam nem találkoztam vele), hogy a Commodore-okhoz használható floppy meghajtó fejét túl lehetett úgy vezérelni, hogy kiakadt és az egység nem működött. A javítás nem volt bonyolult. És voltak, akik ezzel vissza is éltek.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
A másolásvédelem volt úgy megoldva, hogy a floppyn levő program által nem használt állomány utolsó szektora a 47. sávra volt jelölve, a fejnek meg csak 36 sávig volt útja a 34 sávos lemezekhez.
A kiszállt olvasófejet 10 dkg-os műszerészkalapáccsal kellett kiszabadítani, akkora sebességgel futott neki a nem létező helynek.
- A hozzászóláshoz be kell jelentkezni
Sziasztok,
kicsit szkeptikusan olvastam ezen hireket/bejegyzeseket a temaban, mivel nem olyan regota en is egy Samsung laptop (egesz pontosan NP900X4C) tulajdonosa vagyok. S minden remito cikk ellenere üditö peldakent (bar sztem sokan nem estek bele a "hibarataba") müködö Linux rendeszerrel hasznalom a gepet, meghozza UEFI-vel.
Elötelepitett Windows 8-al rendeltem, es meg is tartottam mint masodlagos rendszert.
Elsö napokban az altalam 2 eve megismert es nagyon szimpatikus Linux disztribucot, Arch Linux-t akartam melletelepiteni. Bevallom nem volt egy konnyu eset a dolog, annak ellenere sem h mar azert 6 eve aktivan linuxot hasznalok; s mar többször telepitettem rendszert kulonbozo gepekre. (es itt a masodik csatalasom a cikket illetoen) A legtobb problemam az UEFI-vel illetve a GPT-vel volt. (Windows 7/8 64 bit eseten UEFI csak GPT-re lehetseges)
Elsö neki futasra a particionalasnal bizony sikerult "elbarmolnom" mindent (ertem ezalatt hogy a gep elindult, de sem Win8, sem a recovery nem tudott mar bootolni) Meg szerencse hogy elotte csinaltam backupot az egesz winchesterrol a clonezilla segitsegevel. (Aki nem ismerte eddig, csak ajanlani tudom a programot ;-))
Masodszor mar jobban utanaolvastam, beleragtam magam a temaba....többször atböngesztem az ArchWiki-t, illetve a rEFInd fejlesztöi oldalat. (Utobbit nezve azert elfogja az embert a jofele 56k modemes hangulat --- "natur minimalizmus"; azonban a design mindenkeppen forditottan aranyos a tartalommal, mindenkinek csak ajanlani tudom aki UEFI ugy altalaban többet szeretne tudni: http://www.rodsbooks.com/refind/)
A tema elmeleti megismerese mellett gyakran bootoltam a gepet USB-rol, többek között elövettem az Ubuntu 12.10 iso-t is. Egyszer (mondjuk összesen kb 5 ubuntu boot-bol) tapasztaltam en is "fagyast", amely utan csak a power gomb hozott megvaltast.
Ekkor meg bele sem gondoltam hogy ez akar "elteglasitast" okozhat..... o.O
Szerencsere nem törtent ilyesmi, eddig! 'kop kop kop'
A hibajegyben/forumokok masok tapasztaltak kernel panicot Samsung laptopon az inditas soran. Nos ez a jelenseg nalam is fellepett. Ez meghozza az ArchLinux bootja soran mikor USB-rol inditottam a gepet; tette mindezt sporadikusan. (2012.12.01-es iso-t hasznaltam)
Miutan odaig jutottam hogy volt egy telepitett Arch linux a Windows8 mellett, nagyon megorultem .... s nem is foglalkoztatott a kernel panic, mert a telepitett verzional mar nem tapasztaltam.
samsung-laptop kernel module mondjuk nem ment sohasem, ezaltal jelen pillanatban nincsen 1-2 funkcio linux alatt; de ilyen cikkek utan ugy erzem jobb is igy.
Meg 1 kis kiegeszites, ami azt hiszem a temaba vaghat:
3.6.11-es kernelt hasznaltam sokaig a gepen, majd jöttek a frissitesek....es azt hiszem a 3.7.2 meg rendben volt, majd 3.7.3-al nem tudtam bootolni!!!! "de csak" a linux nem ment. LiveUSB-vel tudtam javitani. Majd most 3.7.4-1 az aktualis verzioszam a gepen (jelenleg is errol irok ide), megy minden (kiveve billentyu hattevilagitas, es power modok --- tehat amiert elvileg a samsung-laptop LKM felelne)....a gep hatarozottan nem "tegla" ;-)
Ezert is vagyok szkeptikus a dolgokkal. Sajnalom h vkinek emiatt a garanciat kellett igenybe venni, remelem sikeresen elmanoverezek en is a "hiba" mellett....mindenesetre most kernelt nem igazan illetve fokozottan ovatosan frissitek...mindaddig amig nincs tisztazva ez a dolog.
Jah igen.....a Windows 8 alatti Intel SW update a hetvegen feldobta nekem hogy BIOS update elerhetö...egyelore azt mondtam neki h ne tegyen semmit. Sajnos hasznalhato irast (change log-t) nem talaltam....igy "rosszabb lesz mint volt" alapon egyelore nem engedem telepulni.
Kivancsian varom amugy hogy mikor lesznek javitasok az ugyet illetoen.
Udv,
balazs4
- A hozzászóláshoz be kell jelentkezni
Ez is egy Samu lapos, csak Linux (Mint Nadia 64 bit) van rajta és nem tégla.
Egyszerű az oka, nem mindegyik Samu laposnál jön elő.
--
AGA@
Fork portal és az egyik logóm :)
- A hozzászóláshoz be kell jelentkezni