[Gelöst] Samsung 840 EVO - 3.16.7-21-desktop;

revealed · 6 Aug. 2015

Nein trimm muss ich später dann nicht mehr jeden Tag ausführen. Aktuell tue ich dies aber definitiv zur Fehlersuche.

Danke für die Bestätigung.; .... ehm Nvidia Treiber? --- Werd ich schon sehen dann.

Gruß,

R

josef-wien · 6 Aug. 2015

revealed schrieb:
KERNEL:HEAD

Dort gibt es den letzten release candidate. Einen stabilen findest Du in http://download.opensuse.org/repositories/Kernel:/stable/standard/ bzw. http://download.opensuse.org/tumbleweed/repo/oss/.

revealed schrieb:
Nvidia Treiber?

Selber übersetzen.

Anonymous · 6 Aug. 2015

revealed schrieb:
ehm Nvidia Treiber? --- Werd ich schon sehen dann.

Wenn der im Kernel 4.1 Verhandene läuft, genügt das doch vorerst.
Ob sich die SUSE13.2-Quellen des nVidia-Repo für Kernel 4.1 übersetzen lassen, musst Du ausprobieren.

revealed · 6 Aug. 2015

Ah lol das war jetzt ein unwanted WIN:

Code:

 libata: Blacklist queued TRIM on all Samsung 800-series
  (bnc#930599)

In kernel head in:
3.16.7-97.gec183cc-desktop #1 SMP PREEMPT

Frage mich, wann der per update reinschneit dann könnte ich das "HEAD" wieder deaktivieren.

Code:

Do 21 Mai 2015 14:00:00 CEST

??? Waaaaaas? Dann hätte der Kernel aus update doch schon tun müssen?

Gruß,

R

Anonymous · 6 Aug. 2015

Also Problem bald gelöst?
Woher hast Du diese Info zum 3.16.7-97.gec183cc ?

revealed · 6 Aug. 2015

Yast Änderungsprotokoll.

Entschuldige bitte, dich nötigen zu müssen mein letztes Posting nochmal anzuschauen.

Bzw. entschuldige bitte, falls. War da seit Mai kein Update mehr für den Kernel?

Gruß,

R

Anonymous · 6 Aug. 2015

revealed schrieb:
Yast Änderungsprotokoll.

Aha. Danke.
Ich bin noch bei openSUSE 13.1.

Was steht denn bzgl. Samsung in der libata-core.c des bei Dir aktuell installieren Kernels?

revealed · 6 Aug. 2015

Warte ich zieh die source...

Code:

        /* devices that don't properly handle queued TRIM commands */
        { "Micron_M500*",               NULL,   ATA_HORKAGE_NO_NCQ_TRIM, },
        { "Crucial_CT???M500SSD*",      NULL,   ATA_HORKAGE_NO_NCQ_TRIM, },
        { "Micron_M550*",               NULL,   ATA_HORKAGE_NO_NCQ_TRIM, },
        { "Crucial_CT*M550SSD*",        NULL,   ATA_HORKAGE_NO_NCQ_TRIM, },
        { "Samsung SSD 8*",             NULL,   ATA_HORKAGE_NO_NCQ_TRIM, },

Das ist jetzt wohl gemerkt die source von dem Update aus HEAD;

Ich frage mich gerade wie lange der Patch schon drin ist. Und ob der Patch schon in dem Kernel sein sollte der aus Update kam?

Ich checks kurz... haue HEAD raus und downgrade.

Also in dem aktuellen Kernel aus dem update repository ist der Patch noch nicht drin. also im 3.16.7-21;

Jetzt ist die Frage, wie bald kann ich mit einem Update realease rechnen?
Ich bleib für heute erst mal ohne HEAD repo. Eigentlich tendiere ich eher zu weniger frequentierten repositories.

Gruß,

R

Harter tobak:
http://comments.gmane.org/gmane.linux.suse.kernel/6271

Noch eine Frage die sich auftut:
/repositories/Kernel:/stable/standard/ <- ist demnach hier: http://kernel.opensuse.org/packages/stable
Für Tumbleweed; Geht der überhaupt für 13.2? (Hab ihn probiert). Geht bei mir nicht. Da will er einige Module nicht laden. Unter anderem geht meine Tastatur /receiver combo MK700 MK710 dann nicht mehr. Und ich müsste den Nvidia Treiber selber bauen. Das ist mir dann zu viel.

Werde dann wohl mal den hier testen und alle vorigen überlegungen zurückstellen:
http://download.opensuse.org/repositories/Kernel:/openSUSE-13.2/standard/

Bzw. die Planänderung ist genannten Kernel 3.16.7-97 mit dem Patch für die Samsung 8er ohne die zuvor genutzte Kernel boot option zu probieren.

Gruß,

R

Des schaut doch schon ganz anders aus:

Code:

[    1.091265] ata2: SATA max UDMA/133 abar m2048@0xf7216000 port 0xf7216180 irq 41
[    1.396304] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[    1.396535] ata2.00: supports DRM functions and may not be fully accessible
[    1.396637] ata2.00: disabling queued TRIM support
[    1.396638] ata2.00: ATA-9: Samsung SSD 840 EVO 120GB, EXT0DB6Q, max UDMA/133
[    1.396639] ata2.00: 234441648 sectors, multi 1: LBA48 NCQ (depth 31/32), AA
[    1.396898] ata2.00: supports DRM functions and may not be fully accessible
[    1.396980] ata2.00: disabling queued TRIM support
[    1.396982] ata2.00: configured for UDMA/133

Code:

cat /sys/block/sdb/device/queue_depth

31

Noch was neues...

Code:

FADT declares the system doesn't support PCIe ASPM, so disable it

http://www.heise.de/open/meldung/Neue-Linux-Kernel-beseitigen-Stromsparproblem-1429456.html

Anonymous · 7 Aug. 2015

revealed schrieb:

Des schaut doch schon ganz anders aus:

Code:

[    1.396638] ata2.00: ATA-9: Samsung SSD 840 EVO 120GB, EXT0DB6Q, max UDMA/133
[    1.396639] ata2.00: 234441648 sectors, multi 1: LBA48 NCQ (depth 31/32), AA
[    1.396898] ata2.00: supports DRM functions and may not be fully accessible
[    1.396980] ata2.00: disabling queued TRIM support

Also Problem mit Kernel HEAD Repo doch gelöst.

—

Kernel 3.11 schrieb:
FADT declares the system doesn't support PCIe ASPM, so disable it
Disabling ASPM (FADT indicates it is unsupported)
(…) can't disable ASPM; OS doesn't have ASPM control

revealed · 7 Aug. 2015

Mit dem gepatchten 3.16.7-97.gec183cc-desktop läuft jetzt soweit.

Hast du zufällig Ahnung wie man bei den Meldungen zu ASPM vorgeht?

Gruß,

R

Code:

dmesg -t | grep -i 'error\|warn\|exception'
ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20140424/hwxface-580)
ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20140424/hwxface-580)
ACPI Warning: SystemIO range 0x000000000000f000-0x000000000000f01f conflicts with OpRegion 0x000000000000f000-0x000000000000f00f (\_SB_.PCI0.SBUS.SMBI) (20140424/utaddress-258)

Das hier ist glaube ich, weil das BIOS die gehäuselüfter steuert?

josef-wien · 7 Aug. 2015

Diese Meldungen hattest Du auch früher. Ich habe sie ebenfalls:

Code:

ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20150410/hwxface-580)
ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20150410/hwxface-580)
ACPI Warning: SystemIO range 0x000000000000F040-0x000000000000F05F conflicts with OpRegion 0x000000000000F040-0x000000000000F04F (\_SB_.PCI0.SBUS.SMBI) (20150410/utaddress-254)

Jedes BIOS ist nun einmal fehlerhaft, solche Sachen stören mich nicht, der Kernel weiß schon, was er zu tun hat.

Anonymous · 7 Aug. 2015

@revealed
Diese Fehlermeldung ist, soweit ich gesehen habe, mindestens drei Jahre alt (Intel Panther Point). Gut zu wissen, dass josef-wien sie mit Wildcat Point auch hat.

Aber ein BIOS hat Dein Mainboard keines mehr.

revealed · 7 Aug. 2015

0o wie meinst du das? Freilig hat die Kiste ein BIOS.

Gruß,

R

Anonymous · 8 Aug. 2015

Ein Basic Input Output System hat es nicht mehr.

revealed · 8 Aug. 2015

Hallo.

Die Annahme finde ich aber interessant jetzt. Auszug aus dem Datenblatt:

Code:

BIOS
 
• The motherboard BIOS provides "Plug & Play" BIOS which detects the peripheral devices and expansion cards of the board automatically.
• The motherboard provides a Desktop Management Interface(DMI) function which records your motherboard specifications.

BIOS ist AMI.

Gruß,

R

josef-wien · 8 Aug. 2015

Laß Dich von diesem i-Tüpferl-Reiter nicht in die Irre locken. Formal heißt das Ding UEFI (Unified Extensible Firmware Interface) und gilt als Nachfolger des herkömmlichen BIOS, die Hersteller verwenden aber weiterhin den Begriff BIOS oder bestenfalls UEFI-BIOS, denn im Gegensatz zum i-Tüpferl-Reiter wollen sie ihre Kunden nicht vorsätzlich verwirren.

revealed · 8 Aug. 2015

Hallo.

Dass das Board UEFI hat, ist mir klar. Dennoch spricht selbst American Megatrends auf ihrer Website in diesem Zusammenhang auch von: "BIOS and UEFI Firmware" oder "The Next Generation of UEFI BIOS".

Ich finde es keinesfalls bemängelnswert, wenn jemand sagt "BIOS".

Aber zum eigentlichen Thema. Wann denkt ihr kann ich damit rechnen dass dieser Kernelpatch ins normale Updaterepository wandert?
Von all zu wilder Repository Auswahl bin ich mit der 13.2 zwischenzeitlich geheilt.

Gruß,

R

Anonymous · 8 Aug. 2015

josef-wien schrieb:
Laß Dich von diesem i-Tüpferl-Reiter nicht in die Irre locken.

Naja: „auf i-Tüpferln herumreiten“ und „jemanden in die Irre locken“ sind zwei sehr gegensätzliche Motivationen.
Beide in Kombination verwandt — das kenne ich so nur von boshaften Menschen.

revealed schrieb:
Ich finde es keinesfalls bemängelnswert, wenn jemand sagt "BIOS".

Du könntest alternativ z.B. Mainboard Firmware sagen, oder?
Bei Dir steht das Mainboard in der Signatur. Aber generell ist es nicht egal, ob BIOS oder UEFI vorhanden ist, wenn man Hilfestellung geben möchte.

revealed schrieb:
Aber zum eigentlichen Thema. Wann denkt ihr kann ich damit rechnen dass dieser Kernelpatch ins normale Updaterepository wandert?

Es ist gerade Urlaubszeit.
Und dann steht Leap 42.1 in Kürze an: Natürlich wieder mit völlig anderen Fehlern, so dass es uns auf keinen Fall langweilig wird.

Wenn TRIM jetzt funktioniert, brauchst Du Dich ja wegen ein paar Wochen die noch verbleiben nicht extra verbiegen.
Mich würde noch interessieren, wie die fstrim-Ausgabe jetzt bei Dir aussieht.
Werden da weiterhin bei jedem Aufruf zusammengerechnet 71 GiB ±x gemeldet?

revealed · 8 Aug. 2015

Also die Menge an zu trimmendem freien Bereich ist erheblich. Da ich jetzt mit diesem Kernel beobachten konnte, dass mein dailycron läuft werde ich diesen auf einen Wöchentlichen statt täglichen zyklus umstellen. Mit "discard" möchte ich nicht arbeiten, nachdem ich einiges über dessen funktionsweise und Nutzen gelesen habe.

Ich will jetzt nicht frech sein, aber muss ich Firmware sagen? Ich wollte keine Grundsatzdiskussion über Therminilogie führen. Bitte verzeiht mir das. Ich seh das nur alles nicht so eng.

BIOS - UEFI - EFI - Firmware - ? Und ich vermute wie gesagt, S1 S2 wird nicht gefunden da mein Rechner für S5 optimiert ist. Und die conflicting region müsste dem zugrunde legen, dass AMI - BIOS - UEFI - EFI - Firmware ? das steuern der Gehäuselüfter übernimmt. Dies zwar von aussen zulassen kann. Prinzipiell ist das aber für eine MSI eigene Software vorgesehen.

-- hoffe zumindest, dass es keine größeren Probleme damit gibt. Weil ich habe eh schon den verdacht, wenn man das jetzt fixen würde und dann käme ein BIOS update das von neuem benötigt sein könnte.

Oder siehst du meine verballerte Einstellung dazu und möchtest mir sagen, es könnte viel einfacher sein?

Gruß,

R

PS.: Jetzt macht man es den Kids mit einer umstellung von GB auf GiB schon einfacher und dann wird man im Gegenzug konfrontiert, weil man sich herausnimmt einen Begriff wie BIOS zu verwenden. Und meines Wissensstandes ist es einfach völlig korrekt BIOS zu sagen. Und selbst wenn es nicht korrekt ist, tue ich es trotzdem. :down:

Und ich bitte es zu entschuldigen, dass ich keinen Hochschulabschluss habe und eine Schreibschwäche.

Letzter automatischer Trim:

Code:

*** Sat, 08 Aug 2015 20:00:47 +0200 ***
/: 21.3 GiB (22834040832 bytes) trimmed
/home: 49.6 GiB (53231038464 bytes) trimmed

Wobei sehr viel Bewegung bis zu dem Trim auf dem Datenträger war, da ich erst KDE upgegraded dann downgegraded und die Paketauswahl grundlegend ändern musste und das einiges nach sich zog. Deswegen scheint mir das durchaus realistisch.

Anonymous · 9 Aug. 2015

revealed schrieb:
Letzter automatischer Trim:

Code:

*** Sat, 08 Aug 2015 20:00:47 +0200 *** /: 21.3 GiB (22834040832 bytes) trimmed /home: 49.6 GiB (53231038464 bytes) trimmed

Wobei sehr viel Bewegung bis zu dem Trim auf dem Datenträger war, da ich erst KDE upgegraded dann downgegraded und die Paketauswahl grundlegend ändern musste und das einiges nach sich zog. Deswegen scheint mir das durchaus realistisch.

So, jetzt habe ich ein Problem.
Da habe ich avd700 nämlich zur TRIM-Menge Unsinn erzählt!

Was fstrim mit der Option -v ausspuckt, ist tatsächlich die Größe des jeweiligen Dateisystems und nicht die Anzahl der auf der SSD freigewordenen Bytes. Deine letzte Ausgabe hat mir eben das nochmal bestätigt. Außerdem liefert:

»man fstrim« schrieb:
fstrim will report the same potential discard bytes each time, but only sectors which had been written to between the discards would actually be discarded by the storage device.

Und ich war immer der Meinung, dass es anderes herum sei und hatte mir dazu die fstrim-Ausgabe im wiki.ubuntuusers.de/SSD/TRIM eingepägt:

wiki.ubuntuusers.de/SSD/TRIM schrieb:
Eine Ausgabe (von /sbin/fstrim -v) sieht dann z.B. so aus:

*** Sun, 12 Oct 2014 12:51:07 +0200 ***
/: 290,9 MiB (305029120 bytes) trimmed
/home: 116,4 MiB (122036224 bytes) trimmed

Nun: Ein root-Dateisystem, welches insgesamt nur aus 290,9 MiB besteht, wäre für mich absurd.

[Gelöst] Samsung 840 EVO - 3.16.7-21-desktop;

Guru

Ultimate Guru

Anonymous

Gast

Guru

Anonymous

Gast

Guru

Anonymous

Gast

Guru

Anonymous

Gast

Guru

Ultimate Guru

Anonymous

Gast

Guru

Anonymous

Gast

Guru

Ultimate Guru

Guru

Anonymous

Gast

Guru

Anonymous

Gast