Περίεργο πρόβλημα με τεμπέλικο μηχάνημα σε Debian και Ubuntu

[Errik]

Καλησπέρα, αντιμετωπίζω ένα σημαντικό πρόβλημα, και επειδή δεν έχω καταφέρει να βγάλω άκρη μόνος μου, ζητάω την πολύτιμη βοήθειά σας. Πριν περίπου ένα χρόνο έστησα ένα μηχάνημα, ειδικά για linux server, που θα είχε χρήση για οτιδήποτε χρειαστώ, file server, web server καθώς και virtual machine server, για ατομική χρήση πάντα. Επέλεξα αρκετά ισχυρά και ποιοτικά υποσυστήματα, για να είμαι καλυμμένος αρκετά χρόνια:

AMD 945 3GHz

Mobo Gigabyte Gigabyte GA-MA785GMT-UD2H

Γραφικά onboard

Μνήμη 4x1GB DDR3 καλής μάρκας

Τροφοδοτικό 400watt seasonic

Σκληρούς γενικά βάζω WD Black

 

Γενικά το σύστημα έχει πολύ ήπια χρήση, για fileserver με samba, ωστόσο κατα καιρούς ανάλογα με τα project που τρέχω μπορεί να ανεβάσω και κανα virtual machine, για αυτό και πήρα τα 4GB μνήμη (χρησιμοποιούνται ~ 340ΜΒ μόνιμα) και τον 4πύρηνο (το 99% του χρόνου είναι στα 800ΜHz και στο 0%)

Στο σύστημα έβαλα debian 5.0 stable AMDx64, χωρίς να βάλω κανέναν κλειστό driver (έτσι και αλλιώς μόνο κονσόλα τρέχω, αντε και κανα xfce για το virtualbox...). Κατά καιρούς είχα παρατηρήσει κάτι περίεργα κολλήματα και restarts, αλλά ήταν αρκετά σπάνια και δεν έδινα σημασία. Συνέβαιναν κυρίως όταν το έβαζα να κάνει κάτι κάτι λίγο πιο βαρύ από το συνηθισμένο samba share, όπως συμπίεση ενός αρχείου αρκετών GB για backup, ή σήκωμα virtual machines.

Πρόσφατα, χρειαζόταν να κάνω ένα project και αυτά τα κολλήματα πραγματικά μου έσπασαν τα νεύρα και με εμπόδιζαν να κάνω την δουλειά μου. Εψαξα και βρήκα τρόπο να κάνω reproduce συστηματικά το σφάλμα. Συγκεκριμένα εμφανίζεται όταν κάνει μεγάλη χρήση της μνήμης. Σίγουρα μου κολλάει όταν:

>Τρέχω pi 10000000 (υπολογίζει τα ψηφία του π και χρησιμοποιείται σαν benchmark)

>memtester 4096 (προσπαθεί σε user mode να κάνει allocate όσο περισσότερη μνήμη μπορεί και μετά την τεστάρει, αλλά μεσα από το λειτουργικό, είναι διαφορετικό από το memtest86+ που τρέχει πριν το λειτουργικό)

Αυτό που συμβαίνει είναι low level κόλλημα που απαιτεί hard reset από το κουμπί. Κολλάνε τα πάντα, εμφανίζονται artifacts στην οθόνη και δεν αναβοσβήνει ούτε το φωτάκι num lock στο πληκτρολόγιο. Καμιά φορά, κάνει και restart μόνο του.

 

Σε windows 7 x64 που έτρεχα λίγο καιρό πριν το στήσω με debian δεν είχα παρατηρήσει πρόβλημα ή περίεργα κολλήματα.

 

Τι έχω δοκιμάσει (και εδώ αρχίζει το σπάσιμο νεύρων):

> Το προφανές memtest+ το περνάει κανονικά όσες ώρες και να το αφήσω, άρα δεν είναι πρόβλημα μνήμης (καλύτερα να μην το περνούσε, να αλλάξω μνήμη να τελειώνω, αλλά όχι, όλα τα περίεργα, σε μένα τυχαίνουν )

 

>Debian 6.0 stable απο live cd, πάλι όταν βάζω τα ίδια προγράμματα έχει την ίδια συμπεριφορά, άρα δεν λύνεται με απλό upgrade

 

>Ubuntu live cd 8.10, 9.10, 10.10 , με τα πακέτα του debian πάλι συμπεριφέρεται με τον ίδιο τρόπο (το ubuntu δεν τα έχει στο δικό του repository)

 

>Απενεργοποίηση οτιδήποτε intergraded συσκευών απενεργοποιούνται στο bios μήπως υπάρχει κανα conflict.

 

>Απενεργοποίηση του usb legacy support (το διάβασα και αυτό οτι μπορεί να χτυπάει)

 

>Ενημέρωση του bios στο καινούριο

 

>Απενεργοποίηση του HPET στο bios

 

Γενικά δεν δουλεύει τίποτα, και έχω απελπιστεί. Εχω δώσει αρκετά € για να μπορεί να σηκώσει βαρύτερες εφαρμογές, και απλά όταν φορτώνεται τα παρατάει και μου σπάει τα νεύρα. Έχω σκεφτεί να το γυρίσω σε windows 2008 server R2, αλλά είχα βολευτεί με το debian, το έχω σετάρει, και γενικά προτιμώ linux για σοβαρές server εφαρμογές. Επίσης δεν έχω εμπειρία με το software raid 5 των windows, φοβάμαι οτι θα είναι εντελώς γτπ σε σχέση με το δοκιμασμένο χρόνια mdadm.

 

 

 

Συμπηρωματικές πληροφορίες:

Σε debian 5.0 μου βγάζει ένα μήνυμα σχετικά με το iommu

Απο αυτά που διάβασα μπορώ να το αγνοήσω ελεύθερα, δεν με νοιάζουν τα 64MB...

 

Σε debian 6.0 μου βγάζει ένα μήνυμα σχετικά με conflict μνήμης που ακούγεται αρκετά σημαντικό

Ωστόσο από όσο το έψαξα, απλά δεν φορτώνεις ένα kernel module (κάτι που κάνει αυτόματα) και γενικά δεν έχεις πρόβλημα.

 

Οποιαδήποτε ιδέα, τρελή η μη ευπρόσδεκτη. Οτιδήποτε πέρα από το "βάλε windows" !!! (η ειρωνία σε όλο της το μεγαλείο...) Δεν με νοιάζει το σύστημα να τρέχει λίγο πιο αργά, αρκεί να είναι απόλυτα σταθερό. Να μην φοβάμαι πριν τρέξω κάτι αν θα κολλήσει ή όχι.

[NullScan]

Άνοιξε μιά κονσόλα (ή tty, ότι σε βολεύει) και δώσε πρώτα αυτό:

dmesg -n8

αμέσως μετά κάνε

tail -f /var/log/kern.log

Επέστρεψε στην άλλη κονσόλα και ξεκίνα τον υπολογισμό του π τον memtester και αφού ξεκινήσει γύρνα στην κονσόλα που παρακολουθεί το log file.

Όταν κολήσει τράβα μιά φωτογραφία και ανέβασέ την. Το πιθανότερο είναι κάποιο Oops αλλά ας το επιβεβαιώσουμε πρώτα.

[Errik]

Δυστυχώς τίποτα. Κάνει restart ή κολλάει χωρίς να προλάβει να γράψει τίποτα. Πώς γίνεται να το κάνω να μπουτάρει με το μέγιστο βαθμό logging για να δω μετά μήπως γράψει τίποτα που θα μου δώσει κάποιο στοιχείο;

 

(Edit, δοκιμάζω το ίδιο σε Debian 6.0 live cd, ένα λεπτό...)

[NullScan]

Επειδή τα Live CD μπορεί να είναι έτσι ρυθμισμένα ώστε να κάνουν αυτόματα reboot σε περίπτωση oops, καλύτερα να γίνει όλη αυτή η διαδικασία με την κανονική σου εγκατάσταση.

[Errik]

To debian 5.0 είναι κανονική εγκατάσταση και έκανε restart χωρίς να γράψει τίποτα. Τo debian 6.0 από live cd είχε την ίδια συμπεριφορά. Τι να κάνω; Πως γίνεται να μπουτάρω με το μέγιστο logging level, μήπως δώ τίποτα περίεργο στο allocation των περιοχών της μνήμης;

[NullScan]

Πέρνα σαν kernel parameter στον boot loader σου το option debug.

[Errik]

Οκ. Επι την ευκαιρία, να βάλω και ένα noacpi; δεν το έχω δοκιμάσει...

[NullScan]

Θα χάσεις όλα τα power interrupts που είναι ικανό να καταλάβει το σύστημά σου. Ξεκίνα με το debug να γίνει η διαδικασία να δούμε τί λέει ο kernel την ώρα που χάνεις το σύστημα και βλέπουμε.

[Errik]

Δυστυχώς, δεν γράφει τίποτα. Το έγραψα σε κάμερα, για να γίνει κατανοητό το τι γίνεται (είμαι σε τερματικό και το Pi τρέχει στο γραφικό περιβάλλον) 1,7ΜΒ: http://hotfile.com/dl/107178230/961148a/IMG_0301.mp4.html

[NullScan]

Δέν κατάλαβα τί έγινε στο video σου. Μετά από αυτό το σύστημα παγώνει χωρίς κανένα error?

Κάνε restart και μέσα στο /var/log/ θα βρείς μιά σειρά από αρχεία messages(.1.gz, .2.gz κτλ) καθώς και kern.log. Άνοιξέτα και βρές ποιό είναι το αρχείο με τα logs από το session στο οποίο το σύστημα πάγωσε. Ανέβασέ τα κάπου να ρίξουμε μιά ματια.

[Errik]

Στο βίντεο δείχνω τι έγινε στο κόλλημα. Σε άλλη κονσόλα τρέχω το pi 10000000 και σε αυτήν που βιντεοσκοπώ έχω κάνει tail -f /var/log/kern.log , περιμένοντας να κολλήσει και να γράψει κάτι. Στο 6ο δευτερόλεπτο κολλάει, εμφανίζονται τα artifacts, και όπως φαίνεται δεν γράφει τίποτα.

 

Μια εξέλιξη είχα μόνο. Κάποιες φορές όταν αλλάζω κάποιο hardware, στο επόμενο boot, μου αναγνωρίζει στο debian τον ένα πυρήνα. Τότε δεν κολλάει τίποτα, όλα δουλεύουν ρολόι. Μου έτυχε και χθες αυτό, γιατί δοκίμασα (και πάλι χωρίς αποτέλεσμα) να βάλω μια εξωτερική pci κάρτα γραφικών, και να απενεργοποιήσω την onboard, αποδεσμεύοντας και τα 128MB κεντρικής μνήμης που τραβάει. Στο πρώτο boot, μου αναγνώρισε ένα πυρήνα και όλα δούλεψαν ok. Στο δεύτερο boot αναγνωρίστηκαν και οι 4 πυρήνες και η συμπεριφορά ήταν όπως πριν. Τα έχω όλα στο log. Το session που όλα δουλεύουν οκ, τελειώνει με

Feb 24 21:31:19 teras shutdown[3605]: shutting down for system halt

 

Όλα τα sessions που κολλάνε, το logging τελειώνε με το μήνυμα

 

NET: Registered protocol family 5

 

το οποίο εμφανίζεται αρκετά πριν το κόλλημα και δεν έχει σχέση. Δεν έχω δηλαδή καμία debugging πληροφορία λίγο πριν ή λίγο μετά το κόλλημα.

 

Edit: επισυνάπτω και τα logs του live cd debian 6.0, φυσικά πριν κολλήσει, μήπως βγάλει κανείς καμια άκρη με τα μηνύματα που πετάει στην αρχή με το allocate της μνήμης και το ACPI... log live cd debian 6.0.zip

logs.zip

[NullScan]

Λοιπόν, στο log από το κανονικό σου σύστημα φαίνονται κάποια stack traces από processes που crash-αραν. apache, postgress, syslog κτλ και όλα τα traces έχουν να κάνουν με τον mm (memory manager).

>Out of memory: kill process 2585 (postgres) score 71860 or a child
Feb 24 21:30:17 teras kernel: [  286.359570] Killed process 3582 (postgres)
Feb 24 21:30:17 teras kernel: [  286.890500] rsyslogd invoked oom-killer: gfp_mask=0x1201d2, order=0, oomkilladj=0
Feb 24 21:30:17 teras kernel: [  286.890508] Pid: 2485, comm: rsyslogd Tainted: P          2.6.26-2-amd64 #1
Feb 24 21:30:17 teras kernel: [  286.890510] 
Feb 24 21:30:17 teras kernel: [  286.890511] Call Trace:
Feb 24 21:30:17 teras kernel: [  286.890541]  [<ffffffff80273810>] oom_kill_process+0x57/0x1dc
Feb 24 21:30:17 teras kernel: [  286.890547]  [<ffffffff8023b43d>] __capable+0x9/0x1c
Feb 24 21:30:17 teras kernel: [  286.890549]  [<ffffffff80273b3b>] badness+0x188/0x1c7
Feb 24 21:30:17 teras kernel: [  286.890551]  [<ffffffff80273d6f>] out_of_memory+0x1f5/0x28e
Feb 24 21:30:17 teras kernel: [  286.890556]  [<ffffffff80276ac0>] __alloc_pages_internal+0x31d/0x3bf
Feb 24 21:30:17 teras kernel: [  286.890562]  [<ffffffff80278776>] __do_page_cache_readahead+0x79/0x183
Feb 24 21:30:17 teras kernel: [  286.890566]  [<ffffffff80273025>] filemap_fault+0x15d/0x33c
Feb 24 21:30:17 teras kernel: [  286.890570]  [<ffffffff8027e5a4>] __do_fault+0x50/0x3e6
Feb 24 21:30:17 teras kernel: [  286.890578]  [<ffffffff8031ddc6>] rb_erase+0x1c8/0x2aa
Feb 24 21:30:17 teras kernel: [  286.890582]  [<ffffffff80281907>] handle_mm_fault+0x3f4/0x867
Feb 24 21:30:17 teras kernel: [  286.890584]  [<ffffffff80235788>] do_syslog+0x180/0x38b
Feb 24 21:30:17 teras kernel: [  286.890588]  [<ffffffff80246111>] autoremove_wake_function+0x0/0x2e
Feb 24 21:30:17 teras kernel: [  286.890594]  [<ffffffff80221fbc>] do_page_fault+0x5d8/0x9c8
Feb 24 21:30:17 teras kernel: [  286.890600]  [<ffffffff8029b778>] vfs_read+0x11e/0x152
Feb 24 21:30:17 teras kernel: [  286.890608]  [<ffffffff8042a689>] error_exit+0x0/0x60

Το εντυπωσιακό είναι οτι καλείται ο oom-killer (OutOfMemory-killer) τη στιγμή που το σύστημα έχει αναγνωρίσει:

>Memory: 4052420k/4718592k available (2228k kernel code, 137952k reserved, 1085k data, 392k init)

4G δηλαδή... Ανάλογα stack traces είναι και στα υπόλοιπα που σκάνε.

Το θέμα μου βρωμάει hardware. Θα έλεγα να κάνεις τα εξής:

1. Βρές από τον κατασκευαστή της μνήμης σου το voltage στο οποίο πρέπει να δουλεύουν τα dimms και πήγαινε στο BIOS και βάλε την τιμή που θα βρείς αν είναι διαφορετική από αυτή που έχει ορίσει από μόνο του.

2. Επειδή ο kernel σου είναι λίγο παλιός για τέτοιο hardware (2.6.26) θα έλεγα να δοκιμάσεις κάποιον πιό καινούργιο είτε από το backports είτε (ακόμα καλύτερα) να κάνεις build μόνος σου τον καινούργιο από το www.kernel.org. Έτσι για να εξαλείψεις οποιαδήποτε περίπτωση bug στον kernel λόγω πολύ καινούργιας 64bit αρχιτεκτονικής. Ο Phenom II είναι ούτως ή άλλως πολύ καινούργιος. Ίσως να σου λυθεί και το πρόβλημα με την μή αναγνώριση των άλλων cores με πιό καινούργιο SMP.

3. Άν τίποτα από όλα αυτα δεν δουλέψει αρχίζεις και ψάχνεις για τα ρεύματα που σου δίνει το PSU σου οτι είναι σωστά.

4. Τελευταίο βήμα είναι να βρείς μιά άλλη M/B για να κάνεις testing.

Μήν βασίζεσαι και πάρα πολύ στο τί βλέπεις με το LiveCD (άν και ομολογώ οτι δέν έχω πολύ χρόνο τώρα για να κοιτάξω τα logs από το Live σύστημα που ανέβασες, λίγο αργότερα ίσως). Υπάρχει και η επιλογή του να κάνεις monitor το σύστημα με serial console ή net console το οποίο θα σου δίνει όλα τα logs του συστήματος μέσω σειριακής θύρας ή δικτύου αντίστοιχα το οποίο είναι και πιό αξιόπιστο σαν logging μηχανισμός από το να παίρνεις τα αρχεία μετά το crash στο επόμενο reboot.

Για να δουλέψει αυτό πρέπει να φορτώσεις 2 kernel modules με παραμέτρους για τις MAC addresses του συστήματος που θέλεις να παρακολουθήσεις αλλά καί του συστήματος με το οποίο θα συνδεθείς (netconsole λύση). Και πάλι λόγω έλλειψης χρόνου για να το αναπτύξω, θα σε παραπέμψω εδώ για λεπτομέρειες (documentation από το source του kernel) και προτείνω άν έχεις χρόνο/όρεξη να το κάνεις και να μας πείς τα αποτελέσματα.

Καλό κουράγιο!

[twiner]

όταν είχες windows 7, είχες εκτελέσει ποτέ τις αντίστοιχες εντολές: pi κτλ;

[Errik]

Το log που παραθέτεις, είναι όταν είχα βάλει μια παλιά PCI κάρτα γραφικών, που δεν μου είχε αναγνωρίσει τους 4 πυρήνες αλλά μόνο τον ένα, και μου δούλεψαν τα πάντα!! Στο επόμενο boot μου αναγνώρισε και τους άλλους πυρήνες και ξαναάρχισαν τα κολλήματα. Γενικά μου αναγνωρίζει τους 4 πυρήνες. Κάποια άκρη αρχίζει να βγαίνει και στο thread στο adslgr, ρίξε αν μπορεις καμιά ματιά για εξτρα ιδέα... Προς το παρόν, μάλλον θα κάνω καθαρή εγκατάσταση debian 6.0 σε άλλο σκληρό, για δοκιμές...

 

http://www.adslgr.com/forum/showthread.php?t=481379

 

Ευχαριστώ πολύ για τον χρόνο σας και τις πολύτιμες συμβουλές!!

 

@twiner δεν υπάρχουν αυτά τα προγραμματάκια σε windows 7, αλλά γενικά έτρεξα βαριές εφαρμογές και δεν είχε πρόβλημα...

[NullScan]

Η PCI κάρτα γραφικών δέν πρέπει να έχει κανονικά επίδραση στο πόσους cores θα σου αναγνωρίσει το σύστημα...

Δοκίμασε όλα αυτά που σου είπα και κυρίως κάνε ένα upgrade στον kernel σου.