Fájlmásolás --> Kernel panic

Debian GNU/Linux

Üdv mindenkinek!

Az itthoni rendszerem:
- Athlon 64 processzor 1GB RAM
- SATA HDD-n Debian Lenny AMD64 (több ext3 partícióval)
- IDE primary master HDD-n Win2000 (több NTFS partícióval)

Az NTFS partíciókat ntfs-3g -vel csatolom fel rw módban. Minden szépen működik egészen addig, míg egy méretesebb fájlt (jellemzően > 300 MB) meg nem próbálok átmásolni az egyik NTFS partícióra. Ilyenkor a legváltozatosabb pillanatokban (de jellemzően 50% felett) dob egy kernel panic-ot a rendszer. Próbaként csináltam egy másolást két ext3 partíció között is, ott nem jelentkezett a probléma.

Találkozott már valaki ilyennel?

Ps.: még annyit vettem észre (de ez lehet belemagyarázás is), hogy amikor X felületen megy a másolás, akkor hajlamosabb előbb kifagyni, míg konzolon némileg stabilabbnak tűnik (értsd: többet másol át, mint X alatt).

  • 1704 megtekintés

( tovis v | 2008. 06. 14., szo – 00:19 )

Javítsatok ki, de én úgy tudom hogy az ntfs írása linux alól nem biztonságos. Használj fat32 -őt.

* Én egy indián vagyok. Minden indián hazudik.

Rolling On The Floor Laughing My Ass Off gondolom. Magyarul a földön hemperegve szétröhögi a seggét :D fogalmazza meg magyarosabban aki tudja :P

-----------------------------------------------------------------------------------------------------------------------------
AMD Athlon 64 X2 Dual Core 6000+, Nvidia Geforce 8500GT 512Mb, 2GB DDR2-800Mhz, MSI K9 Neo v3, Debian "lenny",2.6.24-amd64

Nagyjából 1 éve használom az ntfs-3g -t és ezen kívül semmi gondom nincs vele. A felírt fájlok Windows alatt gond nélkül elérhetők, kezelhetők.
Azért a Fat32-őt te sem gondolhatod komolyan. Akkor már inkább felteszem Windows alá az IFS-t (egyik gépen fenn is van) és azzal felcsatolom az ext partíciókat.

--------------------------------------------------------------
"Tegnap reggel addig röhögtünk a főnök viccén, míg ki nem derült, hogy az a napi feladat."

Elég sok szoftvert írtam már, volt ezek között egyszerű fájl kezelgető is.
Én hiszek a fejlesztőknek, és úgy gondolom amíg ők azt nem mondják hogy OK addig csak ha feltétlenül muszáj. Gépen belül marad a FAT32, az egyetlen gond a nagyfájloknál jelentkezik, a fragmentálódást kezelni lehet. Az ntfs fragmentálósásához vastagon fizetős cucc kell.
Az ifs -el az a gondom hogy lassú.
Mi a helyzet a vmware -el - egyidőben futtat két oprendszert amit akár hálózaton beköthetsz?

* Én egy indián vagyok. Minden indián hazudik.

( szaka | 2008. 06. 14., szo – 03:52 )

Tipikus hardver hibanak tunik. Latszolag amikor nagyobb a terheles a gepeden, akkor osszedol. Ellenorizd a kernel logokat, s teszteld a geped. RAM, tap, vinyo (hibas szektorok), vinyo kabel a tipikus hardver hibak ilyen estekben.

Udv: Szaka

--
NTFS-3G: http://ntfs-3g.org

Meglátjuk. A RAM-ot már teszteltem egy héttel ezelőtt, jónak tűnik. A táp esélyes lehet, bár napi 12-14 órás használat mellett szerintem már kijött volna a gondja.

Az jutott eszembe, hogy a SATA HDD-n létrehozok egy NTFS partíciót és azon is kipróbálom a másolást. Ha ottt működik, akkor egyértelműen az IDE HDD vacakol (8 éves IBM, szóval megvan rá az esély).
Majd jelentkezem az eredménnyel.

--------------------------------------------------------------
"Tegnap reggel addig röhögtünk a főnök viccén, míg ki nem derült, hogy az a napi feladat."

( Oscon | 2008. 06. 14., szo – 11:46 )

1. A kernel bugot feltehetnéd vhova, hátha kiderül belőle valami. Lehet hogy SATA->ATA másolási probléma lesz (?).

2. Ha van pl. knoppix live dvd-d, esetleg megnézheted ia32-es kernellel is produkálja-e vagy amd64 specifikus a gond ?

3. Próbáld meg captive-ntfs sel is /márha működik / ugyanazt hogy fagy-e vagy sem. Ha igen akkor sanszos hogy fuser kernel modullal van probléma.Ha nem, akkor az úgy érdekes...

3. Biztos hogy teljesen ép az NTFS partíciód ? chkntfs /f /r win2k alól ?

4. smartctl -t long /dev/[vinyó]hda majd 30-35 perc múlva amit ír smartctl -a /dev/[vinyó]

5. Akkor is fagy ha NTFS-ről másolsz vissza ext3ra ?

------------

Nem a zsömle kicsi, a pofátok nagy...

( Hunger | 2008. 06. 14., szo – 11:59 )

Pont a lényeget, a kernel pánic üzenetet és a hozzá tartozó információkat nem írtad ide.

( Dr_Mac | 2008. 06. 14., szo – 16:19 )

Közben el kellett mennem, most kerültem ismét gép közelébe. Megpróbálok egyszerre válaszolni.
Igaz, hogy a kernel panic üzeneteit nem másoltamide. Mentségemre szolgáljon, hogy amikor megnyitottam a témát, már egy kiscit fáradt voltam.
Az IFS lassúságát eddig még nem vettem észre és nekem gond nélkül csatolt eddig fel minden ext2/3 partíciót.

Az elmúlt egy órában létrehoztam egy ntfs partíciót a SATA hdd-n és a következőket csináltam:
- 1.5 GB-os fájlt másoltam SATA ext3 --> SATA ntfs irányban (rendben)
- ugyanakkora fájl másolása PATA ntfs --> SATA ext3 irányban (rendben)
- és a végén ugyanennek a fájlnak a másolása SATA ext3 --> PATA ntfs irányban (rendben)

Ezek alapján erősen hardverhiba felé hajlok, konkrétan melegedésre gyanakszom. Még egy SMART-ot ráeresztek a rendszerre, hátha mutat valamit (a logokban eddig semmit nem találtam). Ha esetleg sikerült ismét elkapnom a jelenséget, lejegyzem a kernel panic üzeneteit is és ismét jelentkezem.

Köszönöm az eddigieket.

--------------------------------------------------------------
"Tegnap reggel addig röhögtünk a főnök viccén, míg ki nem derült, hogy az a napi feladat."

( Dr_Mac | 2008. 07. 04., p – 16:02 )

Nos, újra itt. Egy órával ezelőtt a hiba ismét előjött (az elmúlt két hétben nem volt gond). Szerencsére konzolon csináltam épp egy másolást SATA ext3 --> IDE NTFS irányban, amikor kifagyott. Viszont a képernyőn fennmaradt egy részlet a kernel panic-ból: 


<IRQ>[<ffffffff80302d0f>]__end_that_request_first+0x1ab/0x3a9
[<ffffffff80305600>] blk_run_queue+0x41/0x73
[<ffffffff88095efc>]:ide_core:__ide_end_request+0x50/0x76
[<ffffffff8809d7c7>]:ide_core:ide_dma_intr+0x67/0xac
[<ffffffff8809d760>]:ide_core:ide_dma_intr+0x0/0x0ac
[<ffffffff88096d2c>]:ide_core:ide_intr+0x18e/0x1fe
[<ffffffff8026cb28>] handle_irq_event+0x25/0x53
[<ffffffff8026e168>] handle_edge_irq+0xe4/0x28
[<ffffffff8020ede4>] do_IRQ+0x6c/0xd4
[<ffffffff8020b09d>] default_idle+0x0/0x3d
[<ffffffff8020c341>] ret_from_intr+0x0/0xa
<EOI>  [<ffffffff8020b0c6>] default_idle+0x29/0x3d
[<ffffffff8020b16a>] cpu_idle+0x90/0xbb
[<ffffffff80556a6d>] start_kernel+0x2d9/0x2e5
[<ffffffff8055611d>]_sinittext+0x11d/0x124

Code: ff 50 38 48 89 df 5b e9 32 14 00 00 41 57 49 89 f7 41 56 41
RIP:[<ffffffff802b83ce>] end_bio_bh_io_sync+0x21/0x2d
   RSP <ffffffff805aae28>
CR2 ffff800013dc6cc8
--- [ end trace 3768d2420025cba8 ] ---
Kernel panic - not syncing: Aiee, killing interrupt handler!

Nos, ennyit sikerült megmentenem. A logokban semmi nyoma ezeknek.
A Google keresések eléggé vegyes eredményt hoztak. Az egyik szerint memória probléma, a másik szerint le kell tiltani az ACPI-t. Én elpasszolom, ennyire (sajnos) nem vagyok jó.
Esetleg valaki hozzáértőnek ötlete?

--------------------------------------------------------------
"Tegnap reggel addig röhögtünk a főnök viccén, míg ki nem derült, hogy az a napi feladat."

A hddtemp szerint az IDE egység 49 fokos, a SATA pedig 54 fokos. Szóval ez még jó islehet. Lehet, hogy a hdparm marad a megoldás, mert új kernel forgatásához most nincs sok hangulatom (jelenleg 2.6.24). A bajom mindössze annyi, hogy a hiba nagyon esetlegesen jön elő. Most eltelt 2 hét gond nélkül, de néha naponta kétszer is előjön.
Meglátjuk.

--------------------------------------------------------------
"Tegnap reggel addig röhögtünk a főnök viccén, míg ki nem derült, hogy az a napi feladat."

Jelenleg 1.2506-os van fenn csomagból. Holnap talán megpróbálok egy 1.2531-est fordítani. Ma már nem, mert tuti valamit elbaltázok.

--------------------------------------------------------------
"Tegnap reggel addig röhögtünk a főnök viccén, míg ki nem derült, hogy az a napi feladat."

Hat, nekem a root 80-as IDE 35 C, a /home 500-as WD IDE 43C. A ket SATA wincsi (olyan 160-300 kozottiek, mar nem emlekszem :) a ketto kozott.
Itt bent a cegnel (normal hazban, routerkent hasznalva, jo 30+ kulso homerseklet van) 30C a wincsi. De ez nincs semennyire sem meghajtva.

Szoival sztem az a 49 es 54 eleg sok. Valami hutesrol kellene gondoskodni. Legalabb a gepet kiporolni.

Én csak egy egységsugarú user vagyok, de én megpróbálnám ezt a patchet ha egy erre járó naprakész hw-s kockának se lesz jobb ötlete:

http://lwn.net/Articles/286341/

Amúgy ha normál 32bites linuxod van, felesleges rá X64es kernelt tenni. meg egyébként is ki kéne szórni a kernel configból a felesleges "szemetet": "szemet"=nem használt kernel modulok, opciók. Pl. ha normál egymagos egyszerű processzorod van. minek az SMP meg a többiek ?

----------

r=1 vagyok, de ugatok...

A rendszerem gyári 64 bites Debian Lenny, a kernel is csomagból jött. Nincs külön egy- vagy többprocesszoros változat, csak ez az egy.
Mint feljebb is írtam, a kernellel most nincs nagyon hangulatom foglalkozni, szóval ezt a lehető legutolsó pontnak hagynám.
Holnap még foglalkozom egy kicsit a ház szellőzésével, meglátom mennyivel megy lejjebb a HDD-k hőfoka.

--------------------------------------------------------------
"Tegnap reggel addig röhögtünk a főnök viccén, míg ki nem derült, hogy az a napi feladat."

Tényleg meleg a diszk, de ha csak az NTFS-el kapcsolatban tapasztalod, mindig Linux alatt, mindig másolásnál, és ugyanolyan kernel panic, akkor az annyira determinisztikus, hogy szoftverhiba kell hogy legyen.

Elsősorban bugreportold.

Utána próbálj meg másik gyári kernelt feltenni, az nem sok munka.

Arra még nem válaszoltál, hogy egyébként biztosan clean-e az NTFS?

--
The Net is indeed vast and infinite...
http://gablog.eu

Az NTFS (szerintem) biztosan tiszta. Ugyanis minden ilyen karnel panic után Windowst indítok és az összes partícióra ráengedem az ellenőrzést és javíttatom a hibát.

Az a bajom, hogy a hibát nem tudom rendszeresen és felismerhetően előidézni. Teljesen rapszodikusan csinálja. Tegnap éjjel például aptitude-ot indítottam és amikor elkezdte letölteni a frissebb csomagokat, akkor feküdt ki. Pedig itt aztán NTFS szóba sem jön.

Talán mégis nekiállok fordítani egy kernelt (vagy csinálok egy downgrade-et egy régebbi gyárira).

--------------------------------------------------------------
"Tegnap reggel addig röhögtünk a főnök viccén, míg ki nem derült, hogy az a napi feladat."

kellene egy fsck ext3-ra is ...

[snip]
EXT3-fs: sda1: orphan cleanup on readonly fs
ext3_orphan_cleanup: deleting unreferenced inode 380692
ext3_orphan_cleanup: deleting unreferenced inode 5294583
ext3_orphan_cleanup: deleting unreferenced inode 5294103
ext3_orphan_cleanup: deleting unreferenced inode 327688
ext3_orphan_cleanup: deleting unreferenced inode 327685
ext3_orphan_cleanup: deleting unreferenced inode 327684
ext3_orphan_cleanup: deleting unreferenced inode 327683
ext3_orphan_cleanup: deleting unreferenced inode 327682
[snip]

gentoo gnu/linux @ linux-2.6.26-rc8-git2 | patch
info

Bocs, ez kicsit megtévesztő. Pont a legutolsó kernel panic utáni első bootfolyamatot sikerült bemásolnom :D
Azért ráküldök egyet, biztonság kedvéért.

--------------------------------------------------------------
"Tegnap reggel addig röhögtünk a főnök viccén, míg ki nem derült, hogy az a napi feladat."