# [RISOLTO] Comportamento strano

## Nemo1970

Ho fatto la stupidaggine di comprare un portatile ASUS N53SV, scoprendo sulla mia pelle che non si riesce a disattivare la scheda Intel integrata nel processore a favore della NVIDIA, ma il problema piu' grosso non e' quello. Questo dannato laptop si pianta, o meglio, freeza di colpo senza una ragione apparente, e senza lasciare nulla in /var/log/messages che mi possa fare capire che cosa ha causato il freeze; ho gia' provato di tutto, ma senza risultato, e non e' il portatile, perche' il precedente laptop (mandato in garanzia per il disco fisso e rubato al corriere) aveva lo stesso identico difetto, e con win7 installato non si e' mai piantato a questa maniera.

A questo punto posso solo sperare in un colpo di fortuna se qualcuno ha avuto un problema similare e mi indirizza verso la strada giusta, ma la mia domanda e' un'altra : visto che non mi posso tenere una ciofeca come questa, avrei pensato di cambiarlo, ma per non prendere un'altra fregatura, che portatile con core I7 mi consigliate ?

giusto per completezza, il mio sistema e' compilato cosi' : 

Kernel

emerge --info

Saluti a tuttie grazie in anticipo

-- 

AlessandroLast edited by Nemo1970 on Tue Nov 08, 2011 8:51 pm; edited 4 times in total

----------

## ago

Moved from Forum italiano (Italian) to Forum di discussione italiano.

----------

## Onip

non centra con la tua domanda, ma nell'overlay sunrise c'è questo pacchetto

```
* x11-drivers/asus-switcheroo [1]

     Available versions:  ~*0_p20110504 **9999 {kernel_linux video_cards_intel video_cards_nouveau video_cards_nvidia}

     Homepage:            https://github.com/awilliam/asus-switcheroo

     Description:         Modules to turn off nVidia card for ASUS laptops
```

magari ti può aiutare per il problema delle schede video

----------

## Nemo1970

 *Onip wrote:*   

> non centra con la tua domanda, ma nell'overlay sunrise c'è questo pacchetto
> 
> ```
> * x11-drivers/asus-switcheroo [1]
> 
> ...

 

Provo subito a vedere come e'; per ora sembra che tenga, ho provato a ripulire per bene il kernel da tutto quello che non dovrebbe servire; per ora ancora non si e' impiantato, sperando che la soluzione sia quella

grazie per la dritta.

Saluti

----------

## Nemo1970

Si, per adesso e' a posto, sicuramente era quache opzione del kernel che andava di traverso al portatile, anche se non sono riuscito a identificare quale. Ho spempre pero' il problema con il pacchetto asus-switcheroo, che quando tento di emergerlo mi da un errore di mancanza di un file: 

```

voyager conf.d # emerge asus-switcheroo

Calculating dependencies... done!

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) x11-drivers/asus-switcheroo-0_p20110814 from sunrise

 * asus-switcheroo-0_p20110814.tar.gz RMD160 SHA1 SHA256 size ;-) ...                                                                                                                    [ ok ]

 * Determining the location of the kernel source code

 * Found kernel source directory:

 *     /usr/src/linux

 * Found kernel object directory:

 *     /lib/modules/2.6.39-gentoo-r3/build

 * Found sources for kernel version:

 *     2.6.39-gentoo-r3

 * Checking for suitable kernel configuration options...                                                                                                                                 [ ok ]

>>> Unpacking source...

>>> Unpacking asus-switcheroo-0_p20110814.tar.gz to /var/tmp/portage/x11-drivers/asus-switcheroo-0_p20110814/work

>>> Source unpacked in /var/tmp/portage/x11-drivers/asus-switcheroo-0_p20110814/work

>>> Preparing source in /var/tmp/portage/x11-drivers/asus-switcheroo-0_p20110814/work/awilliam-asus-switcheroo-9231be9 ...

>>> Source prepared.

>>> Configuring source in /var/tmp/portage/x11-drivers/asus-switcheroo-0_p20110814/work/awilliam-asus-switcheroo-9231be9 ...

>>> Source configured.

>>> Compiling source in /var/tmp/portage/x11-drivers/asus-switcheroo-0_p20110814/work/awilliam-asus-switcheroo-9231be9 ...

ln: creazione del collegamento simbolico "Module.symvers" non riuscita: Il file esiste

 * Preparing asus-switcheroo module

make -j9 HOSTCC=x86_64-pc-linux-gnu-gcc CROSS_COMPILE=x86_64-pc-linux-gnu- LDFLAGS= default 

make -C /lib/modules/2.6.39-gentoo-r3/build M=/var/tmp/portage/x11-drivers/asus-switcheroo-0_p20110814/work/awilliam-asus-switcheroo-9231be9 modules

make[1]: Entering directory `/usr/src/linux-2.6.39-gentoo-r3'

  CC [M]  /var/tmp/portage/x11-drivers/asus-switcheroo-0_p20110814/work/awilliam-asus-switcheroo-9231be9/asus-switcheroo.o

  CC [M]  /var/tmp/portage/x11-drivers/asus-switcheroo-0_p20110814/work/awilliam-asus-switcheroo-9231be9/i915-jprobe.o

  CC [M]  /var/tmp/portage/x11-drivers/asus-switcheroo-0_p20110814/work/awilliam-asus-switcheroo-9231be9/nouveau-jprobe.o

  CC [M]  /var/tmp/portage/x11-drivers/asus-switcheroo-0_p20110814/work/awilliam-asus-switcheroo-9231be9/byo-switcheroo.o

  Building modules, stage 2.

  MODPOST 4 modules

  CC      /var/tmp/portage/x11-drivers/asus-switcheroo-0_p20110814/work/awilliam-asus-switcheroo-9231be9/asus-switcheroo.mod.o

  CC      /var/tmp/portage/x11-drivers/asus-switcheroo-0_p20110814/work/awilliam-asus-switcheroo-9231be9/byo-switcheroo.mod.o

  CC      /var/tmp/portage/x11-drivers/asus-switcheroo-0_p20110814/work/awilliam-asus-switcheroo-9231be9/i915-jprobe.mod.o

  CC      /var/tmp/portage/x11-drivers/asus-switcheroo-0_p20110814/work/awilliam-asus-switcheroo-9231be9/nouveau-jprobe.mod.o

  LD [M]  /var/tmp/portage/x11-drivers/asus-switcheroo-0_p20110814/work/awilliam-asus-switcheroo-9231be9/nouveau-jprobe.ko

  LD [M]  /var/tmp/portage/x11-drivers/asus-switcheroo-0_p20110814/work/awilliam-asus-switcheroo-9231be9/i915-jprobe.ko

  LD [M]  /var/tmp/portage/x11-drivers/asus-switcheroo-0_p20110814/work/awilliam-asus-switcheroo-9231be9/byo-switcheroo.ko

  LD [M]  /var/tmp/portage/x11-drivers/asus-switcheroo-0_p20110814/work/awilliam-asus-switcheroo-9231be9/asus-switcheroo.ko

make[1]: Leaving directory `/usr/src/linux-2.6.39-gentoo-r3'

>>> Source compiled.

>>> Test phase [not enabled]: x11-drivers/asus-switcheroo-0_p20110814

>>> Install asus-switcheroo-0_p20110814 into /var/tmp/portage/x11-drivers/asus-switcheroo-0_p20110814/image/ category x11-drivers

 * Installing asus-switcheroo module

 * ERROR: x11-drivers/asus-switcheroo-0_p20110814 failed (install phase):

 *   !!! newinitd: /var/lib/layman/sunrise/x11-drivers/asus-switcheroo/files/switcheroo-dir.rc does not exist

 * 

 * If you need support, post the output of 'emerge --info =x11-drivers/asus-switcheroo-0_p20110814',

 * the complete build log and the output of 'emerge -pqv =x11-drivers/asus-switcheroo-0_p20110814'.

 * This ebuild is from an overlay named 'sunrise': '/var/lib/layman/sunrise/'

 * The complete build log is located at '/var/tmp/portage/x11-drivers/asus-switcheroo-0_p20110814/temp/build.log'.

 * The ebuild environment file is located at '/var/tmp/portage/x11-drivers/asus-switcheroo-0_p20110814/temp/environment'.

 * S: '/var/tmp/portage/x11-drivers/asus-switcheroo-0_p20110814/work/awilliam-asus-switcheroo-9231be9'

```

In pratica non trova un file, ma secondo me chi ha messo insieme l'ebuild ha semplicemente sbagliato il nome di un file ......

Beh, appena ho tempo ci quardo meglio.

Per ora grazie a tutti.

----------

## ago

guarda in 

```
/var/lib/layman/sunrise/x11-drivers/asus-switcheroo/files/
```

 se c'è lo script di init;in caso affermativo modifica l'ebuild.

----------

## djinnZ

dato che ho sunrise sincronizzato (e non ricordo più perchè) ho fatto una piccola verifica

/var/lib/layman/sunrise/x11-drivers/asus-switcheroo/files/switcheroo-dir.rc che vuole l'ebuild non c'è ma c'è /var/lib/layman/sunrise/x11-drivers/asus-switcheroo/files/switcheroo.rc

noto con piacere che l'affidabilità di sunrise è sempre la stessa.

Potrebbe anche essere che si siano scordati di mettere un nuovo script in files ma una prova puoi concedertela. Nel peggiore dei casi sarai costretto a resettare il pc (quindi non disabilitare rc interactive o come si diavolo si chiama).

Ma anche se funziona cercherei di contattare chi ha scritto l'ebuild comunque per farlo correggere.

----------

## ago

 *djinnZ wrote:*   

> noto con piacere che l'affidabilità di sunrise è sempre la stessa.

 

Dai una mano anche tu così la qualità del servizio può migliorare   :Cool: 

----------

## djinnZ

Non ho un asus e sto attendendo per l'acquisto del nuovo pc proprio perché questi i7 non mi convincono per niente.

Quindi cosa segnalo (o correggo) se quel pacchetto non lo installerò mai?

Il problema è che per me è inconcepibile metter sull'overlay qualcosa che non è stato completamente verificato ed in troppi lo fanno, continuano a farlo

e se ne fregano. Ed in più è un macello contattarli.

A suo tempo so che si discusse di prevedere un bugzilla ma si disse di no (almeno per poter introdurre una politica di cancellazione).

In questo modo quell'overlay non produrrà mai niente di utile.

Se è un pacchetto che uso mi applico ma fino ad ora ho sempre fatto prima a trovare un'alternativa (o rivolgermi ad altri overlay) che tentare di capire cosa contenessero quegli ebuild. Se non fosse per pigrizia... l'avrei già tolto.

----------

## Nemo1970

Niente da fare, molto meno di prima ma continua a freezare in maniera inconcepibile, e senza lasciare tracce di sorta....... A questo punto non so proprio piu' dove guardare ........

----------

## darkmanPPT

la butto là;

hai provato ad

1) aprire una porta per ssh

2) quando ti freeza il computer, riesci a collegarti ad ssh attraverso un'altro pc e ad usarlo?

ti dico. a me quando freezava il driver ATI non ero più capace più di fare nulla; anche la tastiera si piantava.

notai però che riuscivo a collegarmi attraverso ssh e ad usare il pc. in realtà il pc non si freezava realmente, ma era come se lo fosse stato, dato che risultava inutilizzabile.

ti dico questo perchè anche io non trovavo log con errori. una volta entrato attraverso ssh, cercai in /var/log/ i vari log e ho trovai il mio errore. (era infatti, come pensavo, un errore del driver ati in conflitto con xorg).

(giusto per informazione, risolsi facendo un downgrade del driver.)

----------

## Nemo1970

 *darkmanPPT wrote:*   

> la butto là;
> 
> hai provato ad
> 
> 1) aprire una porta per ssh
> ...

 

Non ci avevo ancora pensato; appena freeza di nuovo provo anche questa strada, chi sa che stavolta riesco a inchiodare il malefico animaletto.

grazie per la dritta.

----------

## djinnZ

 *Nemo1970 wrote:*   

> Kernel

 non mi ci sono applicato più di tanto ma a naso dare uno sguardo a quest'estratto del diff

```
< # CONFIG_BSD_PROCESS_ACCT is not set

< CONFIG_FHANDLE=y

< # CONFIG_TASKSTATS is not set

< # CONFIG_AUDIT is not set

< CONFIG_SPARSE_IRQ=y

< CONFIG_LOG_BUF_SHIFT=18

< CONFIG_CGROUPS=y

< CONFIG_CGROUP_NS=y

< CONFIG_CGROUP_FREEZER=y

< CONFIG_CGROUP_DEVICE=y

< CONFIG_CPUSETS=y

< CONFIG_PROC_PID_CPUSET=y

< CONFIG_CGROUP_CPUACCT=y

< CONFIG_CGROUP_SCHED=y

< CONFIG_FAIR_GROUP_SCHED=y

< CONFIG_RT_GROUP_SCHED=y

< CONFIG_BLK_CGROUP=y

< CONFIG_NAMESPACES=y

< CONFIG_UTS_NS=y

< CONFIG_IPC_NS=y

< CONFIG_USER_NS=y

< CONFIG_PID_NS=y

< CONFIG_NET_NS=y

< CONFIG_SCHED_AUTOGROUP=y

< CONFIG_JUMP_LABEL=y

< CONFIG_BLK_DEV_INTEGRITY=y

< CONFIG_BLK_DEV_THROTTLING=y

< CONFIG_CFQ_GROUP_IOSCHED=y

< CONFIG_FREEZER=y

< # CONFIG_CALGARY_IOMMU is not set

> CONFIG_CALGARY_IOMMU=y

> CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT=y

< CONFIG_SCHED_MC=y

< CONFIG_IRQ_TIME_ACCOUNTING=y

< CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y

< CONFIG_MICROCODE=y

< CONFIG_X86_MSR=y

< CONFIG_X86_CPUID=y

< CONFIG_COMPACTION=y

< CONFIG_KSM=y

< CONFIG_MEMORY_FAILURE=y

< CONFIG_TRANSPARENT_HUGEPAGE=y

< # CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS is not set

< CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y

< CONFIG_X86_CHECK_BIOS_CORRUPTION=y

< CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y

< CONFIG_CC_STACKPROTECTOR=y

< # CONFIG_HZ_100 is not set

< CONFIG_HZ_1000=y

< CONFIG_HZ=1000

< CONFIG_ACPI_PROCFS=y

< CONFIG_ACPI_PROCFS_POWER=y

< CONFIG_ACPI_POWER_METER=y

< CONFIG_ACPI_AC=y

< CONFIG_ACPI_BATTERY=y

> CONFIG_ACPI_FAN=m

< CONFIG_ACPI_PROCESSOR=y

< CONFIG_ACPI_PROCESSOR_AGGREGATOR=y

< CONFIG_ACPI_THERMAL=y

< CONFIG_ACPI_CONTAINER=y

< CONFIG_ACPI_HED=y

< CONFIG_CPU_FREQ_TABLE=y

< CONFIG_CPU_FREQ_GOV_POWERSAVE=y

< CONFIG_CPU_FREQ_GOV_USERSPACE=y

< CONFIG_CPU_FREQ_GOV_ONDEMAND=y

< CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y

< CONFIG_I7300_IDLE_IOAT_CHANNEL=y

< CONFIG_I7300_IDLE=y

< CONFIG_FIRMWARE_IN_KERNEL=y

< CONFIG_EXTRA_FIRMWARE="qualcosa"

< CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"

< CONFIG_CONNECTOR=y

< CONFIG_PROC_EVENTS=y

___

< CONFIG_AGP_INTEL=y

< # CONFIG_VGA_ARB is not set

< CONFIG_DRM_KMS_HELPER=y

< CONFIG_DRM_I915=y

< # CONFIG_FB_CON_DECOR is not set

< # CONFIG_LOGO is not set

< CONFIG_EDAC_DECODE_MCE=y

< CONFIG_ASUS_WMI=m

< CONFIG_ASUS_NB_WMI=m

< # CONFIG_EEEPC_WMI is not set

< # CONFIG_MSI_WMI is not set

< CONFIG_EXPORTFS=y

2736,2737c2704,2705

< CONFIG_FUSE_FS=y

< CONFIG_CUSE=y

< CONFIG_NLS_DEFAULT="utf8"
```

potrebbe esserti d'aiuto, in particolare starei attento al KMS, la mia esperienza su ati mi dice che i blob è meglio che siano integrati nel kernel ed è meglio che sia builtin (oltre al fatto che un kernel kms esclude il ricorso ai driver proprietari).

Eventualmente potresti pensare di integrare il supporto a kdump&c nello switcheroo ma dalla scarsa rifinitura della conf del kernel non mi sembri troppo scafato a questi pasticci. Mi pare che hai ancora molta roba inutile in driver ed altra macante qua e là.

Lasciare il gart intel generico amd o ibm può far si che venga caricato modulo sbagliato e mi pare scontato attendersi che la grafica vada in crash.

Se siete alle prime armi con gentoo, anche se usate da molto altre distribuzioni (quelle serie ... non immondizia windozz-like) non fate gli eroi e rifinite con genkernel --menuconfig . Fate prima ed evitate seccature.

Se proprio non vi va scaricatevi il .config che usa genkernel e partite da un oldconfig con quello.

----------

## Nemo1970

Allora, nel momento in cui il monitor freeza, e' proprio il pc a inchiodarsi completamente, nemmeno un ssh da un pc in rete con lui va a buon fine, l'unica manovra possibile e' spegnerlo brutalmente e riaccenderlo. Per quanto riguarda asus-switcheroo per ora sono arrivato a spegnere la Intel e accendere la nvidia, ma sul monitor non appare altro che un cursore non lampeggiante in alto a sinistra. Tramite un altro pc ho appurato che effettivamente la intel e' su off e la nvidia accesa, ma il segnale video di quest'ultima al monitor non ci arriva. Ma dico io, era tanto brutto mettere uno switch nel bios per costringere il mux video a papparsi il segnale della scheda discreta ? 

Scusate lo sfogo .........[/code]

----------

## djinnZ

La politica di nvidia non è altro che una estremizzazione di quella di intel (non è che motorola sia stata tanto santa ai tempi in cui facevano ancora le cpu o amd non abbia i suo peccati), devi essere legato mani e piedi alla distribuzione ed alla versione dei driver che dicono loro di modo che possano decidere quando il tuo pc è da buttare non supportando l'aggiornamento.

Ma purtroppo siamo persone civili ed il mercato non offre molte alternative.

Tornano seri continuo ad essere scettico sulla possibilità di effettuare lo switch senza scaricare e ricaricare i moduli del kernel e ti ripeto che ai tempi dei primi tentativi con la ati del mio portatile sono diventato pazzo per i crash fino a che non ho capito che dovevo forzare il kernel ad usare l'interfaccia agp gart ati in vece di quella generica amd dell'autoriconoscimento o di quella di fglrx, risolto questo ho scoperto che il config del kernel disabilitava autonomamente alcune legacy e pertanto .

Riduci al minimo la configurazione ed inizia a giocare con le opzioni per il codice deprecato.

Quando si fanno queste prove modificare la conf dell'acpi per lanciare un riavvio alla pressione del power sitch non è una cattiva idea.

Per il resto ti ho già detto che se vuoi venirne a capo devi far ricorso a kdump e sysrq.

NB: Come ho già ripetuto ad altri l'approccio giusto è presupporre una serie di concause e dedicarsi ad identificarle e risolverle una alla volta. Non ci sono formule magiche nella realtà.

Visto che il menuconfig del kernel ha il brutto vizio di disabilitare o abilitare automaticamente alcune opzioni in dipendenza della selezione corrente andrei anche fare dei fdiff tra una configurazione e l'altra.

----------

## table

 *Nemo1970 wrote:*   

> Allora, nel momento in cui il monitor freeza, e' proprio il pc a inchiodarsi completamente, nemmeno un ssh da un pc in rete con lui va a buon fine, l'unica manovra possibile e' spegnerlo brutalmente e riaccenderlo. .[/code]

 

Ciao,

anche io come puoi vedere da QUESTO thread ho un problema simile, per adesso ho installato il kernel 3.0.6  e non ho ancora avuto problemi.

Ho comunque abilitato i tasti SYSRQ per evitare lo spegnimento brutale nel caso in cui il pc si freezi improvvisamente.

Finora però non ho avuto nessun freeze, quindi non ho potuto debuggare ulteriormente

----------

## Nemo1970

 *Quote:*   

> Ciao,
> 
> anche io come puoi vedere da QUESTO thread ho un problema simile, per adesso ho installato il kernel 3.0.6  e non ho ancora avuto problemi.
> 
> Ho comunque abilitato i tasti SYSRQ per evitare lo spegnimento brutale nel caso in cui il pc si freezi improvvisamente.
> ...

 

Ho seguito il tuo consiglio, e ho provato anche io a passare al kernel 3.0.6, impostandomelo da zero e cercando di mettere solo cio' che e' realmente necessario, nello stesso tempo ho anche disattivato la partizione di swap; sono tre giorni che lo sto usando e non si e' piu' piantato. 

Se a questo punto il problema impiantamenti e' risolto, cerchero' di affrontare l'altro nocciolo duro : far funzionare la nvidia discreta.

Per il momento grazie a tutti per i molti consigli che mi avete dato.

----------

## djinnZ

 :Confused:  Mi pare che non hai risolto un tubo ma forse hai individuato il problema.

 *Nemo1970 wrote:*   

> impostandomelo da zero

 se sei un novellino (al di là dell'essere anagraficamente un vecchio bacucco come me) non fare l'eroe e parti dalla conf di genkernel. Puoi anche lanciare su un terminale

```
cd /usr/src/linux ; make MENUCONFIG_COLOR=blackbg menuconfig
```

e nell'altro

```
genkernel --menuconfig all
```

per confrontare. Una volta caricata la conf il menu non ha più bisogno di accedere al file e non blocca l'accesso in scrittura. Basta che poi non fai la cretinata di uscire dalla configurazione salvando e sovrascdrivendo quellla che genkernel sta usando per compilare il kernel (come capita spesso al sottoscritto). *Nemo1970 wrote:*   

> cercando di mettere solo cio' che e' realmente necessario

 eccellente, questo è lo spirito *Nemo1970 wrote:*   

> disattivato la partizione di swap

 male per due ragioni:

in primo luogo la swap su sistemi moderni va vista come una specie di assicurazione contro il memory full (ed in quest'ottica va dimensionata con l'eccezione dei flashdisk dove è controproducente) quindi disabiltarla non è una buona idea;

in secondo luogo problemi con la swap sono un indizio di possibili problemi hardware legati al disco (ed un connettore appena allentato è sufficiente, come un disco che appena appena è spostato dalla sua collocazione).

Se non erro il suspend (anche il cd. suspend in ram sebbene sembri strano, ma non sono sicuro) dipende da SWAP=y (ovviamente una cosa è avere il supporto swap attivo altro usarlo effettivamente visto che sui sistemi con disco flash sarebbe da evitare per risparmiare scritture) quindi c'è da vedere se il tuo problema non è legato all'evento di sospensione od un sovraccarico nel momento in cui il sistema attacca a scrivere sul disco (saturazione della cache hardware malgestita, controller puffo che si blocca, conflitti irq etc.).

Non hai sbagliato nel provare a disattivarla, eccellente intuizione, ma non è utile credere che il problema si risolva così, questo non è molto intelligente.

----------

## Nemo1970

Ok, ne sono venuto a una, compilato un kernel 3.0.6 (come da post di table, che ringrazio come tutti coloro che mi hanno messo sulla strada giusta) partendo da zero e non ricopiando la configurazione da altre parti, scremato tutto il possibile e .... magilla, non freeza piu'. Probabilmente, anche se mi sono compilato (da quando uso la 1.4 di gentoo) almeno un centinaio di kernel, ho fatto il grossolano errore di portarmi dietro una configurazione gia' fatta, che sicuramente abilitava o disabilitava un qualche cosa che era il responsabile dell'impuntamento. Ho anche riattivato la swap e funzia bene senza problemi.

Adesso picchiero' la mia proverbiale testa dura (sono sardo  :Smile:  ) sul secondo problema : asus-switcheroo.

Ancora un grosso grazie a tutti.

Saluti

----------

## djinnZ

diff vecchiaconf nuovaconf e cerca di capire cosa potrebbe essere la causa. A quel punto apri un bug o posti sulla ml (del kernel). L'open source è basato su questo.

Alla fine ho scoperto che il driver sensori winbond a causa dei pasticci fatti dal costruttore della MB (abit dimm.) schiantava il pc per dirne una.

Se sei su ramdisk la swap non è un bene (ma è bene avere il supporto come ti ho già detto).

----------

