Debian 6 UDMA gond

Debian GNU/Linux

sziasztok!

egy olyan gondom lenne hogy valamiért vissza veszi a debian a winyoim udma módját udma6-ról udma2-re.
Indításkor még minden renben van aztàn menet közben vissza rakja őket udma2be.
Kàbeleket màr cseréltem, teljesen friss a rendszer.

mi lehet a probléma??

előre is köszi!

  • 4312 megtekintés

( locsemege v | 2012. 10. 30., k – 12:32 )

Hogyan van megoldva a csatlakozás? 80 eres az IDE kábel? Egy vagy két eszköz van a kábelen? Ha egy, akkor az a kábel közbenső, vagy végén lévő csatlakozójára csatlakozik? Master, slave konfiguráció hogyan van? Mondhatnám, minek kérdezel, ha nem mondasz semmit.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Szia!

Mindegyik SATAII-es diszk.
Van közte egy NTFS file rendszerű diszk is, az is formázva lesz majd ext4-re amint lementettem róla az adatokat. Egyenlőre ntfs-3g-vel van mountolva.
De UDMA2-ben annyira nem vicces több száz giga adat mozgatás.

massages.log-ban érdekes sorokat találtam ami segíthet a probléma megfejtésében.(UDMA/33-re érdemes rákeresni...)

Itt a log file: https://dl-web.dropbox.com/get/messages?w=e44e872c

Alaplapi SATA vezérlővel használom őket.(Gigabyte 8i945p-g)

Error (403), a linkkel nem tudok mit kezdeni.

Akkor nem tudom. Arra gondoltam, hogy PATA esetén a lezáratlan IDE kábel végéről visszaverődő jel miatt csak alacsonyabb sebességgel hajlandó esetleg működni. A SATA viszont eleve hullámimpedanciával lezárt Rx és Tx szimmetrikus érpárak, ha jól tudom, tehát a kérdés ebben a formában fel sem merül.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Érdekes, mintha állandóan vergődne, megpróbálná újra inicializálni a SATA portot. Táp felől a HDD GND-je rendben van? Ugye, nem egy jelföldről szedi a nagyáramú földet a HDD? (Nem belekötni, tudom, hogy pongyola a megfogalmazásom.) Nekem sokkal stabilabb körülmények között a 3.6.4-es kernel ezt meséli:

Oct 30 13:58:07 deer kernel: [    1.364628] ata4: softreset failed (device not ready)
Oct 30 13:58:07 deer acpid: waiting for events: event logging is off
Oct 30 13:58:07 deer kernel: [    1.364691] ata4: applying PMP SRST workaround and retrying
Oct 30 13:58:07 deer kernel: [    1.519210] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Oct 30 13:58:07 deer kernel: [    1.520122] ata4.00: ATA-8: WDC WD5000AAKS-00A7B0, 01.03B01, max UDMA/133
Oct 30 13:58:07 deer kernel: [    1.520131] ata4.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
Oct 30 13:58:07 deer kernel: [    1.520138] ata4.00: SB600 AHCI: limiting to 255 sectors per cmd
Oct 30 13:58:07 deer kernel: [    1.521113] ata4.00: SB600 AHCI: limiting to 255 sectors per cmd
Oct 30 13:58:07 deer kernel: [    1.521120] ata4.00: configured for UDMA/133
Oct 30 13:58:07 deer kernel: [    1.521471] scsi 3:0:0:0: Direct-Access     ATA      WDC WD5000AAKS-0 01.0 PQ: 0 ANSI: 5
Oct 30 13:58:07 deer kernel: [    1.521841] sd 3:0:0:0: Attached scsi generic sg0 type 0
Oct 30 13:58:07 deer kernel: [    1.521853] sd 3:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
Oct 30 13:58:07 deer kernel: [    1.522109] sd 3:0:0:0: [sda] Write Protect is off
Oct 30 13:58:07 deer kernel: [    1.522200] sd 3:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Oct 30 13:58:07 deer kernel: [    1.539621]  sda: sda1 sda2 < sda5 sda6 >
Oct 30 13:58:07 deer kernel: [    1.540581] sd 3:0:0:0: [sda] Attached SCSI disk

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Windowsos konfig korában nem volt vele gond.
Nem is olyan rég(kb 1 hónapja) még egyik ismerősömnél volt csere gépként, akkor még tökéletes volt.
Előtte nekem volt itthon az egyik asztalim, windózzal. És tökéletesen ment.

Bár hogy biztosak legyünk a táp hibátlanságában rakhatok bele egy másik tápot is akár.

Nagyon nem értek hozzá, de úgy tűnik, az ata2 interface-en van egy Samsung és egy WD HDD, az előbbi 512 byte-os, az utóbbi 4096 byte-os fizikai szektormérettel. Nem tudom, jó-e ez így. Nem lehetne a 3 TB-os WD HDD-t olyan interface-re rakni, ahol nincs más?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Tudom, most az UDMA a gondod, de biztos, hogy nyerő egy 4 kiB-os fizikai szektorokkal rendelkező HDD-t úgy használni, hogy a logikai szektorméret 512 byte? Szerintem eleve lassú lesz, hiszen fel kell olvasnia 4 kiB-ot, a megfelelő 512 byte-ot módosítani, majd visszaírni 4 kiB-ot. Lényegesen több adatot mozgatsz, mint amit feltétlenül kellene. Lehet persze, hogy ez HDD-n belül történik, de még akkor is így van. Gondolom, ez a GPT világába vezet már.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

4db SATA portom van így másra nem tudom rakni.
512byte-os szektor méret meg nem nyerő mert akkor nem tudom használni mind a 3TB-ot, ahhoz mindenképp GPT-vel kell particionálnom, ami meg ugye 4k-s szektor méretet ad.

Javíts ki ha tévednék!

Am ha valóba ez lenne a gáz akkor mivel magyarázod azt hogy az 500as samsungról a 160as maxtorra másolva miért állt vissza a maxtor udma2-be??

Mindegyiken egyforma a szektor méret.

512byte-os szektor méret meg nem nyerő mert akkor nem tudom használni mind a 3TB-ot, ahhoz mindenképp GPT-vel kell particionálnom, ami meg ugye 4k-s szektor méretet ad.

Bajban vagyok, nem értem. Most úgy áll a dolog, hogy 4 kiB-os fizikai szektoraid vannak, s 512 byte-os emulációt használsz rajta. Én is azt mondom, hogy nem nyerő, aztán mégis ezt csinálod. Szerintem GPT kellene arra a HDD-re, s valóban 4 kiB-os szektorok. Úgy értem, nem csak fizikailag, de logikailag is.

Ugyanakkor valóban az a gyanúm, az UDMA problémádat nem ez okozza. Amit esetleg tesztelnék, az az, hogy megnézném, külön-külön jelentkezik-e a probléma a HDD-kkel, s ha igen, melyekkel. Tehát csak egy HDD-t csatlakoztatnék a portra, másolnék dd-vel a /dev/zero-ból rá, s nézném a sebességet meg a logokat. Vigyázz, sebességnél a disk cache miatt az elején nagyon nagy érték jöhet ki, hiszen RAM-ba megy az adat, a RAM meg nagyon gyors.

Utána nézném a másik HDD-vel, de megint csak eggyel. A többi HDD és ODD SATA csatlakozóját addig lehúznám. Oprendszert pedig pendrive-ról boot-olnék. Aztán a következővel, s így tovább, s nézném a kernel logjait is - dmesg illetve messages -, hogy lássam, jelentkezik-e a gond. Így talán behatárolható a hiba, kiderül, függ-e HDD-től. Megnézném azt is, hogy egy adott HDD másik, harmadik SATA porton produkálja-e a hibát.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Igen abban teljesen igazad van hogy 512-es logikai és 4096-os fizikai méret van.
Hogy tudom azt elérni hogy valóban 4k-s szektorok legyenek?
Mikor beraktam csak annyit csináltam parteddal hogy mklabel gpt meg mkpart primary ext4 0% 100% majd quit és mkfs.ext4 /dev...

Jelentkezik az mindegyikkel csak idő kérdése. Most hogy bennt van 3 winyó, akár melyiket letudom küzdeni udma2-be. Szval mindegyiken jelentkezik előbb vagy utóbb. Volt amikor megörültem hogy már átvitt majdnem 10gigát erre bumm vissza esett. 

Oct 29 09:14:12 debian-server kernel: [    1.330888] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x2)

úgy tűnik, mintha már bootoláskor kezdődnének a gondok: az ata 2.00-n pedig a samu van. 

Oct 29 09:14:12 debian-server kernel: [    1.312505] ata2.00: HPA detected: current 625140335, native 625142448
Oct 29 09:14:12 debian-server kernel: [    1.312511] ata2.00: ATA-8: SAMSUNG HD321KJ, CP100-13, max UDMA7
Oct 29 09:14:12 debian-server kernel: [    6.506850] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x2)
Oct 29 09:14:12 debian-server kernel: [    6.506895] ata2.00: limiting speed to UDMA/133:PIO3
Oct 29 09:14:12 debian-server kernel: [   11.642850] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x2)
Oct 29 09:14:12 debian-server kernel: [   11.642893] ata2.00: disabled

Tipp1: Húzd le ezt a samut átmenetileg, hogy akkor is nyarvog-é?

Esetleg egy smart ot érdemes lenne átnézetni vele.

Tipp2: van valami oka, hogy nem az AHCI-t használod ?
(nem tudja a biosod ?)

Hátha a ata_piix helyett az ahci vezérlővel nem jön elő a hiba. Egy bootolást megér ? 

Oct 29 09:14:12 debian-server kernel: [    1.125116] scsi0 : ata_piix
Oct 29 09:14:12 debian-server kernel: [    1.125221] scsi1 : ata_piix

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

Huh köszi hogy szóltál erre ránézek.
Egy ideig nem nálam volt a lap. Egyik ismerősömnél, és fel sem merült hogy át állította volna az AHCI-t.
Elvileg tudja az AHCI-t, vagyis konkrét ilyen opció emlékeim szerint nincsen benne, hanem az on-chip sata mode-ot kell enhanced rakni ekkor lesz SATA módban.
Am ha nem sata módban menne akkor miért SDx-nek ísmeri fel a winyókat?
A PATA winyókat nem HDx-nek kéne felismernie?

Ez a samu jelenleg le van húzva mert félig halott csak az adatokat húzom le róla aztán megy sör alátétnek.

Az alaplap amúgy egy Gigabyte 8i945p-g.

Sajna csak vasárnap derül ki, mert jelenleg csak SSH-n férek hozzá, mivel nem vagyok fent Pesten.

A pata vinyókat a libata kezeli, ami pedig scsi devfile-al jár (sdx).
Az AHCI-t ez a lap nem támogatja (On-Chip SATA mode - Enhanced != AHCI), mivel ezen valószínűleg csak az alapmodell ICH7 van (nem a dh vagy r végződésű ami tud AHCI-t).
Ha nincs az "Integrated Peripherals" BIOS menüben "SATA/RAID AHCI Mode" menüpont, akkor biztos, hogy nem tudja az AHCI-t.

(Fontold meg amit lentebb írtam a green-ről.)

kapcsold le, áramtalanítsd, kösd át a WD-t a lekötött samu HELYÉRE ata2.00-ra ata2.01-ről. hátha (?).
egyéb ötlet nincs.

Mondjuk gyanusan azzal a kóddal dobja el mint a "döglött samut", sz'al lehet, hogy a WD sincs már rendben (?). 

Oct 29 22:34:27 debian-server kernel: [  111.082608] ata2: soft resetting link
Oct 29 22:34:27 debian-server kernel: [  111.282067] ata2.01: configured for UDMA/133
Oct 29 22:34:27 debian-server kernel: [  111.282084] ata2: EH complete
Oct 29 22:34:34 debian-server kernel: [  118.322124] ata2: soft resetting link
Oct 29 22:34:35 debian-server kernel: [  118.520204] ata2.01: failed to IDENTIFY (I/O error, err_mask=0x2)

legalábbis ez a ata2-es port ez valahogy nincs rendben.

Ha átkötnéd a vinyókat érdemes lenne megnézni, hogy a hiba a portot követi-e, vagy a vinyót. Ha a portot, akkor az alaplap sanszosan lassan megadja magát szvsz, ha a vinyót, akkor meg a vinyó.

Mondjuk megcseréled a ata1-en levő egyik vinyót az ata2-n levő WD-vel.

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

Hagyd ki a WD Green nevű ipari hulladékát a konfigból (bocsánat, de túl sokat szívok WD-kel mostanság). Ha a "hiba" eltűnik, akkor megvan a tettes, és nagyon gyanús hogy a green lesz az.
Az még csak egy dolog hogy UDMA/133-ként hirdeti meg magát, de valószínűleg a aggresszív fejparkoltatás miatt generál néhány hibát, amire az egész kontrollert leküldi /133-ra (hacsak ez nem a chipset limitációja).

Ajánlom még figyelmedbe, talán segíthet valamit, a persistent rész oldhatná meg:
Special_Consideration_for_WD_Green_HDDs

( ztamas | 2012. 11. 02., p – 10:46 )

Többiek még nem mondták, de egy memtestet nézhetnél. Ugyanígy 6os Debiannal hasonlóba belefutottam már. Ha elkezdtem másolni ott is kegyetlenül lelassult a dolog. Volt kábelcsere meg tápcsere is persze. Végén kiderült, hogy a memória a bűnös.