Külső SSD egység csak második csatlakoztatásra működik

Fórum: 

Külső, USB3-n keresztül csatlakoztatott SSD egység elsőre nem működik.

A Nemoban látszik ugyan a Devices alatt (nagy sokára), de nem látszik mellette a kilökő
nyilacska sem, és ha rákattintok, nem történik semmi.
Ha jobb egérrel a Mount parancsot adom ki, akkor hibaüzenetet kapok: Unable to mount ...,
An operation is already pending. Ha ugyanitt azt mondom, hogy Safely remove, akkor
Error mounting /dev/sdb1 at media/... a hibaüzenet stb.  ugyanakkor jön egy rendszerüzenet is,
hogy ... can be safely unplugged.

Ha ezek után kihúzom az egységet és visszadugom, akkor azonnal működik.

A gép bekapcsolása után a fenti folyamat mindig ugyanígy játszódik le.

Viszont ha nem ez az egység volt először bedugva, hanem egy másik pendrive vagy
külső vinyó, akkor már az SSD is elsőre működik.

Operating System: Linux Mint 20.3
Kernel: Linux 5.4.0-99-generic
Architecture: x86-64

EDITION="Cinnamon"

Ez még mindig az Asrock gép?

Sokat gondolkodtam a dolgon, de kb. az lehet, hogy új táp kellene.

Olyan, mintha az USB tápellátás ingadozna. Pontosabban az energiatakarékos üzemmódból lassan ébred fel. Bár ennek a külső merevlemez ellentmond.

Lehetne egy dmesg, közvetlenül azután, hogy bedugod az SSD-t?

Értékelés: 

0
Még nincs értékelve
kimarite képe

Asrock | dmesg

#2 Az első dmesg kimeneten a 829. sortól ismétlődő hibák:

[ 21.756748] sd 4:0:0:0: Attached scsi generic sg1 type 0
[ 21.765445] sd 4:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB)
[ 21.765521] sd 4:0:0:0: [sdb] Write Protect is off
[ 21.765523] sd 4:0:0:0: [sdb] Mode Sense: 43 00 00 00
[ 21.765682] sd 4:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 21.765883] sd 4:0:0:0: [sdb] Optimal transfer size 33553920 bytes
[ 21.795020] sdb: sdb1
[ 21.810004] sd 4:0:0:0: [sdb] Attached SCSI disk
[ 21.816314] sd 4:0:0:0: [sdb] tag#1 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 21.816320] sd 4:0:0:0: [sdb] tag#1 Sense Key : Aborted Command [current]
[ 21.816325] sd 4:0:0:0: [sdb] tag#1 Add. Sense: Information unit iuCRC error detected
[ 21.816330] sd 4:0:0:0: [sdb] tag#1 CDB: Read(10) 28 00 00 00 00 28 00 00 10 00
[ 21.816337] blk_update_request: I/O error, dev sdb, sector 40 op 0x0:(READ) flags 0x80700 phys_seg 2 prio class 0
...

... aztán ide torkollik,

[ 52.661991] xhci_hcd 0000:00:14.0: bad transfer trb length 3584 in event trb
[ 52.662817] xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 1
[ 52.662820] xhci_hcd 0000:00:14.0: Looking for event-dma 000000015fdf8d20 trb-start 000000015fdf8d30 trb-end 000000015fdf8d30 seg-start 000000015fdf8000 seg-end 000000015fdf8ff0

mígnem jó. Az SCSI közvetlen a gépben van?

[ 134.175660] scsi host4: uas
[ 134.176501] scsi 4:0:0:0: Direct-Access ASMT USB 3.0 Destop H 0 PQ: 0 ANSI: 6

A lemez állapotát nézted? Másik USB kábel?

Értékelés: 

0
Még nincs értékelve

Asrock | dmesg

#2.1

"Az SCSI közvetlen a gépben van?" Kérdésre nemigen tudok válaszolni, mert nem értem. Ha esetleg arra gondolsz, hogy a gépben van egy másik SSD, akkor igen.

A külső lemez új, állapotát Windows alatt a Crystaldiskinfo tökéletesnek mutatja. Sajnos másik apa-apa USB csatlakozóm nincs, ezt adták az SSD tokhoz.

Egy másik gépen Windows alatt általában elsőre működik az eszköz, ámbár időnként ott is várni kell azért mondjuk 1-2 percet, többet mint normális esetben egy pendrájvra vagy külső vinyóra.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Asrock | dmesg

#2.1.1 Amit lala írt (UASP, TRIM) azt próbáltam megfogalmazni, elég körülményesen. Arra gondoltam, hogy külső SATA átalakítód vagy USB HUB-od van, szóval ~eszköz hiba :). Valami gond van itt, nem egy-két perc semelyik operációs rendszeren a külső meghajtó befűzése. Nemrég vettem egy, nem túl márkás külső házat, és a fájlrendszerhibás, de 1 TB-os HDD-met szinte azonnal befűzi a rendszer. És biztos, hogy kevesebb, mint 1 percet kell várni a fájlkezelőben a fájlok és mappák mutatására, de csak akkor, ha valamelyik könyvtárat megnyitom. Amúgy minden könyvtár azonnal megjelenik. És igen, tápellátás gond is lehet, tapasztalat sajnos.

Értékelés: 

0
Még nincs értékelve

Asrock Asrock Asrock Asrock

#2
A 2 dmesg kimenet különbsége ?

amikor még nem működik a drive:
dmesg > dmesg1

Kihúz és visszarak és rögtön jó lesz, utána ismét a dmesg:
dmesg > dmesg2

A 2 közti különbség:
diff dmesg1 dmesg2

Ennek mi a kimenete ?

Más:
Ebbe a külső USB-s házba Te tetted az SSD-t ?
A kézi trim lefut ?
sudo fstrim -av

Értékelés: 

0
Még nincs értékelve

dmesg - fstrim

#2.2

Az előző két dmesg különbsége:
https://pastebin.com/6huW6sHU

Érdekes, amíg megírtam az előző választ eltelt egy kis idő, és aztán beraktam a SSD-t és elsőre jó lett.
Fejvakar...
?

A házba én operáltam bele az SSD-t.

Lefutott ez a parancs:
sudo fstrim -av
eredmény:
/boot/efi: 511 MiB (535801856 bytes) trimmed on /dev/sda1
/: 97,8 GiB (105041530880 bytes) trimmed on /dev/sda5

Nem tudom, ez jó-e?

Értékelés: 

0
Még nincs értékelve

dmesg - fstrim

#2.2.1

Igen, ez jónak látszik !
Azért kérdeztem, mert sok USB3-as külső ház nem támogatja az UASP-t, és a TRIM-et.
Az ilyen házakba tett SSD-ket lassan "gyilkolják" a házak.
Nem "engedik át magukon" a SATA-s trim parancsot.

Értékelés: 

5
Átlag: 5 (1 szavazat)

dmesg - fstrim

#2.2.1.1

Ezt nem nézted el? Most utánakeresgéltem és valóban azt írják például a Prohardveres tesztekben, hozzászólásokban, hogy a külső házak általában nem engedik át a trimet. Szerintem nekem sem, itt mintha nem is látszódna. Az sdb volna a külső ssd, ami az fstrimnél nem látszik:

Ez a belső ssd-m, Adata, 128GB:

[    1.045831] scsi 2:0:0:0: Direct-Access     ATA      ADATA SU800      3A   PQ: 0 ANSI: 5
[    1.046005] sd 2:0:0:0: Attached scsi generic sg0 type 0
[    1.046073] sd 2:0:0:0: [sda] 250069680 512-byte logical blocks: (128 GB/119 GiB)
[    1.046083] sd 2:0:0:0: [sda] Write Protect is off

...

Ez meg a külső Crucial, 1GB:

[   21.756276] scsi 4:0:0:0: Direct-Access     ASMT     USB 3.0 Destop H 0    PQ: 0 ANSI: 6
[   21.756748] sd 4:0:0:0: Attached scsi generic sg1 type 0
[   21.765445] sd 4:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB)

 

sudo fstrim -av
/boot/efi: 511 MiB (535801856 bytes) trimmed on /dev/sda1
/: 97,8 GiB (105041530880 bytes) trimmed on /dev/sda5

 

Azt nem tudom, miért csinált a Linux két ilyen sorszámú partíciót, én nem adtam meg semmit.

 

Értékelés: 

0
Még nincs értékelve

dmesg - fstrim

#2.2.1 gondolom az sda az a gépben levő, az sdb pedig a külső SSD. Utóbbival kapcsolatban egy csomó I/O errror hibát jelez mindkét dmesg. Lehet vacak a kábel, hibás a ház, vagy hibás az SSD, ami benne van, vagy csak tényleg nem jut elég áramhoz.

Azt kideríteni, hogy ezek közül melyik a hunyó, elég körülményes, de azzal kezdeném, hogy ssd-t beszerelném a gépbe, ráfuttatnék ellenőrzést, majd dmesg, aztán merevlemezt a házba, próba, dmesg, nézni van-e sdb hiba (pirossal jelzi a dmesg), másik házba tenni az SSD-t....

Az, hogy új a ház, nem jelent semmit, nekem is volt olyan, hogy vadi új ház hibás volt, gariba cserélték másikra, az már jó volt.

Értékelés: 

0
Még nincs értékelve
kimarite képe

options usb-storage quirks=****:****:u

#2.2.1.2 Az uas driverrel és az USB v3-mak függhet esetleg össze a történet. Ez Raspbian, de (a megoldások nem ugyanazok): https://github.com/raspberrypi/linux/issues/3070#issuecomment-720122515
https://forums.raspberrypi.com/viewtopic.php?t=245931 )

To fix it I had to update the firmware from version 2.04 to version 5.08, and now TRIM works.
  • Connecting it to the USB3 ports, it is well recognized as Driver=uas, but generates many errors such as uas_eh_abort_handler, uas_eh_device_reset_handler, uas_zap_pending, etc... not very reassuring.
$ lsusb
Bus 002 Device 002: ID 152d:1576 JMicron Technology Corp. / JMicron USA Technology Corp.

$ lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
    |Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
  • I have also tested the Quirk mode and the adapter works better but in Driver=usb-storage, however in this mode TRIM is not possible anymore
  • Next I have connected it to the USB2 ports and... everything works fine !
    Driver=uas ok
    TRIM ok
    and no more uas_* errors
    But the access times are not so good

Egy módszer, természetesen az eszköz ID-it át kell írnod (lsusb -t)!
https://ubuntuforums.org/showthread.php?t=2307662&s=58707fd4e632aad12be825872572c3ee&p=13421453#post13421453
https://unix.stackexchange.com/questions/441668/debian-usb3-hdd-uas-i-o-errors

echo options usb-storage quirks=357d:7788:u | sudo tee /etc/modprobe.d/blacklist_uas_357d.conf
sudo update-initramfs -uk all
sudo systemctl reboot # rendszer újraindítás

Lényegében, itt is ugyanaz a javaslat (említi a  GRUB-ot, ott máshogy néz ki a  kifejezés):
https://leo.leung.xyz/wiki/How_to_disable_USB_Attached_Storage_(UAS)

Nézni kéne a TRIM-et utána..., állítólag, az usb_storage nem tudja.

Másik módszer lehet,
https://unix.stackexchange.com/a/593970
mondjuk, az nem jó jel, hogy az elérési út, sem részlete az én rendszeremen nem létezik. Úgyhogy, felejtsük el (ebben a formában).

/sys/module/usb_storage/parameters/quirks

Értékelés: 

0
Még nincs értékelve
kimarite képe

options usb-storage quirks=****:****:u

#2.2.1.2.1 A parancssort itt korrigálom. Nem is figyeltem, hogy nem tette macskakörömbe... :(

echo "options usb-storage quirks=357d:7788:u" | sudo tee /etc/modprobe.d/blacklist_uas_357d.conf
sudo update-initramfs -uk all
sudo systemctl reboot # rendszer újraindítás

Tehát az ID-ket szerkeszteni kell.

Off: hm, nem írja külön... (teszt)

echo "options usb-storage quirks=357d:7788:u"
options usb-storage quirks=357d:7788:u
echo options usb-storage quirks=357d:7788:u
options usb-storage quirks=357d:7788:u

Ha a szóközös sorokat macskakörmök közé zárod, biztos nem lesz baj, mert az echo egy sornak veszi.

Értékelés: 

5
Átlag: 5 (1 szavazat)

options usb-storage quirks=****:****:u

#2.2.1.2.1.1

Ezt a három lépést megcsináltam (echo, update, reboot).

Utána rögtön jó lett az eszköz elsőre.

Rendes ki- és visszakapcsolás után is rögtön jó.

Pár nap múlva kiderül, hogy akkor ez lett-e tényleg a megoldás.

Akár az lesz, akár nem, köszönöm az erőfeszítésedet, hogy alaposan utánajártál a problémának.

Értékelés: 

0
Még nincs értékelve
kimarite képe

options usb-storage quirks=****:****:u

#2.2.1.2.1.1.1 Ok.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Viszont ha nem ez az egység volt először bedugva, hanem egy mási

Viszont ha nem ez az egység volt először bedugva, hanem egy másik pendrive vagy
külső vinyó, akkor már az SSD is elsőre működik.

Húzz le mindent, és a rendszert indítsd újra.

Dugd be a másik pendrive-ot vagy merevlemezt és

dmesg

Húzd ki a fentieket, dugd be az SSD-t -amit tesztelük- és

dmesg

... kimenet.

#2.2.1.2.1.1   Mutatnál kimenetet erről is(fájl tartalom lesz)?

cat /etc/modprobe.d/blacklist_uas_357d.conf

Értékelés: 

0
Még nincs értékelve

egy teszt

1. telepíteni a smartmontools csomagot:

sudo apt install smartmontools

2. Majd SSD-t bedugni, ha nem csatolja, kivenni, újra bedugni és:

sudo smartctl -t short /dev/sdb

3. Várni, ez pár percet igénybe vesz, az üzenet jelez egy időpontot, akkor lesz kész, azután még egy perc, majd:

sudo smartctl -a /dev/sdb

Amit mutat, pasztázni....

Értékelés: 

0
Még nincs értékelve

egy teszt

#3

Az eredmény:

https://pastebin.com/z6ByEKLk

Értékelés: 

0
Még nincs értékelve

egy teszt

#3 túl hamar lett kiadva az utolsó parancs, a teszt nem futott le.

Több időt kellene neki hagyni.

SMART adatsor:

UDMA_CRC_Error_Count 0x0032 100 100 000 Old_age Always - 358

Ez kábel hibára utal.

Értékelés: 

0
Még nincs értékelve

egy teszt

#3.2

Újabb teszt eredmény:

https://pastebin.com/U0j3rK5Z

Értékelés: 

0
Még nincs értékelve

első csatlakozási kísérletek

Nemigen volt időm, de ma rögtön becsatolta az SSD-t, viszont tegnap nem. A héten nem volt rá lehetőség többet próbálkoznom. Ugyanakkor tegnap benn hagytam sokáig és valahány perc múlva (nem mértem, mert nem számítottam rá), talán 5-10 perc múlva mégis becsatolta elsőre. Szóval úgy tűnik talán dolgozik az elsőre is, csak nagyon sokat kell várni.
Egyszer megpróbáltam még a hátsó USB-ben (sajnos nincs szabad, ki kellett húznom a billentyűzetet), ott is működött rögtön.

Értékelés: 

0
Még nincs értékelve

Ez az SSD kétszer látszik a Double Commanderben

Még egy feature, azaz tény, tulajdonság, de hogy hiba-e, azt nem tudom.

Csak ez az egy SSD egység a Double Commanderben kétszer látszik. A többi külső meghajtóm nem. Az egyik meghajtó mounted azaz élő, működő, a másik unmounted állapotú. Abban az esetben, amíg a drive még ex-lex állapotú, azaz meghajtás alatt van :-), szóval akkor is kétszer látszik, csak akkor persze egyik sem működik.

El tudom nyomni az Options-Behaviors-Automatically Hide Unmonted Devices opcióval, szóval nem zavaró, csak írtam, hogy ilyen is van.

A Nemoban vagy a Krusaderben csak egyszer látszik.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Ez az SSD kétszer látszik a Double Commanderben

#4 Tehát reboot után jó és kikapcsolás, bekapcsolás után is jó? Hibernálás, suspend - szoktad valamelyiket vagy csak újraindítás és kikapcsolás?

Ezt a három lépést megcsináltam (echo, update, reboot).

Utána rögtön jó lett az eszköz elsőre.

Rendes ki- és visszakapcsolás után is rögtön jó.

#5 Automatically hide unmounted devices ( * )

Ha azt mondod, a Double Commander normális működése az, hogy a leválasztott meghajtót kétszer is mutatja,

Csak ez az egy SSD egység a Double Commanderben kétszer látszik. A többi külső meghajtóm nem.

de ezt is mondod,

Az egyik meghajtó mounted azaz élő, működő, a másik unmounted állapotú.

akkor kérdezem, a másik külső meghajtót hova dugod be egyszerre ezzel az SSD-vel? Mert korábban azt írtad, egy USB van elől, és egy USB hátul (amit a billentyűzet használ, azaz, nincs hova bedugni kettő külső meghajtót :)

Értékelés: 

0
Még nincs értékelve

Ez az SSD kétszer látszik a Double Commanderben

#5.1

Nem tudok határozott válaszokat adni, de ahogy telik az idő és egyre több a tapasztalat, ezeket tudom mondani:

Egyre inkább úgy látom, hogy elsőre is mindig jó, csak sokat kell várni, akár 10 percet is. Néha viszont nem kell várni és azonnal használható, de az első eset gyakoribb. Ha volt olyan, hogy újraindítás után is rögtön jó, akkor ezek valószínűleg független események lehettek. A ki és behúzás után is sokszor rögtön jó lett, de ez sem segített mindig.

Csak az újraindítás és a kikapcsolás funkciókat használom.

 

A másik kérdésre az a válasz, hogy soha nem dugok be egyszerre két meghajtót. Csak az egyetlen problémás SSD látszik kétszer és az egyik mounted a másik unmounted állapotú a Double Commanderben. Persze csak akkor, amikor már becsatlakozott az SSD. Amíg nem csatlakozott be, addig is kétszer szerepel, csak persze mindkettő unmounted.

 

Értékelés: 

0
Még nincs értékelve
kimarite képe

Ez az SSD kétszer látszik a Double Commanderben

#5.1.1 Mindkét külső lemeznél mutatnál kimenetet erre?

sudo fdisk -l

Értékelés: 

0
Még nincs értékelve

Ez az SSD kétszer látszik a Double Commanderben

#5.1.1.1

Nincs két külső lemez csak egy. Az ADATA SU800 a belső lemez.

Íme a kimenet:

Disk /dev/sda: 119,25 GiB, 128035676160 bytes, 250069680 sectors
Disk model: ADATA SU800     
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0cd3f05d

Device     Boot   Start       End   Sectors   Size Id Type
/dev/sda1  *       2048   1050623   1048576   512M  b W95 FAT32
/dev/sda2       1052670 250068991 249016322 118,8G  5 Extended
/dev/sda5       1052672 250068991 249016320 118,8G 83 Linux

Disk /dev/sdb: 931,53 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: USB 3.0 Destop H
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 33553920 bytes
Disklabel type: dos
Disk identifier: 0x3be2f40a

Device     Boot Start        End    Sectors   Size Id Type
/dev/sdb1        2048 1953521663 1953519616 931,5G  7 HPFS/NTFS/exFAT

 

Értékelés: 

0
Még nincs értékelve
Koppány képe

Ez az SSD kétszer látszik a Double Commanderben

#5.1.1.1.1

Arra gondolsz hogy így jelenik meg példa:

"Sdc" és még egyszer mint "sdc1" ??

Értékelés: 

0
Még nincs értékelve
kimarite képe

Ez az SSD kétszer látszik a Double Commanderben

#5.1.1.1.1.1 Ahh, köszi, az „emlékeztetőt”. Igen, én kihagytam véletlenül -elfelejtettem- hogy a Live USB-s telepítők nem egyszer jelennek meg a fájlkezelőkben. A formázás miatt, van ilyen is, és olyan is, mármint, partíció az USB-s telepítőn. De, ha ilyesmi lenne, akkor a többi fájlkezelő is ugyanígy mutatná.

#5.1.1.1.1 HPFS/NTFS/exFAT

Windows rendszeren is használod? Van valami olvasási, írási gond mindentől függetlenül. Én arra gyanakszom, ez áll az olykor soká tartó befűzés mögött (a dmesg-t is néztük, a kimenet mutatta). Tehát, ha nem partíció hiba, akkor valamilyen fájl vagy könyvtár sérült... . Nekem egy ilyen volt egy elromlott HDD-n, egy magazin összes kiadása tömörítve, nem is tudtam átmásolni, elméletileg elveszett, gyakorlatilag valaki, valahol közölte a legális letöltési linket. Nem innen, mert csak a negyede volt méretben. :) (habár lehet, ha letöltöm a torrentet, meglátom, mennyi)

A Double Commander nem tudom, miért mutatja kettőzöttként, hiba lehet.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Ez az SSD kétszer látszik a Double Commanderben

#5.1.1.1.1.1.1 Esetleg betetted a lemezt „könyvjelzőként” is a Double Commanderben?
Példa: https://doublecmd.github.io/doc/en/help.html#mnu_fav
Csak találgatok, nem használom a DC-t.

Értékelés: 

0
Még nincs értékelve

Ez az SSD kétszer látszik a Double Commanderben

#5.1.1.1.1.1.1
Igen, Windowsos gépen is használom és eleve ott lett formázva.
Hűha, most jutott eszembe, hogy ez egy formázatlan lemez volt és először a Linuxos gépen formáztam, de hiába lett NTFS, a Windows nem látta. Ezért újraformáztam Windows alatt, ami már működött Linux alatt. Hátha megjegyzett valamit a Mint rendszer magának?

Ha hibás fájl vagy folder van rajta, akkor érdemes letörölni mindent róla és újra felmásolni? Hát az el fog tartani jó sok óráig...

Értékelés: 

0
Még nincs értékelve
kimarite képe

Ez az SSD kétszer látszik a Double Commanderben

#5.1.1.1.1.1.1.2 Írtam még egy hozzászólást is.

Én gondolkodom, Bluray DVD ROM vásárlásán, adatmentés céljából. 25 GB (vagy 50 GB) kicsit több dologra elegendő, de olykor még ez is kevés lehet :), azonban személyes, fontos dolgokra éppen elég. Igazából, az árán kívül az optikai írási tulajdonsága tart vissza, mert ugyan több, mint tíz éves DVD-im simán visszaolvashatóak, de az optikai fej el szokott mászni, mondhatni az adathordozó túléli az írót. Még mindig a HDD a legolcsóbb, és tárolásra, mentésre is biztonságos: https://www.rentit.hu/hu-HU/Cikk/erdekessegek/az-adattarolas-fejlodese.rentit
https://www.mogi.bme.hu/TAMOP/mikromechanika/ch08.html
Vagy a felhő, ami például a nagy testvérnél (G) olcsó, de benne van, hogy eladod a „lelkedet is”.

#5.1.1.1.1.1.1.1.1 Akkor nem ez okoz duplázást.

Értékelés: 

0
Még nincs értékelve

Ez az SSD kétszer látszik a Double Commanderben

#5.1.1.1.1.1 Szerintem az a kolléga baja mint ami nálam jelentkezik kb. 1-2 havonta.
Mindegy milyen lemez, nekem előszeretettel duplikálja a belső sata SSD összes partícióját is meg a külső lemezeimet is. 

Meg kéne nézni a fájlkezelőbe a /media/sajátneved alatt hogy van-e duplikált lemez amikor be van dugva.
Nálam ez így jelentkezik, 
https://mega.nz/file/V4pQSTRL#jnscdaouvv0L8koibrHvLRwbIfjW9dBvJNgxANRy1xs  
és mikor ez a hiba van, nem is tudom megnyitni a fájlkezelőbe mert a nemlétezőt akarja megnyitni.
Ilyenkor törlöm a duplikátumot de ezt nagyon figyelmesen mert ha az épp jót törlöd akkor ugrik az egész lemez vagy partíció!!Ez a duplikálás valami nyavajája a Linuxnak, legalábis az Ubuntunak mert ezt eljátssza velem a stabil 2 telepítésem 2 teljesen más pc-n és a portable Ubuntum is elég sűrűn.

A mellékelt képen látható hogy a Manjaro nevű partíció is beleragadt az agyába pedig az most nincs is csatolva lévén az egy másik lemezen van ami jelenleg 20 kilométerre van a géptől. Törlöm is.

Leírtam, hátha valami ilyesmivel küzd a kolléga is és hátha segít.

Értékelés: 

0
Még nincs értékelve

Ez az SSD kétszer látszik a Double Commanderben

#5.1.1.1.1.1.3

Köszönöm a tippet, sajnos vagy szerencsére, ezt nem tudom, de nálam a /media/sajátnevem alatt csak egyszer látszik a meghajtó.

Kimarite ötlete alapján olyannal próbálkozom majd, de ez sok idő, hogy folyamatosan kitörlök mindent a SSD-ről és újraírom, hátha tényleg van itt valami sérült bejegyzés.

Jelentkezem, ha tapasztalok valami újat.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Ez az SSD kétszer látszik a Double Commanderben

#5.1.1.1.1.1.3.1 A korábbi változtatás sikerességére keress rá, azaz, hogy milyen modul van betöltve, csak az usb-storage vagy az uas is? Csatlakoztasd a külső meghajtót, majd...

sudo lsmod | egrep -i 'uas|usb-storage'

Ez is működhet (a rendszeremen, nekem valamiért csak az egrep hatékony)

sudo lsmod | grep 'uas|usb-storage'

Aztán így is meg lehet nézni, melyik modul vezérel:

inxi -Fzxxx

Ha az uas, akkor esetleg le fogjuk tiltani.

Értékelés: 

0
Még nincs értékelve

Ez az SSD kétszer látszik a Double Commanderben

#5.1.1.1.1.1.3.1.1

Csak az egrep működött nálam is:

sudo lsmod | egrep -i 'uas|usb-storage'

uas                    28672  1
usb_storage            77824  1 uas

***

inxi -Fzxxx
System:
  Kernel: 5.4.0-100-generic x86_64 bits: 64 compiler: gcc v: 9.3.0
  Desktop: Cinnamon 5.2.7 wm: muffin 5.2.0 dm: LightDM 1.30.0
  Distro: Linux Mint 20.3 Una base: Ubuntu 20.04 focal
Machine:
  Type: Desktop Mobo: ASRock model: H110M-STX serial: <filter>
  UEFI [Legacy]: American Megatrends v: P7.60 date: 02/22/2018
CPU:
  Topology: Dual Core model: Intel Pentium G4560 bits: 64 type: MT MCP
  arch: Kaby Lake rev: 9 L2 cache: 3072 KiB
  flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 27999
  Speed: 800 MHz min/max: 800/3500 MHz Core speeds (MHz): 1: 800 2: 800
  3: 800 4: 800
Graphics:
  Device-1: Intel HD Graphics 610 vendor: ASRock driver: i915 v: kernel
  bus ID: 00:02.0 chip ID: 8086:5902
  Display: x11 server: X.Org 1.20.13 driver: modesetting
  unloaded: fbdev,vesa resolution: 1280x1024~60Hz
  OpenGL: renderer: Mesa Intel HD Graphics 610 (KBL GT1) v: 4.6 Mesa 21.2.6
  direct render: Yes
Audio:
  Device-1: Intel 100 Series/C230 Series Family HD Audio vendor: ASRock
  driver: snd_hda_intel v: kernel bus ID: 00:1f.3 chip ID: 8086:a170
  Sound Server: ALSA v: k5.4.0-100-generic
Network:
  Device-1: Intel Ethernet I219-V vendor: ASRock driver: e1000e v: 3.2.6-k
  port: f040 bus ID: 00:1f.6 chip ID: 8086:15b8
  IF: enp0s31f6 state: up speed: 100 Mbps duplex: full mac: <filter>
  IF-ID-1: ppp0 state: unknown speed: N/A duplex: N/A mac: N/A
Drives:
  Local Storage: total: 1.03 TiB used: 19.49 GiB (1.9%)
  ID-1: /dev/sda vendor: A-Data model: SU800 size: 119.24 GiB
  speed: 6.0 Gb/s serial: <filter> rev: 3A temp: 52 C scheme: MBR
  ID-2: /dev/sdb type: USB vendor: Crucial model: CT1000BX500SSD1
  size: 931.51 GiB serial: <filter> scheme: MBR
Partition:
  ID-1: / size: 116.38 GiB used: 19.49 GiB (16.7%) fs: ext4 dev: /dev/sda5
Sensors:
  System Temperatures: cpu: 51.0 C mobo: N/A
  Fan Speeds (RPM): N/A
Info:
  Processes: 196 Uptime: 8m Memory: 3.55 GiB used: 1.16 GiB (32.6%)
  Init: systemd v: 245 runlevel: 5 Compilers: gcc: 9.3.0 alt: 9 Shell: bash
  v: 5.0.17 running in: gnome-terminal inxi: 3.0.38

***

És a lemez újraírása nem segített sajnos.

Értékelés: 

0
Még nincs értékelve
kimarite képe

SSD | UAS

#5.1.1.1.1.1.3.1.1.1 Hát bizony, nem lett kikapcsolva az UAS:

sudo lsmod | egrep -i 'uas|usb-storage'

uas                    28672  1
usb_storage            77824  1 uas

Az látszik, hogy be van kapcsolva, és az usb_storage is átadja neki a stafétabotot.

Kapcsoljuk ki, Futtasd:

echo "uas" | sudo tee /etc/modprobe.d/uas_blacklist.conf

Ezután indíts újra a rendszert, és teszteld a tárolót, ahogy szoktad. Írd ide a tapasztalatokat. Van még egy javaslatom majdanra...

És mutasd a kimeneteket:

sudo lsmod | egrep -i 'uas|usb-storage'
dmesg

Értékelés: 

0
Még nincs értékelve

SSD | UAS

#5.1.1.1.1.1.3.1.1.1.1

Sajnos semmi nem változott, ugyanúgy várni kellett 5-10 percet és ugyanúgy kétszer látszik DC-ben,

és ez is maradt:

sudo lsmod | egrep -i 'uas|usb-storage'
uas                    28672  1
usb_storage            77824  1 uas

Valami új error is megjelent pirossal a végefelé, ami eddig nem volt:

https://pastebin.com/5WPk59FM

Értékelés: 

0
Még nincs értékelve
kimarite képe

Ez az SSD kétszer látszik a Double Commanderben

#5.1.1.1.1.1.3 KDE (.).

Értékelés: 

0
Még nincs értékelve

Ez az SSD kétszer látszik a Double Commanderben

#5.1.1.1.1.1.3.2 Lehet hogy KDE viszont  xfce munkamenet alatt Thunar is ugyanezt mutatja.

Ezt a show responsest nem lehet kiölni, a helyét beszántani, sóval behinteni es biztos ami biztos még felgyújtani? A show response alatt van mégegy show response, mire megtaláltam a friss hozzászólást mobilon, elkopott az ujjam az érintőképernyőn.

 

Értékelés: 

0
Még nincs értékelve
kimarite képe

Ez az SSD kétszer látszik a Double Commanderben

#5.1.1.1.1.1.3.2.1 Ezt a show responsest...

Ha van Drupal-hoz értő ismerősöd, akkor küldd. :)

viszont  xfce munkamenet alatt Thunar is ugyanezt mutatja.

Kevert rendszer. ;)

Értékelés: 

0
Még nincs értékelve
kimarite képe

Ez az SSD kétszer látszik a Double Commanderben | ntfs3

#5.1.1.1.1.1.3.2.1 A befűzést próbáld így: ntfs3

cat /usr/share/doc/linux-doc-5.15/html/_sources/filesystems/ntfs3.rst.txt
.. SPDX-License-Identifier: GPL-2.0

=====
NTFS3
=====

Summary and Features
====================

NTFS3 is fully functional NTFS Read-Write driver. The driver works with NTFS
versions up to 3.1. File system type to use on mount is *ntfs3*.
...

Az 5.15-ös kernel újítása, azaz kell hozzá minimum az 5.15-ös.
https://www.heiko-sieger.info/new-ntfs-driver-in-kernel-5-15/
https://9to5linux.com/linux-kernel-5-15-released-with-new-ntfs-file-system-in-kernel-smb-server-and-more
https://www.kernel.org/doc/html/latest/filesystems/ntfs3.html

Úgy tűnik, az épp használt kernelem nincs beállítva:

grep -Ei ntfs /boot/config-$(uname -r)
# CONFIG_NTFS3_FS is not set
[ -d "/lib/modules/$(uname -r)/kernel/fs/ntfs3" ] && echo "NTFS3 is here"
(visszatér a készenléti jelzés)

Ha nálad sincs, akkor próba, de vélhetően nem fog működni.

Értékelés: 

0
Még nincs értékelve
kimarite képe

grep -Ei ntfs /boot/config-$(uname -r)

#5.1.1.1.1.1.3.2.1.2 Az oldal alján az aktuális válaszom, ez csak jegyzet, Nálam változott a parancssor

grep -Ei ntfs /boot/config-$(uname -r)

kimenete:

CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not set
CONFIG_NTFS_RW=y
CONFIG_NTFS3_FS=m # itt
# CONFIG_NTFS3_64BIT_CLUSTER is not set
CONFIG_NTFS3_LZX_XPRESS=y
CONFIG_NTFS3_FS_POSIX_ACL=y

Itt is változás:

[ -d "/lib/modules/$(uname -r)/kernel/fs/ntfs3" ] && echo "NTFS3 is here"
NTFS3 is here

A kernel most (igazából 14):

uname -rv
5.17.0-13.1-liquorix-amd64 #1 ZEN SMP PREEMPT liquorix 5.17-17.1~bullseye (2022-06-07)

Értékelés: 

0
Még nincs értékelve
kimarite képe

Nem látom a hozzászólásodat | show responses

#6 Kedves Olsen!

Remélem, nem sértelek azzal vérig ;), hogy-véleményem szerint- egy óvodás (csak a példa kedvéért!) is észreveszi ezt az elemet, és megnyomja:
A honlap működése 1. rész: Show responses, Hide responses (válaszok)
Nem nyereményjáték, de nyersz vele! :)
Légy szíves, jegyezd meg. Nekem nem szégyen válaszolni. Kérted. ;)
Nekem a kérés nagy szégyen, adjon úgy is, ha nem kérem (Nagy László verse):
https://www.youtube.com/watch?v=9wgLaT8WLJo

Értékelés: 

0
Még nincs értékelve

Nem látom a hozzászólásodat | show responses

#6.1

Természetesen ismerem és használom a Show responses funkciót, ez a téma régóta csak így látható.

Ma reggel 8:04-kor hozzászóltam, válaszoltam neked. Ezek után ránéztem később és láttam, hogy frissült a téma, te szóltál hozzá, de a Show responses-zal sem láttam a válaszodat, ahogyan most sem látom.

Most tényleg nem tudom, hogy a 8:04-re nem válaszoltál, csak én néztem el, hogy frissült a téma, vagy válaszoltál, de eltűnt a hozzászólásod.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Nem látom a hozzászólásodat | show responses | 2022. már. 05. 08

#6.1.1 Ez alatt van a válaszom a 8:04-esre:
https://linuxmint.hu/comment/53497#comment-53497
Továbbiakban, az oldalon történő keresgélésben nem igazán tudok segíteni.

Valami új error is megjelent pirossal a végefelé, ami eddig nem volt:
https://pastebin.com/5WPk59FM

Melyik a piros?

Értékelés: 

0
Még nincs értékelve

Elveszve a fórumban

Ha kifejezetten nem ellenzed én nem használnám a Válasz funkciót, mert már elvesztem a fórumban. Valóban, már két egymásba ágyazott Show Responses volt, ezek szerint a második még többszörös átnézésre is elkerülte a figyelmemet. Most megtaláltam végre, de különösen nehéz volt, ráadásul a 8:27-es írásod nem került a 8.04-es alá, hanem több régi bejegyzés között van.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Elveszve a fórumban | Válasz elem

#7 A Válasz elem hanyagolását én, de a többiek sem szeretnénk. Nagy, átláthatatlan káosz lenne az eredménye. Maradjuk a Válasz elem használatában, és én is csak egy választ adok a továbbiakban.

Értékelés: 

0
Még nincs értékelve

piros hiba

Szerintem ez volt piros hiba (többek között), korábban ilyen durva pirosakat nem láttam:
[ 267.745028] xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 1

Értékelés: 

0
Még nincs értékelve

pendrájv dmesg eredmény

Újraindítottam, bedugtam egy pendrájvot, ami rögtön működött.

dmesg:

https://pastebin.com/f5f9EMCd

Piros hiba is volt, ilyen azelőtt nem volt:

[   78.151882] sd 4:0:0:0: [sdb] Asking for cache data failed
[   78.151889] sd 4:0:0:0: [sdb] Assuming drive cache: write through

 

Értékelés: 

0
Még nincs értékelve

SSD piros hibák

Kivettem a pendrájvot, bedugtam az SSD és megvártam, amíg feléled (5 perc)

dmesg:

https://pastebin.com/JduW0QTj

Egy csomó piros I/O hiba, ebből az utolsó:

[  554.104731] blk_update_request: I/O error, dev sdb, sector 6269832 op 0x0:(READ) flags 0x80700 phys_seg 32 prio class 0

Értékelés: 

0
Még nincs értékelve

SSD piros hibák

#10 Egy csomó piros I/O hiba

Igen, ezek ugyanazok, mint topic indítás kezdetén, február 20-án voltak. Azóta sincs újabb kábel, másik gépen kipróbálva, másik házban kipróbálva, de mind1 is, a lényeg legyen egy hiba, ami, ha sokat beszélünk róla lehet megjavul. ;-)

Értékelés: 

0
Még nincs értékelve

SSD piros hibák

#10.1

Nem írtam róla ugyan, másik két számítógépen is használom, amin Windows van, azokon tökéletesen működik ezzel a kábellal.

Értékelés: 

0
Még nincs értékelve
kimarite képe

blacklist_uas_357d.conf fájl SSD piros hibák

#11 A probléma a beállításunk eredménye.

Kapcsoljuk ki a beállítást,

sudo mv /etc/modprobe.d/blacklist_uas_357d.conf.ORIG

majd indítsd újra a rendszert.
A másik kérdésekre nem adok választ..., hiszen az a gond, hogy...

-. elkerülte a figyelmed ez a mondatom:
https://linuxmint.hu/comment/53496#comment-53496

Egy módszer, természetesen az eszköz ID-it át kell írnod (lsusb -t)!

Mocorgott már a kérdés bennem, de most érett meg.
Kétlem, hogy a javaslatom szerinti eszköz ID-i ugyanazok, mint a te eszközöd ID-i. Javasoltam, közöltem, írd át.

Kérdés

Kimenet (amikor a tesztelt SSD van bedugva)?

lsusb ; echo ; lsusb -t

Szóval, még nem jön a másik javaslatom (bezártam, de majd megkeresem) ..., hiszen a javaslatot vélhetően rosszul valósítottad meg. Nem tudjuk, hogy jól alkalmazva működik-e.

Értékelés: 

0
Még nincs értékelve

blacklist_uas_357d.conf fájl SSD piros hibák

#11.1

Gondolom ezt akartad írni:

sudo mv /etc/modprobe.d/blacklist_uas_357d.conf /etc/modprobe.d/blacklist_uas_357d.conf.ORIG

Lefuttattam, újraindítottam.

Az eszköz ID-t valóban nem írtam át, mert nekem úgy tűnt, hogy azt T. Istvánnak válaszoltad az ő problémájára, ezért annak idején átugrottam.

Hogy hogyan kell átírni az eszköz ID-t, még nem világos, az lsusb -t-re ezt írja ki:

lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
    |__ Port 3: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 480M
    |__ Port 4: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
    |__ Port 4: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
    |__ Port 5: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M

Továbbá:

lsusb ; echo ; lsusb -t
Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse
Bus 001 Device 002: ID 04f3:0103 Elan Microelectronics Corp. ActiveJet K-2024 Multimedia Keyboard
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
    |__ Port 3: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 480M
    |__ Port 4: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
    |__ Port 4: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
    |__ Port 5: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M

 

Most mit is kellene tennem?

Értékelés: 

0
Még nincs értékelve
kimarite képe

blacklist_uas_357d.conf fájl SSD piros hibák

#11.1.1 Oks. Két újabb kimenet kéne a chipset ID-k kiderítéséhez:

sudo lsusb -v
usb-devices

Persze, amikor be van fűzve az SSD. Mi a típusa pontosan?

Értékelés: 

0
Még nincs értékelve

blacklist_uas_357d.conf fájl SSD piros hibák

#11.1.1.1

Ez a sudo lsusb -v eredménye:

https://pastebin.com/ivxMyPw7

Ez pedig a  usb-devices-é:

https://pastebin.com/DhjxkMy8

SSD típusa:

Crucial BX500 2.5 1TB SATA3

Értékelés: 

0
Még nincs értékelve
kimarite képe

blacklist_uas_357d.conf fájl SSD piros hibák

#11.1.1.1.1 Ez lenne:

Bus 002 Device 003: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
T: Bus=02 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 3 Spd=5000 MxCh= 0
D: Ver= 3.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1
P: Vendor=174c ProdID=55aa Rev=01.00
S: Manufacturer=ASMT
S: Product=USB 3.0 Destop HD EP0 Product string
S: SerialNumber=000000000DD6
C: #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=0mA
I: If#=0x0 Alt= 1 #EPs= 4 Cls=08(stor.) Sub=06 Prot=62 Driver=uas

A teendő sorban:

* régi beállítás kikapcsolása

sudo mv /etc/modprobe.d/blacklist_uas_357d.conf /etc/modprobe.d/blacklist_uas_357d.conf.ORIG

* új beállítás alkalmazása

echo options usb-storage quirks=174c:55aa:u | sudo tee /etc/modprobe.d/blacklist_uas_174c.conf

* rendszer újraindítás, és teszt (betöltés befűzéskor, stb.)

* driver and display messages kimenet

dmesg

Értékelés: 

0
Még nincs értékelve
kimarite képe

blacklist_uas_357d.conf fájl SSD piros hibák

#11.1.1.1.1.1 Ha valamilyen problémába ütközöl, akkor a GRUB Recovery módban (root elemre katt, ha már benn vagy) át tudod nevezni a változtatást:

mv /etc/modprobe.d/blacklist_uas_174c.conf /etc/modprobe.d/blacklist_uas_174c.conf.ORIG

A TAB billentyű segít az elérési utaknál: begépeled /et, majd TAB, és így tovább..
És a Live rendszerrel be tudsz lépni a fórumra. Ha van USB-kulcsot Live rendszerrel.
Azért írom, mert eltűntél, hátha baj van. Semmi probléma, nekem is sok a dolgom.

Értékelés: 

0
Még nincs értékelve

blacklist_uas_357d.conf fájl SSD piros hibák

#11.1.1.1.1.1
Megcsináltam mindegyik lépést, itt az eredmény:
https://pastebin.com/izKmBkzT

Értékelés: 

0
Még nincs értékelve
kimarite képe

options usb-storage quirks=174c:55aa:u

#11.1.1.1.1.1.2 Egy újabb (alá írom):

[ 0.051929] DMAR-IR: x2apic is disabled because BIOS sets x2apic opt out bit.
[ 0.051929] DMAR-IR: Use 'intremap=no_x2apic_optout' to override the BIOS setting.

Első a BIOS beállítás vagy a kernel kapcsoló a második sorban.

[ 354.795451] usb 2-3: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[ 354.816318] usb 2-3: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00
[ 354.816323] usb 2-3: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[ 354.816327] usb 2-3: Product: USB 3.0 Destop HD EP0 Product string
[ 354.816330] usb 2-3: Manufacturer: ASMT
[ 354.816332] usb 2-3: SerialNumber: 000000000DD6
[ 354.834826] usb 2-3: UAS is blacklisted for this device, using usb-storage instead
[ 354.834827] usb-storage 2-3:1.0: USB Mass Storage device detected
[ 354.834950] usb-storage 2-3:1.0: Quirks match for vid 174c pid 55aa: c00000
[ 354.834970] scsi host4: usb-storage 2-3:1.0
[ 354.835053] usbcore: registered new interface driver usb-storage
[ 354.837192] usbcore: registered new interface driver uas

Elméletben az uas tiltva az SSD-hez, de kimenet kéne:

lsmod
lsusb -v
usb-devices

Egyéb hiba

[ 355.923058] blk_update_request: I/O error, dev sdb, sector 520 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0
[ 355.934021] sd 4:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 355.934028] sd 4:0:0:0: [sdb] tag#0 Sense Key : Aborted Command [current]
[ 355.934033] sd 4:0:0:0: [sdb] tag#0 Add. Sense: Information unit iuCRC error detected
[ 355.934038] sd 4:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 74 70 68 00 00 01 d0 00
[ 355.934044] blk_update_request: I/O error, dev sdb, sector 1953523712 op 0x0:(READ) flags 0x80700 phys_seg 21 prio class 0

Jobb lett?

___

Volt ilyen is:

sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

Jegyzet:
https://linux.goeszen.com/what-is-doesnt-support-dpo-or-fua.html
https://serverfault.com/questions/229443/what-is-read-cache-in-sda-write-cache-enabled-read-cache-enabled-doesnt/229445#229445

Az AHCI van bekapcsolva a BIOS-ban az energiakezelésnél?

TPM chip. Jól gondolom, nincs ilyen?

[ 0.537077] ima: No TPM chip found, activating TPM-bypass!
[ 0.537082] ima: Allocated hash algorithm: sha1
[ 0.537087] ima: No architecture policies found

Értékelés: 

0
Még nincs értékelve

modinfo | quirks

#12

cat /sys/module/usb_storage/parameters/quirks
174c:55aa:u

 

sudo modinfo -F depends usb_storage
ez semmit nem ír ki

 

sudo modinfo -F depends uas
usb-storage

 

Értékelés: 

0
Még nincs értékelve
kimarite képe

modinfo | quirks

#12.1 Tökéletes: az SSD ID-k.

cat /sys/module/usb_storage/parameters/quirks
174c:55aa:u

Nekem igen (Debian). Ha semmi kimenet, akkor nincs függőség, magányos modul.

sudo modinfo -F depends usb_storage
ez semmit nem ír ki

Tehát az uas modulnak kell az usb-storage modul.

sudo modinfo -F depends uas
usb-storage

____

Debian alatt némileg hasonló azért (ez az alap beállítás):

sudo modinfo -F depends usb_storage
scsi_mod,scsi_common,usbcore
sudo modinfo -F depends uas
usbcore,scsi_mod,usb-storage,scsi_common

Értékelés: 

5
Átlag: 5 (1 szavazat)

Mintha kezdene megjavulni?

Már kétszer volt gépbekapcsolás és az eszköz mindkétszer rögtön működött. Mintha kezdene megjavulni?

Értékelés: 

0
Még nincs értékelve

Mintha kezdene megjavulni?

#13.1

Hát igen, most harmadszor kapcsoltam be a gépet és most is rögtön jó.

Gyanús, hogy sikerült megoldanod...

Mindjárt megnézem a többi dolgot is.

Köszönöm, hogy vasárnapi szabidődet erre fordítottad, csak abban reménykedem, hogy ez neked is örömet okoz, illetve tanulsz belőle.

A Double Commanderes "feature" megmaradt (mounted és unmounted állapotú dupla megjelenés), de egyrészt az az ottani beépített opcióval elnyomható és csak ott jelentkezik, más fájlkezelőben nem.

 

 

Értékelés: 

0
Még nincs értékelve

Csúnya piros hibák eltűntek, AHCI, TPM

A csúnya piros hibák eltűntek (blk_update_request: I/O error)

AHCI: megnéztem a BIOS-t, de sajnos nem találtam meg az AHCI-t, nem tudom be van-e kapcsolva. Az alaplapi leírás nem igazán ír róla:

https://download.asrock.com/Manual/H110M-STX.pdf

TPM chip: nem tudom van-e, illetve hol kell megnézni.

Még mindig jó az SSD!

:-)))

 

Értékelés: 

0
Még nincs értékelve
kimarite képe

Csúnya piros hibák eltűntek, AHCI, TPM

#15 Nálad valószínűleg nincs, de a Security résznél (megvan, lentebb írom). Mostanában, az egyik gépem BIOS-a kissé összekavarodott, kikapcsoltam a TPM-et, de keresi. Alapra állítva bekapcsol(t)...

Örülök, hogy jó már az SSD. wink
A trimről beszélgettünk az elején, hogy csak az uas-sal működik. Rákeresek, mi volt ez, és hogyan lehet ellenőrizni most.

Rákerestem a PDF olvasóval ezekre:

AHCI

  • Ha minden igaz, itt van: 4.6.5 ACPI Configuration # mégsem, mert
  • itt: 4.6.3 Storage Configuration
    • SATA Aggressive Link Power Management
    • SATA Aggressive Link Power Management allows SATA devices to enter a low
    • power state during periods of inactivity to save power. It is only supported by AHCI
    • mode.
      • # Be van kapcsolva? Ha igen, akkor csak AHCI módot támogat. Ez jó.

TPM

  • itt: 4.9 Security Screen
    • Intel(R) Platform Trust Technology
    • Enable/disable Intel PTT in ME. Disable this option to use discrete TPM Module.
      • # Ne nyúlj hozzá. Ez a beállítás jó így (akárhogy is van). Ha gondolod, olvass utána, mi ez, és feltétlen kérdezz itt a fórumon is (fentebb linkelem).

Értékelés: 

0
Még nincs értékelve
kimarite képe

TRIM

#15.1 Mondjuk, nézz rá így:

sudo fstrim --verbose --all

Kimenet?

https://opensource.com/article/20/2/trim-solid-state-storage-linux
https://wiki.archlinux.org/title/Solid_state_drive#TRIM

Értékelés: 

0
Még nincs értékelve
kimarite képe

TRIM | trimmed on

#15.1.1.1 Két lehetőség van, a régebbi discard, és a manapság használatos fstrim. Szerintem így jó.

Értékelés: 

0
Még nincs értékelve
kimarite képe

TRIM | külső SSD

#15.1.1.1 No igen, ez a belső SSD (sda), a külső SSD nem látszik (sdb).
Az egyik megoldás az eSATA,
https://logout.hu/bejegyzes/king_unique/ssd_es_usb_3_0_trim_bot_vs_uasp.html
a másik, az udev szabály,
https://www.glump.net/howto/desktop/enable-trim-on-an-external-ssd-on-linux
mely leírás ezen forrásokra hivatkozik:

Tehát, van még teendő.

Az sdb5 a kiterjesztett partíció. Kérdezted, itt válaszolok.

Értékelés: 

0
Még nincs értékelve

TRIM | külső SSD

#15.1.1.1.2

Köszönöm, hogy még hajnalban is a "problémámon" dolgozol. Talán ez a trim kérdés megér egy újabb fórumtémát, mert messzire vezet?

Jelenleg az összefoglalón dolgozom, házi feladatként.

***

Egyébként pedig:

7 éve írták a prohardveren:

A TRIM-mel kapcsolatban ezt sajnos tudomásul kell vennünk, hogy USB-n nem működik. Bár én is reménykedtem benne, hogy bizonyos körülmények között működhet, de nem úgy tűnik. :( Legalábbis mostani ismereteink szerint).

***

Ugyanakkor:

Itt ennél már azt írják, támogatja a TRIM-et és UASP-t is, pedig ez is olcsó ház:
https://www.axagon.eu/hu/produkty/adsa-fp2

***

A 4811-as és 4813-as hozzászólás alapján mintha a Gembird EE2-U3S-2 ház (nekem ilyen van) mintha támogatná a Trimet:
https://logout.hu/tema/kulso_2_5_mobil_rack-ek_topikja/hsz_4801-4850.html
 

 

Értékelés: 

0
Még nincs értékelve
kimarite képe

TRIM | külső SSD

#15.1.1.1.2.1 Ezzel tesztelték:
https://github.com/CyberShadow/trimcheck
Kipróbálhatod, habár 2014-es.
A DMD kell hozzá, linkelik.
Csak nem tudom, hogy a „régiség” települ-e.

Rápihennék kicsit a válaszra, a mutatott lehetőségeket most nem tudom átnézni.
Előzetesként azt mondom, hogy általában véve, ha a TRIM támogatva lenne, akkor az ellenőrző parancs mutatná az sdb-t. MOst -érthető okokból- a UASP nincs bekapcsolva, de az UASP támogatja a TRIM-et biztosan. USB v2 biztosan jó választás, mert itt nincs TRIM támogatással gond UASP nélkül sem - legalábbis ezt olvastam- de érdemes leellenőrizned, viszont mindenképpen lassabb fájlátvitelt biztosít, mint az USB3.

Értékelés: 

0
Még nincs értékelve
kimarite képe

TRIM | külső SSD TRIM | külső SSD

#15.1.1.1.2 Ránézhetünk a javaslatra.

Telepítsd az sg_vpd/readcap-t tartalmazó csomagot:

sudo apt-get install sg3-utils

Nézz rá a külső SSD-re,

sudo sg_readcap -l /dev/sdb
sudo sg_vpd -a /dev/sdb

és vessük össze az sda-val.

sudo sg_readcap -l /dev/sda
sudo sg_vpd -a /dev/sda

A teljes kimeneteket mutasd.

Nálam az sda az unmap beállítást nem támogatja (belső, Gigabyte):

sudo sg_vpd -a /dev/sda
...
  Logical block provisioning VPD page (SBC):
  Unmap command supported (LBPU): 0
  Write same (16) with unmap bit supported (LBPWS): 1
  Write same (10) with unmap bit supported (LBPWS10): 0
  Logical block provisioning read zeros (LBPRZ): 0
  Anchored LBAs supported (ANC_SUP): 0
  Threshold exponent: 0 [threshold sets not supported]
  Descriptor present (DP): 0
  Minimum percentage: 0 [not reported]
  Provisioning type: 0 (not known or fully provisioned)
  Threshold percentage: 0 [percentages not supported]

A másik kimenet:

sudo sg_readcap -l /dev/sda
Read Capacity results:
   Protection: prot_en=0, p_type=0, p_i_exponent=0
   Logical block provisioning: lbpme=1, lbprz=0
   Last LBA=234441647 (0xdf94baf), Number of logical blocks=234441648
   Logical block length=512 bytes
   Logical blocks per physical block exponent=0
   Lowest aligned LBA=0
Hence:
   Device size: 120034123776 bytes, 114473.5 MiB, 120.03 GB

És az van beállítva, amelyik támogatja (a TAB billentyűvel találtam meg a lemez nevét):

cat /sys/block/sda/device/scsi_disk/0\:0\:0\:0/provisioning_mode
writesame_16

Értékelés: 

0
Még nincs értékelve

TRIM | külső SSD

#15.1.1.1.2.2

Íme, az eredmények:

sudo sg_readcap -l /dev/sdb
 
Read Capacity results:
   Protection: prot_en=0, p_type=0, p_i_exponent=0
   Logical block provisioning: lbpme=0, lbprz=0
   Last LBA=1953525167 (0x74706daf), Number of logical blocks=1953525168
   Logical block length=512 bytes
   Logical blocks per physical block exponent=0
   Lowest aligned LBA=0
Hence:
   Device size: 1000204886016 bytes, 953869.7 MiB, 1000.20 GB

 

sudo sg_vpd -a /dev/sdb
 
Supported VPD pages VPD page:
  Supported VPD pages [sv]
  Unit serial number [sn]
  Device identification [di]
  Block limits (SBC) [bl]
 
Unit serial number VPD page:
  Unit serial number: 6DD000000000
 
Device Identification VPD page:
  Addressed logical unit:
    designator type: NAA,  code set: Binary
      0x5000000000000001
 
Block limits VPD page (SBC):
  Write same non-zero (WSNZ): 0
  Maximum compare and write length: 0 blocks [Command not implemented]
  Optimal transfer length granularity: 1 blocks
  Maximum transfer length: 65535 blocks
  Optimal transfer length: 65535 blocks
  Maximum prefetch transfer length: 65535 blocks
  Maximum unmap LBA count: 0 [Unmap command not implemented]
  Maximum unmap block descriptor count: 0 [Unmap command not implemented]
  Optimal unmap granularity: 0 blocks [not reported]
  Unmap granularity alignment valid: false
  Unmap granularity alignment: 0 [invalid]
  Maximum write same length: 0 blocks [not reported]
  Maximum atomic transfer length: 0 blocks [not reported]
  Atomic alignment: 0 [unaligned atomic writes permitted]
  Atomic transfer length granularity: 0 [no granularity requirement
  Maximum atomic transfer length with atomic boundary: 0 blocks [not reported]
  Maximum atomic boundary size: 0 blocks [can only write atomic 1 block

 

sudo sg_readcap -l /dev/sda
 
Read Capacity results:
   Protection: prot_en=0, p_type=0, p_i_exponent=0
   Logical block provisioning: lbpme=1, lbprz=0
   Last LBA=250069679 (0xee7c2af), Number of logical blocks=250069680
   Logical block length=512 bytes
   Logical blocks per physical block exponent=0
   Lowest aligned LBA=0
Hence:
   Device size: 128035676160 bytes, 122104.3 MiB, 128.04 GB

 

sudo sg_vpd -a /dev/sda

https://pastebin.com/2t5DqmXL

Értékelés: 

0
Még nincs értékelve
kimarite képe

TRIM | külső SSD

#15.1.1.1.2.2.1 Köszi. Ezen gondolkodni kell. :)

Értékelés: 

0
Még nincs értékelve
kimarite képe

TRIM | külső SSD

#15.1.1.1.2.2.1 Megnézhetjük, hova tudnánk beírni, hogy unmet. Kimenet?

ls /sys/block/sda/device/scsi_disk/

Értékelés: 

0
Még nincs értékelve

AHCI, TPM

#15.1

Mindkét beállítása Disabled állapotban van. Nem nyúltam hozzájuk.

Értékelés: 

0
Még nincs értékelve
kimarite képe

AHCI, TPM

#15.1.2 A SATA agresszív kapcsolat energiagazdálkodás lehetővé teszi a SATA eszközök számára, hogy alacsony fogyasztási üzemen kívüli időszakokban energiatakarékos állapotba kerüljenek, hogy energiát takarítsanak meg. Ezt csak az AHCI támogatja módban.

Ez szerintem jól hangzik.
Nálad, lehet itt lesz az AHCI-ra állíthatóság:

Forrás: https://hetmanrecovery.com/recovery_news/how-to-enable-ahci-mode-for-sata-in-the-bios-without-reinstalling-windows.htm

Vagy itt:

Forrás: https://www.partitionwizard.com/partitionmanager/how-to-get-best-performance-from-ssd.html

https://duckduckgo.com/?q=ahci+mode&t=ffsb&iar=images&iax=images&ia=images )

Esetleg, a gyártó megmondja, most hogyan működik, AHCI vagy sem.

Értékelés: 

0
Még nincs értékelve

AHCI, TPM

#15.1.2.1

Amit írtál korában is, a Storage Configuration alatt a SATA Aggressive Link Power Management-et állítottam Enabled-re, valóban ebben van az AHCI.

Értékelés: 

0
Még nincs értékelve

AHCI, TPM

#15.1.2.1.1.1

Windowsos suportot is vállalsz? wink

Na nem, komoly, de a Windosos gépemen is Asrock alaplap van, a menüje szinte tökéletesen ugyanaz mint ennek a Linuxos gépnek, és ott sincs engedélyezve a Storage Configuration alatt a SATA Aggressive Link Power Management, gondolom akkor ott is célszerű enegdélyezni.

Annak idején ezt jegyeztem fel magamnak: SATA SSD AHCI módban legyen, ne IDE módban (jótanács valamelyik informatikai szaklapból). Ezt írtam még fel: Nálam nincs ilyen, helyett a Solid State  Drive vagy Hard Disk Drive módok közül az előbbit kellett beállítani. Az interfész így hatékonyabb és az SSD Trim funkciójához pedig szükséges. Azt hiszem, ezt adtam meg a Linuxos gépen is, majd megnézem. A lényeg, hogy ezek szerint mégis van valami AHCI is, csak az a SATA Aggressive Link Power Management alatt van, és ezt valószínűleg minden operációs rendszeren érdemes engedélyezni.

Mr. Bean: hát igen, 3 évente kötelezően végignézem.

Értékelés: 

0
Még nincs értékelve

Kétféle kidobó üzenet

Nem hiba, csak érdekesség és nincs köze ehhez a témához közvetlenül, de kidobáskor kétféle üzenet jön elő. Ennél az SSD-nél ... has just been stopped majd ... can be turned off if necessary. Máskor például pendrájvnál ...can safely unplugged ... can be removed az üzenet. A lényeg, hogy kétféle üzenet van, nem tudom mitől függ. Érdekesség.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Kétféle kidobó üzenet

#16 Nem magyar a rendszer?
Az egyik a Biztonságos eltávolítás, a másik a Kiadás.
Nálam is váltogat néha a rendszer, gondolkodtam már azon, hogy mi az ok, de nem jöttem rá.

Értékelés: 

0
Még nincs értékelve

Kétféle kidobó üzenet

#16.1
Angol nyelvű, mert bármi hibára vagy beállításra rá kell keresni, nagyobb eséllyel kapok érdemi találatot, mint magyarul. Már Windowsban is ezért használok régóta angolt.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Angol | magyar

#16.1.1 Így is lehet:

* terminálban

LANG=C sudo apt-get update
LANG=C sudo apt-get upgrade
LANG=C man wget

* grafikus alkalmazásnál

LANG=en-US firefox

Utóbbi esetben a példában angol nyelvi fájloknak (l10n) is telepítve kell lennie.

Értékelés: 

0
Még nincs értékelve

MEGOLDVA-összefoglaló később

Az SSD pedig szuperul működik azóta! Majd hétvégén írnék egy összefoglalót (magamnak is, elmenteni, ha hasonló probléma lesz más eszközzel vagy új telepítésnél) meg elvileg ide is illene, de azt hiszem, segítségedet igénybe kell vennem hozzá, mert sokat nem tudtam követni belőle. De 4 napos hétvége jön.

Értékelés: 

0
Még nincs értékelve
kimarite képe

MEGOLDVA-összefoglaló később

#17 Ismételten örülök. Még mindig! :)
Hasznos, ha a saját szavaiddal leírod.

Értékelés: 

0
Még nincs értékelve

ÖSSZEFOGLALÓ 1. változat

Jelenség:
Külső, USB3-n keresztül csatlakoztatott SSD egység nagyon lassan fűződik fel, ez akár 10-15 perc is lehet.
A folyamat általában meggyorsítható, hogy kilökjük és kivesszük az eszközt és újra bedugjuk. Ekkor sokszor rögtön működőképes lesz, de sokszor ez sem segített. Kilökéskor persze kapunk mindenféle hibaüzenetet is, hogy az eszköz mountolása még függőben van.
 
Megoldás felé vezető út lépései:
sudo lsmod | egrep -i 'uas|usb-storage'
 
uas                    28672  1
usb_storage            77824  1 uas
 
https://leo.leung.xyz/wiki/How_to_disable_USB_Attached_Storage_(UAS)
Hogyan lehet letiltani az USB csatolt tárolót (UAS)
 
Az USB Attached Storage (UAS) ma már általánosan használatos az USB 3.0 tárolóeszközökhöz. Ez azonban néha problémákat okoz a nem megfelelő adapterekkel, amelyek miatt le kell tiltani. Az UAS engedélyezésével kapcsolatos problémák közé tartozik a lassú írási teljesítmény, vagy az eszköz véletlenszerű leállása, amíg az USB-kapcsolatot vissza nem állítják.
 
Az USB-eszköz azonosítójának megkeresése
 
Az UAS letiltásához egy adott USB-eszközön keresse meg a meghajtóhoz társított USB-eszközt. Ez a dmesg kernelnaplók áttekintésével vagy az lsusb használatával érhető el.
 
lsusb
Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse
Bus 001 Device 002: ID 04f3:0103 Elan Microelectronics Corp. ActiveJet K-2024 Multimedia Keyboard
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 
Kizárásos alapon ebből az első a külső SSD.
Az SSD eszköz azonosítója tehát 174c:55aa
 
Több módszer lehetséges az UAS letiltásásra, ebből az egyik a modprobe.d folderben egy konfig fájl megadása.
 
Hozzunk létre egy disable-uas.conf nevű fájlt a /etc/modprobe.d/ könyvtárban a következő tartalommal:
options usb-storage quirks=174c:55aa
 
Más oldalakon blacklist-uas.conf néven hozzák létre a fájlt, talán ezt Linuxfüggő?
 
Például így létrehozhatjuk:
echo options usb-storage quirks=174c:55aa:u | sudo tee /etc/modprobe.d/blacklist_uas_174c.conf
 
Azt nem értem, hogy mi nem disable-uas.conf, sem blacklist-uas.conf néven hoztuk létre, hanem blacklist_uas_174c.conf néven, vajon a rendszer ezt honnan tudja??? Egyrészt nálunk nem kötőjel van, hanem aláhúzás, és beletettük az azonosító egy részét is a fájlnévbe...
 
Valószínű, hogy mindegy is a fájl neve, abból a könyvtárból talán minden conf végződésű fájlt kiolvashat a rendszer?

A félbehagyott blacklist_uas_357d.conf.ORIG nevű fájl törölhető?

 
Ezután újra kell indítani a rendszert és tesztelni, hogy valóban letiltottuk-e az UAS-t.
 
Újraindításkor, amikor a kernelmodul újra betöltődik, fel kell ismernie a "quirks"-t.
Ha ez nem válik be, próbálja ki az alábbi cmdline argumentum beállítást:
sudo update-initramfs -u
(A "quirk" az eszközök azon attribútumai, amelyek nem felelnek meg a várt működésnek.
Van erre magyar kifejezés?)
 
Nekem nem kellett a fenti parancsot futtatni.
 
Az eszköz megjavult! Csatlakoztatás után pár másodpercen belül megjelenik az asztalon és használható.
 
dmesg kimenet részlet:
[ 354.795451] usb 2-3: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[ 354.816318] usb 2-3: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00
[ 354.816323] usb 2-3: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[ 354.816327] usb 2-3: Product: USB 3.0 Destop HD EP0 Product string
[ 354.816330] usb 2-3: Manufacturer: ASMT
[ 354.816332] usb 2-3: SerialNumber: 000000000DD6
[ 354.834826] usb 2-3: UAS is blacklisted for this device, using usb-storage instead
[ 354.834827] usb-storage 2-3:1.0: USB Mass Storage device detected
[ 354.834950] usb-storage 2-3:1.0: Quirks match for vid 174c pid 55aa: c00000
[ 354.834970] scsi host4: usb-storage 2-3:1.0
[ 354.835053] usbcore: registered new interface driver usb-storage
[ 354.837192] usbcore: registered new interface driver uas
 
UAS le van tiltva, helyette usb-storage van csak használatban.

***

Lábjegyzet:

Ugyanakkor a hibák azóta is vannak, nem zavaróak, ha nem futtatnám a dmesg parancsot, nem is tudnék róla:

[ 1870.085432] usb 2-3: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[ 1870.106299] usb 2-3: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00
[ 1870.106304] usb 2-3: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[ 1870.106308] usb 2-3: Product: USB 3.0 Destop HD EP0 Product string
[ 1870.106310] usb 2-3: Manufacturer: ASMT
[ 1870.106313] usb 2-3: SerialNumber: 000000000DD6
[ 1870.142691] usb 2-3: UAS is blacklisted for this device, using usb-storage instead
[ 1870.142693] usb-storage 2-3:1.0: USB Mass Storage device detected
[ 1870.142809] usb-storage 2-3:1.0: Quirks match for vid 174c pid 55aa: c00000
[ 1870.142854] scsi host4: usb-storage 2-3:1.0
[ 1870.142925] usbcore: registered new interface driver usb-storage
[ 1870.144329] usbcore: registered new interface driver uas
[ 1871.157892] scsi 4:0:0:0: Direct-Access     ASMT     USB 3.0 Destop H 0    PQ: 0 ANSI: 6
[ 1871.158548] sd 4:0:0:0: Attached scsi generic sg1 type 0
[ 1871.162028] sd 4:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB)
[ 1871.162268] sd 4:0:0:0: [sdb] Write Protect is off
[ 1871.162275] sd 4:0:0:0: [sdb] Mode Sense: 43 00 00 00
[ 1871.162504] sd 4:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 1871.186961]  sdb: sdb1
[ 1871.219766] sd 4:0:0:0: [sdb] Attached SCSI disk
[ 1871.231705] sd 4:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 1871.231712] sd 4:0:0:0: [sdb] tag#0 Sense Key : Aborted Command [current]
[ 1871.231717] sd 4:0:0:0: [sdb] tag#0 Add. Sense: Information unit iuCRC error detected
[ 1871.231722] sd 4:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 74 70 68 00 00 01 d0 00
[ 1871.231729] blk_update_request: I/O error, dev sdb, sector 1953523712 op 0x0:(READ) flags 0x80700 phys_seg 24 prio class 0

stb.

[Ez az eredeti problémán túlmutat, meg akarjuk ezt is oldani (esetleg később egy másik topicban, ahogy előjött a trim ügy is)? Sőt megfigyeltem, hogy más eszközöknél (pld. pendrájv) is vannak hibák, de másmilyenek.]

Értékelés: 

0
Még nincs értékelve
kimarite képe

ÖSSZEFOGLALÓ 1. változat

#18 Például így létrehozhatjuk:

echo options usb-storage quirks=174c:55aa:u | sudo tee /etc/modprobe.d/blacklist_uas_174c.conf

Azt nem értem, hogy mi nem disable-uas.conf, sem blacklist-uas.conf néven hoztuk létre, hanem blacklist_uas_174c.conf néven, vajon a rendszer ezt honnan tudja??? Egyrészt nálunk nem kötőjel van, hanem aláhúzás, és beletettük az azonosító egy részét is a fájlnévbe...

Valószínű, hogy mindegy is a fájl neve, abból a könyvtárból talán minden conf végződésű fájlt kiolvashat a rendszer?

Bármilyen néven létrehozhatnánk, a tartalom számít, és esetleg az is, hogy conf (beállítás) legyen a kiterjesztés (talán utóbbi nem annyira, de mutatja a fájl jellegét). A blacklist (feketelista) és a disable (kikapcsolva) egyaránt jó. Az egyik ID használata pedig szintén jó. Az a lényeg, kifejező, azaz adott eszközre és modulra jellemző legyen a név, hogy te tudd, mi ez. Mert lehetne a név makosretes_kokuszviragcukorral.conf is, de ez egyáltalán nem mond semmit ... neked. Mert ha egy biztonsági mentés csinálsz róla külső meghajtóba, felhőbe, pastebinre (stb.), és később is használnád, könnyen megtaláld.
Kötőjel, aláhúzás nem számít.

A félbehagyott blacklist_uas_357d.conf.ORIG nevű fájl törölhető?

Igen. Az ORIG-féle átnevezés is elég kifejező (a rendszergazdák használják), de itt most persze megtévesztő, mert nem az eredetit mentettük, hanem egy nem működőt kapcsoltunk ki. Linux rendszeren a beállítások törlése nem célravezető, mert amit végleg törölsz, az nem hozható vissza (biztonsági mentés hiányában). Amit átnevezel -mert nem tudod, kell-e- az visszaállítható. Itt törölheted, például admin joggal, a fájlkezelőben, vagy, ha másolod a parancssort, terminálban is:

sudo rm /etc/modprobe.d/blacklist_uas_174c.conf.ORIG

Csak az rm-nél (remove: eltávolítás, törlés)) figyelni kell, nem szabad kapkodni, ne maradjon le a fájlnév vége a másoláskor, jó legyen az elérési út, mert mást törölhetsz (végleg). Csak így kapsz figyelmeztetés, azaz kérdést (de itt is ellenőrizni kell, mit törölsz):

sudo rm -i /etc/modprobe.d/blacklist_uas_174c.conf.ORIG

Kézikönyv (man rm):

      -i, --interactive
              Minden fájl eltávolítása előtt megkérdezi a  felhasználót,  hogy
              törölheti-e  az  adott  állományt.  Ha a válasz nem `y' vagy `Y'
              betűvel kezdődik, a következő állományt veszi.

(A "quirk" az eszközök azon attribútumai, amelyek nem felelnek meg a várt működésnek.
Van erre magyar kifejezés?)

Furaságok, de inkább egyedi mód. Még gondolkodom a honosított néven. :)
https://www.kernel.org/doc/htmldocs/writing_musb_glue_layer/device-quirks.html

A „folder” magyar nyelven egészen biztosan könyvtár. ;)

Ahhoz, hogy kiderítsük a quirks módot használó karakterláncot, meg kell találnunk az adapterünk eszközazonosító karakterláncát, ...
https://github.com/openfans-community-offical/Debian-Pi-Aarch64/blob/master/docs/pi4-usb-boot-problems.md

... Sajnálatos módon a linux kernel fejlesztői gyakran késve értesülnek az ilyen furcsaságokkal rendelkező új eszközökről, és időbe telhet, amíg megtalálják a probléma megoldását, és további időbe, amíg a módosított kód elérhetővé válik a linux terjesztett verzióiban (pl. openSUSE, Red Hat vagy Ubuntu).
Az alábbiakban a folyamat lerövidítésének módjait ismertetjük.
https://en.opensuse.org/SDB:USB_3.0_Hard_Drive_troubleshooting

Igazából még több flag (zászló) lehetséges:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.7_release_notes/kernel_parameters_changes

u = IGNORE_UAS (don’t bind to the uas driver)
u = IGNORE_UAS (nem kötődik az uas illesztőprogramhoz)

        usb-storage.quirks=
                        [UMS] A list of quirks entries to supplement or
                        override the built-in unusual_devs list.  List
                        entries are separated by commas.  Each entry has
                        the form VID:PID:Flags where VID and PID are Vendor
                        and Product ID values (4-digit hex numbers) and
                        Flags is a set of characters, each corresponding
                        to a common usb-storage quirk flag as follows:
                                a = SANE_SENSE (collect more than 18 bytes
                                        of sense data, not on uas);
                                b = BAD_SENSE (don't collect more than 18
                                        bytes of sense data, not on uas);
                                c = FIX_CAPACITY (decrease the reported
                                        device capacity by one sector);
                                d = NO_READ_DISC_INFO (don't use
                                        READ_DISC_INFO command, not on uas);
                                e = NO_READ_CAPACITY_16 (don't use
                                        READ_CAPACITY_16 command);
                                f = NO_REPORT_OPCODES (don't use report opcodes
                                        command, uas only);
                                g = MAX_SECTORS_240 (don't transfer more than
                                        240 sectors at a time, uas only);
                                h = CAPACITY_HEURISTICS (decrease the
                                        reported device capacity by one
                                        sector if the number is odd);
                                i = IGNORE_DEVICE (don't bind to this
                                        device);
                                j = NO_REPORT_LUNS (don't use report luns
                                        command, uas only);
                                k = NO_SAME (do not use WRITE_SAME, uas only)
                                l = NOT_LOCKABLE (don't try to lock and
                                        unlock ejectable media, not on uas);
                                m = MAX_SECTORS_64 (don't transfer more
                                        than 64 sectors = 32 KB at a time,
                                        not on uas);
                                n = INITIAL_READ10 (force a retry of the
                                        initial READ(10) command, not on uas);
                                o = CAPACITY_OK (accept the capacity
                                        reported by the device, not on uas);
                                p = WRITE_CACHE (the device cache is ON
                                        by default, not on uas);
                                r = IGNORE_RESIDUE (the device reports
                                        bogus residue values, not on uas);
                                s = SINGLE_LUN (the device has only one
                                        Logical Unit);
                                t = NO_ATA_1X (don't allow ATA(12) and ATA(16)
                                        commands, uas only);
                                u = IGNORE_UAS (don't bind to the uas driver);
                                w = NO_WP_DETECT (don't test whether the
                                        medium is write-protected).
                                y = ALWAYS_SYNC (issue a SYNCHRONIZE_CACHE
                                        even if the device claims no cache,
                                        not on uas)
                        Example: quirks=0419:aaf5:rl,0421:0433:rc

Forrás: https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html

Lehetséges, a jelenlegi hibák tekintetével ezzel lehet valamit kezdeni...
A fenti kapcsolók, a GRUB sorba írhatóak, ha szöveges fájlban állítjuk be, akkor az usb-storage.quirks kifejezésben pont helyett szóköz használatos.

A TRIM témához nemrég szóltam hozzá.

Gratulálok, jó lett!

Értékelés: 

0
Még nincs értékelve

TRIM | külső SSD

Szia!

Azt a Show Responsát neki!

Nekem kb. 10 percig tartott megtalálni az új bejegyzésedet. Azt mondtad, hogy csak egy választ adsz legfeljebb. A lineáris fórumnak is vannak hátrányai, de talán több előnye van, mint ennek a bokor struktúrának.

A parancs kimenete:

ls /sys/block/sda/device/scsi_disk/
2:0:0:0

 

Értékelés: 

0
Még nincs értékelve
kimarite képe

TRIM | külső SSD

#19 Jó is, hogy kijöttünk a napra :), mert az én tesztelésemből indultam ki, és így kéne a kimenetnek nekifutni:

ls /sys/block/sdb/device/scsi_disk/

# Egyre, nem kettőre válaszoltam, és a Firefox kb. oda lép, ahol -általában fejlebb- megnyitható a show. ;)

Értékelés: 

0
Még nincs értékelve

TRIM | külső SSD

Ja, igen, most már én is tudom, hogy az sda a belső, az sdb a külső:

ls /sys/block/sdb/device/scsi_disk/
4:0:0:0

 

Értékelés: 

0
Még nincs értékelve
kimarite képe

TRIM | külső SSD | udev

#20 Állítsd be a provisioning módot az unmap beállításra (*).

echo "unmap" | sudo tee /sys/block/sdb/device/scsi_disk/4\:0\:0\:0/provisioning_mode

De a scsi_disk könyvtár után jobb lenne, ha a TAB-bal írnád be az eszközt.

echo "unmap" | sudo tee /sys/block/sdb/device/scsi_disk/[TAB] # majd provisioning_mode

Hozd létre az udev szabályt.

echo 'ACTION=="add|change", ATTRS{idVendor}=="174c", ATTRS{idProduct}=="55aa", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"' | sudo tee-a /etc/udev/rules.d/10-uas-discard.rules

Frissítsd az udev szabályokat.

sudo udevadm control --reload-rules ; sudo udevadm trigger

Ellenőrizd az eredményt.

lsblk --discard /dev/sdb
sudo fstrim --verbose --all
sudo fstrim /media/Abakusz1

Utolsó parancssornál TAB, ha más a neve (címke).

(ez nem jó így, használd a válasz elemet)

Értékelés: 

0
Még nincs értékelve

TRIM | külső SSD | udev TRIM | külső SSD | udev

#20.1

 

Provisioning mód az unmap beállításra:

echo "unmap" | sudo tee /sys/block/sdb/device/scsi_disk/4\:0\:0\:0/provisioning_mode

unmap
-----------------
Hozzuk létre az udev szabályt:

echo 'ACTION=="add|change", ATTRS{idVendor}=="174c", ATTRS{idProduct}=="55aa", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"' | sudo tee -a /etc/udev/rules.d/10-uas-discard.rules

ACTION=="add|change", ATTRS{idVendor}=="174c", ATTRS{idProduct}=="55aa", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"
-----------------
Frissítsük az udev szabályokat:

sudo udevadm control --reload-rules ; sudo udevadm trigger
-----------------
Ellenőrizzük az eredményt:
lsblk --discard /dev/sdb

NAME   DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sdb           0      512B       4G         0
└─sdb1        0      512B       4G         0

sudo fstrim --verbose --all
fstrim: /media/../Abakusz1: FITRIM ioctl failed: Remote I/O error
/boot/efi: 511 MiB (535801856 bytes) trimmed on /dev/sda1
/: 1,7 GiB (1801744384 bytes) trimmed on /dev/sda5

sudo fstrim /media/.../Abakusz1
fstrim: /media/.../Abakusz1: the discard operation is not supported

Értékelés: 

0
Még nincs értékelve
kimarite képe

TRIM | külső SSD | udev

#20.1.1 Eltekintve az fstrim jelzéstől, nálad megjelent a discard itt:

lsblk --discard /dev/sdb

NAME   DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sdb           0      512B       4G         0
└─sdb1        0      512B       4G         0

De a „continuous” discard helyett (folyamatos), az „periodic” fstrim (szakaszos, időnként ismétlődő) szolgáltatást használod most a TRIM-re.
https://wiki.archlinux.org/title/Solid_state_drive#Periodic_TRIM

Mi van itt, kimenet?

cat /sys/block/sdb/device/scsi_disk/*/provisioning_mode

Nyilván fut, de nézzünk rá (tedd nagyra a terminál ablakot):

-- itt fontos az első kimenet, látjuk, mikor futott le

sudo systemctl status fstrim.service --no-pager

-- az időzítés (állapota)

sudo systemctl status fstrim.timer --no-pager -l

A sudo-t emiatt (nem parancssorok)

Warning: some journal files were not opened due to insufficient permissions.

az l paramétert emiatt használom a status lekérdezéssel:

Hint: Some lines were ellipsized, use -l to show in full.

Majd indítsd újra a rendszert, és kéne egy kimenet.

dmesg

Értékelés: 

0
Még nincs értékelve

TRIM | külső SSD | udev

#20.1.1.1

cat /sys/block/sdb/device/scsi_disk/*/provisioning_mode
unmap

**********************************

sudo systemctl status fstrim.service --no-pager    
● fstrim.service - Discard unused blocks on filesystems from /etc/fstab
     Loaded: loaded (/lib/systemd/system/fstrim.service; static; vendor preset: enabled)
     Active: inactive (dead)
TriggeredBy: ● fstrim.timer
       Docs: man:fstrim(8)

**********************************

sudo systemctl status fstrim.timer --no-pager -l
● fstrim.timer - Discard unused blocks once a week
     Loaded: loaded (/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Mon 2022-03-14 07:25:53 CET; 57min ago
    Trigger: Mon 2022-03-21 00:00:00 CET; 6 days left
   Triggers: ● fstrim.service
       Docs: man:fstrim
 
márc 14 07:25:53 netpc systemd[1]: Started Discard unused blocks once a week.

**********************************

Újraindítás után:

dmesg

https://pastebin.com/kpw01jjw

Értékelés: 

0
Még nincs értékelve
kimarite képe

TRIM | külső SSD | udev

#20.1.1.1.1 Ezt találtam:

[ 121.676707] sd 4:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 121.676709] sd 4:0:0:0: [sdb] tag#0 Sense Key : Illegal Request [current]
[ 121.676710] sd 4:0:0:0: [sdb] tag#0 Add. Sense: Invalid command operation code
[ 121.676712] sd 4:0:0:0: [sdb] tag#0 CDB: Unmap/Read sub-channel 42 00 00 00 00 00 00 00 18 00
[ 121.676713] blk_update_request: critical target error, dev sdb, sector 5967992 op 0x3:(DISCARD) flags 0x800 phys_seg 1 prio class 0

Azaz, egy trimmelés nem sikerül...

Korábban írás/olvasás hiba volt - még a javítás előtt:
https://linuxmint.hu/comment/53716#comment-53716

[  554.104731] blk_update_request: I/O error, dev sdb, sector 6269832 op 0x0:(READ) flags 0x80700 phys_seg 32 prio class 0

Ha jól emlékszem (és a dmesg kimenetben is látszik), SCSI a csatlakozás,

sudo smartctl -a -d scsi /dev/sdb

de nézzünk rá ATA-val is.

sudo smartctl -a -d ata /dev/sdb

Kimenetek?

Még az is lehet, hogy a telepített kernel által nem támogatott beállítást kapcsoltunk be.
https://bugzilla.redhat.com/show_bug.cgi?id=1874092
Kimenet?

sg_vpd -a /dev/sdb

Értékelés: 

0
Még nincs értékelve

TRIM | külső SSD | udev

#20.1.1.1.1.1

Kitartó vagy... Én már fáradok, pedig te dolgozol.

sudo smartctl -a -d scsi /dev/sdb
 
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.0-104-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org
 
=== START OF INFORMATION SECTION ===
Vendor:               ASMT
Product:              USB 3.0 Destop H
Revision:             0
Compliance:           SPC-4
User Capacity:        1.000.204.886.016 bytes [1,00 TB]
Logical block size:   512 bytes
Logical Unit id:      0x5000000000000001
Serial number:        6DD000000000
Device type:          disk
Local Time is:        Mon Mar 14 13:32:22 2022 CET
SMART support is:     Available - device has SMART capability.
SMART support is:     Enabled
Temperature Warning:  Disabled or Not Supported
 
=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK
Current Drive Temperature:     0 C
Drive Trip Temperature:        0 C
 
Error Counter logging not supported
 
Device does not support Self Test logging
 
********************
sudo smartctl -a -d ata /dev/sdb
 
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.0-104-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org
 
Read Device Identity failed: Invalid argument
 
A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.
 
********************
sudo sg_vpd -a /dev/sdb

Supported VPD pages VPD page:
  Supported VPD pages [sv]
  Unit serial number [sn]
  Device identification [di]
  Block limits (SBC) [bl]
 
Unit serial number VPD page:
  Unit serial number: 6DD000000000
 
Device Identification VPD page:
  Addressed logical unit:
    designator type: NAA,  code set: Binary
      0x5000000000000001
 
Block limits VPD page (SBC):
  Write same non-zero (WSNZ): 0
  Maximum compare and write length: 0 blocks [Command not implemented]
  Optimal transfer length granularity: 1 blocks
  Maximum transfer length: 65535 blocks
  Optimal transfer length: 65535 blocks
  Maximum prefetch transfer length: 65535 blocks
  Maximum unmap LBA count: 0 [Unmap command not implemented]
  Maximum unmap block descriptor count: 0 [Unmap command not implemented]
  Optimal unmap granularity: 0 blocks [not reported]
  Unmap granularity alignment valid: false
  Unmap granularity alignment: 0 [invalid]
  Maximum write same length: 0 blocks [not reported]
  Maximum atomic transfer length: 0 blocks [not reported]
  Atomic alignment: 0 [unaligned atomic writes permitted]
  Atomic transfer length granularity: 0 [no granularity requirement
  Maximum atomic transfer length with atomic boundary: 0 blocks [not reported]
  Maximum atomic boundary size: 0 blocks [can only write atomic 1 block]

Értékelés: 

0
Még nincs értékelve
kimarite képe

TRIM | külső SSD | udev

#20.1.1.1.1.1.1 Te melyik terminált használod? Ugyanis, a kimenet végét immár másodszor nem közlöd (az első eset | 2022. már. 12. 10:56):

sudo sg_vpd -a /dev/sdb

Supported VPD pages VPD page:
...
  Maximum atomic boundary size: 0 blocks [can only write atomic 1 block]
... a vége?

Értékelés: 

0
Még nincs értékelve

TRIM | külső SSD | udev

#20.1.1.1.1.1.1.1

Gnome Terminal, 3.36.2-es, ez van a tálcán.

Most újra kipróbáltam, most is ez az utolsó sor:

Maximum atomic boundary size: 0 blocks [can only write atomic 1 block]

 

Értékelés: 

0
Még nincs értékelve
kimarite képe

TRIM | külső SSD | udev | unmap

#20.1.1.1.1.1.1.1.1 Én csak arra alapozok, hogy korábban is úgy közölted, hogy eddig tart, aztán még ott volt egy paste is, ahol viszont a teljes kimenet volt valahogy mégis. A kimeneteket pasztázd!

Én arra voltam kíváncsi, a támogatás (supported) most mit mutat (és nálam ez a vége):

...
  Maximum atomic boundary size: 0 blocks [can only write atomic 1 block]

Block device characteristics VPD page (SBC):
  Non-rotating medium (e.g. solid state)
  Product type: Not specified
  WABEREQ=0
  WACEREQ=0
  Nominal form factor: 2.5 inch
  ZONED=0
  RBWZ=0
  BOCS=0
  FUAB=0
  VBULS=0
  DEPOPULATION_TIME=0 (seconds)

Logical block provisioning VPD page (SBC):
  Unmap command supported (LBPU): 0
  Write same (16) with unmap bit supported (LBPWS): 1
  Write same (10) with unmap bit supported (LBPWS10): 0
  Logical block provisioning read zeros (LBPRZ): 0
  Anchored LBAs supported (ANC_SUP): 0
  Threshold exponent: 0 [threshold sets not supported]
  Descriptor present (DP): 0
  Minimum percentage: 0 [not reported]
  Provisioning type: 0 (not known or fully provisioned)
  Threshold percentage: 0 [percentages not supported]

Only hex output supported
VPD page code=0xb9:
fetching VPD page code=0xb9: failed
fetching VPD page failed: Illegal request
sg_vpd failed: Illegal request

De ha ez van, akkor nincs támogatva a kernel által az unmap, és vissza kell állni a korábbi állapotra.

Így (az előzményekből érthető remélem, az egyes parancssorok jelentése):

echo "writesame_16" | sudo tee /sys/block/sdb/device/scsi_disk/4\:0\:0\:0/provisioning_mode
sudo rm -fi /etc/udev/rules.d/10-uas-discard.rules
sudo udevadm control --reload-rules ; sudo udevadm trigger

És mutasd:

sg_vpd -a /dev/sdb
lsblk --discard /dev/sdb
sudo fstrim --verbose --all
dmesg

Ez sem volt jó itt:

FITRIM ioctl failed: Remote I/O error

Értékelés: 

0
Még nincs értékelve
kimarite képe

TRIM | külső SSD | udev | unmap # magyarázat

#20.1.1.1.1.1.1.1.1.1 Tehát ez (2022. már. 12. 10:56)

Logical block provisioning VPD page (SBC):
Unmap command supported (LBPU): 0
Write same (16) with unmap bit supported (LBPWS): 1
Write same (10) with unmap bit supported (LBPWS10): 0

tény, azaz kernel és firmware sajátosság, vagyis nem állítható át másra.

Vagyis a kernel (a firmware által) észlelte (lásd fentebb) az eszközöd adattérkép-feloldási képességét és az „sg_vpd -a /dev/sdb” parancssor által mutatta is.

Az összes támogatás ez:

unmap
writesame_16
writesame_10
writesame_zero
disabled

wink

Értékelés: 

0
Még nincs értékelve
kimarite képe

TRIM | külső SSD | udev | unmap # magyarázat + ső (és)

#20.1.1.1.1.1.1.1.1.1.1 És még ezt ki lehet próbálni (udev szabály a meglévő támogatás alapján):

echo 'ACTION=="add|change", ATTRS{idVendor}=="174c", ATTRS{idProduct}=="55aa", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="writesame_16"' | sudo tee-a /etc/udev/rules.d/10-usb-storage-fstrim.rules

Utána udev szabály frissítés, majd próbák - amiket nemrég (2022. már. 15. 08:50)  írtam.

Persze, miután törölted a korábbi udev szabályt. Ez egy új...

Értékelés: 

0
Még nincs értékelve

TRIM | külső SSD | udev | unmap

#20.1.1.1.1.1.1.1.1.1

A kimeneteket másoltam, nincs más. Próbáltam a kimenetet beírni egy fájlba, akkor is csak ezt adja vissza, akkor is ez az utolsó sor:

Maximum atomic boundary size: 0 blocks [can only write atomic 1 block]

Végrehajtottam a fenti utasításokat, a

sg_vpd -a /dev/sdb

kimenete ugyanaz, mint eddig, egyetlen karakter sem változott.

***

sudo lsblk --discard /dev/sdb
NAME   DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sdb           0      512B       4G         0
└─sdb1        0      512B       4G         0

***

sudo fstrim --verbose --all

fstrim: /media/imi/Abakusz1: FITRIM ioctl failed: Remote I/O error
/boot/efi: 511 MiB (535801856 bytes) trimmed on /dev/sda1
/: 96,5 GiB (103568625664 bytes) trimmed on /dev/sda5

***

dmesg:

https://pastebin.com/eqnnPjq9

 

Értékelés: 

0
Még nincs értékelve
kimarite képe

TRIM | külső SSD | udev | unmap

#20.1.1.1.1.1.1.1.1.1.2 Végrehajtottam a fenti utasításokat, a

sg_vpd -a /dev/sdb

kimenete ugyanaz, mint eddig, egyetlen karakter sem változott.

Akkor hatástalan egyelőre a változtatás. A rendszert is indítsd újra és mindent mutass újra... . Köszi.

Értékelés: 

0
Még nincs értékelve
kimarite képe

xhci_hcd 0000:00:14.0: cache line size of 64 is not supported

#20.1.1.1.1.1.1.1.1.1.2.1 Ez sem jó így, de a rendszer újraindítás után megjavul szerintem.
https://www.linuxquestions.org/questions/linux-hardware-18/usb-3-0-isnt-working-under-linux-mint-4175545674-print/

Azért sem foglalkozom ezzel a mostani állapottal,mert átmeneti.., megmaradt ez is:

blk_update_request: critical target error, dev sdb, sector 5968000 op 0x3:(DISCARD) flags 0x800 phys_seg 1 prio class 0

Értékelés: 

0
Még nincs értékelve

Hibaüzenet kernel frissítéskor

A Linux kernel frissítést rendszeresen pár percre lelassítja, hogy egy csomó hibát dob a rendszer és molyol velük.

Probléma nincs vele, sikeresen lefut a frissítés.

A hibaüzenet:

libkmod: ERROR ../libkmod/libkmod-config.c:656 kmod_config_parse:
/etc/modprobe.d/uas_blacklist.conf line 1: ignoring bad line starting with 'uas'

Kb. 50-szer írja ezt ki.

 

Értékelés: 

0
Még nincs értékelve
kimarite képe

Hibaüzenet kernel frissítéskor

#21 Kicsit nehéz követni a szálat, és lehetséges, lefutott tanácsra valami nem jó. A parancssor kimenete?

cat /etc/modprobe.d/* ; echo ; ls -1 /etc/modprobe.d/ ; echo ; cat /etc/modprobe.d/uas_blacklist.conf

Értékelés: 

0
Még nincs értékelve
kimarite képe

Hibaüzenet kernel frissítéskor

#21.1.1 Két lehetőség.

1) Kikapcsolod az uas modult. Az usb-storage modul függ tőle elvileg...

A helyes parancssor:

echo "blacklist uas" | sudo tee /etc/modprobe.d/uas_blacklist.conf

Majd.

sudo update-initramfs -uk all

A rendszer újraindítása után kimenet (teszt):

sudo lsmod | egrep -i 'uas|usb-storage'
dmesg

A fentit próbáld.

2) Illetve, ki lehet kapcsolni a tiltást, de akkor..., be lesz kapcsolva, ami hibát okoz.

sudo mv /etc/modprobe.d/uas_blacklist.conf /etc/modprobe.d/uas_blacklist.conf.ORIG

Majd.

sudo update-initramfs -uk all

A rendszer újraindítása után kimenet (teszt):

sudo lsmod | egrep -i 'uas|usb-storage'
dmesg

Értékelés: 

0
Még nincs értékelve

Hibaüzenet kernel frissítéskor

#21.1.1.1

Az 1-es pontot végigcsináltam, az eredmény:

sudo lsmod | egrep -i 'uas|usb-storage'

nem adott vissza semmit.

A dmesg:

https://pastebin.com/JKyfzY7D

Értékelés: 

0
Még nincs értékelve
kimarite képe

Hibaüzenet kernel frissítéskor

#21.1.1.1.1 A kimenetben sem sdb, sem ID (174c:55aa), sem scsi host4, sem uas vagy usb-storage nem látszik.Te látod az SSD-t (amely gondolom, a dmesg futtatásának idején be volt fűzve)?

Értékelés: 

0
Még nincs értékelve

Hibaüzenet kernel frissítéskor

#21.1.1.1.1.1

Bocsánat, az SSD nem volt benn. Az SSD-t betettem, működik, készítettem egy új kimenetet:

https://pastebin.com/8wmHtFib

Értékelés: 

0
Még nincs értékelve
kimarite képe

Hibaüzenet kernel frissítéskor

#21.1.1.1.1.1.1 Eredmények.

Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

A lemez átmeneti tár engedélyezve, bizonyos módokat (DPO, FUA) nem támogat (*, **).

[ 181.640470] usb 2-3: UAS is blacklisted for this device, using usb-storage instead
[ 181.640471] usb-storage 2-3:1.0: USB Mass Storage device detected
[ 181.640531] usb-storage 2-3:1.0: Quirks match for vid 174c pid 55aa: c00000
[ 181.640549] scsi host4: usb-storage 2-3:1.0
[ 181.640633] usbcore: registered new interface driver usb-storage

Az SSD (sdb) felismerve, az uas helyett az usb-storage modul kezeli.

[ 182.796111] sd 4:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 182.796118] sd 4:0:0:0: [sdb] tag#0 Sense Key : Aborted Command [current]
[ 182.796123] sd 4:0:0:0: [sdb] tag#0 Add. Sense: Information unit iuCRC error detected
[ 182.796128] sd 4:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 74 70 6c 20 00 00 08 00
[ 182.796135] blk_update_request: I/O error, dev sdb, sector 1953524768 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[ 182.805024] sd 4:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 182.805031] sd 4:0:0:0: [sdb] tag#0 Sense Key : Aborted Command [current]
[ 182.805036] sd 4:0:0:0: [sdb] tag#0 Add. Sense: Information unit iuCRC error detected
...
blk_update_request: I/O error, dev sdb, sector 6239368 op 0x0:(READ) flags 0x80700 phys_seg 2 prio class 0

A jelzés az utolsó sorban, elméletileg lehet az usb-storage használat miatt,
https://bugzilla.redhat.com/show_bug.cgi?id=1854271#c9
de mi is elméletileg megoldottuk valami hasonlóval (lényegében ugyanaz a megoldás), mint itt.
https://retropie.org.uk/forum/topic/27705/raspberry-pi-4-usb-boot-blk_update_request-i-o-error/1

Futtatni kéne egy ellenőrzést (*, **, ***).

sudo smartctl -l selftest /dev/sdb

Teljes ellenőrzést is le lehet futtatni.
Egyébként, az uas használatakor is ugyanezen hibák jelentkeztek:
https://linuxmint.hu/comment/53486#comment-53486

Viszont ez már elmúlt (vélhetően ezért):

Ha jobb egérrel a Mount parancsot adom ki, akkor hibaüzenetet kapok: Unable to mount ...,
An operation is already pending. Ha ugyanitt azt mondom, hogy Safely remove, akkor
Error mounting /dev/sdb1 at media/... a hibaüzenet stb.  ugyanakkor jön egy rendszerüzenet is,
hogy ... can be safely unplugged.
Ha ezek után kihúzom az egységet és visszadugom, akkor azonnal működik.
A gép bekapcsolása után a fenti folyamat mindig ugyanígy játszódik le.
Viszont ha nem ez az egység volt először bedugva, hanem egy másik pendrive vagy
külső vinyó, akkor már az SSD is elsőre működik.

Új kábelt ki tudsz próbálni?
TRIM ellenőrzést is kéne végezni valahogy... (nem jutottunk a végére). Beállítottuk a nálad támogatott writesame_16-ra.
AHCI módban van a BIOS, de csak nem az AHCI energiatakarékosság-mód miatt nincs elég tápfeszültség..

Még gondolkodom, mit lehet lépni a most látszó jelenségekre.
Az majd kipróbálhatjuk, hogy a modprobe-os módszert a kernel parancssorba is beleírjuk.

Egyelőre egy új kábelt kéne kipróbálni.

Kimenetek?

cat /etc/udev/rules.d/10-uas-discard.rules
cat /sys/block/sdb/device/scsi_disk/*/provisioning_mode
sudo sg_vpd -a /dev/sdb

És a SMARTctl (*).

Értékelés: 

0
Még nincs értékelve

Szerintem másik (más típusú) külső ház kellene

Van olyan, hogy külső ház kontrollere nem teljesen kompatibilis minden SATA eszközzel. Bővebb információ erről nincs (mármint olyan lista hogy melyik vezérlő melyik eszközzel), csak ismert dolog.

Jelen esetben úgy néz ki erről van szó. Ha pl, SSD helyett mondjuk egy HDD jól működik, SSD a gépbe közvetelenül beszerelve jól működik -> akkor új ház után kell nézni.

Milyen külső házról van szó konkrétan?

Értékelés: 

0
Még nincs értékelve

Szerintem másik (más típusú) külső ház kellene

#22

A ház típusa Gembird EE2-U3S-2. A korábban beállított konfigurációval végülis jól működik az SSD.

Csak kernelfrissítéskor vettem észre. hogy vannak hibaüzenetek, de végülis az is rendben lemegy.

Csak jeleztem a problémát, de zavart nem okoz.

Értékelés: 

0
Még nincs értékelve

Szerintem másik (más típusú) külső ház kellene

#22.1 nem tudom hová tűnt a délelőtti postom.

>A ház típusa Gembird EE2-U3S-2

Aham, ez JMS578 csipes, amelyek között voltak "hardver" hibásak is, így vagy úgy, ez előfordul másoknál is, csak mondjuk az Asmedia jobban megoldja a gyártókkal, hogy firmware frissítések könnyebben eljussanak a végfelhasználókhoz....

Persze, egy olyan cégtől, amelyik a Gamebird-re való alliterációra épít, nem tudom mit lehet elvárni.

Ezzel a házzal előfordul W10-el is anomália: https://www.tenforums.com/drivers-hardware/161445-windows-10-ssd-via-usb-detected-hdd.html

És persze, ezek eléggé random dolgok, nem lehet tudni, milyen firmware van éppen használva a kütyüben, a Jmicron csak a gyártók felé teszi elértővé a szoftvereket, akik vagy közzéteszik az oldalaikon a frissítéseket, vagy nem, de az újabb sarzsnál már javított verziót használnak, ami előtte meg kiment, az meg úgy marad....

A JMS578 csiphez elérhető alternatív forrásokból mindenféle firmwarek:

https://ralimtek.com/posts/2021/jms578/

további infók:

https://gbatemp.net/threads/how-to-update-firmware-of-jmicron-jms578-usb3-0-sata-enclosure-black-screen-lock-music-stop.569158/

Több eltérő verziójú bin fájl is elérhető, a frissítéshez jellemzően Windows kell, arra figyelni kell, hogy az adott verziójú firmware-nak mi a tulajdonsága, pl. mennyi idő alatt megy stand-by állapotba.

 

Értékelés: 

0
Még nincs értékelve
kimarite képe

Szerintem másik (más típusú) külső ház kellene

#22.1 Akkor ezt most nem értem...

Nemrég sikeresen kikapcsoltad az uas modult. Így:

echo "blacklist uas" | sudo tee /etc/modprobe.d/uas_blacklist.conf

Amúgy sem működött helyesen a korábbi beállítással (uas), de erről kaptál boot üzeneteket is.
Miyen régi beállítás? A fenti parancssor előtti helyzet?

De akkor, mi van, ha kikapcsolod a tiltást (ami amúgy sem volt bekapcsolva!). Így:

sudo mv /etc/modprobe.d/uas_blacklist.conf /etc/modprobe.d/uas_blacklist.conf.ORIG
sudo udevadm control --reload-rules ; sudo udevadm trigger

Aztán reboot.

Kérdésem, hogy ez esetben megmaradnak-e ezek az üzenetek? (dmesg)

[ 182.796111] sd 4:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 182.796118] sd 4:0:0:0: [sdb] tag#0 Sense Key : Aborted Command [current]
[ 182.796123] sd 4:0:0:0: [sdb] tag#0 Add. Sense: Information unit iuCRC error detected
[ 182.796128] sd 4:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 74 70 6c 20 00 00 08 00
[ 182.796135] blk_update_request: I/O error, dev sdb, sector 1953524768 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[ 182.805024] sd 4:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 182.805031] sd 4:0:0:0: [sdb] tag#0 Sense Key : Aborted Command [current]
[ 182.805036] sd 4:0:0:0: [sdb] tag#0 Add. Sense: Information unit iuCRC error detected
...
blk_update_request: I/O error, dev sdb, sector 6239368 op 0x0:(READ) flags 0x80700 phys_seg 2 prio class 0

Értékelés: 

0
Még nincs értékelve
kimarite képe

Szerintem másik (más típusú) külső ház kellene

#22.1.2 Még az előzőhöz kérdés. Kimenet?

cat /sys/block/sdb/device/scsi_disk/4\:0\:0\:0/provisioning_mode

Ezt tudja a géped (writesame_16):

Write same (16) with unmap bit supported (LBPWS): 1

Ha nem ez van beállítva, akkor be kell állítani, persze kell hozzá ez is,

/etc/modprobe.d/uas_blacklist.conf

tehát nem szabad átnevezni (még, azaz, ha nem writesame_16 a kimenet).

Értékelés: 

0
Még nincs értékelve

Szerintem másik (más típusú) külső ház kellene

#22.1.2.1

Ezt írja ki:
full

Értékelés: 

0
Még nincs értékelve
kimarite képe

External SSD with TRIM support | provisioning_mode

#22.1.2.1.1.1 Ha a kernel nem észlelte az eszközöd adattérkép-feloldási képességét, akkor ez valószínűleg "full" értéket fog visszaadni. A kernel SCSI tárolóillesztője a "full" mellett jelenleg a következő provisioning_mode értékeket ismeri:

unmap
writesame_16
writesame_10
writesame_zero
disabled

Forrás:
https://wiki.archlinux.org/title/Solid_state_drive#External_SSD_with_TRIM_support

Ezért kéne az előzményben említett kimenet. Kimenet?

sudo sg_vpd -a /dev/sdb

Emlékszem, hiányos volt..., de hátha most nem lesz az.

Értékelés: 

0
Még nincs értékelve

External SSD with TRIM support | provisioning_mode

#22.1.2.1.1.1.1

Most ez lett az eredmény:

sudo sg_vpd -a /dev/sdb

Supported VPD pages VPD page:
  Supported VPD pages [sv]
  Unit serial number [sn]
  Device identification [di]
  Block limits (SBC) [bl]

Unit serial number VPD page:
  Unit serial number: 6DD000000000

Device Identification VPD page:
  Addressed logical unit:
    designator type: NAA,  code set: Binary
      0x5000000000000001

Block limits VPD page (SBC):
  Write same non-zero (WSNZ): 0
  Maximum compare and write length: 0 blocks [Command not implemented]
  Optimal transfer length granularity: 1 blocks
  Maximum transfer length: 65535 blocks
  Optimal transfer length: 65535 blocks
  Maximum prefetch transfer length: 65535 blocks
  Maximum unmap LBA count: 0 [Unmap command not implemented]
  Maximum unmap block descriptor count: 0 [Unmap command not implemented]
  Optimal unmap granularity: 0 blocks [not reported]
  Unmap granularity alignment valid: false
  Unmap granularity alignment: 0 [invalid]
  Maximum write same length: 0 blocks [not reported]
  Maximum atomic transfer length: 0 blocks [not reported]
  Atomic alignment: 0 [unaligned atomic writes permitted]
  Atomic transfer length granularity: 0 [no granularity requirement
  Maximum atomic transfer length with atomic boundary: 0 blocks [not reported]
  Maximum atomic boundary size: 0 blocks [can only write atomic 1 block]

 

Viszont végrehajtottam a legutóbb érkezett kernelfrissítést, és az említett hibaüzenetek (...ignoring bad line starting with 'uas') nélkül sikeresen lefutott. Így tulajdonképpen az általad javasolt módosítások ezt a hibát kijavították.

 

Értékelés: 

0
Még nincs értékelve
kimarite képe

External SSD with TRIM support | provisioning_mode

#22.1.2.1.1.1.1.1 Szuper! Azért csak nézz rá időközönként a dmesg kimenetre: biztos, ami tuti. :)

Értékelés: 

0
Még nincs értékelve

External SSD with TRIM support | provisioning_mode

#22.1.2.1.1.1.1.1.1

Köszönöm a segítséget!

Most megint volt firmware frissítés, most sem volt hiba.

Akkor ez volt a kulcs, a korábbi beállításokhoz képest, ugye?

sudo mv /etc/modprobe.d/uas_blacklist.conf /etc/modprobe.d/uas_blacklist.conf.ORIG

Gyakorlatilag erre a konfig fájlra mégsincs szükség, uas-t nem használok. Ha jól látom ezt a fájl nem létezett eredetileg, te javasoltad létrehozását, de ezek szerint ez csak zavart okozhat.


 

 

Értékelés: 

0
Még nincs értékelve
kimarite képe

External SSD with TRIM support | provisioning_mode

#22.1.2.1.1.1.1.1.1.1 Elméletben szükség van rá. Korábban írtam ezt...

A helyes parancssor:

echo "blacklist uas" | sudo tee /etc/modprobe.d/uas_blacklist.conf

Majd.

sudo update-initramfs -uk all

A rendszer újraindítása után kimenet (teszt):

sudo lsmod | egrep -i 'uas|usb-storage'
dmesg

A fentit próbáld.

2) Illetve, ki lehet kapcsolni a tiltást, de akkor..., be lesz kapcsolva, ami hibát okoz.

sudo mv /etc/modprobe.d/uas_blacklist.conf /etc/modprobe.d/uas_blacklist.conf.ORIG

Majd.

sudo update-initramfs -uk all

A rendszer újraindítása után kimenet (teszt):

sudo lsmod | egrep -i 'uas|usb-storage'
dmesg

Értékelés: 

0
Még nincs értékelve

Szerintem másik (más típusú) külső ház kellene

#22.1.2

Az eredeti régi beállítást úgy értettem, hogy a március 12-én leírt összefoglalóban, az általad megadott
beállítottások alapján az eszköz megjavult és megbízhatón működik.

Ezen a múlt heti módosítások sem rontottak, az eszköz továbra is jól működik.

Végrehajtottam a parancsokat, újraindítottam, bedugtam, az eszköz működik, de az általad kérdezett hibaüzentek megmaradtak.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Kitérő

#22.1.2.2 A március 12-i összefoglaló inkább elmélet. Most a gyakorlat felé vennénk az utat.

Értékelés: 

0
Még nincs értékelve
kimarite képe

Összefoglaló

  • Bekapcsoltuk az USB-STORAGE modult, és kikapcsoltuk az UAS modult ID szerint:
echo options usb-storage quirks=174c:55aa:u | sudo tee /etc/modprobe.d/blacklist_uas_174c.conf
  • Kikapcsoltuk az UAS modult így is (általában, nem ID szerint):
echo "blacklist uas" | sudo tee /etc/modprobe.d/uas_blacklist.conf
  • Bekapcsoltuk a nálad támogatott writesame_16 módot eszköz szerint:
echo "writesame_16" | sudo tee /sys/block/sdb/device/scsi_disk/4\:0\:0\:0/provisioning_mode

... de a scsi_disk könyvtár után jobb, ha a TAB-bal írod be az eszközt.

echo "writesame_16" | sudo tee /sys/block/sdb/device/scsi_disk/[TAB] # majd provisioning_mode
  • Bekapcsoltuk a nálad támogatott writesame_16 DISCARD módot ID szerint UDEV szabályként:
echo 'ACTION=="add|change", ATTRS{idVendor}=="174c", ATTRS{idProduct}=="55aa", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="writesame_16"' | sudo tee -a /etc/udev/rules.d/10-uas-discard.rules

( ... fentebb, két fájlt is uas néven hoztuk létre, és nem usb-storage néven, de úgy vélem, ez nem számít. )

  • A beállítások után az UDEV szabályokat frissítettük:
sudo udevadm control --reload-rules ; sudo udevadm trigger
  • A BIOS beállításaiban AHCI energia beállításokat állítottunk be:

A Storage Configuration alatt a SATA Aggressive Link Power Management beállítása Enabled-re, ebben van az AHCI.

  • És végül újraindítottuk a rendszert.

Értékelés: 

0
Még nincs értékelve