Hibás gépben a hiba meghatározása .....

Alaplapok

A következő a problémám:
Van egy Asus P5B alaplap + core2duo 2,4Ghz + 2db sata + 1db ata hdd, Debian 4.0
Olyat csinál a gép, hogy ha másolok egy olyan 30Gb adatot a load felmegy 5-6 körülire és vagy kifagy hibaüzenet nélkül vagy egy számomra értelmezhetetlen teljes oldalas kernelpánikkal áll meg.
Mi lehet a hiba? Valaki találkozott már valaha hasonlóval?

  • 2651 megtekintés

( efbijn | 2009. 01. 04., v – 09:46 )

syslog?
SMART ellenőrzés? Memtest?

up: jah az utolsó kettő az javaslat és nem kérdés. :-)

@@
"You can hide a semi truck in 300 lines of C."
Debian Lenny 2.6.27.6
OpenSolaris 2008.05

( Helios | 2009. 01. 04., v – 09:56 )

Hasonlóval találkoztam már régebben RHEL3 alatt még 2.4-es kernel verzióval.
Ott bizonyos verziójú kernelekkel, ha több százezer kis fájlt kellett másolni, akkor előbb utóbb a kifagyáshoz hasonlót produkált nagy loaddal, mert valamiért nem ürítette jól a disk cachet és nekiállt swappelni... (Vagy valami ilyesmi :), már nem emléxem pontosan, de a jelenség stimmel.) Pánikot viszont sosem produkált.
Ilyenkor csak kb. reset illetve talán a copy process időben kilövése segített.

Megoldás az volt - hogy amíg ki nem javították a kernel hibát, amihez elég sok idő kellett - addig olyan régi kernelt használtam, ami még nem produkálta ezt a hibát.

----------------------------
"Még jó, hogy nem szeretem a finomfőzeléket. Mert ha szeretném, meg kellene ennem. Pedig nem szeretem."

Eleinte nekem is csak egyszerűen befagyott az alap (4.0r6) debiannal, de amikor már feltettem rá ezt: http://kmuto.jp/debian/d-i/ etch-custom-0622.iso AMD64 akkor már főként kernel pánikot produkált.
Érdekes, hogy a gép alapesetben jól megy. Egy sima dvd iso-t még át is másol, de amikor egy nagyobb mennyiséget adok neki akkor kiakad ...

AMD64 == EM64T
A 64 bites x86 cuccok ilyenek.
Mivel az AMD csinál elöször 64 bites x86 -os processzort, ezért AMD64 lett a neve.
Később az Intel is kijött a 64 bites x86 procijaival, de természetesen ez AMD64 kompatibilis.
Az Intel azért csak kitalálta az EM64T nevet az architektúrának, de ez gyakorlatilag ugyan az, mint az AMD64
És mivel az AMD elsőzött ebben a kérdésben, ezért AMD64-nek hívját a 64 bites x86 platformot.
Szokott szerepelni egébként az x86_64 jelölés is, ez is ugyan ezt takarja.

http://hu.wikipedia.org/wiki/X86-64

Az IA64 totál más dolog, semmi köze ezekhez, az nem x86-os processzor. Az az Intel Itanium platformja.

(Általánosságban: hányszor fog még ez a dolog felmerülni? sóhaj...)

Eddig gyári 2.6.24.*-amd64 kernelt és a custom debian telepítő 2.6.25.*-amd64 kernelét használtam.
Most kipróbáltam a 2.6.18-6-amd64-es kernelt és úgy néz ki ezzel jól működik, legalább is közel 30Gb átmásolása + közben 4db virtuális gép elindítása és leállítása (többször) egyszerre sem fektette ki a gépet.

Ez mire jó? És mit old meg?

Az a probléma, hogy jelenleg kb. 130km választ el a géptől és ha kifektetem újra akkor megint hívhatom a srácokat, hogy indítsák újra. :S
Előzőleg 32bites rendszer volt rajta és a 2.6.18-4-bigmem kernellel elég stabilnak tűnt, de a 64 bit miatt újra telepítettem, de a telepítő 2.6.25 ... kernelével önmagától egy idő után megállt.
Most újra próbáltam, hogy régebbit teszek rá, de úgy néz ki ez most nem segít.

Szerk.: Most már mind1 is, mert önmagától újra elérhetetlen a gép. Most már csak ez a lentebbi infó maradt.

Ez főként nagy fájl (>20Gb) másolásakor következik be.


Jan 14 10:01:28 nautilus kernel: BUG: soft lockup detected on CPU#1!
Jan 14 10:01:28 nautilus kernel:
Jan 14 10:01:28 nautilus kernel: Call Trace:
Jan 14 10:01:28 nautilus kernel: [] softlockup_tick+0xdb/0xed
Jan 14 10:01:28 nautilus kernel: [] update_process_times+0x42/0x68
Jan 14 10:01:28 nautilus kernel: [] smp_local_timer_interrupt+0x23/0x47
Jan 14 10:01:28 nautilus kernel: [] smp_apic_timer_interrupt+0x41/0x47
Jan 14 10:01:28 nautilus kernel: [] apic_timer_interrupt+0x66/0x6c
Jan 14 10:01:28 nautilus kernel: [] :ext3:ext3_releasepage+0x0/0x73
Jan 14 10:01:28 nautilus kernel: [] :jbd:journal_grab_journal_head+0x4/0x44
Jan 14 10:01:28 nautilus kernel: [] :jbd:journal_try_to_free_buffers+0x6f/0x16d
Jan 14 10:01:28 nautilus kernel: [] shrink_inactive_list+0x4a5/0x7e1
Jan 14 10:01:28 nautilus kernel: [] thread_return+0x0/0xe7
Jan 14 10:01:28 nautilus kernel: [] shrink_zone+0xe2/0x107
Jan 14 10:01:28 nautilus kernel: [] kswapd+0x2f9/0x41b
Jan 14 10:01:28 nautilus kernel: [] autoremove_wake_function+0x0/0x2e
Jan 14 10:01:28 nautilus kernel: [] keventd_create_kthread+0x0/0x61
Jan 14 10:01:28 nautilus kernel: [] kswapd+0x0/0x41b
Jan 14 10:01:28 nautilus kernel: [] keventd_create_kthread+0x0/0x61
Jan 14 10:01:28 nautilus kernel: [] kthread+0xd4/0x107
Jan 14 10:01:28 nautilus kernel: [] child_rip+0xa/0x12
Jan 14 10:01:28 nautilus kernel: [] keventd_create_kthread+0x0/0x61
Jan 14 10:01:28 nautilus kernel: [] kthread+0x0/0x107
Jan 14 10:01:28 nautilus kernel: [] child_rip+0x0/0x12
Jan 14 10:01:28 nautilus kernel:
Jan 14 10:02:11 nautilus kernel: Unable to handle kernel NULL pointer dereference at 0000000000000008 RIP:
Jan 14 10:02:11 nautilus kernel: [] :ext3:walk_page_buffers+0x34/0x9a
Jan 14 10:02:11 nautilus kernel: PGD 196e97067 PUD 195c76067 PMD 0
Jan 14 10:02:11 nautilus kernel: Oops: 0000 [1] SMP
Jan 14 10:02:11 nautilus kernel: CPU 0
Jan 14 10:02:11 nautilus kernel: Modules linked in: ipv6 button ac battery dm_snapshot dm_mirror dm_mod loop i2c_i801 psmouse i2c_core parport_pc parport serio_raw tsdev joydev evdev pcspkr ext3 jbd mbcache jmicron usbhid sd_mod generic ide_core r8169 ahci libata scsi_mod ehci_hcd uhci_hcd thermal processor fan
Jan 14 10:02:11 nautilus kernel: Pid: 3743, comm: pdflush Not tainted 2.6.18-4-amd64 #1
Jan 14 10:02:11 nautilus kernel: RIP: 0010:[] [] :ext3:walk_page_buffers+0x34/0x9a
Jan 14 10:02:11 nautilus kernel: RSP: 0018:ffff81018622bbe0 EFLAGS: 00010206
Jan 14 10:02:11 nautilus kernel: RAX: 0000000000000000 RBX: 0000000000003000 RCX: 0000000000000000
Jan 14 10:02:11 nautilus kernel: RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000002000
Jan 14 10:02:11 nautilus kernel: RBP: ffff810077482430 R08: 0000000000000000 R09: ffffffff880e24d9
Jan 14 10:02:11 nautilus kernel: R10: ffff8100774823d0 R11: 0000000000000060 R12: 0000000000002000
Jan 14 10:02:11 nautilus kernel: R13: 0000000000001000 R14: 0000000000000000 R15: 0000000000000000
Jan 14 10:02:11 nautilus kernel: FS: 0000000000000000(0000) GS:ffffffff80521000(0000) knlGS:0000000000000000
Jan 14 10:02:11 nautilus kernel: CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
Jan 14 10:02:11 nautilus kernel: CR2: 0000000000000008 CR3: 0000000193e9a000 CR4: 00000000000006e0
Jan 14 10:02:11 nautilus kernel: Process pdflush (pid: 3743, threadinfo ffff81018622a000, task ffff810199957830)
Jan 14 10:02:11 nautilus kernel: Stack: ffffffff880e24d9 0000000000001000 ffff81019674c558 ffff81019ef4eb10
Jan 14 10:02:11 nautilus kernel: ffff81019674c558 000000009674c558 ffff810077482430 ffff81018622be70
Jan 14 10:02:11 nautilus kernel: 0000000000000000 ffffffff880e5362 ffff81019ef4eb10 ffff81018622be70
Jan 14 10:02:11 nautilus kernel: Call Trace:
Jan 14 10:02:11 nautilus kernel: [] :ext3:bget_one+0x0/0x7
Jan 14 10:02:11 nautilus kernel: [] :ext3:ext3_ordered_writepage+0xdf/0x198
Jan 14 10:02:11 nautilus kernel: [] mpage_writepages+0x1a6/0x34d
Jan 14 10:02:11 nautilus kernel: [] :ext3:ext3_ordered_writepage+0x0/0x198
Jan 14 10:02:11 nautilus kernel: [] do_writepages+0x29/0x2f
Jan 14 10:02:11 nautilus kernel: [] __writeback_single_inode+0x1b4/0x38b
Jan 14 10:02:11 nautilus kernel: [] del_timer_sync+0xc/0x16
Jan 14 10:02:11 nautilus kernel: [] schedule_timeout+0x92/0xad
Jan 14 10:02:11 nautilus kernel: [] process_timeout+0x0/0x5
Jan 14 10:02:11 nautilus kernel: [] sync_sb_inodes+0x1d1/0x2b5
Jan 14 10:02:11 nautilus kernel: [] keventd_create_kthread+0x0/0x61
Jan 14 10:02:11 nautilus kernel: [] writeback_inodes+0x7d/0xd3
Jan 14 10:02:11 nautilus kernel: [] background_writeout+0x82/0xb5
Jan 14 10:02:11 nautilus kernel: [] pdflush+0x0/0x1ed
Jan 14 10:02:11 nautilus kernel: [] pdflush+0x143/0x1ed
Jan 14 10:02:11 nautilus kernel: [] background_writeout+0x0/0xb5
Jan 14 10:02:11 nautilus kernel: [] kthread+0xd4/0x107
Jan 14 10:02:11 nautilus kernel: [] child_rip+0xa/0x12
Jan 14 10:02:11 nautilus kernel: [] keventd_create_kthread+0x0/0x61
Jan 14 10:02:11 nautilus kernel: [] kthread+0x0/0x107
Jan 14 10:02:11 nautilus kernel: [] child_rip+0x0/0x12
Jan 14 10:02:11 nautilus kernel:
Jan 14 10:02:11 nautilus kernel:
Jan 14 10:02:11 nautilus kernel: Code: 4c 8b 76 08 46 8d 24 2f 0f 96 c2 3b 7c 24 08 0f 93 c0 08 c2
Jan 14 10:02:11 nautilus kernel: RIP [] :ext3:walk_page_buffers+0x34/0x9a
Jan 14 10:02:11 nautilus kernel: RSP
Jan 14 10:02:11 nautilus kernel: CR2: 0000000000000008

( corvusaze | 2009. 01. 17., szo – 23:01 )

Hogy talán mások számára is hasznos legyen megosztom a megoldást:
Egyszerűen csak a videokártya és az alaplapi hálókártya miatt fagyott le üres járásban vagy másolás közben .... már a végén már mindentől fagyott.
Kicsit gyanús is volt, hogy lassabban boot-ol ... videokártya csere után sokkal gyorsabb lett a gép, aztán pedig hogy letiltottam az alaplapi hálókártyát és tettem bele másik pci-osat egyből hibamentes lett a gép! De erre a hibaüzenetekből nem lehetett rájönni.

( corvusaze | 2009. 01. 19., h – 08:59 )

A probléma úgy látszik nem oldódott meg. A másolás vagy bármilyen terhelés már nem fagyasztja ki, de kb. 10-15 óra terhelés mentes állapot után gyakorlatilag elérhetetlen távolról a gép. (Van amikor hajlandó a pingre válaszolni.)

Van egy olyan gyanúm, hogy hosszas, akár több napos tesztelés után tudod csak meg a hiba okát. Szóval először gondoskodni kellene arról, hogy valami helyettesítse a gépet (ha kell), utána az eddigi módszert követve kicserélni egy-egy alkatrészt (én az alaplappal kezdeném).

Szerencsére nincs rajta semmi szolgáltatás, de már nem ártana ha jó lenne, mert 1-2 dogot szeretnék rátenni, de így nincs értelme és még fizethetem is utána az elhelyezési pénzt. :S

A probléma az, hogy gyakorlatilag minden alkatrészből kellene csere ami ha lenne akkor nem szarakodnék vele, hanem mindent kicserélnék és ez meg mehetne a kukába, de nincs és igazából feles pénzem se, hogy most csak úgy vegyek egy próba alaplapot és processzort és memóriát és tápot és kábeleket és stb ...

Igazából sokáig ment ez a cucc itthon hibátlanul ... aztán 2 hónapig volt benne egy quad proci, mert az új gépemhez nem volt mindenből amit szerettem volna és használtam addig is ebben a procit, de kellett biost frissíteni (Asus EzFlash) hogy a quadot bevegye, de most hogy az új itthoni gépem össze állt így a régit össze raktam és látszólag jó volt. Lehet hogy a bios frissítés tett be neki? Pedig a quaddal jó volt és nem egyszer volt, hogy 3-5 napig ment ...

Ebben az esetben érdekes ez a BIOS vonal is. Szerintem érdemes utánanézni, lehet, hogy egy újbóli frissítés megoldja a problémát.

Másik ötlet: ha nincs cserealkatrészed, akkor be lehetne vinni egy szervizbe, ott letesztelik, jó esetben megmondják, mi a baja. Szerintem még alkudozhatsz is, mennyiért. (Szervizes koromban nem volt pofánk ilyenekért 5k-nál többet elkérni. Olcsóbb, mint alkatrészeket venni...)