[Ubuntu] 9.04 server 64-bit hangt bij gebruik samba

[Oguz286]

Hallo iedereen,

ik heb al een tijdje twee problemen met mijn server waarop een volledig geupdate Ubuntu server 9.04 64-bit op draait. Ik heb een paar dingen geprobeerd en heb naar wat oplossingen gezocht en gevonden die ik nog niet allemaal heb uitgeprobeerd. Toch zou ik graag wat advies van jullie willen hebben want 2 weten meer dan 1 (en heel GoT zelfs meer) Allereerst de specs.

Wat zijn de specs

• AMD Athlon X2 4850e
• Abit A-S78H, AMD 780G chipset
• Seagate Momentus 5400.4 ST9120817AS, 120GB (bootschijf)
• 3x Western Digital Caviar Green WD10EADS, 1TB (RAID5-array)
• 2GB (2x 1GB) DDR2 PC2-5300 Kingston Valueram
• Seasonic S12II-330, 330 Watt

Voor degenen die een link willen: alstu.

Wat zijn de problemen

1. Wanneer ik mijn samba shares access (en eventueel iets kopieer van/naar de server) dan loopt mijn server op random momenten compleet vast. Dit kan meteen zijn, maar ook na een paar uur later. De server is niet meer te bereiken via SSH, het systeem reageert niet op het toetsenbord (ook niet op SysRq-commando's), het netwerkkaart lampje blijft knipperen (als ik iets kopieerde) en als ik de onboard grafische kaart aanzet dan knippert de cursor maar verder gebeurt er helemaal niets.
   Ik heb top gedraaid en voordat de server weer vastliep had de samba daemon ~65% cpu tijd nodig.
2. Mijn RAID5-array begint soms spontaan te rebuilden zonder enige aanleiding (voor mij althans).

Wat heb ik allemaal geprobeerd

1. HARDWAREMATIG
Omdat ik een zuinige server wilde heb ik uiteraard de onboard grafische kaart uitgezet, maar omdat ik dan geen visuele informatie meer kreeg heb ik het tijdelijk aangezet. Het aparte is dat het daarna mijn server niet meer vastliep Het eerste wat bij me opkwam is dat er een probleem was met het geheugen, omdat de onboard grafische kaart geheugen afsnoept van het interne geheugen. Omdat ik geen X gebruik wordt van het 128MB grafisch geheugen maar een klein deel gebruikt. Ik vermoedde dus dat er misschien een fout met het geheugen in dat stukje was.

Dat vermoeden werd deels bevestigd toen ik een losse grafische kaart in de server drukte en de onboard grafische kaart uitschakelde. Bij samba gebruik liep de server weer helemaal vast waardoor ik steeds meer het geheugen begon te vermoeden. Ook dacht ik dat de spontane rebuilds van mijn RAID5-array hiermee te maken had.

Ik heb vanochtend memtest86+ v4.00 gedraaid op de server. Allereerst liep memtest meteen vast met een blauw scherm en alleen de tekst 'memtest86+ v4.00'. Ik heb daarna het eerste geheugen latje losgehaald waarna ik 1GB ram had in slot 2. Nu werkte memtest prima en 6 uur later had ik nog steeds geen enkel probleem. Ik heb daarna datzelfde latje nu in slot 1 geplaatst om een kapot slot uit te sluiten en ook toen trad er geen enkel probleem op. Wanneer ik de reepjes verwisselde (slot maakte niet uit) liep memtest weer direct vast waardoor ik nu bijna zeker weet dat dat reepje kapot is. Ik heb verder niks veranderd in het bios wat betreft voltages en snelheden dus alles loopt op default instellingen.

Helaas liep de server weer compleet vast toen ik net met de goede reep geheugen de server opstartte en de sambashares gebruikte. Op dit moment draait hij prima maar het kan dus zijn dat als ik mijn shares gebruik dat hij dan de hele tijd goed werkt en ineens kan vastlopen.

WAT GA IK PROBEREN?
Omdat het een kit van 2 reepjes betreft ga ik RMA aanvragen voor beide gezien ik nog garantie heb. Ondanks dat memtest bij de ene reep geen enkel foutje heeft gevonden kan ik zo uitsluiten dat het aan het geheugen ligt. Verder ga ik een reepje uit mijn pc testen in de server om geheugenproblemen zoveel mogelijk uit te sluiten.

2. SOFTWAREMATIG
Ik heb verscheidene logs in /var/log/ doorgenomen (messages, syslog, kern.log) maar kon er geen enkele melding van een fout of iets dergelijks vinden. Het systeem logt alles totdat het vastloopt en wanneer ik opnieuw start wordt weer van alles gelogd maar er komt niks in te staan over een fout of iets wat aanduidt op een fout.

Ik heb op google gezocht naar vastlopers van ubuntu 9.04 en de kernels die ik heb gedraaid en nu draai (2.6.28-16-server), maar heb niks kunnen vinden wat leek op mijn probleem. Ook het zoeken naar vastlopers van het systeem bij gebruik samba leverde niet veel op. Er werd wel gehint naar problemen met acpi en apic, maar het werkte allemaal prima wanneer de onboard grafische kaart aanstond en de server belast werd met samba, torrents enz.

Verder heb ik niks vreemds draaien op mijn server, maar gewoon de standaard services zoals samba en apache.

De RAID5-array is trouwens software RAID m.b.v. mdadm.

WAT GA IK PROBEREN?
Hoewel ik liever niet opnieuw Ubuntu wil installeren ga ik dat als een van de laatste oplossingen proberen. Dan probeer ik waarschijnlijk 8.04 LTS of update ik misschien naar 9.10, dat moet ik nog even uitzoeken. Verder weet ik niet wat ik allemaal nog kan doen vandaar dat ik dit in NOS plaats en niet in PMG of OH, gezien ik hardwarematig al wat dingen heb geprobeerd en ook weet wat ik nog kan doen.

Additionele informatie

Relevante stukken uit smb.conf:

[global]
	log file = /var/log/samba/log.%m
	hide dot file = yes
	passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
	obey pam restrictions = yes
	socket options = SO_KEEPALIVE TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=40960 SO_RCVBUF=40960
	map to guest = bad user
	encrypt passwords = true
	passwd program = /usr/bin/passwd %u
	passdb backend = tdbsam
	dns proxy = no
	server string = %h server (Samba, Ubuntu)
	unix password sync = yes
	workgroup = WORKGROUP
	security = user
	syslog = 0
	usershare allow guests = no
	panic action = /usr/share/samba/panic-action %d
	max log size = 1000
	pam password change = yes

[oguz286]
	path = /mnt/raid/oguz286
	revalidate = yes
	readonly = no
	comment = Oguz286 Network Storage
	valid users = oguz286
	create mode = 750
	guest = no
	directory mode = 750

[Mustafa]
	valid users = oguz286,mustafa
	path = /mnt/raid/mustafa

Wie kan mij helpen en mij in de goede richting sturen?

[Nvidiot]

Ook last van gehad op mijn server, bleek dat de koeling van de CPU niet goed was. Bij de wekelijkse array-check werd de cpu zwaarder belast en te heet -> crash. Kijk dus even hoe heet ie wordt als je aan het rekenen is. Dit zou je evt met 'sensors' kunnen doen vanuit Ubuntu zelf.

[zordaz]

Volgens mij kun je jezelf de tijd en de moeite van een herinstallatie / upgrade van Ubuntu besparen, dit lijkt me vrijwel zeker een hardware probleem met het geheugen of het moederbord.

[gertvdijk]

Hardware errors kan je vaak ook terugzien in Machine Check Error logs (pakket mcelog installeren).

Ook kan ik mij voorstellen dat de AMD 780G Chipset liever een wat nieuwere kernel heeft, dus probeer eens een Karmic kernel o.i.d.
Wat me overigens niet duidelijk wordt is of je software RAID of de fakeraid van het mobo gebruikt.

[Oguz286]

Nvidiot schreef op donderdag 03 december 2009 @ 22:22:
Ook last van gehad op mijn server, bleek dat de koeling van de CPU niet goed was. Bij de wekelijkse array-check werd de cpu zwaarder belast en te heet -> crash. Kijk dus even hoe heet ie wordt als je aan het rekenen is. Dit zou je evt met 'sensors' kunnen doen vanuit Ubuntu zelf.

Mijn server heeft meer dan 700GB data gekopieerd zonder enig probleem en heeft meerdere malen de array moeten rebuilden zonder dat de cpu 'heet' werd (met de hand gevoeld). Hij is met sensors ook nooit warmer dan 40 graden. Dus ik denk niet dat het daaraan ligt, maar ik zal de volgende keer even goed opletten

zordaz schreef op donderdag 03 december 2009 @ 22:48:
Volgens mij kun je jezelf de tijd en de moeite van een herinstallatie / upgrade van Ubuntu besparen, dit lijkt me vrijwel zeker een hardware probleem met het geheugen of het moederbord.

Dat zou natuurlijk heel goed kunnen, maar dan zou hij met de onboard grafische kaart ook niet moeten werken nu de 'kapotte' RAM module eruit is denk ik zo. Maar om er zeker van te zijn probeer ik zo een latje van mijn pc in de server.

gertvdijk schreef op donderdag 03 december 2009 @ 22:55:
Hardware errors kan je vaak ook terugzien in Machine Check Error logs (pakket mcelog installeren).

Ook kan ik mij voorstellen dat de AMD 780G Chipset liever een wat nieuwere kernel heeft, dus probeer eens een Karmic kernel o.i.d.
Wat me overigens niet duidelijk wordt is of je software RAID of de fakeraid van het mobo gebruikt.

Ik ga even mcelog installeren, lijkt mij inderdaad een handik pakket. Ik gebruik software RAID (mdadm). Zal het even in de TS zetten. Ik heb de upgrade naar 9.10 gestart

[gertvdijk]

Oguz286 schreef op donderdag 03 december 2009 @ 23:06:
Ik ga even mcelog installeren, lijkt mij inderdaad een handik pakket. Ik gebruik software RAID (mdadm). Zal het even in de TS zetten. Ik heb de upgrade naar 9.10 gestart

Oké mooi.

Wat ik me ook nog kan bedenken is dat je BIOS de SPD timings en voltages verkeerd interpreteert of dat die verkeerd op de modules staan. Dit gezien je verhaal over je memtests. Ik heb een paar jaar geleden eens een combo van geheugen, mobo en proc gehad die onbegrijpelijk de verkeerde (te lage) voltages default had in het BIOS. Ik moest daarvoor eerst geheugen pakken dat wél werkte met default instellingen, dan de geheugenvoltages handmatig verhogen en vervolgens het oorspronkelijke geheugen plaatsen, omdat de hele PC niet eens wilde POSTen zonder dat verhoogde voltage met het oorspronkelijke geheugen. Nu is dat later gefixt in een BIOS update, maar inmiddels heb ik al ander geheugen in die bak die wel altijd werkte.
Dus: BIOS up to date? Voltages van DIMMs gecheckt met setting in BIOS?

[Oguz286]

BIOS is up to date en de voltages kloppen ook (1.8V staat op de modules, in de BIOS en in de datasheet aangegeven). De enige timings die ik kan vinden is dat het CL5 is en dat gaf hij ook in de BIOS aan, dus dat lijkt mij ook niet het probleem. Maar er zijn natuurlijk vaker problemen voorgekomen waarbij ik dacht dus ik zal dat voor de zekerheid nogmaals checken.

De update is gelukt btw, hij is nu bezig met het resyncen van mijn array. Het ging eerst met 1MB/s en dat duurt met 3 1TB schijven nogal lang Ik wacht eerst het resyncen af en dan ga ik de BIOS in.

EDIT:

Trouwens ik heb gekeken naar mcelog en heb de manpage gelezen maar wijzer ben ik niet geworden. Er staat in dat je het het beste als een crobjob kan runnen. Ik dacht juist dat het een daemon was, omdat het systeem constant gemonitord moet worden zou ik denken. Als nu m'n server zou vastlopen, zou mcelog het dan loggen naar /var/log/mcelog ?

[ Voor 23% gewijzigd door Oguz286 op 04-12-2009 00:35 ]

[gertvdijk]

Oguz286 schreef op vrijdag 04 december 2009 @ 00:32:
Trouwens ik heb gekeken naar mcelog en heb de manpage gelezen maar wijzer ben ik niet geworden. Er staat in dat je het het beste als een crobjob kan runnen. Ik dacht juist dat het een daemon was, omdat het systeem constant gemonitord moet worden zou ik denken. Als nu m'n server zou vastlopen, zou mcelog het dan loggen naar /var/log/mcelog ?

Nee, maar dat is met geen enkele log op te lossen! In een goede hang gaat er niets meer naar de schijven en kan alleen wat op het scherm getoond worden vaak. Je krijgt dan een kernel panic op je scherm met (afhankelijk van je config) debug info erbij.
Het enige wat mcelog doet is zoiets als SMART bij harde schijven. Soms kan je in je mcelog zien dat er bitjes omvallen of dat er relatief veel ECC fouten optreden (had ik laatst bij een server), etc.

[Oguz286]

En zojuist is m'n server weer gaan hangen na een hele nacht goed gewerkt te hebben Ik keek een film die erop stond en toen ik wat verder skipte reageerde het nergens meer op.

Ik ga eerst nogmaals de BIOS in, daarna probeer ik een latje van m'n pc, daarna probeer ik wat in de logs te vinden en daarna weet ik het ook niet meer

EDIT:

Ik heb er nu een latje van m'n pc erin gedrukt. Daarna wat spullen gekopieerd (rond de 4GB) en dat ging goed. Meteen daarna wilde ik nog 2GB kopieren en hij liep weer vast. Tijdens het kopieren van die 4GB zag ik in top dat 9MB na al het RAM werd gebruikt. Toen ik de 2GB kopieerde was het ongeveer 700MB vol en toen liep het vast. Ik krijg nu het vermoeden dat het niet aan het geheugen ligt. Verder kan ik hardwarematig weinig proberen, dus ik hoop dat de oplossing softwarematig is.

[ Voor 42% gewijzigd door Oguz286 op 04-12-2009 18:29 ]

[Oguz286]

Hierbij een update:

Ik heb nog steeds hetzelfde probleem en ik vroeg me af of het met mijn swap te maken zou kunnen hebben. Ik heb namelijk 1GB swapspace gebruikt omdat ik normaal gesproken 2GB RAM heb en ik niks bijzonders doe op mijn server (samba + apache).

Er is iets wat ik nog niet heb uitgelegd lees ik net. De sambashares staat op mijn RAID5 array. Ik dacht daarom dat het misschien niet met samba maar met mijn array te maken zou kunnen hebben. Maar ik heb net wel een paar GB gekopieerd via de commandline naar een usb stick en alles werkte prima. Daarom krijg ik steeds meer het gevoel dat het aan samba ligt.

Is er verder iemand die een idee heeft?

[gertvdijk]

Installeer eens atop (die logt elke paar minuten een gehele proceslijst, geheugengebruik, diskgebruik, netwerkverkeer en die kan je op elk gewenst moment weer afspelen en elke snapshot rustig inspecteren).
Als het probleem heel plots ontstaat kan je er niets mee ondervangen, maar een memory leak in samba kan je ermee wel vrij snel opmerken. Al stroken jouw symptomen niet geheel met dat scenario, want bij memory leaks gaat de OOM killer in werking en vriest niet je hele systeem.

[Oguz286]

Ik heb atop net geinstalleerd en gedraaid. Toen ik een filmpje kopieerde liep de server meteen weer vast (12MB gekopieerd) en volgens atop had ik op dat moment 530MB RAM en 0MB swap gebruikt.

ATOP - ubuntu-server      2009/12/09  00:40:51               10 seconds elapsed
PRC | sys   6.95s | user   0.03s | #proc    113 | #zombie    0 | #exit      0 |
CPU | sys     65% | user      0% | irq       5% | idle    129% | wait      0% |
cpu | sys     64% | user      0% | irq       5% | idle     30% | cpu001 w  0% |
cpu | sys      0% | user      0% | irq       0% | idle    100% | cpu000 w  0% |
CPL | avg1   1.01 | avg5    0.50 | avg15   0.19 | csw    15216 | intr   24705 |
MEM | tot    1.0G | free  529.7M | cache  86.5M | buff   11.5M | slab   27.8M |
SWP | tot    0.0M | free    0.0M |              | vmcom 337.7M | vmlim 499.6M |
DSK |         sdc | busy     38% | read    7647 | write      0 | avio    0 ms |
DSK |         sdd | busy     34% | read    7683 | write      0 | avio    0 ms |
DSK |         sdb | busy     31% | read    7686 | write      0 | avio    0 ms |
DSK |         sda | busy      0% | read       0 | write      3 | avio    0 ms |
NET | transport   | tcpi     109 | tcpo      91 | udpi       8 | udpo       1 |
NET | network     | ipi      117 | ipo       92 | ipfrw      0 | deliv    117 |
NET | eth0     0% | pcki     117 | pcko      92 | si   17 Kbps | so   11 Kbps |

  PID  SYSCPU  USRCPU  VGROW  RGROW  RDDSK  WRDSK  ST EXC S  CPU CMD     1/1
  398   4.75s   0.00s     0K     0K     0K     0K  --   - D  47% md0_resync
  397   2.11s   0.00s     0K     0K     0K     0K  --   - R  21% md0_raid5
 1955   0.03s   0.01s     0K    56K     4K     0K  --   - S   0% smbd
 1953   0.04s   0.00s     0K     0K     0K     0K  --   - R   0% atop
 1241   0.00s   0.02s     0K     0K     0K     0K  --   - S   0% mysqld
    7   0.02s   0.00s     0K     0K     0K     0K  --   - S   0% ksoftirqd/1
 1761   0.00s   0.00s     0K     0K     0K     4K  --   - S   0% miniserv.pl
 1638   0.00s   0.00s     0K     8K     0K     4K  --   - S   0% nmbd
  419   0.00s   0.00s     0K     0K     0K    28K  --   - S   0% kjournald

Hier is wel te zien dat md0_resync en md0_raid5 aardig wat cpu tijd verbruiken, maar dat was natuurlijk te verwachten met een gigabit netwerk. Ik ga nu even kijken wat dat replayen precies inhoudt en kan me dat wat wijzer maken.

Ik zal ook even voor de volledigheid nogmaals vermelden dat de netwerkkaart ledje constant knippert wanneer de server is vast gelopen. Ook blijft de HDD led constant aan.

Als test ga ik nog een share maken op mijn bootschijf en als alles prima werkt met die share, dan denk ik dat ik het meer moet zoeken in de richting van mijn array.

EDIT: ik ben weer eens 'snel'... mijn array zit zichzelf weer te rebuilden en ik heb geen idee waarom dat komt waarschijnlijk omdat ik m'n server the hard way moest uitzetten. Ik heb het vermoeden dat het niet hardwarematig is, maar dat het echt bij de software ligt. Daarom ga ik een nieuwe share maken en dat testen. Mocht dat ook helpen met het vinden van een oplossing, dan ga ik proberen windows erop te zetten en kijken of dat wel fatsoenlijk werkt. Mocht dat ook niet werken dan weet ik dat het aan de hardware ligt.

[ Voor 14% gewijzigd door Oguz286 op 09-12-2009 00:57 ]

[gertvdijk]

Oguz286 schreef op woensdag 09 december 2009 @ 00:45:
EDIT: ik ben weer eens 'snel'... mijn array zit zichzelf weer te rebuilden en ik heb geen idee waarom Ik heb het vermoeden dat het niet hardwarematig is, maar dat het echt bij de software ligt. Daarom ga ik een nieuwe share maken en dat testen. Mocht dat ook helpen met het vinden van een oplossing, dan ga ik proberen windows erop te zetten en kijken of dat wel fatsoenlijk werkt. Mocht dat ook niet werken dan weet ik dat het aan de hardware ligt.

Ik heb ook een vermoeden dat je array een beetje brakkig is. Zoek eens uit waarom hij aan het rebuilden is, laat dat eens voltooien: check status met

cat /proc/mdstat

en evt met een handige watch:

watch -n 1 cat /proc/mdstat

En belangrijker: wat zeggen je logs over je RAID array of andere hardware falen? (dmesg, syslog) Dat lijkt mij vanzelfsprekend dat je daar kijkt, maar ik heb je er nog niet over gehoord.

[ Voor 10% gewijzigd door gertvdijk op 09-12-2009 01:01 ]

[Oguz286]

gertvdijk schreef op woensdag 09 december 2009 @ 01:00:
[...]
Ik heb ook een vermoeden dat je array een beetje brakkig is. Zoek eens uit waarom hij aan het rebuilden is, laat dat eens voltooien: check status met

cat /proc/mdstat

en evt met een handige watch:

watch -n 1 cat /proc/mdstat

En belangrijker: wat zeggen je logs over je RAID array of andere hardware falen? (dmesg, syslog) Dat lijkt mij vanzelfsprekend dat je daar kijkt, maar ik heb je er nog niet over gehoord.

Ik heb net mijn post aangepast, maar ik denk dat het komt omdat ik tijdens het 'kopieren' de spanning heb uitgeschakeld omdat hij compleet was vastgelopen. Nu heb ik meerdere malen in dmesg en syslog gekeken, maar ik zie daar niks staan wat aanduidt op het falen van mijn array.

Ik heb even op pastebin de laatste 1000 regels uit syslog geplakt. Ik zie niks verkeerds staan, maar zo ontzettend ervaren met linux ben ik ook niet dus het kan heel goed dat ik er gewoon overheen kijk.

EDIT: ik doe verder ook niks met mijn array zolang hij aan het rebuilden is, want ik wil die data niet echt kwijt Verder heb ik geprobeerd een nieuwe share aan te maken en dat is gelukt. Het gekke is dat die prima werkt (even afkloppen), maar die staat NIET op de RAID5 array maar is een folder in mijn home directory. Dan zou het inderdaad aan mijn array kunnen liggen, maar waarom zou dan de hele server compleet vastlopen? Mijn OS staat er niet op en ik kan hooguit al m'n data verliezen, maar dan zou het nog niet vast moeten lopen zou ik denken.

EDIT2: Ik zeg wel dat het aan mijn array kan liggen, maar waarom kan ik gigabytes data kopieren via ssh naar een usb schijf, maar via samba niet? Dan begin ik aan iets anders te denken. Ik heb namelijk nooit WOL aan de praat gekregen terwijl ik echt alles heb gedaan om het aan de praat te krijgen. Nu kan dat natuurlijk komen door een verkeerde driver of iets dergelijks en ik vond het niet interessant genoeg om te vermelden. Maar het enige verschil tussen de kopieeropdracht geven via ssh en samba is dat samba gebruik maakt van mijn netwerkkaart en ssh niet (voor het kopieren). Maar ik draai een rsync script op mijn pc die een backup van mijn bestanden op de server plaatst en dat gaat altijd prima. Bovendien werken torrents ook prima, het is echt alleen met samba dat de server vastloopt.

Ik word een beetje moedeloos

[ Voor 40% gewijzigd door Oguz286 op 09-12-2009 01:37 ]

[gertvdijk]

Oguz286 schreef op woensdag 09 december 2009 @ 01:26:
Maar het enige verschil tussen de kopieeropdracht geven via ssh en samba is dat samba gebruik maakt van mijn netwerkkaart en ssh niet (voor het kopieren).

Kan je dat even uitleggen? Hoe doe jij SSH niet over het netwerk en Samba wel?

Ik heb even in je syslog gekeken en ik kom toch wel tot de conclusie dat je een ontzettend billig BIOS hebt: hij adverteert met ECC geheugen terwijl het dat niet is en er moeten diverse workarounds plaatsvinden voor jouw type mobo en chipset (waaronder USB freezes, SATA soft reset fail).
Kan je voor de zekerheid de volgende dingen even uitzoeken/nagaan?

• Of je BIOS up to date is
• of de SMART waarden van al je harddisks nog normaal en healthy zijn
• Wat er nou in de /var/log/mcelog staat (gezien je meldingen in syslog over het niet snappen van de MCE reporting van je CPU)
• En wat zijn je vendor/product id's van je netwerkkaart en SATA controller?
  

  lspci -nn

  
  Het zal niet de eerste netwerkkaart of SATA driver/module die op z'n gat gaat bij een hoge load. Googlen met vendor/product id's levert vaak specifiekere problemen/oplossingen op.

[Oguz286]

Nou kijk, wat ik heb gedaan is een usb harde schijf aansluiten op de server en via ssh wat data kopieren via de command line naar de usb schijf. Tuurlijk heb ik voor ssh een netwerkverbinding nodig, maar ik kopieer niet via het netwerk, maar direct van mijn RAID5-array naar de usb schijf. Vandaar dat ik geen netwerk gebruik tijdens het kopieren.

• Mijn BIOS is up to date (had ik volgens mij al aangegeven).
• De SMART waarden heb ik op pastebin gezet:
  /dev/sda (OS, laptopschijf)
  /dev/sdb, /dev/sdc. /dev/sdd (RAID5-array)
  Nu zie ik dat mijn OS schijf (waarop shares prima werken) een hele hoge waarde heeft voor 'Hardware ECC Recovered' namelijk: 223585234. Dat lijkt mij niet echt goed, maar ik weet niet precies wat voor impact het zou kunnen hebben op de stabiliteit. De reden dat ik een laptopschijf gebruik is omdat die wat langer meegaat dan een usb-stick (wat ik eerst wilde gebruiken).
  Bij de andere schijven zie ik niks raars staan.
• In /var/log/mcelog staat helemaal niks.
• 00:11.0 SATA controller [0106]: ATI Technologies Inc SB700/SB800 SATA Controller [AHCI mode] [1002:4391]
• 02:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller [11ab:4364] (rev 14)

Het moederbord heeft een AMD 780 chipset en ik heb bewust voor deze chipset gekozen omdat hij zuinig is. Ik heb namelijk een hele tijd het 'nieuwe zuinige server' topic gevolgd en veel mensen hebben ook voor deze chipset gekozen. Zoals het er nu uitziet lijkt het alsof mijn laptopschijf problemen kan veroorzaken.

EDIT: De seek error rate is ook heel hoog, maar het schijnt dat Seagate schijven altijd zo'n hoge waarde geven en dat niet betekent dat de schijf kapot gaat (bron).

EDIT2: Ik bedenk me net dat ik nog een laptopschijf heb liggen die altijd goed gewerkt heeft. Ik ga die er eens in bouwen en kijken of ik nog steeds deze problemen krijg. Verder heb ik gezocht naar informatie over de sata controller en het enige wat een klein beetje in de buurt kwam van mijn probleem was deze pagina. Maar dat is voor later.

[ Voor 14% gewijzigd door Oguz286 op 09-12-2009 13:28 ]

[gertvdijk]

Oguz286 schreef op woensdag 09 december 2009 @ 13:03:
EDIT2: Ik bedenk me net dat ik nog een laptopschijf heb liggen die altijd goed gewerkt heeft. Ik ga die er eens in bouwen en kijken of ik nog steeds deze problemen krijg. Verder heb ik gezocht naar informatie over de sata controller en het enige wat een klein beetje in de buurt kwam van mijn probleem was deze pagina. Maar dat is voor later.

Die bug gaat over OpenSolaris...
Deze bug komt beter in de buurt van jouw klachten: Ubuntu bug #292876 en komt geheel overeen met de symptomen van een Pentium III VIA chipset die ik een paar jaar geleden reproduceerbaar onderuit kon helpen met een te grote bandbreedte over de IDE kanalen met modernere harde schijven. Bij teveel heftig dataverkeer gaat die chip op z'n gat, lijkt het.

Je USB harddisk trekt nooit die bandbreedte vol en verklaart waarschijnlijk ook waarom het dan niet optreedt.

Sorry over je BIOS, dat had je natuurlijk al vermeld. En je SMART waarden zien er niet te slecht uit hoor. De UDMA checksum error is bij sommige schijven inderdaad op een exotische waarde. Kan me voorstellen dat dat een sign probleem is ofzo in het uitlezen.

[ Voor 15% gewijzigd door gertvdijk op 09-12-2009 13:56 ]

[Oguz286]

Ja ik had gezien dat het OpenSolaris betrof en die link die je gaf heb ik ook gezien.

Maar hoe kan het dan dat mijn share op de OS schijf wel gewoon prima werkt? Die is ook aangesloten op dezelfde controller als de andere schijven.

Ik probeer nu al een paar uur om de laatste ubuntu server te installeren via het netwerk maar uiteraard lukt dat niet Daarom wilde ik het liefst niet opnieuw installeren, maar ik moet toch dingen uitsluiten anders kom ik er nooit. Je had het over dat de kernel tijdens het booten wat meldingen geeft die eigelijk niet voor horen te komen. Misschien dat een clean install zal werken.

[gertvdijk]

Oguz286 schreef op woensdag 09 december 2009 @ 14:44:
Maar hoe kan het dan dat mijn share op de OS schijf wel gewoon prima werkt? Die is ook aangesloten op dezelfde controller als de andere schijven.

Omdat die OS schijf in z'n eentje véél minder bandbreedte trekt op de PCI(-E) bus waar die SATA controller aanhangt! Als je op RAID5 werkt met 3 schijven gaat alles dus 3x zo hard in bandbreedte (2x netto data + 1x parity).

Oguz286 schreef op woensdag 09 december 2009 @ 14:44:
Ik probeer nu al een paar uur om de laatste ubuntu server te installeren via het netwerk maar uiteraard lukt dat niet Daarom wilde ik het liefst niet opnieuw installeren, maar ik moet toch dingen uitsluiten anders kom ik er nooit. Je had het over dat de kernel tijdens het booten wat meldingen geeft die eigelijk niet voor horen te komen. Misschien dat een clean install zal werken.

Een clean install gaat je niet helpen. Eenzelfde Ubuntu installatie heeft gewoon dezelfde kernel en zal dus altijd diezelfde meldingen geven. Wat je nog kan doen is een nieuwere kernel proberen (2.6.32), waarvoor wel PPA's zijn of je pakt hem zelf van kernel.org.
Maar ik vrees het ergste: dat die onboard SATA controller het gewoon niet trekt. Misschien is het het overwegen waard om een aparte controller aan te schaffen (niet RAID, maar gewoon fatsoenlijke SATA chip).

[Oguz286]

gertvdijk schreef op woensdag 09 december 2009 @ 14:48:
Omdat die OS schijf in z'n eentje véél minder bandbreedte trekt op de PCI(-E) bus waar die SATA controller aanhangt! Als je op RAID5 werkt met 3 schijven gaat alles dus 3x zo hard in bandbreedte (2x netto data + 1x parity).

Maar natuurlijk, doh! Ik ben niet helemaal wakker

Een clean install gaat je niet helpen. Eenzelfde Ubuntu installatie heeft gewoon dezelfde kernel en zal dus altijd diezelfde meldingen geven. Wat je nog kan doen is een nieuwere kernel proberen (2.6.32), waarvoor wel PPA's zijn of je pakt hem zelf van kernel.org.
Maar ik vrees het ergste: dat die onboard SATA controller het gewoon niet trekt. Misschien is het het overwegen waard om een aparte controller aan te schaffen (niet RAID, maar gewoon fatsoenlijke SATA chip).

Ok maar waarom heeft er verder niemand last van? Er zijn genoeg mensen met dezelfde chipset die RAID5 draaien en die juist deze chipset aanraden omdat het zo goed werkt. Het kan heel goed zijn dat dat het probleem is, ik sluit het zeker niet uit want het verklaart ook waarom alles vastloopt, maar ik wil het zeker weten natuurlijk. Misschien heb toevallig een gaar exemplaar en kan ik hem RMA'en. Maar eerst wil ik zoveel mogelijk uitsluiten.

En ik bedenk met net nog iets: tijdens het rebuilden haal ik ook rond 80MB/s en dat is ongeveer net zo snel als wanneer ik iets via het netwerk kopieer. Het rebuilden gaat alleen altijd goed.

[ Voor 7% gewijzigd door Oguz286 op 09-12-2009 15:22 ]

[gertvdijk]

Oguz286 schreef op woensdag 09 december 2009 @ 15:16:
En ik bedenk met net nog iets: tijdens het rebuilden haal ik ook rond 80MB/s en dat is ongeveer net zo snel als wanneer ik iets via het netwerk kopieer. Het rebuilden gaat alleen altijd goed.

De rebuild speed kan je zelf instellen en wordt ook vermeld in je syslog bij het booten. Daarnaast is het rebuilden van je array in RAID5 voornamelijk lezen (zie ook je atop snapshot!) en als je iets kopieert naar het volume is het voornamelijk schrijven; iets dat in de controller fundamenteel anders kan zijn ingericht i.v.m. NCQ, caches e.d.
Misschien nog een idee om wat van die SATA2 features te tweaken met hdparm/sdparm? Heb er zelf geen ervaring mee, maar in theorie kan je er dit soort features mee uitschakelen.
Waarom je 'de enige' bent met dit probleem durf ik niet te zeggen. Er zijn mogelijk meer factoren die een rol spelen bij het optreden van het probleem.

[Oguz286]

Ik heb dus op mijn andere laptopschijf ubuntu-server 9.10 geinstalleerd en volledig geupdate. Daarna heb ik een share aangemaakt en toen ik net weer een filmpje keek liep alles vast. Het laatste wat in dmesg staat:

[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 2.6.31-16-server (buildd@yellow) (gcc version 4.4.1 (Ubuntu 4
.4.1-4ubuntu8) ) #52-Ubuntu SMP Thu Dec 3 23:03:41 UTC 2009 (Ubuntu 2.6.31-16.52-server)
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.31-16-server root=UUID=c459b661-
a098-4ed5-9f32-940d901993cd ro quiet splash
[    0.000000] KERNEL supported cpus:
[    0.000000]   Intel GenuineIntel
[    0.000000]   AMD AuthenticAMD
[    0.000000]   Centaur CentaurHauls
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 0000000000097800 (usable)
[    0.000000]  BIOS-e820: 0000000000097800 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 000000003ff81000 (usable)
[    0.000000]  BIOS-e820: 000000003ffe0000 - 000000003ffe3000 (ACPI NVS)
[    0.000000]  BIOS-e820: 000000003ffe3000 - 000000003fff0000 (ACPI data)
[    0.000000]  BIOS-e820: 000000003fff0000 - 0000000040000000 (reserved)
[    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
[    0.000000]  BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
[    0.000000] DMI 2.5 present.
[    0.000000] Phoenix BIOS detected: BIOS may corrupt low RAM, working around it.
[    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserv
ed)

Het is dus zeer, zeer waarschijnlijk de hardware. Nu moet ik er alleen nog achterkomen WAT er fout is. Zoals je zei zou het heel goed aan de sata controller kunnen liggen (brak exemplaar ga ik vanuit). Ik zal kijken naar hdparm, maar ik ga ook proberen om de HDD's in IDE mode te draaien i.p.v. AHCI.

Zoals ik zei, alles werkte prima als ik mijn interne grafische kaart aanzette. Dat zou dus te maken kunnen hebben met de meldingen in dmesg, omdat de grafische kaart zover ik weet de laagste regionen van het geheugen gebruikt en die kan nou net 'corrupt' zijn. Alleen omdat ik toch alleen in textmode draai, wordt dat stukje geheugen lang niet volledig gebruikt, waardoor er geen 'corruptie' onstaat.

Als er verder nog ideeen zijn, dan hoor ik ze graag

[gertvdijk]

Oguz286 schreef op woensdag 09 december 2009 @ 16:46:
Als er verder nog ideeen zijn, dan hoor ik ze graag

Ja, kijk eens naar je dmesg. Alles heeft timestamp 0 en je syslog maakt melding van een false clocksource. Nou weet ik technisch niet wat een clocksource op je mobo allemaal aanstuurt, maar ik weet wel dat een onbetrouwbare clocksource funest is bij paravirtualisatie (Xen) en je domU's willekeurig kan laten crashen.

Al met al denk ik dat het gewoon goedkope hardware is of een afgeranseld BIOS wat nog gauw ff op de markt moest worden gezet. Of misschien ben ik gewoon te verwend met fatsoenlijke hardware (lees: Dell servers, Thinkpad notebook) en ben ik daar teveel aan gewend geraakt.

Hier is nog iemand met vergelijkbare problemen als jij.

@hieronder: deze kaart zou mijn suggestie zijn.

[ Voor 24% gewijzigd door gertvdijk op 09-12-2009 17:03 ]

[_root]

Ik heb dit probleem ook een keer gehad, heeft me veel tijd gekost.
De oorzaak was bij mij een half rotte netwerkkaart die spontaan roet in het eten gooide.
Vaak bij belasting, (volgens mij de meeste problemen met samba) maar ook wel eens met een paar MB heen en weer zetten.

Zou je deze kaart eens kunnen vervangen, of als het een onboard is, een kaartje erbij zetten.

[ Voor 6% gewijzigd door _root op 09-12-2009 17:02 ]

[Oguz286]

Dank voor de suggesties. Ik zal een ander netwerkkaart proberen, want ik wil zeker zijn van wat de oorzaak is.

Trouwens, bij de installatie van 9.10 net kreeg ik een melding dat er een hot-pluggable network interface was gevonden, maar dat heb ik helemaal niet. Misschien dat mijn onboard kaart niet goed wordt herkend.

@gertvdijk: ik zie even het verband tussen mijn probleem en die link niet Bedoel je het stukje over AHCI en Seagate schijven? Ik ga inderdaad even AHCI uitschakelen zo en mijn OS schijf is een Seagate. Wie weet...

EDIT: Ik heb AHCI uitgeschakeld, op native IDE gezet en nogmaals getest. Ik kon nu wat langer films kijken en ik heb zelfs +- 5GB gekopieerd van en naar de server zonder problemen. Maar nu heb ik iets anders ontdekt.

Wanneer ik een film stream dan zie ik in top dat de belasting slechts een paar procent is (2-5%) en wanneer ik die bestanden kopieerde schoot het omhoog naar 50-60% (was te verwachten). Maar nadat ik klaar was met kopieren bleef de samba daemon rond de 50% cpu tijd gebruiken en voordat het vastliep was het 23%. Zoals gewoonlijk knippert nu de led van de netwerkkaart.

Waarom bleef de samba daemon zoveel cpu tijd verbruiken? De videospeler buffert natuurlijk en daarom zag ik even een cpu gebruik van een paar procent, maar wanneer het bufferen klaar was, zakte het gebruik weer naar '0%'. Alleen bij het kopieren bleef het aanhouden. Wat kan dit betekenen?

EDIT2: Ik heb die Intel netwerkkaart besteld. Hopelijk lost dat het probleem op, maar ik zal ook naar andere oplossingen kijken, want ik wil dit gewoon werkend hebben.

[ Voor 49% gewijzigd door Oguz286 op 09-12-2009 19:46 ]

[Verwijderd]

Hoi, heb / had soortgelijke problemen op een ASUS M2A74-AM SE en ik verdenk de southbridge (SB700) waarin de SATA controller zit evt icm linux software raid. Draai 3 virtual machines op een raid 1 set bestaande uit 2 sata schijven. Performance was om te huilen, nu heb ik de virtual machine met de zwaarste load (iowait > 50%) verplaatst naar een PATA schijf en deze gaat nu als een speer. (iowait 0.12%). Dit is overigens met Ubuntu 9.10 64 bits en een intel NIC.

[ Voor 0% gewijzigd door Verwijderd op 11-12-2009 14:48 . Reden: bride != bridge ]

[Oguz286]

Verwijderd schreef op vrijdag 11 december 2009 @ 14:47:
Hoi, heb / had soortgelijke problemen op een ASUS M2A74-AM SE en ik verdenk de southbridge (SB700) waarin de SATA controller zit evt icm linux software raid. Draai 3 virtual machines op een raid 1 set bestaande uit 2 sata schijven. Performance was om te huilen, nu heb ik de virtual machine met de zwaarste load (iowait > 50%) verplaatst naar een PATA schijf en deze gaat nu als een speer. (iowait 0.12%). Dit is overigens met Ubuntu 9.10 64 bits en een intel NIC.

Liep de machine helemaal vast bij je dan? Ik heb namelijk ALS het werkt hele goede performance. Als het goed is komt morgen m'n Intel NIC binnen en hoewel ik vermoed dat het niet gaat helpen hoop ik op het beste.

EDIT: Zojuist is m'n server weer vastgelopen, alleen stonden deze keer alleen wat torrents te seeden met max 150KB/s. Dit is de eerste keer dat dat gebeurt. Het zou dus toch aan de NIC kunnen liggen, want 150KB/s is peanuts voor een chipset.

[ Voor 13% gewijzigd door Oguz286 op 11-12-2009 18:44 ]

[Oguz286]

Even een update:

Ik heb vandaag de Intel NIC erin gezet, de onboard NIC uitgezet in de BIOS en het ziet ernaar uit dat het stabiel is Ik heb al meerdere gigabytes aan data gekopieerd, wat torrents gedownload en het blijft prima werken. Iedereen die heeft bijgedragen aan de oplossing (even afkloppen): heel erg bedankt

[_root]

Je was wat sceptisch in het begin over deze oplossing , maar gelukkig heb je het lek boven...

Suc6 verder

[Oguz286]

Inderdaad omdat op dat moment de suggestie van gertvdijk mij logischer leek (alhoewel ik jouw oplossing zeker niet uitsluitte). Toen het vastliep bij minimaal gebruik van de hardeschijven begon ik steeds meer de NIC te verdenken en dat bleek tot nu toe dus waar te zijn Hopelijk blijft het zo