Problem with XP scheduler?
in [Win32 Kernel]
|
From: tanix on 28 Dec 2009 23:41 In article <O9u0FFDiKHA.5380(a)TK2MSFTNGP06.phx.gbl>, "Boba" <Boba(a)somewhere.net> wrote: >"Leo Davidson" <leonudeldavidson(a)googlemail.com> wrote in message >news:3471eff1-3a57-417a-be18-4603a05004df(a)b2g2000yqi.googlegroups.com... >>On Dec 24, 9:31 pm, "Boba" <B...(a)somewhere.net> wrote: >>> no. im'saying it is ford motor co.s' resposibility to >> >>But you said "Windows is not a proper multitasking OS" Is it? >I did not say that (though I do partially agree with that). >Boba TC. > > -- 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: Tim Roberts on 29 Dec 2009 00:32 Grzegorz Wr�bel </dev/null(a)localhost.localdomain> wrote: >Tim Roberts wrote: >> >> Get real. A software problem cannot cause your machine to lock up so hard >> that even mouse and keyboard stop. > >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. No. A user mode app can certainly prevent other user mode apps from processing mouse and keyboard input, yes, but the mouse pointer keeps moving, and pressing the caps lock key still toggles the caps lock indicator. Stopping those requires the "assistance" of kernel code. -- Tim Roberts, timr(a)probo.com Providenza & Boekelheide, Inc.
From: tanix on 29 Dec 2009 03:09 In article <uv4jj555v1pdnvb08m63mcmqvg5lpa560g(a)4ax.com>, Tim Roberts <timr(a)probo.com> wrote: >Grzegorz Wr�bel </dev/null(a)localhost.localdomain> wrote: > >>Tim Roberts wrote: >>> >>> Get real. A software problem cannot cause your machine to lock up so hard >>> that even mouse and keyboard stop. >> >>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. > >No. A user mode app can certainly prevent other user mode apps from >processing mouse and keyboard input, yes, but the mouse pointer keeps >moving, and pressing the caps lock key still toggles the caps lock >indicator. Stopping those requires the "assistance" of kernel code. That's the whole point here. Again, mouse is the highest priority anything in windows architecture as far as anything physical is concerned, and it is ran by the kernel. It could, or rather should, care less what app is doing what. It was interesting to observe that I had task manager running to see what happens when mouse freezes, and it was a shocker to see that after mouse freezes, one of 4 cores was loaded 100% on firefox 3.5.5, and 3 cores went to 100% load with ff 3.5.6. BUT. The task manager kept updating the CPU history windows. So the kernel WAS in fact running. It was not a crash. -- 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 29 Dec 2009 03:08 "Paul Baker [MVP, Windows Desktop Experience]" wrote... > > I now find myself amused by phrase "the user would be presented with a > system that appears to have crashed". There's a big difference between > appearing to crash and crashing :) Especially with a server that can > do all kinds of non-interactive things without ever needing an > interactive session! Some lines in that whitepaper sound very carefully worded, indeed ;-) Server scenarios aside, I believe the same caveat would apply nowadays to standalone workstations with fast user switching enabled and multiple active sessions. Liviu
From: Liviu on 29 Dec 2009 03:09
"tanix" <tanix(a)mongo.net> wrote... > In article <ObYOMm$hKHA.5020(a)TK2MSFTNGP02.phx.gbl>, "Liviu" > <lab2k1(a)gmail.c0m> wrote: >>"Tim Roberts" <timr(a)probo.com> wrote... >> >>> The likely issues are [...] (2) graphics driver problem, > > I doubt, but who knows. Just the fact that nothing else causes > this kind of lockup does not mean it is certainly not a graphics > driver, although I have my doubts. As I said, one step to check that theory would be to run the stock SVGA driver and try to duplicate the problem. In addition to Tim's shortlist of suspects, I'd also suggest (4) overclocking and (5) overloading the power supply. > To me, these kinds of lockups are so common that to call windows > a fully multitasking OS is not only a joke. It is pathetic. To me, those kind of lockups are virtually absent. Can't honestly remember the last time I had to use the hard reset button. YMMV and apparently does. Yet, that doesn't automatically make it OS's fault. Liviu |