Slashdot Mirror


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."

16 of 268 comments (clear)

  1. It looks like a software problem. by stikves · · Score: 4, Informative

    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).

    1. Re:It looks like a software problem. by spitzak · · Score: 2, Informative

      /sbin/update would cause power saving to fail on *all* systems, not just some mysterious new systems. This is as though somehow /sbin/update did not use power at all when running (due to some clever hack), and thus there was no reason to be removed from Linux, but when you get this new processor, somehow that new one causes the hack to break and /sbin/update starts using power.

  2. Re:Disgusting Insensitivity by csirac · · Score: 3, Informative

    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.

    "Chink in the armour" is an outrageously common phrase in the English language.

    My thoughts when I read it? "What does armour have to do with battery runtimes...".

    The first thoughts of racist association did not enter my head until I read your comment. I'm from Australia, though, and if people are going to be racist there are much worse words that can be used.

  3. AMD's Dual Core x2 4400+ problem as well by dr+ttol · · Score: 2, Informative

    I just recently upgraded to X2 4400+ running Win XP SP2 and 2GB dual channel ram. OS is running off a 15k RPM drive, and storage is on 3 x 250GB 16mb cache drives. The motherboard is A8N32-SLI. Video card is eVGA nvidia 7800GT.

    I can't run Windows for more than 24 hours before Outlook takes a hold of one of the CPU's. ending outlook process makes the system pick another process, usually explorer.exe, to take 50% of total CPU (or one whole processor). Shortly after, the entire system freezes.

    Seems like AMD has a problem as well. So it could be a Windows issue with dual core processors.

    I also applied the "windows dual core hot fix" (google that), and set the registry setting from the KB article to 1, which didn't fix it, so I set it to 0, and that didn't fix it either. So, my system is stable for ~24 hours then kaput.

    1. Re:AMD's Dual Core x2 4400+ problem as well by Anonymous Coward · · Score: 5, Informative

      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.

  4. Re:Disgusting Insensitivity by Anonymovs+Coward · · Score: 4, Informative
    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.

  5. Re:So... by Johan+Veenstra · · Score: 2, Informative

    "pre-production sample of MSI's Megabook S270. This is an ultra-portable notebook system with an AMD Sempron 3000+ CPU"

    This ultra-portable has a much smaller battery (25Wh vs 50Wh), no wonder it gets half the battery life....

  6. Re:Disgusting Insensitivity by Turn-X+Alphonse · · Score: 3, Informative

    I guess it depends how you read it.

    Chink in the armour - An asian in the armour, so clearly your defences are now screwed
    Chink in the armour - A slight defect/damage to the armour.

    Define in Google says

    * offensive terms for a person of Chinese descent
    * tinkle: make or emit a high sound; "tinkling bells"
    * a narrow opening as e.g. between planks in a wall
    (more here but unneeded).

    I guess when people can't do a simple check on a word they must run around screaming racist/sexist/whatever, just to make sure we don't miss their ignorance.

    --
    I like muppets.
  7. Microsoft Bugs CAN affect Linux and Apple by essinger · · Score: 3, Informative

    What if the current ACPI driver isn't faulty but the previous one was? What if Intel relied on the previous driver to design the sleep functions for the Core Duo? Then Microsoft fixes the ACPI driver. Uh-oh. This kind of thing happens in software all the time. There does seem to be some evidence for this scenerio in the article.

    The problem is only reported on the latest Service Pack.

    The problem has been known for seven months but not "fixed."

    The problem only occurs on the Core Duo.

    Microsoft seems ready to take responsibility for the problem even though the evidence points to a hardware problem.

    The following quote from the Intel rep -- "It is something we have asked our engineers to put a high priority on. At this time, we may be able to solve the problem through drivers, firmware and software. If there is no solution from a software persepctive, we will look into hardware fixes for future platforms to prevent this issue."

    And this other quote pointing a finger at the reference implementation -- "All the vendors have to design their products according to the power management specifications. If one component is not working properly, the whole system may be impacted."

    So even if the bug was a Microsoft bug it could still affect all other system using the hardware designed to run on Windows.

    You'd think the authors might install Linux on the notebook to check.

  8. Re:Why? by undeadly · · Score: 4, Informative
    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.
  9. God I wish I had mod points right now. by Andy+Dodd · · Score: 4, Informative

    "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.

    --
    retrorocket.o not found, launch anyway?
  10. Dual core the culprit by cnettel · · Score: 1, Informative

    The Windows scheduler is different in single and dual core, or more specifically: single or multi CPU. This is quite understandable, as there are some optimizations possible for the synchronization objects if you know for a fact that there is only one real execution path. Synchronization in different forms is used A LOT in the NT kernel, as it's a piece of full reentrancy fetishism.

  11. There may be no fix, but there is a workaround by Anonymous Coward · · Score: 4, Informative

    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.

  12. Re:And thanks to the confidiality agreement by willfe · · Score: 3, Informative

    Because as the article suggests, it may be a functionality problem in the Intel hardware that the Microsoft driver exposes. Sure, Apple's not using Microsoft's drivers, but suppose their own work accidentally stumbles into this and starts grinding through those shiny new Mac batteries. What happens then? More accusations of FUD as batteries start going flat sooner than they're supposed to?

    --
    Read my stuff.
  13. KB Article by Anonymous Coward · · Score: 2, Informative

    A Windows XP SP2-based portable computer uses its battery power more quickly than you expect when a USB 2.0 device is connected
    View products that this article applies to.

    Partner Only Article Article ID : 899179
    Last Review : July 12, 2005
    Revision : 1.0
    Important This article contains information about how to modify the registry. Make sure to back up the registry before you modify it. Make sure that you know how to restore the registry if a problem occurs. For more information about how to back up, restore, and modify the registry, click the following article number to view the article in the Microsoft Knowledge Base:
    256986 (https://premier.microsoft.com/kb/256986/) Description of the Microsoft Windows registry
    SYMPTOMS
    Consider the following scenario. You install Microsoft Windows XP Service Pack 2 (SP2) on a portable computer. Then, you connect a USB 2.0 device to the computer. In this scenario, the computer uses its battery power more quickly than you expect.
    CAUSE
    Windows XP SP2 installs a USB 2.0 driver that initializes any connected USB device. However, the USB 2.0 driver leaves the asynchronous scheduler component continuously running. This problem causes continuous instances of memory access that prevent the computer from entering the deeper Advanced Configuration and Power Interface (ACPI) processor idle sleep states. These processor idle sleep states are also known as C states. For example, these include the C3 and C4 states. These sleep states are designed, in part, to save battery power. If an otherwise idle portable computer cannot enter or maintain the processor idle sleep states, the computer uses its battery power more quickly than you expect.
    RESOLUTION
    Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall your operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk. To resolve this problem, add the EnIdleEndpointSupport entry to the USB registry key. To do this, follow these steps: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.

    STATUS
    Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.

    APPLIES TO
      Microsoft Windows XP Service Pack 2, when used with:
            Microsoft Windows XP Professional
            Microsoft Windows XP Home Edition

      Top of Page

    Keywords: kbtshoot kbbug kbnofix kbprb KB899179

  14. Re:jeebus by Foolhardy · · Score: 2, Informative
    Were this a change posted to a linux page it would read: "Add a DWORD named EnIdleEndpointSupport with value 1 to HKLM\SYSTEM\CurrentControlSet\Services\USB", only it would be in a /etc config file. The parent just lists it step-by-step. Alternatively, on XP, just type this into a terminal:
    reg add HKLM\SYSTEM\CurrentControlSet\Services\USB /v EnIdleEndpointSupport /t REG_DWORD /d 1