Problem with XP scheduler?
in [Win32 Kernel]
|
From: tanix on 28 Dec 2009 16:51 In article <ObYOMm$hKHA.5020(a)TK2MSFTNGP02.phx.gbl>, "Liviu" <lab2k1(a)gmail.c0m> wrote: >"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, Not in my cases. Tested that thing for 20 hrs. >> (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. >> or (3) USB controller problem (if you have USB mouse). Did not think of that one. Except I'd assume the standard driver OS driver is used. >#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). Well, if it is just a local session, that is another story. >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. Would not be surprised at all. 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. >Liviu > > -- 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: Paul Baker [MVP, Windows Desktop Experience] on 28 Dec 2009 16:51 Liviu, The argument put forth in this article that the same potential for unreliability caused by bad graphics drivers existed before the change is weak: "the Win32 server process is considered a critical system component of Windows NT 3.51, such that if the CSRSS.EXE process faults the entire Windows NT operating system is shutdown." "[...] However, from the user's point of view, that potential to disrupt the system has always existed. If the GDI process in Windows NT 3.51 should fail for any reason, the user would be presented with a system that appears to have crashed. The fact that the kernel is still operating is invisible to the user, because it simply appears that the system is not responding.". I much prefer your argument, thanks for sharing: "[...] in NT3.x a GDI bug alone could not bring down a server (though it could still freeze its local interactive session).". The phrase "is considered" is particularly interesting. It is as if whoever wrote it knows it is more of a considered opinion than a fact. The article would, in my mind, come across as more "honest" if it fully disclosed the risk and explained that the risk is justified. You can work with (babysit) vendors all you want, some of them are going to screw up if not during the transition, then later. Unfortunately, bad software is common, even in critical drivers. Paul "Liviu" <lab2k1(a)gmail.c0m> wrote in message news:ObYOMm$hKHA.5020(a)TK2MSFTNGP02.phx.gbl... > "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 > >
From: Paul Baker [MVP, Windows Desktop Experience] on 28 Dec 2009 16:55 Liviu, I know it's probably not good for me to follow up my own post but... 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! Paul "Paul Baker [MVP, Windows Desktop Experience]" <paulrichardbaker(a)community.nospam> wrote in message news:ORMQhfAiKHA.1536(a)TK2MSFTNGP06.phx.gbl... > Liviu, > > The argument put forth in this article that the same potential for > unreliability caused by bad graphics drivers existed before the change is > weak: > > "the Win32 server process is considered a critical system component of > Windows NT 3.51, such that if the CSRSS.EXE process faults the entire > Windows NT operating system is shutdown." > > "[...] However, from the user's point of view, that potential to disrupt > the system has always existed. If the GDI process in Windows NT 3.51 > should fail for any reason, the user would be presented with a system that > appears to have crashed. The fact that the kernel is still operating is > invisible to the user, because it simply appears that the system is not > responding.". > > I much prefer your argument, thanks for sharing: > > "[...] in NT3.x a GDI bug alone could not bring down a server (though it > could still freeze its local interactive session).". > > The phrase "is considered" is particularly interesting. It is as if > whoever wrote it knows it is more of a considered opinion than a fact. > > The article would, in my mind, come across as more "honest" if it fully > disclosed the risk and explained that the risk is justified. You can work > with (babysit) vendors all you want, some of them are going to screw up if > not during the transition, then later. Unfortunately, bad software is > common, even in critical drivers. > > Paul > > "Liviu" <lab2k1(a)gmail.c0m> wrote in message > news:ObYOMm$hKHA.5020(a)TK2MSFTNGP02.phx.gbl... >> "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 >> >> > >
From: Alexander Grigoriev on 28 Dec 2009 19:14 With the modern servers, if you control it through remote desktop, as it's often done, you don't depend on any buggy driver running on it. Actually, starting with 2008, Windows server simply uses a generic SVGA driver. "Paul Baker [MVP, Windows Desktop Experience]" <paulrichardbaker(a)community.nospam> wrote in message news:uzVbAiAiKHA.2188(a)TK2MSFTNGP04.phx.gbl... > Liviu, > > I know it's probably not good for me to follow up my own post but... > > 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! > > Paul >
From: Boba on 28 Dec 2009 21:47
"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" I did not say that (though I do partially agree with that). Boba TC. |