[ubuntu] Problema allo spegnimento, l'alimentatore bippa

[S3pHiroTh]

Ciao ragazzi,
sono utente nuovo di Linux e precisamente sto usando Ubuntu 8.10.
Ho un piccolo problema con il pc, cioè quando cerco di spegnerlo l'alimentatore comincia a bippare.
Questo succede solo con Ubuntu, perchè se si spegne con Windows, l'alimentatore non ha questo problema, cioè dopo averlo spento con Windows l'alimentatore resta "acceso" per un tot di tempo e continua a far girare le ventoline per far raffreddare il pc, mentre con Ubuntu si spegne subito e così l'alimentatore inizia a bippare per alcuni secondi (spero di essere stato chiaro).

La configurazione HW è questa:
Enermax Infinity 720watt
Asus M2NPV-VM
AMD X2 4800+
3Gb RAM
HD SATA WesternDigital 400Gb
Scheda audio Creative Audigy
Masterizzatore SATA
Lettore Schedine (tipo SD, MMC, etc)

Grazie molte a chi mi può aiutare

[sacarde]

bippa dopo che si e' spento ubuntu ?


quanti bip? o di continuo

[S3pHiroTh]

Originariamente inviato da sacarde

bippa dopo che si e' spento ubuntu ?


quanti bip? o di continuo

Allora si spegne il pc regolarmente, poi quando l'alimentatore dovrebbe stare acceso un tot di tempo per raffreddarsi, invece si spegne dopo pochissimi secondi e l'alimentatore fa 2 o 3 bip per poi spegnersi definitivamente anche lui.
Sinceramente non so cosa da possa dipendere sto problema , ma non vorrei che a lungo andare l'alimentatore mi possa lasciare a piedi (con i soldi che ho speso poi...)

[sacarde]

hai visto se nel BIOS c'e' qualcosa a riguardo?


avevi provato altri linux prima?

o hai notato se partendo da un linux cdlive fa lo stesso?

[S3pHiroTh]

Originariamente inviato da sacarde

hai visto se nel BIOS c'e' qualcosa a riguardo?


avevi provato altri linux prima?

o hai notato se partendo da un linux cdlive fa lo stesso?

Ho provato or ora ad attivare il QFan (o come si chiama) nel bios, vedo se questo risolve.
Avevo provato altre versioni di Ubuntu, ma davano lo stesso problema...
Per il CD Live non mi ricordo, dovrei riprovare, appena posso lo faccio

[S3pHiroTh]

Allora, dopo aver attivato il QFan, non è cambiato nulla.
Provato anche con il livecd di Ubuntu sempre il solito problema.
Adesso provo una versione livecd di Fedora, vedo se dà lo stesso problema

[Gimli[2BV!2B]]

Il tuo alimentatore ha molti optional; la funzionalità incriminata è la "Cool Guard".
In pratica, in base alla temperatura (soglia 45°C, misurata al suo interno) l'alimentatore tiene alta la tensione dei 12V per un tot di tempo dopo lo spegnimento, facendo girare tutte le ventole di sistema.

Non c'è modo di disattivare questa funzionalità se funziona male.
Nel tuo caso non sembrerebbe trattarsi di incompatibilità con la tua scheda madre, visto che con Win funziona a dovere.

I bip prodotti dall'alimentatore, che dovrebbe avere anche dei led di diagnostica, fanno parte di un'altra funzionalità: "Power Guard".
Quale errore segnala (pag. 6)?

Credo che il problema sia nella sequenza di spegnimento di Linux, che è diversa da quella di Win e potrebbe portare la scheda madre in uno stato diverso da quello che si aspetta il "Cool Guard", facendo scattare il segnale del "Power Guard".
Intanto vediamo l'errore preciso, poi si tratterà di capire dove provare a mettere le mani...

[Gimli[2BV!2B]]

Ho trovato una possibile pista: il file /etc/default/halt.

Dovrebbe contenere questa riga:
HALT=poweroff

Prova a modificarla in questo modo:
HALT=halt

Da man 5 halt:
HALT

• If set to poweroff the system will be powered down after it has been brought down. This is the default.
• If set to halt the system will only be halted after it has been brought down. What exactly this means depends on your hardware.

[S3pHiroTh]

Originariamente inviato da Gimli[2BV!2B]

Il tuo alimentatore ha molti optional; la funzionalità incriminata è la "Cool Guard".
In pratica, in base alla temperatura (soglia 45°C, misurata al suo interno) l'alimentatore tiene alta la tensione dei 12V per un tot di tempo dopo lo spegnimento, facendo girare tutte le ventole di sistema.

Non c'è modo di disattivare questa funzionalità se funziona male.
Nel tuo caso non sembrerebbe trattarsi di incompatibilità con la tua scheda madre, visto che con Win funziona a dovere.

I bip prodotti dall'alimentatore, che dovrebbe avere anche dei led di diagnostica, fanno parte di un'altra funzionalità: "Power Guard".
Quale errore segnala (pag. 6)?

Credo che il problema sia nella sequenza di spegnimento di Linux, che è diversa da quella di Win e potrebbe portare la scheda madre in uno stato diverso da quello che si aspetta il "Cool Guard", facendo scattare il segnale del "Power Guard".
Intanto vediamo l'errore preciso, poi si tratterà di capire dove provare a mettere le mani...

Originariamente inviato da Gimli[2BV!2B]

Ho trovato una possibile pista: il file /etc/default/halt.

Dovrebbe contenere questa riga:
HALT=poweroff

Prova a modificarla in questo modo:
HALT=halt

Da man 5 halt:
HALT

* If set to poweroff the system will be powered down after it has been brought down. This is the default.
* If set to halt the system will only be halted after it has been brought down. What exactly this means depends on your hardware.

Innanzitutto grazie per l'aiuto, allora per prima cosa ho fatto la prova con Fedora, ha lo stesso difetto ma l'alimentatore fa dei beep diversi, mi spiego meglio:
- Ubuntu: spento il sistema, l'alimentatore fa 2 beep ad intervalli regolari (circa 1 al secondo), la lucina passa dal verde fisso al rosso intermittente per poi al terzo secondo circa passare la lucina al colore arancio, quindi alimentatore in stanby;
- Fedora: spento il sistema, l'alimentatore fa 2 beep in rapida successione poi uno stop di circa un secondo per poi rifare lo stesso, la lucina passa dal verde al rosso fisso;

Ho provato il suggerimento che mi hai scritto modificando quel file e l'unica cosa che mi è successa è che il pc non si è più spento
"La barra dello shutdown" di Ubuntu ci mette un po' di più nella sua procedura e alla fine appare sullo schermo la seguente scritta: ACPID: Exiting e resta lì, sono rimasto circa 3 minuti a vedere se andava via ma niente, alla fine ho riavviato e messo a posto il file.

Comunque guardando il manuale che mi hai linkato, nella prova Ubuntu sembra che l'alimentatore segnali che la ventola è difettosa perchè gira piano (infatti si spegne subito cosa che non dovrebbe fare), mentre in Fedora sembra che non dia un corretto segnale al Power Guard... mah

[Gimli[2BV!2B]]

Ho ripassato un po' quel che succede nella sequenza di spegnimento.

/etc/init.d/halt
/sbin/halt -d -f (-p con HALT=poweroff in /etc/default/halt)

halt -dfp (senza -p hai detto che non si spegne):

kill(1, SIGTSTP);
reboot(MAGIC1, MAGIC2, LINUX_REBOOT_CMD_POWER_OFF);

/usr/src/linux-2.6.27.9/kernel/sys.c

case LINUX_REBOOT_CMD_POWER_OFF:
	kernel_power_off();
	unlock_kernel();
	do_exit(0);
	break;

void kernel_power_off(void)
{
	kernel_shutdown_prepare(SYSTEM_POWER_OFF);
	if (pm_power_off_prepare)
		pm_power_off_prepare();
	disable_nonboot_cpus();
	sysdev_shutdown();
	printk(KERN_EMERG "Power down.\n");
	machine_power_off();
}

Proviamo a seguire solo l'ultimissima fase: machine_power_off().

/usr/src/linux-2.6.27.9/arch/sh/kernel/process_32.c

void machine_power_off(void)
{
	if (pm_power_off)
		pm_power_off();
}

Dove viene impostata pm_power_off? In sistemi ACPI in:

/usr/src/linux-2.6.27.9/drivers/acpi/sleep/main.c

int __init acpi_sleep_init(void)

Funzione chiamata al boot; per sapere cosa fa nel tuo sistema:
dmesg | grep "ACPI: (supports"

In condizioni normali, con stato S5/G2 ACPI riconosciuto:

printk(" S5");
pm_power_off_prepare = acpi_power_off_prepare;
pm_power_off = acpi_power_off;

static void acpi_power_off_prepare(void)
{
	/* Prepare to power off the system */
	acpi_sleep_prepare(ACPI_STATE_S5);
	acpi_hw_disable_all_gpes();
}

static void acpi_power_off(void)
{
	/* acpi_sleep_prepare(ACPI_STATE_S5) should have already been called */
	printk("%s called\n", __func__);
	local_irq_disable();
	acpi_enable_wakeup_device(ACPI_STATE_S5);
	acpi_enter_sleep_state(ACPI_STATE_S5);
}

/usr/src/linux-2.6.27.9/drivers/acpi/hardware/hwsleep.c

Dove troviamo acpi_enter_sleep_state, che ci porta direttamente in:

/usr/src/linux-2.6.27.9/drivers/acpi/namespace/nsxfeval.c

Questo è il capolinea: in questo file si chiacchiera con l'ACPI.


Idee che mi sono balenate nella mente mentre mi spingevo sempre più in là:

1. Nel BIOS non hai APM attivato, vero?
2. Quando hai provato HALT=halt hai controllato cosa succedeva premendo brevemente una volta il pulsante di accensione?
3. Posta il dmesg in qualche modo, così controllo la strada che ho esplorato nella "gita alle caverne del kernel"...
4. Dovresti provare uno degli ultimi kernel.

P.S. è stato un percorso interessante, ma non so se riuscirò a cavare qualcosa che ti possa servire...

[S3pHiroTh]

Originariamente inviato da Gimli[2BV!2B]

Idee che mi sono balenate nella mente mentre mi spingevo sempre più in là:

1. Nel BIOS non hai APM attivato, vero?
2. Quando hai provato HALT=halt hai controllato cosa succedeva premendo brevemente una volta il pulsante di accensione?
3. Posta il dmesg in qualche modo, così controllo la strada che ho esplorato nella "gita alle caverne del kernel"...
4. Dovresti provare uno degli ultimi kernel.

Innanzitutto un grosso grazie per l'aiuto che mi stai dando, mi stai aiutando più tu che il forum ufficiale di ubuntu, comunque passando alle tue domande:
Punto 1: Penso non ci siano voci nel BIOS riguardanti l'APM, comunque guarderò stasera e ti farò sapere
Punto 1 EDIT: Allora nel BIOS sotto la sezione ACPI e APM ho queste voci messe in questo modo:
ACPI Suspend Type: S1&S3
ACPI APIC support: Enabled
APM Configuration:

Restore on AC Power Loss: Disabled
HDD Down In Suspend: Disabled
PWR Button < 4 secs: Instant-Off
Power On By PCI/PCIE Devices: Disabled
Power On By External Modems: Disabled
Power On By RTC Alarm: Disabled
HPET Support: Disabled
Power On By PS/2 Mouse: Disabled
Power On By PS/2 Keyboard: Disabled

Hardware Monitor:

Q-Fan Controller: Enabled
<Poi segnalazioni per i Volt sui vari canali, i gradi e il regime di rotazione delle ventole>

Punto 2: No, l'unica cosa che ho fatto è aspettare i 3 minuti circa, come ho detto prima, ho visto che non si spegneva più, quindi ho premuto il tasto reset
Punto 2 EDIT: Ho appena provato non succede nulla, resta sempre lì anche se lo premo
Punto 3: Anche questo lo scrivo stasera
Punto 3 EDIT: Ho inserito l'allegato con il risultato del messaggio
Punto 4: Avevo letto in giro che ricompilare il kernel in Ubuntu non era cosa tanto facile perchè il kernel di ubuntu ha delle ottimizzazioni, ma sinceramente, visto che sono un niubbone di linux (anche se in windows sono abbastanza esperto per risolvere le cose), non ho mai provato.

[Gimli[2BV!2B]]

Vediamo un po':

• L'APM è disattivato e non ne ho trovato traccie nel dmesg.
• Tutti gli stati ACPI sono riconosciuti e attivi: ACPI: (supports S0 S1 S3 S4 S5)
• Il kernel è recente (è un 27 patchato Ubuntu: 2.6.27-9.19)

Analizzando il dmesg un po' più genericamente ho trovato varie cosette sospette; in ordine di possibile correlazione col tuo problema:

1. [ 11.395630] ACPI: I/O resource nForce2_smbus [0x4c00-0x4c3f] conflicts with ACPI region SM00 [0x4c00-0x4c05]
   [ 11.395634] ACPI: Device needs an ACPI driver
2. [ 0.000000] Nvidia board detected. Ignoring ACPI timer override.
   [ 0.000000] If you got timer trouble try acpi_use_timer_override
3. [ 0.464411] HPET not enabled in BIOS. You might try hpet=force boot option
   [ 21.112015] Clocksource tsc unstable (delta = -103716598 ns)

Si potrebbe provare ad aggiungere qualche opzione al boot.

1. Quando parte Grub posizionati sulla riga di Ubuntu che usi di solito.
2. Premi e
3. Posizionati sulla riga che inizia con kernel
4. Premi di nuovo e
5. Cancella le parole quiet splash
6. Aggiungi queste opzioni in fondo alla riga:
   acpi_use_timer_override notsc hpet=force clocksource=hpet (la tastiera in Grub è inglese: l'= è sul tasto ì; l'_ è al posto di ?)
7. Premi Invio, quindi b per avviare il sistema.

Queste modifiche sono temporanee: quando riavvierai il sistema troverai le impostazioni originali.

Se il boot non va a buon fine prova con solo acpi_use_timer_override.
Se va tutto bene riposta il dmesg nuovo.

Potrebbe tornare utile anche il log /var/log/syslog in cui ci sono i messaggi relativi alla fase di spegnimento.
Però questo log non è pulito come il dmesg e potrebbe essere già archiviato in /var/log/syslog.N.gz (N = numero progressivo).
I log gzippati li puoi leggere al volo con zcat (ex: zcat /var/log/syslog.1.gz).
Cerca di rintracciare un ciclo completo di vita del tuo pc, da un [ 0.000000] Linux version 2.6.27-9-generic (buildd@yellow) a quello successivo.

In questa prova resta proprio fuori il punto 1: nForce2_smbus.
Le poche traccie che ho trovato sinora portano in casa Asus e sono citate ibernazioni e spegnimenti.
Si potrebbe provare ad aggiungere in fondo ad /etc/modprobe.d/blacklist la riga:
blacklist i2c-nforce2
In questo caso tieni vicina una live con cui poter cancellare la riga se crea problemi.

Se non si otterrà nulla posta anche lspci -v ed lsmod

[S3pHiroTh]

Originariamente inviato da Gimli[2BV!2B]

Vediamo un po':

• L'APM è disattivato e non ne ho trovato traccie nel dmesg.
• Tutti gli stati ACPI sono riconosciuti e attivi: ACPI: (supports S0 S1 S3 S4 S5)
• Il kernel è recente (è un 27 patchato Ubuntu: 2.6.27-9.19)

Analizzando il dmesg un po' più genericamente ho trovato varie cosette sospette; in ordine di possibile correlazione col tuo problema:

1. [ 11.395630] ACPI: I/O resource nForce2_smbus [0x4c00-0x4c3f] conflicts with ACPI region SM00 [0x4c00-0x4c05]
   [ 11.395634] ACPI: Device needs an ACPI driver
2. [ 0.000000] Nvidia board detected. Ignoring ACPI timer override.
   [ 0.000000] If you got timer trouble try acpi_use_timer_override
3. [ 0.464411] HPET not enabled in BIOS. You might try hpet=force boot option
   [ 21.112015] Clocksource tsc unstable (delta = -103716598 ns)

Si potrebbe provare ad aggiungere qualche opzione al boot.

1. Quando parte Grub posizionati sulla riga di Ubuntu che usi di solito.
2. Premi e
3. Posizionati sulla riga che inizia con kernel
4. Premi di nuovo e
5. Cancella le parole quiet splash
6. Aggiungi queste opzioni in fondo alla riga:
   acpi_use_timer_override notsc hpet=force clocksource=hpet (la tastiera in Grub è inglese: l'= è sul tasto ì; l'_ è al posto di ?)
7. Premi Invio, quindi b per avviare il sistema.

Queste modifiche sono temporanee: quando riavvierai il sistema troverai le impostazioni originali.

Se il boot non va a buon fine prova con solo acpi_use_timer_override.
Se va tutto bene riposta il dmesg nuovo.

Potrebbe tornare utile anche il log /var/log/syslog in cui ci sono i messaggi relativi alla fase di spegnimento.
Però questo log non è pulito come il dmesg e potrebbe essere già archiviato in /var/log/syslog.N.gz (N = numero progressivo).
I log gzippati li puoi leggere al volo con zcat (ex: zcat /var/log/syslog.1.gz).
Cerca di rintracciare un ciclo completo di vita del tuo pc, da un [ 0.000000] Linux version 2.6.27-9-generic (buildd@yellow) a quello successivo.

In questa prova resta proprio fuori il punto 1: nForce2_smbus.
Le poche traccie che ho trovato sinora portano in casa Asus e sono citate ibernazioni e spegnimenti.
Si potrebbe provare ad aggiungere in fondo ad /etc/modprobe.d/blacklist la riga:
blacklist i2c-nforce2
In questo caso tieni vicina una live con cui poter cancellare la riga se crea problemi.

Se non si otterrà nulla posta anche lspci -v ed lsmod

Allora ho provato le impostazioni che mi hai detto e ho fatto tutte i listati, scarica lo zip da qui

Allora:
i file lscpi e lsmod ovviamente sono i comandi che mi hai detto di fare alla fine;
il file syslog è il syslog + grosso che ho nella cartella da te menzionata;
il file acpiovveride è il comando dmesg dopo aver inserito le opzioni acpi_use_timer_override notsc hpet=force clocksource=hpet nel bootloader;
il file blacklist è il comando dmesg dopo aver inserito le opzioni blacklist i2c-nforce2.

Comunque in nessuno dei casi si è risolto il problema
Una cosa che ho cominciato a notare ieri, Ubuntu oltre a non farmi funzionare correttamente il CoolGuard dell'alimentatore Enermax in mio possesso, fa esattamente questo:
- La "barra dello shutdown" si completa;
- Si spegne il monitor e si spegne la lucina del stato del pc (sai la lucina che dice se il pc è acceso oppure no)
- Il lettore CD e il lettore schedine SD si riaccendono per circa 1-2 secondi, come se il pc si stesse avviando nuovamente
- Poi si spegne tutto nuovamente e l'alimentatore comincia a bippare

Sinceramente non ci capisco più niente

[sacarde]

l'hai provato il parametro al kernel: noacpi

[S3pHiroTh]

Originariamente inviato da sacarde

l'hai provato il parametro al kernel: noacpi

Grazie molte, sembra proprio che con quel settaggio nel bootloader funzioni a dovere, provo a fare ancora qualche prova ma penso che sia risolto
Solo una domanda sorge spontanea, mettere quel parametro, oltre a farmi funzionare correttamente l'alimentatore, ha altri pro o dei contro nell'usarlo?

Grazie mille ad entrambi siete stati gentilissimi

[Gimli[2BV!2B]]

Soluziona drastica, ma se non noti nulla che non va ed il il problema è risolto direi che sono stato un cretino a non pensarci prima
Di solito serve quando il sistema non parte proprio, devo essere più elastico...

Con noacpi il pc è un po' più indaffarato da interrupt (consuma e scalda un po' di più, ma niente di cui preoccuparsi).
Più che altro, da quel che so, con questa opzione non è possibile sfruttare più di un core.

Se ancora non ti sei stancato di fare delle prove si può tentare di disabilitare solo la parte del codice ACPI che ti maltratta l'alimentatore:
(Tratto da uno specchietto ben fatto su LessWatts.org)

If the system boots with "acpi=off", but fails otherwise, there are a number of boot parameters that disable different parts of ACPI that can be used to isolate where the issue lies.

• acpi=ht the most like "acpi=off", disables all of ACPI except what is needed to enumerate processors. If acpi=off works and acpi=ht fails, then the issue is in the ACPI table parsing code itself, or perhaps the SMP code.
• pci=noacpi Disables ACPI for PCI root bus enumeration. Disables ACPI for IRQ routing.
• acpi=noirq Disables ACPI for IRQ routing.
• pnpacpi=off Disables the ACPI component of the Linux Plug and Play code.
• noapic Disables the IO-APIC for IRQ routing.
• nolapic Disables the Local-APIC and the IO-APIC.

[S3pHiroTh]

Originariamente inviato da Gimli[2BV!2B]

Soluziona drastica, ma se non noti nulla che non va ed il il problema è risolto direi che sono stato un cretino a non pensarci prima
Di solito serve quando il sistema non parte proprio, devo essere più elastico...

Con noacpi il pc è un po' più indaffarato da interrupt (consuma e scalda un po' di più, ma niente di cui preoccuparsi).
Più che altro, da quel che so, con questa opzione non è possibile sfruttare più di un core.

Se ancora non ti sei stancato di fare delle prove si può tentare di disabilitare solo la parte del codice ACPI che ti maltratta l'alimentatore:
(Tratto da uno specchietto ben fatto su LessWatts.org)

If the system boots with "acpi=off", but fails otherwise, there are a number of boot parameters that disable different parts of ACPI that can be used to isolate where the issue lies.

• acpi=ht the most like "acpi=off", disables all of ACPI except what is needed to enumerate processors. If acpi=off works and acpi=ht fails, then the issue is in the ACPI table parsing code itself, or perhaps the SMP code.
• pci=noacpi Disables ACPI for PCI root bus enumeration. Disables ACPI for IRQ routing.
• acpi=noirq Disables ACPI for IRQ routing.
• pnpacpi=off Disables the ACPI component of the Linux Plug and Play code.
• noapic Disables the IO-APIC for IRQ routing.
• nolapic Disables the Local-APIC and the IO-APIC.

Li ho provati tutti, ma solo con noacpi mi funziona correttamente il pc, lo terrò così In alcuni casi mi disabilita addirittura le porte USB e quindi non riesco neanche più a scrivere o usare il mouse (un disastro insomma :P)
Un'ultimissima domanda, ma questo problema del settaggio "noacpi", potrebbe essere legato alla scheda madre che non è pienamente compatibile con Linux?

[Gimli[2BV!2B]]

Perfetto, niente ACPI.
Sì, la tua scheda madre, o l'accoppiata scheda+ali, non sono pienamente supportate dal kernel.
Quando capiteranno aggiornamenti del kernel ricordati di fare un tentativo di avvio con l'ACPI per controllare se la situazione si è sistemata.

Dei parametri di avvio che ti avevo consigliato potresti tenere notsc hpet=force clocksource=hpet che forzano l'utilizzo dell'HPET, che è il timer più preciso disponibile nei pc moderni.