Link alla notizia: http://www.hwupgrade.it/news/portatili/16408.html

E' stato implementato un fix che risolve in parte i problemi di ridotta autonomia riscontrati con i sistemi notebook con periferca USB collegata

Click sul link per visualizzare la notizia.

Non è molto comodo. Speriamo lo risolvano definitivamente.

in quanto la chiave di registro viene persa ripristinando il bug; in questo caso si rende necessario riavviare il PC per ripristinare correttamente il fix.

Questa mi pare proprio una stronzata... Ma alla fine quello che non ho capito è se il problema riguarda solo i notebook con windows o tutti... :wtf:

Riguarda i notebook con intel core DUO (doppio core) e windows XP....

Ma veramente nell'articolo dice addirittura che potrebbe impattare su athlon e turion, e pure su i centrino precedentii...mi sembra strano...
adesso sta a vedere che è un problema che hanno tutti i portatili, fin dalla preistoria a momenti...mah

riguarda tutti i pentium-M, e penso anche ai turion a questo punto, visto che alla fine è un baco di windows e dell'ACPI.

Scusate ma basta inserire in un file di testo le informazioni di registro, con tanto di chiave cui le istruzioni puntano e salvare il tutto con estensione .REG.
Facendo doppio click sul file le informazioni verranno ripristinate senza doverle reinserire a mano. Rimane che vada riavviato il PC.

Ciauz!

riguarda tutti i pentium m. io in tutti i portatili che ho avuto l'ho riuscontrato

non è una novità che ci siano dei Bug negli ACPI dei portatili, utilizzano tutti il compilatore Microsoft che lascia appunto questi crateri assurdi, infatti se si vuole che linux usi bene l'ACPI, nella maggiorparte dei portatili và corretto un bug e ricompilato, e naturalmente non con il compilatore microsoft! E non è questione che "linux non è compatibile", la questione è che linux conosce bene le specifiche, e le frutta al max (vedi la miglior autonomia) quindi è + facile trovare gli errori, ma purtroppo qui si continua a fare le cose come dice microsoft.

Io non capisco, ci sono i Forum, le fondazioni, insomma tutti quegli enti che fanno gli standard, ma perchè cavolo ci devono mettere del loro per fare poi danni? E' un semplice Q.I. basso che non gli permette di capire come funziona una cosa, o lo fanno apposta per battere gli avversari?!?!? Ma questa volta si sono fregati da soli!!!

Beh ed editare manualmente il registro ad ogni avvio sarebbe una soluzione? :mbe: Allora si fa prima a dire che, per risolvere il bug, basta infilare la presa nella spina... :doh:

Dove sono tutti quelli che hanno spalato merda su Intel difendendo MS? Vi siete nascosti? pfui...

Scusate ma basta inserire in un file di testo le informazioni di registro, con tanto di chiave cui le istruzioni puntano e salvare il tutto con estensione .REG.
Facendo doppio click sul file le informazioni verranno ripristinate senza doverle reinserire a mano. Rimane che vada riavviato il PC.

Ciauz!
...o più che altro basta che microsoft implementi meglio i D-States dei vari device...

Sul mio Pavillion con Turion 64 ML 40 l'inconveniente non c'è.
La soluzione defintiva e ufficiale di Microsoft è una patch + un aggiornamento del bios. Quando una patch da sola non basta ma bisogna anche aggiornare il bios non si tratta solo di bug software ma anche hardware, credo nascosto a due mani sperando che non scoppi il bubbone. " Capisci a me."

ecco perchè ieri con l'hd usb il mio Centrino stava sempre a 1600...ma me lo faceva anche sotto linux! °_°

Microsoft è a conoscenza di questo problema, avendo rilasciato delle note nel proprio Knowledge Base article KB899179 del 12 Luglio 2005.


Ma quanto ci mettono a risolvere questo bug? :confused:

Uno paga la licenza per aspettare sei mesi una patch? :muro:

Su Tom's Hardware sono andati più avanti...
http://www.tgdaily.com/2006/02/14/microsoft_to_release_patch_for_power_drain_bug/

Volevo segnalare al Corsini che facendo una ricerca (essendo curioso di natura...) nel registro di XPSP2, tale entrata (EnIdleEndpointSupport) è già presente in alcune sottochiavi di questa chiave:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{36FC9E60-C465-11CF-8056-444553540000}
relativa appunto al Controller USB.
Penso proprio che si debbano abilitare, almeno ove presenti, anche qui, visto che sono impostate come predefinite al valore DWORD:0x00000000(0)
Oppure aspettare la patch (non ho capito se è già in circolo)
Ciao.

Oppure aspettare la patch (non ho capito se è già in circolo)
Ciao.

Intel spokesperson Connie Brown could not confirm the availability of this fix, although she mentioned that Intel has been evaluating possible solutions "for some time."

Ma veramente nell'articolo dice addirittura che potrebbe impattare su athlon e turion, e pure su i centrino precedentii...mi sembra strano...
adesso sta a vedere che è un problema che hanno tutti i portatili, fin dalla preistoria a momenti...mah

Il problema non è tanto dei portatili quanto dal comportamento del driver, a quanto pare.

Beh ed editare manualmente il registro ad ogni avvio sarebbe una soluzione? :mbe: Allora si fa prima a dire che, per risolvere il bug, basta infilare la presa nella spina... :doh:

Nessuno mai infatti ha detto che è una soluzione. E' un semplice workaround in attesa di una soluzione.

ecco perchè ieri con l'hd usb il mio Centrino stava sempre a 1600...ma me lo faceva anche sotto linux! °_°

Quale dovrebbe essere il problema?