Faulty Microsoft Driver Saps Intel Core Duo power

Critical_ writes "Tom's Hardware recently discovered a bug in Microsoft's ACPI driver implementation under Windows XP SP2 that causes a loss of more than one hour of battery time when connecting any USB 2.0 device to an Intel Core Duo based system. Apparently Microsoft, Intel and ODMs have known of this problem under a confidentiality agreement since July 12, 2005 via (a still private) Knowledge Base article KB899179. The bug lies in the asynchronous scheduler component inadvertently being left running causing Windows' internal task scheduler (ITS) to treat it as a running process involving the attached device. This in turn prevents the ITS from powering down the processor into one of the ACPI sleep states causing the system to use more battery power. At this time there seems to be no fix. Strangely, single-core systems and AMD systems are not affected. This leads one to wonder if it is truely a software problem or if there a much larger hardware problem that may affect Core Duo equipped Apple systems."

Comments

It looks like a software problem.

[stikves]

I do not know the exact details, so accept this as a pure speculation.

It seems like a software problem. Think it like the "Weak Reference" issue in garbage collection. Since a system task is always demanding CPU the ACPI subsystem will of course not decrease the power.

Such things also happen in Linux world. For example the update daemon causes disk activity every 10 minutes, which prevented the hard disk from spinning down. Since this was a big issue with laptops, it's now fixed in later versions (my system no longer has /sbin/update).

Re:Disgusting Insensitivity

[Anonymovs Coward]

Maybe CowboyNeal has been in the living in the basement for too long, but everybody else knows that saying "chink" is very offensive to Chinese, Japanese, and other Asian people.

I know it's an old phrase, but niggardly is a word that most people do not use anymore either because of the racist connotations.

Don't be ridiculous. A "chink" in English (including American) is a small crack or a weak spot. And a "niggard" is an English word meaning a miser. It dates back to Middle English, and before that to Scandinavian languages. Neither word has anything to do with racism.

Re:AMD's Dual Core x2 4400+ problem as well

[Anonymous Coward]

I have almost exactly the same hardware (except for the graphics card, I use a Quadro FX4000), and there is absolutely no problem.

I dual boot between Windows XP Pro SP2 for gaming and Windows XP Pro x64 for work, and both work absolutely perfectly. The only issue so far has been that of stable 64-bit driver, but that only pertains to the graphics card.

You might want to check your system for memory errors (if you are using cheapo RAM) or for a motherboard problem. Windows itself (assuming you arent using any broken drivers) works brilliantly with this hardware.

I have been running this system since November with only one or two reboots.

Re:Why?

[undeadly]

My bet the problem is in BIOS, and not EFI. Since this affects only XP computers and those require bios to function. BIOS with ACPI has always been a poor hack.

Yeah, listen to what OpenBSD developers implementing ACPI support thinks about ACPI

Also the ACPI spec blows other specs out of the water when it comes to unreadability. It's a classical spec in the sense that someone was bribed to go to Honolulu to "talk the spec over" and "reach a compromise". They don't even use spec language like shall and optional! It's deliberately vague so that everyone involved could agree. So Marco's engineering assessment is ACPI is a pile of camel pooh.

God I wish I had mod points right now.

[Andy Dodd]

"IBM cell based hardware running GNU/Linux is going to blow all of this trash into a distantly remembered nightmare."

No, it isn't. It's not even going to come close. It's not even going to exist, ever. 90% of the Cell's computing horsepower is in the SPUs, which are optimized for signal processing and geometry processing applications (namely, grinding away on lots of number crunching). No instruction reordering, floating-point only, and very limited branching functionality. The coprocessors are more comparable to devices such as Analog Devices' TigerSHARC or TI's TMS320 series than any general purpose CPU. Despite the insane floating point performance, you don't see TigerSHARC or TMS320 based computers, do you? That's because they are not suitable for general purpose computing in any way.

The Cell's general purpose "controller" CPU is an incredibly stripped down PPC core that has incredibly low performance compared to any standard general purpose CPU.

While it will have incredible performance for gaming and signal processing, the Cell is an utterly crap CPU for general purpose computing. Using a Cell in a normal desktop machine is like trying to cut a tree trunk with a cordless electric drill rather than a reciprocating saw. No matter how nice of a drill it is, it's going to do a shitty job compared to even the cheapest recipro saw, if it manages to do the job at all.

There may be no fix, but there is a workaround

[Anonymous Coward]

I assume this has been posted previously, this is what you've got to do:

1. Click Start, click Run, type regedit, and then click OK.
2. Locate, and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\USB
Note If the USB subkey does not exist, create it. To do this, follow these steps:a. Select the Services key. On the Edit menu, point to New, and then click Key.
b. Type USB in the New Key #1 box to name the new key "USB."

3. Right-click USB, point to New, and then click DWORD Value.
4. In the New Value #1 box that appears, type EnIdleEndpointSupport, and then press ENTER.
5. Right-click EnIdleEndpointSupport, and then click Modify.
6. In the Value data box, type 1, leave the Hexadecimal option selected, and then click OK.
7. Quit Registry Editor.