Upgrade linuxkernel ivm Trim ondersteuning

ko · 13 sep 2010

Copy/paste vanuit: https://techpatterns.com/forums/about933.html

Typical uses of sgfxi
# for normal nvidia install, with composite enabled
sgfxi -c
# for normal fglrx install (direct binary install, no distro packages)
sgfxi
# fglrx binary run package install: distro packages created/installed
sgfxi -D
# for installing normal ati xorg driver
sgfxi -n
# for installing special xorg radeon driver
sgfxi -N radeon
# for installing an older nvidia driver, with composite
sgfxi -co 100.14.19

Ik vermoed dat de door mij opgegeven optie 'sgfxi -D' niet de juiste was voor jouw ATI-card
Voor jouw Radeon 5850 zou je kunnen proberen:

Code:

sgfxi

of

Code:

sgfxi -n

of

Code:

sgfxi -N radeon

of

Code:

sgfxi -N radeonhd

Ik weet niet welke specifieke graphics driver je nodig hebt voor je Radeon kaart.....
Ik zou beginnen met alleen sgfxi [maar ik vermoed dat je een radeonhd driver nodig hebt (Catalyst 10.4), dus 'sgfxi -N radeonhd' ]

....Sorry voor mijn (waarschijnlijke) fout......

Ko

jtech · 13 sep 2010

Dus is er iets anders aan de hand. Welke ATI driver versie werd 'gekozen' door sgfxi ?

Geen idee, de schermen vlogen met grote snelheid voorbij, dus dat heb ik niet zo gauw kunnen ontdekken.

Ik weet niet welke specifieke graphics driver je nodig hebt voor je Radeon kaart.....
Ik zou beginnen met alleen sgfxi [maar ik vermoed dat je een radeonhd driver nodig hebt (Catalyst 10.4), dus 'sgfxi -N radeonhd' ]

....Sorry voor mijn (waarschijnlijke) fout......

Ko

Geen probleem, ik ga hiermee weer aan de slag. Bedankt zover!

jtech · 13 sep 2010

Uit jouw link:

cd /usr/local/bin && wget -Nc smxi.org/smxi.zip && unzip smxi.zip && smxi

In jouw opdrachtregel ontbreekt de laatste smxi. Is dat correct?

ko · 13 sep 2010

jtech zei:
Uit jouw link:

In jouw opdrachtregel ontbreekt de laatste smxi. Is dat correct?

Nee, ik heb alleen aangegeven hoe je sgfxi (voor grafische drivers) uit de smxi.zip download en runt.
Je kunt ook smxi runnen (en sgfxi wordt aangeroepen in de smxi script, dus die kun je ook gebruiken) en dan doe je dat zoals aangegeven.
Dus ja, als je smxi will runnen is dat OK. Voor alleen de grafische driver hoef je smxi (=veel uitgebreider) niet te gebruiken.
Na eenmalig downloaden en uitpakken hoef je overigens die hele regel niet te herhalen.
En zowel smxi als sgfxi updaten zichzelf als ze gerund worden.

Ko

jtech · 13 sep 2010

Ik heb van alles geprobeerd Ko, maar het lukt niet. Het proces lijkt normaal te verlopen zonder foutmeldingen, maar als ik dan probeer opnieuw op te starten dan start het systeem niet door. De enige keer dat het me nog lukte om in de GUI te komen was na het aanvankelijke proces zoals door jou aangegeven, maar toen bleek er dus geen proprietary driver te zijn geladen(??). Opnieuw opstarten lukte dus niet. Ik heb nu een image teruggezet (vanuit Win 7) dat ik van de Root partitie van Gnome had gemaakt alvorens aan dit avontuur te beginnen.

Ik ben bang dat het niet gaat lukken met de combinatie kernel 2.6.35 en de ATI drivers. Of heb jij nog een suggestie?

Is het misschien een idee om de ATI driver direct bij AMD vandaan te halen?

Teruggaan naar de OS drivers is natuurlijk ook een optie. Gaarne je commentaar.

Edit: lees net op Tweakers dat de OS drivers de 5xxx kaarten niet zouden ondersteunen. Dit lijkt me persoonlijk sterk want direct na de install van Mint werk je daar toch automatisch mee?

ko · 13 sep 2010

jtech zei:
Ik heb van alles geprobeerd Ko, maar het lukt niet. Het proces lijkt normaal te verlopen zonder foutmeldingen, maar als ik dan probeer opnieuw op te starten dan start het systeem niet door. De enige keer dat het me nog lukte om in de GUI te komen was na het aanvankelijke proces zoals door jou aangegeven, maar toen bleek er dus geen proprietary driver te zijn geladen(??). Opnieuw opstarten lukte dus niet. Ik heb nu een image teruggezet (vanuit Win 7) dat ik van de Root partitie van Gnome had gemaakt alvorens aan dit avontuur te beginnen.

Ik ben bang dat het niet gaat lukken met de combinatie kernel 2.6.35 en de ATI drivers. Of heb jij nog een suggestie?

Is het misschien een idee om de ATI driver direct bij AMD vandaan te halen?

Teruggaan naar de OS drivers is natuurlijk ook een optie. Gaarne je commentaar.

Edit: lees net op Tweakers dat de OS drivers de 5xxx kaarten niet zouden ondersteunen. Dit lijkt me persoonlijk sterk want direct na de install van Mint werk je daar toch automatisch mee?

Waarschijnlijk werk je met de VESA driver (of een andere os driver), maar niet met een specifieke hardware-accelerating ATI-proprietary driver. Werkte Google-Earth (die heeft accelerated hardware nodig)? Wat staat er in /etc/X11/xorg.conf ?

Hier staat de (laatste) Linux 64/32bit ATI Catalyst drivers, versie 10.4 van April-2010 voor de HD5850:

https://support.amd.com/us/gpudownload/linux/10-4/Pages/radeon_linux.aspx?type=2.4.1&product=2.4.1.3.42&lang=us&rev=10.4&ostype=Linux%20x86_64

Klaarblijkelijk zijn er wel ook enige 32bit packages nodig. Lees bijbehorende tekst en installatie routine als je ermee wilt doorgaan.
(bijgevoegd als .pdf de release notes en de installer routine)
Installeren is niet moeilijk en als het niet zou lukken kun je altijd nog terug naar de originele driver.
Kijk trouwens even welke driver dat nu [nog] is....

Ko

jtech · 13 sep 2010

Vlg. CCC is het nu 8.723.1-xxxx. Dat zal dus wel iets in de buurt van 10.2-10.3 zijn. Kan het zo gauw niet vinden, maar het moet in ieder geval zijn van voor de releasedatum van de distro, want ik heb geen updates voorbij zien komen in die tussentijd.

Of Google Earth werkte kan ik niet zeggen, want die heb ik niet geinstalleerd staan of uitgeprobeerd. In ieder geval heb ik nu de oude situatie weer terug.

Er is bij AMD zelfs al een 10.8 versie te downloaden:

https://support.amd.com/us/gpudownload/linux/Pages/radeon_linux.aspx?type=2.4.1&product=2.4.1.3.42&lang=English

Het uitgangspunt van dit topic was Trimondersteuning. Gek genoeg heb ik dat probleem nu al redelijk ondervangen, want als je een image terugzet dan wordt de hele partitie gewist en de image wordt aaneengesloten teruggeplaatst. Dit betekent in de praktijk dat je de nadelen van enige weken/maanden zonder Trim volledig teniet doet, omdat de schijfcontroller van de SSD dan weer volledig op de hoogte is van de vrije sectoren (dat is nl. exact wat Trim ook doet: de schijfcontroller vertellen welke sectoren weer vrij zijn om zonder eerst te wissen opnieuw beschreven te kunnen worden). Met andere woorden: je kan door periodiek een image terug te zetten de SSD weer "als nieuw" laten functioneren. Intel noemt dit Secure Erase, maar in beginsel is het effect hetzelfde. Ik moet hier nog maar eens goed over nadenken, temeer daar ATI en Linux nou niet bepaald de beste vrienden zijn.

Alvorens de volgende stap te zetten is het denk ik verstandig dit alles nog eens goed te overdenken.

ko · 14 sep 2010

jtech zei:
[............................]
Met andere woorden: je kan door periodiek een image terug te zetten de SSD weer "als nieuw" laten functioneren. Intel noemt dit Secure Erase, maar in beginsel is het effect hetzelfde. Ik moet hier nog maar eens goed over nadenken, temeer daar ATI en Linux nou niet bepaald de beste vrienden zijn.

Alvorens de volgende stap te zetten is het denk ik verstandig dit alles nog eens goed te overdenken.

Lijkt mij ook een verstandige overweging.

re. trim: hoe heb je de linux partities origineel geformatteerd? EXT4? of EXT3?
Beide filesystems zijn 'journaling systems' en behoeven eigenlijk niet ge-defragmenteerd te worden.
Zijn SSD's zoveel gevoeliger (performance-wise) voor defragmentering dan 'normale' harddisks? Of begrijp ik het verkeerd?

Ik onthoud mezelf van ATI-bashing [want nVidia is ook niet alles hoor...], maar ik heb diverse horrorstories over jouw high-end "RadeonHD 5850 en Linux" voorbij zien komen vandaag in Google search.
Ik prefereer low-end, low price nvidia cards die passen bij mijn beperkte grafische performance-eisen (ben geen games-player).

OK - laat me maar een keer weten wat/hoe je verder wilt.

Ko

jtech · 14 sep 2010

re. trim: hoe heb je de linux partities origineel geformatteerd? EXT4? of EXT3?
Beide filesystems zijn 'journaling systems' en behoeven eigenlijk niet ge-defragmenteerd te worden.
Zijn SSD's zoveel gevoeliger (performance-wise) voor defragmentering dan 'normale' harddisks? Of begrijp ik het verkeerd?

Ext4, mede met het oog op (toekomstige) ondersteuning van Trim. Ext4 ondersteunt dat zondermeer, alleen ondersteunt Linux als geheel het pas sinds kernelvs. 2.6.34.

Het zit ongeveer zo: SSD's bestaan uit flashchips en die hebben per definitie een beperkte levensduur als het gaat om het aantal keren dat ze beschreven kunnen worden. Wat een SSD-controller dan ook doet is zo weinig mogelijk naar dezelfde (cluster van) cellen schrijven. Dit staat bekend als wearleveling. Het probleem dat hierbij echter optreedt is dat de controller er geen weet van heeft als ik als gebruiker via het OS bepaalde files delete. De controller denkt dan nog steeds dat die cellen niet beschikbaar zijn en probeert dus de schrijfactie zodanig te regelen dat er steeds lege cellen worden gebruikt. Dit is cruciaal voor de snelheid, want i.t.t magnetische schijven moeten flashchips eerst worden gewist voordat ze kunnen worden beschreven (denk hierbij aan de abominabel slechte transferspeed van de meeste goedkope USB sticks). Trim is een ATA command dat ervoor zorgt dat de controller direct op de hoogte wordt gebracht van het feit dat bepaalde cellen weer kunnen worden beschreven nadat ik als gebruiker (of het systeem zelf for that matter) een aantal files heb verwijderd. In feite zegt het OS tegen de SSD controller: dit zijn vanaf nu lege cellen, dus ga je gang.

Overigens valt het wel mee met de slijtage van flashchips en moet je wel heel erg tekeer gaan wil je bereiken dat bepaalde chips voorgoed niet meer zijn te gebruiken. Intel gaat voor de MLC chips (goedkopere variant i.t.t. SLC) uit van minimaal 10.000 keer beschrijven. Bij een schijf van 80 GB heb je het dus over max 80*10000= 800.000 GB = 800 TB aan maximale schrijfcapaciteit voordat alle chips kunnen worden afgeschreven. Dit is wel een theoretisch maximum, want in het kader van wearleveling worden door de controller ook vrijwel permanent gegevens verplaatst. Maar dan nog is het vrijwel uitgesloten dat je een SSD binnen de economische levensduur volledig op z'n knieën krijgt, althans bij normaal gebruik. Een SSD in een server kan best na 2-3 jaar op zijn einde lopen, maar dat wordt over het algemeen niet gezien als een echt nadeel, omdat de normale HDD's in servers ook regelmatig worden vervangen om de kans op downtime tot een minimum te beperken. Wat je echter wel ziet is dat de snelheid dramatisch kan teruglopen als de controller van de SSD denkt te weinig vrije cellen ter beschikking te hebben.

@(De)fragmentatie: het leuke aan SSD's is met name de toegangstijd van ~0.10 ms (een snelle 7200 RPM HDD mag blij zijn als hij 12-14 ms haalt/een supersnelle WD Velociraptor zit op zo'n 7 ms). Deze snelheid wordt bereikt doordat een SSD totaal geen bewegende delen (lees-/schrijfkoppen gemonteerd op een arm) heeft. Fragmentatie is bij een SSD dan ook totaal geen issue. Defragmentatie is dan ook onnodig en vanuit het oogpunt van slijtage (zie boven) zelfs heel sterk af te raden. Een OS als Win 7 schakelt dan ook automatisch defragmentatie uit als het een voldoende snelle SSD ontdekt.

ko · 14 sep 2010

jtech zei:
Ext4, mede met het oog op (toekomstige) ondersteuning van Trim. Ext4 ondersteunt dat zondermeer, alleen ondersteunt Linux als geheel het pas sinds kernelvs. 2.6.34.
[.......................]

Bedankt voor je uiteenzetting over de beperkte beschrijfbaarheid van SSD's. Zal in desktops inderdaad niet zo'n vaart lopen.

re: EXT4 en Linux kernelversie 2.6.34 : het is echt wel mogelijk om EXT4 te gebruiken met kernel 2.6.32.
Ik gebruik EXT4 in enkele op mijn testsysteem geinstalleerde distros:
Mint 9 Debian-based: 2.6.32-5-686 en
Mint 9 KDE4: 2.6.32-21-generic

Ko

Upgrade linuxkernel ivm Trim ondersteuning

ko

jtech

jtech

ko

jtech

ko

Bijlagen

jtech

ko

jtech

ko

Deel deze pagina