Fedora 14 Standby fagyi

Sziasztok,

Adott egy Fedora 14 64 bites rendszer, frissítve, vanilla kernellel. Mióta belekerült +4gb ram a meglévő 4 mellé (memtest-el végigtesztelve), ha nem használom a rendszert egy idő után fagyizik, csak a reset segít. Log-ban nem találtam semmi erre vonatkozó bejegyzést. Kde-ben lekapcsoltam a memóriába írást ha standby-ra menne a gép. Van valakinek ötlete ez miért lehet, vagy mit nézzek át ?

Hozzászólások

a swap nem kevés h elmentse az összes rambaírt cuccot?

-------------------------------------------------------------------
Semmi közöm ahhoz, ami aktuális. Az mindig látszat...

nem az a gáz... ha ramban több van a swap méreténél akkor ugye altatáskor rambol átírna romba de nemtud mert kevés a rom(a swap) szoval átkell szabni a swapot és akkorának kell lenni mint a ramnak ésígy biztosan nem fog fagyni
64biten nem nehéz telepakolni akármekkora ramot... 32 bit kevesebbet eszik rambol...

-------------------------------------------------------------------
Semmi közöm ahhoz, ami aktuális. Az mindig látszat...

Igen, így szoktam terverzni. Azonban ez valamiért 2gb maradt, meg nem mondom miért. Viszont találtam a logban bejegyzést:
...
....
Mar 9 19:58:21 skynet-x2 pulseaudio[2397]: alsa-source.c: Az értesítés a POLLIN jelzésen keresztül érkezett – viszont a „snd_pcm_avail()” függvény visszatérési értéke 0 volt vagy a második érték kisebb volt, mint a minimum.
Mar 12 01:15:34 skynet-x2 yum[10268]: Updated: alsa-firmware-1.0.24.1-1.fc14.noarch
Mar 12 01:15:35 skynet-x2 yum[10268]: Updated: alsa-tools-firmware-1.0.24.1-1.fc14.x86_64
Mar 12 16:46:05 skynet-x2 pulseaudio[2271]: alsa-util.c: Disabling timer-based scheduling because high-resolution timers are not available from the kernel.
Mar 12 16:46:05 skynet-x2 pulseaudio[2271]: alsa-util.c: Disabling timer-based scheduling because high-resolution timers are not available from the kernel.
Mar 12 16:46:05 skynet-x2 pulseaudio[2271]: alsa-util.c: Disabling timer-based scheduling because high-resolution timers are not available from the kernel.
Mar 12 16:46:07 skynet-x2 pulseaudio[2271]: alsa-sink.c: Az ALSA modul értesítése nyomán új adatokat kellett volna írni az eszközre, de jelenleg semmilyen írandó adat nincsen.
Mar 12 16:46:07 skynet-x2 pulseaudio[2271]: alsa-sink.c: Ez egy hiba lehet az ALSA „snd_hda_intel” eszközmeghajtóban. Kérem jelentse ezt a problémát az ALSA fejlesztői felé.
Mar 12 16:46:07 skynet-x2 pulseaudio[2271]: alsa-sink.c: Az értesítés a POLLOUT jelzésen keresztül érkezett – viszont a „snd_pcm_avail()” függvény visszatérési értéke 0 volt vagy a második érték kisebb volt, mint a minimum.
Mar 12 17:00:57 skynet-x2 ntpd[1551]: 0.0.0.0 c612 02 freq_set kernel -30.998 PPM
Mar 12 17:00:57 skynet-x2 ntpd[1551]: 0.0.0.0 c615 05 clock_sync
...
..
aztán már csak az újraindítás bejegyzései találhatóak

--
r@g3
jáTék0s l1NuX [http://www.youtube.com/user/gerig0d]>

Mégsem segített az ntpd kikapcsolása. Ellenben ha kivettem 4gb ram-ot, akkor hibátlanul megy a szerkezet. Van valamilyen kernel opció, ami kapcsolatos lehet a ram méretével ?

--
r@g3
jáTék0s l1NuX [http://www.youtube.com/user/gerig0d]>

Sajnos attól, hogy a memtest nem jelez hibát, még lehet, hogy van hiba.
Egy alaplap firmware frissítés sem árt, ha van.
Az sem lenne rossz, ha az összes memóriamodul egyforma lenne, bár ez egy bővítésnél nem mindig megoldható.

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

Hi,

Köszi a tippeket. Az alaplapon próbálam a legfrisebb, és az elötte lévő fw-t, de ua. a hibát produkálta. A memóriák egyformák. Kérdés, ha a memtest nem ír hibát, akkor hogy fogják visszavenni ? Bár, meg azt meg lehet tennem, hogy a kivett memóriát rakom vissza, hogy azzal hogy viselkedik a rendszer........
Egyenlőre az 1db 4gb modullal jól muzsikál. Viszont ha a másik modullal is jól fog működnik, akkor megint kérdés a 8gb-os érzékenység....

--
r@g3
jáTék0s l1NuX [http://www.youtube.com/user/gerig0d]>