Re: After Ms patches last Wed ...

From: Andy Shaw (andy_at_east.no)
Date: 04/17/04

  • Next message: Dan Harkless: "Re: After Ms patches last Wed ..."
    To: "phaser-X" <px@zeroday.net>, <aborg@mca.org.mt>
    Date: Sat, 17 Apr 2004 11:48:16 +0200
    
    

    > I had a different issue after Wednesdays updates. Two win2k computers
    in
    > my office were rendered useless after the patch. They were fine
    before,
    > but as soon as the patch finished and the PC was rebooted, the CPU
    usage
    > was 100% and nothing could be done. I left both PC's sitting for about
    20
    > minutes and the 100% CPU usage never came down. Another coworker said
    he
    > had the same issue with his home PC and he was eventually able to get
    into
    > the task manager and noticed that the system process was taking up
    99-100%
    > of the CPU.
    >
    > Anyone else experience this issue?

    I have experienced this issue, eventually I was able to uninstall the
    patch, the specific one that caused it was KB835732. According to some
    information I found using Google it makes a difference if the Secondary
    IDE Channel's Device 1 is set to use DMA if available as a transfer mode
    instead of PIO Only. I'm not sure just how valid this is because I have
    not tried, but I would be interested to know if anyone managed to get
    this fixed after installing the patch. I'm not happy about having to
    leave my system vunerable right now.

    Andy


  • Next message: Dan Harkless: "Re: After Ms patches last Wed ..."

    Relevant Pages

    • Re: RT patch acceptance (scheduler)
      ... > lock up the CPU in IRQ mode for human-perceptible time, ... For non-DMA IDE access data copies are CPU driven ... which can create tons of latency problems for that case. ... I suggest that you read the patch for the answer to softirq ...
      (Linux-Kernel)
    • Re: better wake-balancing: respin
      ... >>I guess I missed the objection for dropping the patch. ... correlation between the CPU the interrupt arrives on and the CPU the ... There is no point in immediate balancing either: ... If this patch hurts other workloads (and please ...
      (Linux-Kernel)
    • Re: Intel DG31PR and RTL8168/8111 issue
      ... The previous patch you used may have problems on multicast filtering. ... CPU supports Enhanced Speedstep, ... <ACPI PCI bus> on pcib0 ... hwrev = 38400000 ...
      (freebsd-stable)
    • Re: [PATCH] AMD Thermal Interrupt Support
      ... I'll add a robust description with the next revision of the patch. ... My buddy at Google suggested that I might as well fix this while I'm ... the throttling MCEs which you might naturally expect to see ... if you're expecting to be warned at 50C that your CPU has ...
      (Linux-Kernel)
    • Re: better wake-balancing: respin
      ... >>a patch may not be the right way to go. ... > correlation between the CPU the interrupt arrives on and the CPU the ... There is no point in immediate balancing either: ... > in such a workload, my patch will clearly improve things, by not ...
      (Linux-Kernel)