Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 96, views: 22.918 •
Submitter: Jeanpaul145

De driver voor bepaalde netwerkkaarten van Intel die in de nieuwste kernels van Linux wordt gebruikt, kan sommige netwerkkaarten fysiek beschadigen. Onder meer Ubuntu, Suse en Mandriva erkennen het probleem.

Netwerkkaarten van Intel die de e1000e -driver gebruiken, lopen het risico beschadigd te worden door de bug. De nieuwste testversie van de kernel van Linux, versie 2.6.27 inclusief rc7, zijn van de bewuste driver voorzien. Wanneer een systeem met ingebouwde of losse Intel-netwerkadapter met deze module wordt aangestuurd, bestaat de kans dat de eeprom van de netwerkkaart corrupte data te verwerken krijgt. In dit geheugen, bestaande uit nvram, wordt informatie als het mac-adres van de netwerkkaart opgeslagen. Hierdoor functioneert de netwerkkaart niet langer en dient deze vervangen te worden.

Intel ICH9Het probleem doet zich zowel bij losse als geïntegreerde netwerkkaarten voor: losse pci-expresskaarten voor gigabit-ethernet en de bekende ICH8- en ICH9-southbridge kunnen gebruik maken van de e1000e-driver. Intel heeft een instructie hoe de netwerkadapter geïdentificeerd kan worden beschikbaar gesteld; ook is een lijst met hardware die de e1000e-driver gebruikt voorhanden. Verder waarschuwen enkele grote Linux-distributes, zoals Ubuntu, Mandrake en Suse dat bezitters van Intel-netwerkkaarten moeten oppassen met de nieuwe driver. Zo zouden de bèta 1-versies van zowel openSuse 11 als SLE 11 de driver aan boord hebben.

Ook Mandriva heeft een waarschuwing voor zijn pre-releases van 2009-versies uitgegeven en raadt gebruikers aan te controleren of de betreffende Intel 82566- of 82567-chipsets aanwezig zijn: lspci | grep 8256[67] en om te controleren of de gewraakte driver gebruikt wordt: /sbin/lsmod | grep e1000e. De nieuwe Intrepid-versie van Ubuntu is ook met kernel 2.6.27 uitgerust en derhalve doet de bug zich ook bij dit besturingssysteem voor.

Reacties (96)

Er zijn amper distro's die de 2.6.27 kernel aanbieden dus het is niet zo dramatisch. De meeste blijven steken rond 2.6.24.
precies, misschien dat enkel een aantal gentoo gebruikers hier last van hebben en wat testers maar het grote publiek hoeft hier (nog) niet bang voor te zijn.

Mijn eigen ubuntu systeem
2.6.24-19 :)
Dankzij die "dommerikken" worden dit soort bugs anders toch bekend. Dus als ik jou was zou ik ze maar dankbaar zijn in plaats van ze te be-/veroordelen...
pfffft, rustig maar, "dommerikken" was sarcastisch. ik probeer alleen een klein beetje informatie te geven over de verdeling van de gebruikers van gentoo, met name betreffende de vraag welke kernel versie ze gebruiken. sommige mensen willen blijkbaar het allernieuwste, en daar zijn we ze dankbaar voor, zeker op momenten als deze.
Dat hangt er ook vanaf of ze stable of unstable draaien. In het eerste geval zal het zo'n vaart niet lopen.
Gisteren nog met gentoo zitten prutsen en hun nieuwste is de 2.6.26.
Het probleem zit 'm ook meer in het feit dat de bug uberhaupt in de kernel terechtgekomen is. Voor hetzelfde geld komt zo'n bug wél via een update terecht op je stabiele OS.

En als je dan je netwerkkaart moet vervangen, of er één moet kopen omdat die van je moederbord kapot is, is dat één ding, maar als je laptop zo'n zelfde chip gebruikt, en die óók vatbaar is heb je een groter probleem. Ik weet niet of deze specifieke chip ook in laptops voorkomt overigens.

Het lullige voor die distro's is dat zij hier geen schuld aan hebben. Als het wordt aangeleverd en het is niet goed, dan moet je daar maar net op tijd achter zien te komen. Maar mensen die thuis ermee werken, en hun hardware gaat kapot, die kijken niet naar kernelontwikkelaars, dan krijgt wel de distro-ontwikkelaar de schuld.
Is het dan niet meer een fout van de chip bakker dat dat stukje geheugen uberhaupt aanspreekbaar is?

Veiligheid moet ook op dat nivo geregeld zijn lijkt me.
Kijk zo'n geheugencomponent is op veel verschillende manieren in te zetten. Dat het bij deze kaart net als nvram gebruikt is om mac adressen op te slaan kun je de chip bakker niet kwalijk nemen, eerder diegene die de chip toepast.
Ter informatie. De chip zit in veel HP-laptops van 2007/2008.

Het is inderdaad erg vreemd dat het in de flash-schrijf-modus terecht kan komen door corrupte data.
Het leuke is dat een Linux bijna nooit bij ondersteunde software staat. Dus je hangt van de goodwill van je fabrikant af hoeveel kosten je zal hebben.
Komt steeds meer hoor. Ook HP met hun servers, Dell met hun laptops, Asus met hun netbooks: allemaal fabrikanten (en niet de kleinsten!) die diverse Linux-distro's ondersteunen.
Deze bug komt niet terecht op je stabiele OS, want dit is een bug in een development versie van de kernel. Ze hebben een bug in beta software gemaakt... shit happens... Ja, lullig dat het je hardware kan slopen, maar niet zo dramatisch als jij nu beweert, en dat soort dingen is nou precies waarom het grote publiek geen beta versie moet draaien en gewoon moet wachten tot de officiele release. Beta software draaien is altijd op je eigen risico.
Maar de mensen die bèta-software draaien zijn in de Linux-wereld juist erg belangrijk voor bug-reports en dergelijke. De vooruitgang van Linux hangt voor een (groot?) deel juist af van de bèta-gebruikers.
Dit soort bugs (die je hardware om zeep helpen) kan wel eens een grote negatieve invloed hebben op het aantal van de bèta-testers en dat is weer slecht voor de ontwikkeling van Linux(distro's).
En zelfs dan is de kans dat een beschadiging als deze optreed ontzettend klein.
[quote]Deze bug komt niet terecht op je stabiele OS, want dit is een bug in een development versie van de kernel.[quote]

De development versie van de kernel bestaat niet echt meer; dit was op initiatief van Linus Thorvalds hemzelve. Vroeger had je 2.3 en 2.5, er zou misschien 2.7 komen, totdat Linus besloot dat er te weinig mensen de development versies probeerden. Daarom werd alle development gedaan in 2.6 en werden distro-makers gepusht om nieuwere testkernels aan de eindgebruiker te leveren: Zodat er meer mensen zouden testen. Was dat niet gebeurd geweest, was deze bug nu misschien nog niet gevonden.

Natuurlijk laat de rc1 tot rc7 zien dat het om een development-versie gaat, maar blijkbaar worden ze netjes door distro's gebruikt; zoals Linus wil. Zo'n bug hoort mijns inziens in een alpha te zitten, en niet in een beta.
Torvalds heeft alleen besloten om van de even nummers voor de stables en de oneven nummers voor de testversie af te stappen. De development versies van de kernels worden nu aangeduid met bijvoorbeeld rc1 t/m 7. De kernels die dit er niet achter hebben staan zijn gewoon stabiele kernels die getest zijn. Het is echt niet zo dat iedereen tegenwoordig een testversie van de kernel draait.
Waar een bug 'hoort' te zitten trekt ie zich meestal niet veel van aan.

Het probleem is wsch dat dit iets is dat alleen in uitzonderlijke gevallen voorkomt, en dus niet makkelijk op te testen is.
Ik heb iets vergelijkbaars gehad met een linux distro enkele jaren terug. Na het booten van de CD-drive was deze stuk , enkel bij dat model cd-rom. heb ik ook pas ontdekt nadat het op een forum te vinden was. Ik dacht dat het een mandrake as met een LG cd-drive
Indien deze versie op een virtual machine geïnstalleerd zou zijn, is dan enkel de virtuele netwerkkaart verknoeit, of wordt dit dan doorgetrokken naar de fysische netwerkkaart? Iemand hier beter van op de hoogte?
Gezien dat de virtuele machine in principe als een soort laag tussen het Guest (het virtuele) OS en het Host (het daadwerkelijk op een machine geinstalleerde OS) draait lijkt het mij onwaarschijnlijk dat dit de fysieke netwerkkaart beinvloedt, omdat je Linux-guest een volledig andere driver zal gebruiken.
Maar er zijn wel enorm veel vrijwilligers die de aankomende versies testen en dus in het ergste geval hun netwerkcontroller zien verdwijnen. De schade kan dus wel vrij groot worden. Daarnaast moet de gebruiker zelf opdraaien voor de kosten, iets wat zeker bij laptops hoog kan oplopen.

Het is dus niet dramatisch, maar wel belangrijk dat het nieuws die mensen bereikt die deze kernel gebruiken
Het is sowieso een beetje een "Telegraaf" kop. Het gaat om driver in de testversie. De unstable dus. Daarvoor dienen testversie's nou juist, om dit soort zaken op te sporen.

Een beetje ICT-er zet geen unstable editie of release candidate in voor productieomgevingen.
Dan nog loopt het mollen van een stuk hardware zelfs voor bèta software toch een klein beetje uit de klauwen.
Yup, maar het is ook wel een beetje eng dat het uberhaupt kan. De meeste hardware krijg je onmogelijk stuk via software, wat je ook doet.
In tegendeel: Schroef de frequenties van je CRT maar eens te hoog op en bel de brandweer....
Eigenlijk is dit een spijtig foutje dat gelukkig ontdekt is en snel gefixt is voor het de stable-omgeving raakt. Is dit een grote fout? IMHO: Niet echt. Soms kan het namelijk handig zijn om je hardware aan te kunnen passen (zoals je MAC-adres of een image van aangepaste firmware). Ik vraag me alleen af of het ook mogelijk is om de chip te "herstellen" door het prommetje opnieuw van de juiste code te voorzien...
Is dat daadwerkelijk nog mogelijk met enigszins latere CRT modellen (die SVGA ondersteunen zeg maar..). Meestal als ik een onzinnige frequenty kies, dan krijg ik iets als "input error", ofwel als ik bij de eigenschappen op het OSD kijk staat daar iets veel lagers.
Dat kon met oudere CRT monitoren ja. Mijn broer heeft het eens voor elkaar gekregen. Overigens is "bel de brandweer" ook overdreven: de monitor geeft gewoon geen beeld meer, rook kwam er niet aan te pas.
Soms kan het namelijk handig zijn om je hardware aan te kunnen passen (zoals je MAC-adres...
Niet nodig, doe je gewoon softwarematig via ifconfig. In Linux dan (BSD ook geloof ik); Windows weet ik niet.
En wat denk je dat er dan gebeurt? Dan wordt aan de driver gevraagd om het mac-adres aan te passen in het nvram van de netwerkkaart...
Dat klopt niet, als je via ifconfig het mac wijzigt is dat geen persistent change en wordt dus blijkbaar niet naar de nvram geschreven.
bij ubuntu is het toch een alpha waar de bug in zit.
Dat de distro een oudere kernel heeft, wil niet zeggen dat deze buggy driver er niet in zit. Om compatible te zijn met de laatste hardware, voegen sommige distros drivers uit de nieuwste kernel toe aan hun oudere Kernel.
Wij draaien hier bijvoorbeeld nog de oude Redhat 4 enterprise, met een 2.6.9 kernel op een quadcore server, met de laatste intel chipset. We moesten daarvoor de 2.6.9-67 update van de kernel hebben i.v.m. hardware ondersteuning. Met iedere nieuwe update, wordt weer meer hardware understeund. Hoe andere distros dat doen weet ik niet, hoop maar dat ze het goed testen.
Apart, je zou zeggen dat je met een stukje software de "kapotte" netwerkkaart dan ook weer moet kunnen fixen, aangezien alleen de eeprom aangetast is. De netwerkkaart "flashen" en het werkt weer, lijkt me?
Als er in dit EEPROM informatie staat die de kaart nodig heeft om te kunnen communiceren met het OS werkt het niet meer.
Dit is ook al eens voorgekomen met een bepaald merk DVD-drives, die zich niet aan de IDE standaard hielden en als ze door Linux aangesproken werden hun firmware kwijt waren.
Alleen moet dat eeprom ook een stukje code bevatten om het flashen mogelijk te maken. Als dat (ook) beschadigd wordt, is het hotflashen niet meer mogelijk. De eeprom zou dan met een losse programmer moeten geflasht worden.
De kostprijs daarvan zou wel een eindje boven de nieuwprijs van een kaartje kunnen liggen ;)

[Reactie gewijzigd door the_stickie op 25 september 2008 15:34]

Maar wellicht niet boven die van een nieuwe laptop?
of een nieuwe server ?
of een nieuwe auto.

edit: ik bedoel dan -> wie gaat die gloednieuwe beta kernel op een server zetten? En je gaat toch akoord met de GPL, en ik quote: " NO WARRANTY

11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.

12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES."

[Reactie gewijzigd door goestin op 25 september 2008 16:32]

Je dacht toch niet dat je op commerciele software wel garantie krijgt?

Windows biedt bijvoorbeeld alleen garantie op de DVD.
Als het schijfje spontaan stuk gaat kan je een nieuw DVD'tje krijgen. Als Windows alle data van je bedrijf weggooit heb je pech.
Zorg maar dat je als windows gebruiker een goede virusscanner hebt want het feit dat je de netwerkkaart om zeep kan helpen zal helaas waarschijnlijk snel geïntegreerd worden in een virusje.
Alleen de netwerkkaart maar? Wel eens gedacht aan BIOS van je optische drives, harddisks, moederbord? Vanuit Windows de processor (te) ver overclocken?
Allemaal dingen die prima mogelijk zijn, vermits je weet welke hardware er in een PC zit. Dus ik zou m'n internet maar afsluiten en m'n alu-hoedje maar opzetten, als ik jou was.
De BIOS flashen door malware is in een grijs verleden al een keer gebeurt, zie het CIH virus..
Geweldig die open source software
Bij die opensource software staat het in koeie-letters BOVEN EN ONDER aan de licentie.

Bij Closed-source software staan dezelfde bepalingen, in de kleine lettertjes.
Het gaat dus om de alpha en beta releases van deze distro's. Stabiele releases gebruiken 2.6.26 of eerder en hebben geen last van dit probleem
The Real WTF is eigenlijk nog wel dat zo'n kaart door een wat corrupte datastroom gesloopt kan worden IMO.
al is het natuurlijk ook een erg vervelende bug, maargoed...
Maar onder "fysiek" beschadigen versta ik toch een hardwarematige beschadiging....
ja en nee, de eeprom krijgt foutieve informatie die word opgeslagen. Hierdoor kan het OS niet meer communiceren met de controller en dient deze dus fysiek vervangen te worden.
Hij dient fysiek opnieuw geprogrameerd te worden, das niet hetzelfde als vervangen.
Nee, hij moet vervangen worden. Hij *kan* namelijk dan niet meer fysiek opnieuw geprogrammeerd worden. Het gaat niet over een losse eeprom ofzoiets maar over een paar transistors in de chip geintegreerd, en als ie eenmaal; stuk is kun je die niet meer schrijven.
In vele hardware word de dag van vandaag een deel van de instructies softwarematig uitgevoerd. Daarom ook dat drivers zo belangrijk zijn en soms moeilijk na te bouwen zijn onder linux. De firmware van zo een controller word telkens bij het laden van de drivers ingeladen in de controller. Als daar iets fout gebeurd is het dus mogelijk dat je alles verknald.
flawed by design idd
Suggestieve kop zeg. Dit betreft in ieder geval voor Ubuntu alleen de "beta" versie van 8.10. Blijft staan dat het een erg vervelende bug is.
Sinds de nieuwe manier van nummeren van kernel versies weet ik niet meer welke kernel versie stabiel is. Vroeger kon je er gewoon vanuit gaan dat alle 2.x.y versies stable waren als x even was.
Deed me ook nogal Telegraaf-stijl aan, maar het valt eigenlijk wel mee met de bug. Het is wel een erg vervelende bug die grote gevolgen kan hebben. Eigenlijk vreemd dat zo "makkelijk" de netwerkkaart kapot te krijgen is. Zo te zien blijkbaar iets wat alleen mogelijk is bij een Intel netwerkkaart. Bugje in de Intel hardware?
Als zo'n bug echt in een beta versie van een distro zit, is er echt iets mis. Dat zo'n bug bestaat okey, maar ik mag hopen niet niets anders dan in een alpha release van de linux kernel. Dat deze optioneel te installeren is, prima. Maar standaard gebruikt wordt voor een beta release... (gebruikt ubuntu alpha kernels voor een beta release, of is de bug in een beta-kernel release gekomen?)
2.6.27-rc7 is allesbehalve alpha. Afhankelijk van de staat van de code zou dat ding van de ene dag op de andere gereleased kunnen worden als stable versie, waarna veel gebruikers zich op de nieuwe kernelversie storten omdat het ding als "af" is verklaard.
Het gaat om de 2.6.27-rc7 versie, en dat is nog niet stabiel zegmaar. Als -rcX eraf is zou de kernel geschikt moeten zijn voor productie.
Zoals door anderen ook al genoemd wordt zo'n kernel alleen in alfa / vroege beta versies gebruikt. Het nieuws is hier dan ook niet dat er een bug zit in linux, maar meer dat het een bug is waarvan je nic kapoet gaat.

@disheaver: Ubuntu 8.10 is nog alfa :)

[Reactie gewijzigd door Jesse op 25 september 2008 16:53]

rc staat voor Release Candidate. Geen Alpha, geen Beta. Release Candidate. Windows van MS wordt zo tegen RC3 RTM gemaakt. (Open deur eigenlijk voor de MS bashers, maar goed).

Al met al, grote fout van de devs, die VEEL te laat is opgemerkt. Je moet er niet aan denken dat het een rtm was geworden.
Vanaf het moment dat er verder wordt ontwikkeld aan de Linux kernel krijgt deze AFAIK het label "rcX" mee. De kernel devvers gebruiken geen Alpha/Beta development status (dat is altijd een persoonlijke keuze he!). De X in de "rcX" loopt steeds verder op tot ergens in de buurt van de 8-9 (zo blijkt uit het verleden althans) en daarna wordt de kernel gefreezed, waarna hij na een tijdje als stable wordt gereleased (heel simpel gezegd dan).

Er is een lullige fout gemaakt, dat zeker, maar dat is nou eenmaal menselijk. Het bewijst ook dat zelfs de strengste codecriteria af en toe onbedoeld een foutje doorlaten (je krijgt echt niet zomaar je code in de vanilla kernel, die wordt eerst goed gepeerreviewed, daarna krijg je een berg met kritiek, dan opnieuw gepeerreviewed, en dan gaat ie in een unstable branch bij iemand, misschien jezelf. Uiteindelijk komt je code er dan misschien in, als er geen beter alternatief bestaat tegen die tijd).
En ook nu nog in feite, maar wel pas wanneer een y nummering gevolgd word door het woord final en niet als alpha, beta of rc.
Ben met je eens dat het een suggestieve kop is. Let wel op je feiten: het is eergisteren op de ubuntu-devel list geweest, en de beta is pas over anderhalve week. Ik neem aan dat er tegen die tijd wel een patch beschikbaar is.

Kan iemand mij wel vertellen hoe het kan dat zo iets in nota bene een netwerkkaartdriver is gekomen? Die dingen zijn toch al praktisch uitontwikkeld?
Ja... het klonk allemaal heel rampzalig... een beetje "OMG mijn server wordt straks gehacked, die draait een grote linux distro en hangt aan het netwerk" style.
Dan blijkt het ineens om een bug in een beta kernel te gaan, die alleen in alpha distros wordt gebruikt, in 1 netwerk driver, die een *kans* heeft om het ding te beschadigen... Ik schat het aantal slachtoffers rond de 5, en daar bedoel ik niet mee dat niemand linux gebruikt, maar dat dit een erg specifieke cornercase is waar alleen mensen last van hebben die er zelf om hebben gevraagd door beta software te installeren.
Is dat zo? Juist de ICH8/9 zijn vrij vaak gebruikte chipsets en pci-express kaarten (toevallig net de pricewatch eens nagekeken) blijkt het ongeveer 50/50 te zijn. En van die 50% zijn juist de Intels vrij populair. Maw de kans dat de combinatie van een populaire chipset en nic aanwezig is indien men een kernel installeerd is vrij respectabel. Verder vragen mensen er helemaal niet om bij een beta dat hun hardware beschadigd raakt. Ik gebruik ook beta al wetende dat het niet altijd correct functioneerd maar dat de hardware daadwerkelijk beschadigd raakt is toch wel een unicum. Imo is het dan ook wel ietwat slordig dat zoiets gebeurd.
Dat terzijde ik meende juist dat RedHat oa een groot aantal computers heeft draaien puur om te testen. Nu ben ik niet bekend met hoe een alpha release gebeurd maar zou het niet prettiger zijn in dit geval om eerst een pre-alpha op deze test bakken te draaien alvorens ze in de wijde wereld los te laten met alle gevolgen van dien?
Ik weet dat het om beta's gaat maar ik vind het toch wel bizar dat deze drivers kennelijk gewoon beschikbaar blijven. Dit is niet bepaald een klein bugje dat de testers alleen wat extra tijd kost. Dit doet echte schade.
Natuurlijk blijft het beschikbaar. Hoe wil je Linux 2.6.27-rc7 van het internet afkrijgen? Dat is door de hele wereld al gemirrord. Waarom denk je dat Linus geen backups maakt? :P Men kan slechts de bug fixen en een nieuwe versie uitbrengen.
Dit is gewoon een simpele bug, die notabene wordt mede-ontwikkeld door Intel's eigen medewerkers. Bovendien is alpha- en beta-software altijd error-prone. Het feit dat deze bug ook hardware damage kan opleveren is reden tot een extra waarschuwing, niet meer, niet minder.
het is dan ook geen 'gewone' bug... een 'gewone' bug heeft geen hardware schade tot gevolg.. moet je eens nagaan als je deze op je laptop hebt, dan kun je de hele laptop dus wel wegknikkeren, of met een losse netwerkkaart moeten werken....
Als jij dit gewoon vindt, dan vraag ik me af wat jij dan een extreme bug vindt..
Als jij dit gewoon vindt, dan vraag ik me af wat jij dan een extreme bug vindt..
Het is zeker een vervelende bug, maar het kan altijd erger:

http://www.thinkwiki.org/wiki/Problem_with_lm-sensors
lm_sensors prior to 2.6.5 caused the corruption of the Thinkpad's AT24RF08 EEPROM, leading to the Thinkpad not being bootable anymore.
Ik vind het ook een fout van Intel. Als je blijkbaar (onboard) chips permanent kunnen beschadigen. Leuk virus kan je schrijven met deze kennis! De brakke drivers downloaden en gaan kijken wat er fout gaat.
Vraag me af of VMWare ESX hier ook last van kan hebben.. het draait dan wel niet op linux maar denk wel dat in het OS de linux driver(source) in verwerkt is ?
Ik denk dat VMWare een héél erg stabiele versie van de kernel gebruikt. Debian heeft bijvoorbeeld nog versie 2.6.18 in de repositories staan. De kans dat VMWare met test-kernels gaat werken is ongeveer 0 komma nada: ze gaan niet het risico lopen hun goede naam weg te gooien doordat ze unstabiele of testversies van de kernel gebruiken, lijkt mij...
Elke package kan in elke distro komen. Voor de ene versie kost het meer kennis/moeite dan de andere. Een stabiele kernel versie zal op de CD staan van de distro, en als default geinstalleerd worden, een alpha kernel versie zal uit dieper water gevist moeten worden.
Dit is geen stable versie van de kernel, en dit kwam er dus juist uit bij het testen. De distros waar het in zit zijn ook allemaal alpha/beta versies
Dat zit niet in officiele distro's. Het zit alleen in alpha distros die 1 specifieke beta kernel gebruiken.
RC kernel. rc7 om precies te zijn...

Op dit item kan niet meer gereageerd worden.



Populair:Apple iPhone 6Samsung Galaxy Note 4Apple iPad Air 2FIFA 15Motorola Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox One 500GBTablets

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013