Problem with XP scheduler?
in [Win32 Kernel]
|
From: Grzegorz Wróbel on 27 Dec 2009 10:55 tanix wrote: >> >> Get rational. User mode app can lock up mouse and keyboard just by >> starving system processes that manage mouse and keyboard input. On the >> single CPU/core machines it was very common to happen. On the multi core >> machines much less likely to happen "naturally", but still possible. > > That means your OS is not trully multitasking. > Not really. It means only it doesn't have efficient mechanisms that prevents process starvation (like aging low priority processes so they could eventually get CPU time). Windows manage priorities only for processes with base priority in range 1-15. So any CPU extensive process with base priority between 16 and 31 can starve lower priority process. But these "real time" priorities should be used with care and in very special cases only. Now, this is true that on Windows having multiple CPU extensive, normal priority processes can have negative impact on mouse, keyboard and GUI response (especially on single CPU machines). I haven't been able to observe the same on linux/unix machines, which could indicate the multitasking architecture is though up better there. That's also probably the reason why many people who used linux feel that Windows is not "truly multitasking". But technically speaking such statement is not correct. -- Grzegorz Wr�bel 677265676F727940346E6575726F6E732E636F6D
From: tanix on 27 Dec 2009 17:33 In article <hh8056$q39$1(a)atlantis.news.neostrada.pl>, =?ISO-8859-1?Q?Grzegorz_Wr=F3bel?= </dev/null(a)localhost.localdomain> wrote: >tanix wrote: >>> >>> Get rational. User mode app can lock up mouse and keyboard just by >>> starving system processes that manage mouse and keyboard input. On the >>> single CPU/core machines it was very common to happen. On the multi core >>> machines much less likely to happen "naturally", but still possible. >> >> That means your OS is not trully multitasking. >> > >Not really. It means only it doesn't have efficient mechanisms that >prevents process starvation (like aging low priority processes so they >could eventually get CPU time). Windows manage priorities only for >processes with base priority in range 1-15. > >So any CPU extensive process with base priority between 16 and 31 can >starve lower priority process. But these "real time" priorities should >be used with care and in very special cases only. > > >Now, this is true that on Windows having multiple CPU extensive, normal >priority processes can have negative impact on mouse, keyboard and GUI >response (especially on single CPU machines). I haven't been able to >observe the same on linux/unix machines, which could indicate the >multitasking architecture is though up better there. That's also >probably the reason why many people who used linux feel that Windows is >not "truly multitasking". > >But technically speaking such statement is not correct. Well, I actually saw an article some time ago that specifically described the whys of windows not being a multitasking OS. I think it is not a particle science to be able to find this or plenty of other articles if you spend a few minutes on it. Except I have no interest. It is just conceptually clear that if your OS can be locked up by some process, no matter what it is, then your machine becomes unusable, which is utterly unacceptable from the standpoint of security at least. Basically, my original question on this thread was just to estimate where is the problem and not necessarily try to identify the exact issue because it looks to me it is going to take hours if not days, and the payoff at the end, even if I manage to find it, is probably zero. Because no one is going to bother with XP and the chance of it getting fixed, even if they know exactly what the issue is is also pretty close to zero. Basically, since it is a new box, first of all, I want to make sure it is not a hardware issue and I end up with a crappy box. If it IS a firefox problem, and it does get under my skin, I can just switch to a different browser. Not the end of the world. If someone does know about this issue and if there is a solution, and it does have something to do with xp scheduler, then I'd like to know if there is a fix for this. That is ALL I am after. The box does not lock up with any other apps so far, and it has been at least a month in a pretty heavy duty use. So.... So far so good. -- Programmer's Goldmine collections: http://preciseinfo.org Tens of thousands of code examples and expert discussions on C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript, organized by major topics of language, tools, methods, techniques.
From: Grzegorz Wróbel on 28 Dec 2009 04:22 tanix wrote: > If it IS a firefox problem, and it does get under my skin, > I can just switch to a different browser. Not the end of the world. > Get an older version of Firefox, like 2.0 and see if it crashes/locks your Xp. If it doesn't you can assume the problem is Firefox 3.x related. I have experienced myself that FF 3.5x is much less stable than older 2.0 version. -- Grzegorz Wr�bel 677265676F727940346E6575726F6E732E636F6D
From: tanix on 28 Dec 2009 06:02 In article <hh9tvc$lmc$1(a)nemesis.news.neostrada.pl>, =?ISO-8859-1?Q?Grzegorz_Wr=F3bel?= </dev/null(a)localhost.localdomain> wrote: >tanix wrote: >> If it IS a firefox problem, and it does get under my skin, >> I can just switch to a different browser. Not the end of the world. >> > >Get an older version of Firefox, like 2.0 and see if it crashes/locks >your Xp. If it doesn't you can assume the problem is Firefox 3.x related. > >I have experienced myself that FF 3.5x is much less stable than older >2.0 version. Could be. Not that I think 2.x was that stable to begin with. Except starting from 3.x, the rendering performance is much better. I am just not sure if I am going create a grand headache if I try to install an older version and then go back to the latest version. -- Programmer's Goldmine collections: http://preciseinfo.org Tens of thousands of code examples and expert discussions on C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript, organized by major topics of language, tools, methods, techniques.
From: Liviu on 28 Dec 2009 15:06
"Tim Roberts" <timr(a)probo.com> wrote... > tanix(a)mongo.net (tanix) wrote: >> >>What happens is box totally freezes [...] > > Get real. A software problem cannot cause your machine to lock up > so hard that even mouse and keyboard stop. True, of course (for user-mode software). > The likely issues are (1) RAM problem, (2) graphics driver problem, > or (3) USB controller problem (if you have USB mouse). #2 and #3 can be verified/eliminated by trying to duplicate the issue with MS's stock video/usb/mouse drivers. FWIW as a historical footnote, the chance of a buggy graphics driver bringing down the entire system was increased after the NT4 decision to move most graphics to kernel mode as a "privileged" Win32 subsystem. While the whitepaper at http://technet.microsoft.com/en-us/library/cc750820.aspx does a good job to describe (and defend) the design decision, fact remains that in NT3.x a GDI bug alone could not bring down a server (though it could still freeze its local interactive session). As for the speed gains delivered by that change, they have been spent many times over since, on the later themes, effects and other gimmicks. Liviu |