If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
SP2 865/875 Microcode Industry Failure?
A very interesting thing has come up regarding SP2 and the motherboard
industry in general. An anomaly was detected in the installation of XP SP2 on Intel 865/875 chipset mobos. After SP2 install most all such mobos from most all mfgs would HANG on reboot. See this post in: microsoft.public.windowsxp.general http://www.google.com/groups?q=+%22c...phx.gbl&rnum=1 An MVP there Cari had detected the issue and was pursuing it with MS and Intel. Current Intel CPUs have the ability to have their internal microcode updated on the fly(addenda fixed). Apparently that microcode update is done both by the mobo's BIOS during POST and during OS init by %windir%\system32\drivers\update.sys. What was determined is that MOST all the major mobo mfgs around are NOT keeping their microcode current, at least for 865/875 chipset mobos, even with recent BIOS updates! That old CPU microcode(non-existent BIOS microcode update apparently in many cases[=0]) was causing SP2 to hang after install. One can view/report that microcode revision level by running Intel's Frequency ID utility. The entry to look for is "CPU Revision = n" where n = 0 which is the microcode revision level. Cari's conclusion as apparently gleaned from MS & Intel was that NO major mobo mfg has been keeping their microcode(addenda) current EXCEPT Intel. Cari claimed to have tried a broad range of 865 and 875 chipset mobos with SP2 and most all failed! She then said that she'd never use anything except an Intel mfged mobo again as if after her eureka moment. Does anyone know more precise details of the overall technology involved here and the overall industry competence with respect to CPU microcode updates. What is the BIOS supposed to be doing here; is there any standard? What does %windir%\system32\drivers\update.sys do exactly? The implication is that most all of us 865/875 chipset mobo owners (and I assume that the issue is MUCH WIDER) have been running with all the CPU bugs/addenda UNFIXED! |
#2
|
|||
|
|||
In article ,
"Ron Reaugh" wrote: A very interesting thing has come up regarding SP2 and the motherboard industry in general. An anomaly was detected in the installation of XP SP2 on Intel 865/875 chipset mobos. After SP2 install most all such mobos from most all mfgs would HANG on reboot. See this post in: microsoft.public.windowsxp.general http://www.google.com/groups?q=+%22c...phx.gbl&rnum=1 An MVP there Cari had detected the issue and was pursuing it with MS and Intel. Current Intel CPUs have the ability to have their internal microcode updated on the fly(addenda fixed). Apparently that microcode update is done both by the mobo's BIOS during POST and during OS init by %windir%\system32\drivers\update.sys. What was determined is that MOST all the major mobo mfgs around are NOT keeping their microcode current, at least for 865/875 chipset mobos, even with recent BIOS updates! That old CPU microcode(non-existent BIOS microcode update apparently in many cases[=0]) was causing SP2 to hang after install. One can view/report that microcode revision level by running Intel's Frequency ID utility. The entry to look for is "CPU Revision = n" where n = 0 which is the microcode revision level. Cari's conclusion as apparently gleaned from MS & Intel was that NO major mobo mfg has been keeping their microcode(addenda) current EXCEPT Intel. Cari claimed to have tried a broad range of 865 and 875 chipset mobos with SP2 and most all failed! She then said that she'd never use anything except an Intel mfged mobo again as if after her eureka moment. Does anyone know more precise details of the overall technology involved here and the overall industry competence with respect to CPU microcode updates. What is the BIOS supposed to be doing here; is there any standard? What does %windir%\system32\drivers\update.sys do exactly? The implication is that most all of us 865/875 chipset mobo owners (and I assume that the issue is MUCH WIDER) have been running with all the CPU bugs/addenda UNFIXED! I don't know why this issue is blown all out of proportion. It is like the second coming or something. If an OS is so dependent on microcode being correct, a fairly simple algorithm and small file of microcode segments would fix it. Microsoft should consider moving the microcode loader up in their boot sequence, like before some other kernel files are loaded. Inside an Asus BIOS, there is a file called cpucode.exe and it will consist of perhaps 8 or so 2KB microcode segments. Apparently, at least in some of the older BIOS, there were also a couple of 2KB "cache segments" in the flash chip as well, and if a new processor is detected, the microcode segment that loads successfully, is stored in one of the two cache segments. The BIOS effectively has to "flash itself", and contains the code to do that. There is actually a procedure for Award BIOS, where a user can "write" the cache segment with their own Prescott 2KB code segment, if they want to. (I have done this on a P2B-S, to get microcode support for a Tualatin.) The program is called CTMC from CT Heise magazine. In other words, for the initiated, they can actually prep their BIOS to be "SP2 ready" if they want to, without waiting for Asus (AFAIK works for Award BIOS, no idea if it works for AMI, as the hook and methodology of the AMI BIOS could be different). Asus updates BIOS files on a fairly regular basis. One user here owns a T2-P Asus small form factor system, and while the Asus cpusupport page doesn't currently list his system, he claims it supports Prescott or the advert copy says it supports Prescott. When I extracted the file of microcode segments for the most recent version of that BIOS, there were no Prescott family code segments in the file. So, indeed, in that case, support was lacking. Other users here who have had "SP2 trouble", aren't running the latest BIOS, so the solution there is clear. To keep all these BIOS updated to cover the latest Intel inprovements, means there will always be a gulf between the latest released microcode segments and what is available for download from Asus. I'm sure when a new processor is released at Intel, it even takes Intel a day or two to update their BIOS files, so Cari shouldn't be too smug sitting on an Intel motherboard. And finally, there is probably a small number of users who have stuffed Prescott processors in non-Prescott boards, and whatever happens, is of their own making. If your old motherboard lists Northwood 0.13u processor support, that is what you should be buying for it. Seeing as microcode loading existed in my 440BX based P2B-S motherboard, I would say the "industry competence" is there. HTH, Paul |
#3
|
|||
|
|||
Complicating the issue even more is the way all kinds of stuff you
probably don't want often gets stuffed into new versions of BIOSen (I've seen people report their Promise Raid drives disappeared when they updated BIOS to a new version). Just more proof that microcode updates belong in the kernel, not the BIOS... -- == The *Best* political site URL:http://www.vote-smart.org/ ==+ email: icbm: Delray Beach, FL | URL:http://home.att.net/~Tom.Horsley Free Software and Politics ==+ |
#4
|
|||
|
|||
"Ron Reaugh" wrote in message ... A very interesting thing has come up regarding SP2 and the motherboard industry in general. An anomaly was detected in the installation of XP SP2 on Intel 865/875 chipset mobos. After SP2 install most all such mobos from most all mfgs would HANG on reboot. Answered in another group - You cross posting, multi posting, don't have a life, freak. |
#5
|
|||
|
|||
"Paul" wrote in message ... In article , "Ron Reaugh" wrote: A very interesting thing has come up regarding SP2 and the motherboard industry in general. An anomaly was detected in the installation of XP SP2 on Intel 865/875 chipset mobos. I FAILED to mention in my opening post that all this is only when using a Prescott CPU. After SP2 install most all such mobos from most all mfgs would HANG on reboot. See this post in: microsoft.public.windowsxp.general http://www.google.com/groups?q=+%22c...phx.gbl&rnum=1 An MVP there Cari had detected the issue and was pursuing it with MS and Intel. Current Intel CPUs have the ability to have their internal microcode updated on the fly(addenda fixed). Apparently that microcode update is done both by the mobo's BIOS during POST and during OS init by %windir%\system32\drivers\update.sys. What was determined is that MOST all the major mobo mfgs around are NOT keeping their microcode current, at least for 865/875 chipset mobos, even with recent BIOS updates! That old CPU microcode(non-existent BIOS microcode update apparently in many cases[=0]) was causing SP2 to hang after install. One can view/report that microcode revision level by running Intel's Frequency ID utility. The entry to look for is "CPU Revision = n" where n = 0 which is the microcode revision level. Cari's conclusion as apparently gleaned from MS & Intel was that NO major mobo mfg has been keeping their microcode(addenda) current EXCEPT Intel. Cari claimed to have tried a broad range of 865 and 875 chipset mobos with SP2 and most all failed! She then said that she'd never use anything except an Intel mfged mobo again as if after her eureka moment. Does anyone know more precise details of the overall technology involved here and the overall industry competence with respect to CPU microcode updates. What is the BIOS supposed to be doing here; is there any standard? What does %windir%\system32\drivers\update.sys do exactly? The implication is that most all of us 865/875 chipset mobo owners (and I assume that the issue is MUCH WIDER) have been running with all the CPU bugs/addenda UNFIXED! I don't know why this issue is blown all out of proportion. It is an issue that is not well known which is why I'm trying to find more details and also see what folks know in general. It is like the second coming or something. If an OS is so dependent on microcode being correct, a fairly simple algorithm and small file of microcode segments would fix it. Well then what does this do in XP? %windir%\system32\drivers\update.sys Microsoft should consider moving the microcode loader up in their boot sequence, like before some other kernel files are loaded. I got the impression that there was some condition precedent required in the BIOS and that's why %windir%\system32\drivers\update.sys didn't work and the fix was to rename update.sys ??? Please clarify. Inside an Asus BIOS, there is a file called cpucode.exe and it will consist of perhaps 8 or so 2KB microcode segments. Apparently, at least in some of the older BIOS, there were also a couple of 2KB "cache segments" in the flash chip as well, and if a new processor is detected, the microcode segment that loads successfully, is stored in one of the two cache segments. The BIOS effectively has to "flash itself", and contains the code to do that. There is actually a procedure for Award BIOS, where a user can "write" the cache segment with their own Prescott 2KB code segment, if they want to. (I have done this on a P2B-S, to get microcode support for a Tualatin.) The program is called CTMC from CT Heise magazine. In other words, for the initiated, they can actually prep their BIOS to be "SP2 ready" if they want to, without waiting for Asus (AFAIK works for Award BIOS, no idea if it works for AMI, as the hook and methodology of the AMI BIOS could be different). Asus updates BIOS files on a fairly regular basis. One user here owns a T2-P Asus small form factor system, and while the Asus cpusupport page doesn't currently list his system, he claims it supports Prescott or the advert copy says it supports Prescott. When I extracted the file of microcode segments for the most recent version of that BIOS, there were no Prescott family code segments in the file. So, indeed, in that case, support was lacking. Other users here who have had "SP2 trouble", aren't running the latest BIOS, so the solution there is clear. To keep all these BIOS updated to cover the latest Intel inprovements, means there will always be a gulf between the latest released microcode segments and what is available for download from Asus. Prescotts were shipping in March. I'm sure when a new processor is released at Intel, it even takes Intel a day or two to update their BIOS files, so Cari shouldn't be too smug sitting on an Intel motherboard. And finally, there is probably a small number of users who have stuffed Prescott processors in non-Prescott boards, and whatever happens, is of their own making. If your old motherboard lists Northwood 0.13u processor support, that is what you should be buying for it. Seeing as microcode loading existed in my 440BX based P2B-S motherboard, I would say the "industry competence" is there. Well, the question is whether the appropriate microcode is getting out in a timely fashion and how users are able to easily know what microcode level is right. It also apparently isn't a one time thing but updates continue to be made available by Intel. It appears that most the major mobo mfgs missed this one for the 865/875+Prescott+SP2 release. It wasn't like nobody new SP2 was coming in August. There appears to have been a mobo industry wide(save Intel) collapse on this issue. There is also some evidence that MS did little regarding a headsup to them or its users as this issue was reported in June(over 40 days before SP2 RTM). From your read of the issue how does the rename of %windir%\system32\drivers\update.sys temporarily fix the issue?? |
#6
|
|||
|
|||
To say that "most all motherboards from most all manufacturers" hang on SP2
installation is absurd. We've installed fifty-three or fifty-four SP2 upgrades on ASUS, ABIT as well as Intel 865 & 875 boards without a single failure. Why people believe these wild tales is beyond me -- as though months of beta testing wouldn't have revealed that problem instantly. (We don't have any Prescott processors, and there may be a problem there on some machines as I understand it.) Good wishes to all. formerprof "Ron Reaugh" wrote in message ... A very interesting thing has come up regarding SP2 and the motherboard industry in general. An anomaly was detected in the installation of XP SP2 on Intel 865/875 chipset mobos. After SP2 install most all such mobos from most all mfgs would HANG on reboot. See this post in: microsoft.public.windowsxp.general http://www.google.com/groups?q=+%22c...phx.gbl&rnum=1 An MVP there Cari had detected the issue and was pursuing it with MS and Intel. Current Intel CPUs have the ability to have their internal microcode updated on the fly(addenda fixed). Apparently that microcode update is done both by the mobo's BIOS during POST and during OS init by %windir%\system32\drivers\update.sys. What was determined is that MOST all the major mobo mfgs around are NOT keeping their microcode current, at least for 865/875 chipset mobos, even with recent BIOS updates! That old CPU microcode(non-existent BIOS microcode update apparently in many cases[=0]) was causing SP2 to hang after install. One can view/report that microcode revision level by running Intel's Frequency ID utility. The entry to look for is "CPU Revision = n" where n = 0 which is the microcode revision level. Cari's conclusion as apparently gleaned from MS & Intel was that NO major mobo mfg has been keeping their microcode(addenda) current EXCEPT Intel. Cari claimed to have tried a broad range of 865 and 875 chipset mobos with SP2 and most all failed! She then said that she'd never use anything except an Intel mfged mobo again as if after her eureka moment. Does anyone know more precise details of the overall technology involved here and the overall industry competence with respect to CPU microcode updates. What is the BIOS supposed to be doing here; is there any standard? What does %windir%\system32\drivers\update.sys do exactly? The implication is that most all of us 865/875 chipset mobo owners (and I assume that the issue is MUCH WIDER) have been running with all the CPU bugs/addenda UNFIXED! |
#7
|
|||
|
|||
"Formerprof" wrote in message ... To say that "most all motherboards from most all manufacturers" hang on SP2 installation is absurd. QUITE RIGHT...but they DO HANG using a Prescott. I FAILED to mention that littel detail but have since corrected that error. We've installed fifty-three or fifty-four SP2 upgrades on ASUS, ABIT as well as Intel 865 & 875 boards without a single failure. Why people believe these wild tales is beyond me -- as though months of beta testing wouldn't have revealed that problem instantly. (We don't have any Prescott processors, and there may be a problem there on some machines as I understand it.) Good wishes to all. formerprof "Ron Reaugh" wrote in message ... A very interesting thing has come up regarding SP2 and the motherboard industry in general. An anomaly was detected in the installation of XP SP2 on Intel 865/875 chipset mobos. After SP2 install most all such mobos from most all mfgs would HANG on reboot. See this post in: microsoft.public.windowsxp.general http://www.google.com/groups?q=+%22c...phx.gbl&rnum=1 An MVP there Cari had detected the issue and was pursuing it with MS and Intel. Current Intel CPUs have the ability to have their internal microcode updated on the fly(addenda fixed). Apparently that microcode update is done both by the mobo's BIOS during POST and during OS init by %windir%\system32\drivers\update.sys. What was determined is that MOST all the major mobo mfgs around are NOT keeping their microcode current, at least for 865/875 chipset mobos, even with recent BIOS updates! That old CPU microcode(non-existent BIOS microcode update apparently in many cases[=0]) was causing SP2 to hang after install. One can view/report that microcode revision level by running Intel's Frequency ID utility. The entry to look for is "CPU Revision = n" where n = 0 which is the microcode revision level. Cari's conclusion as apparently gleaned from MS & Intel was that NO major mobo mfg has been keeping their microcode(addenda) current EXCEPT Intel. Cari claimed to have tried a broad range of 865 and 875 chipset mobos with SP2 and most all failed! She then said that she'd never use anything except an Intel mfged mobo again as if after her eureka moment. Does anyone know more precise details of the overall technology involved here and the overall industry competence with respect to CPU microcode updates. What is the BIOS supposed to be doing here; is there any standard? What does %windir%\system32\drivers\update.sys do exactly? The implication is that most all of us 865/875 chipset mobo owners (and I assume that the issue is MUCH WIDER) have been running with all the CPU bugs/addenda UNFIXED! |
#8
|
|||
|
|||
I had BIOS 1016 on a P4C800-E Dlx and the Intel Frequency ID app showed
CPU Revision = 7. 7 was reported with both the boot floppy version and the XP version underp XP SP1(one). I have now flashed BIOS 1017. The build date as shown inside BIOS setup on the Information Screen 7/24/04. The Intel Frequency ID app continues to show CPU Revision = 7 using the boot floppy version of the Intel app AND using the XP version under XP SP1(one). Yet as cited in the MS XP NG article below, what is supposed to be there is "at least 8". Now if it's supposed to be 8 and apparently it is 8 on Intel mfg mobos then why isn't 8 here in this recent release Asus BIOS? The industry failure and/or competence level may be a version issue and not a there/not there issue. Anyone? "Ron Reaugh" wrote in message ... "Paul" wrote in message ... In article , "Ron Reaugh" wrote: A very interesting thing has come up regarding SP2 and the motherboard industry in general. An anomaly was detected in the installation of XP SP2 on Intel 865/875 chipset mobos. I FAILED to mention in my opening post that all this is only when using a Prescott CPU. After SP2 install most all such mobos from most all mfgs would HANG on reboot. See this post in: microsoft.public.windowsxp.general http://www.google.com/groups?q=+%22c...phx.gbl&rnum=1 An MVP there Cari had detected the issue and was pursuing it with MS and Intel. Current Intel CPUs have the ability to have their internal microcode updated on the fly(addenda fixed). Apparently that microcode update is done both by the mobo's BIOS during POST and during OS init by %windir%\system32\drivers\update.sys. What was determined is that MOST all the major mobo mfgs around are NOT keeping their microcode current, at least for 865/875 chipset mobos, even with recent BIOS updates! That old CPU microcode(non-existent BIOS microcode update apparently in many cases[=0]) was causing SP2 to hang after install. One can view/report that microcode revision level by running Intel's Frequency ID utility. The entry to look for is "CPU Revision = n" where n = 0 which is the microcode revision level. Cari's conclusion as apparently gleaned from MS & Intel was that NO major mobo mfg has been keeping their microcode(addenda) current EXCEPT Intel. Cari claimed to have tried a broad range of 865 and 875 chipset mobos with SP2 and most all failed! She then said that she'd never use anything except an Intel mfged mobo again as if after her eureka moment. Does anyone know more precise details of the overall technology involved here and the overall industry competence with respect to CPU microcode updates. What is the BIOS supposed to be doing here; is there any standard? What does %windir%\system32\drivers\update.sys do exactly? The implication is that most all of us 865/875 chipset mobo owners (and I assume that the issue is MUCH WIDER) have been running with all the CPU bugs/addenda UNFIXED! I don't know why this issue is blown all out of proportion. It is an issue that is not well known which is why I'm trying to find more details and also see what folks know in general. It is like the second coming or something. If an OS is so dependent on microcode being correct, a fairly simple algorithm and small file of microcode segments would fix it. Well then what does this do in XP? %windir%\system32\drivers\update.sys Microsoft should consider moving the microcode loader up in their boot sequence, like before some other kernel files are loaded. I got the impression that there was some condition precedent required in the BIOS and that's why %windir%\system32\drivers\update.sys didn't work and the fix was to rename update.sys ??? Please clarify. Inside an Asus BIOS, there is a file called cpucode.exe and it will consist of perhaps 8 or so 2KB microcode segments. Apparently, at least in some of the older BIOS, there were also a couple of 2KB "cache segments" in the flash chip as well, and if a new processor is detected, the microcode segment that loads successfully, is stored in one of the two cache segments. The BIOS effectively has to "flash itself", and contains the code to do that. There is actually a procedure for Award BIOS, where a user can "write" the cache segment with their own Prescott 2KB code segment, if they want to. (I have done this on a P2B-S, to get microcode support for a Tualatin.) The program is called CTMC from CT Heise magazine. In other words, for the initiated, they can actually prep their BIOS to be "SP2 ready" if they want to, without waiting for Asus (AFAIK works for Award BIOS, no idea if it works for AMI, as the hook and methodology of the AMI BIOS could be different). Asus updates BIOS files on a fairly regular basis. One user here owns a T2-P Asus small form factor system, and while the Asus cpusupport page doesn't currently list his system, he claims it supports Prescott or the advert copy says it supports Prescott. When I extracted the file of microcode segments for the most recent version of that BIOS, there were no Prescott family code segments in the file. So, indeed, in that case, support was lacking. Other users here who have had "SP2 trouble", aren't running the latest BIOS, so the solution there is clear. To keep all these BIOS updated to cover the latest Intel inprovements, means there will always be a gulf between the latest released microcode segments and what is available for download from Asus. Prescotts were shipping in March. I'm sure when a new processor is released at Intel, it even takes Intel a day or two to update their BIOS files, so Cari shouldn't be too smug sitting on an Intel motherboard. And finally, there is probably a small number of users who have stuffed Prescott processors in non-Prescott boards, and whatever happens, is of their own making. If your old motherboard lists Northwood 0.13u processor support, that is what you should be buying for it. Seeing as microcode loading existed in my 440BX based P2B-S motherboard, I would say the "industry competence" is there. Well, the question is whether the appropriate microcode is getting out in a timely fashion and how users are able to easily know what microcode level is right. It also apparently isn't a one time thing but updates continue to be made available by Intel. It appears that most the major mobo mfgs missed this one for the 865/875+Prescott+SP2 release. It wasn't like nobody new SP2 was coming in August. There appears to have been a mobo industry wide(save Intel) collapse on this issue. There is also some evidence that MS did little regarding a headsup to them or its users as this issue was reported in June(over 40 days before SP2 RTM). From your read of the issue how does the rename of %windir%\system32\drivers\update.sys temporarily fix the issue?? |
#9
|
|||
|
|||
"Ron Reaugh" wrote in message ... I had BIOS 1016 on a P4C800-E Dlx and the Intel Frequency ID app showed CPU Revision = 7. 7 was reported with both the boot floppy version and the XP version underp XP SP1(one). I have now flashed BIOS 1017. The build date as shown inside BIOS setup on the Information Screen 7/24/04. Correction 7/22/04. The Intel Frequency ID app continues to show CPU Revision = 7 using the boot floppy version of the Intel app AND using the XP version under XP SP1(one). Yet as cited in the MS XP NG article below, what is supposed to be there is "at least 8". Now if it's supposed to be 8 and apparently it is 8 on Intel mfg mobos then why isn't 8 here in this recent release Asus BIOS? The industry failure and/or competence level may be a version issue and not a there/not there issue. Anyone? "Ron Reaugh" wrote in message ... "Paul" wrote in message ... In article , "Ron Reaugh" wrote: A very interesting thing has come up regarding SP2 and the motherboard industry in general. An anomaly was detected in the installation of XP SP2 on Intel 865/875 chipset mobos. I FAILED to mention in my opening post that all this is only when using a Prescott CPU. After SP2 install most all such mobos from most all mfgs would HANG on reboot. See this post in: microsoft.public.windowsxp.general http://www.google.com/groups?q=+%22c..._minm=5&as_min y=2004&as_maxd=28&as_maxm=8&as_maxy=2004&selm=eAqp SwjiEHA.2664%40TK2MSFTNGP1 1.phx.gbl&rnum=1 An MVP there Cari had detected the issue and was pursuing it with MS and Intel. Current Intel CPUs have the ability to have their internal microcode updated on the fly(addenda fixed). Apparently that microcode update is done both by the mobo's BIOS during POST and during OS init by %windir%\system32\drivers\update.sys. What was determined is that MOST all the major mobo mfgs around are NOT keeping their microcode current, at least for 865/875 chipset mobos, even with recent BIOS updates! That old CPU microcode(non-existent BIOS microcode update apparently in many cases[=0]) was causing SP2 to hang after install. One can view/report that microcode revision level by running Intel's Frequency ID utility. The entry to look for is "CPU Revision = n" where n = 0 which is the microcode revision level. Cari's conclusion as apparently gleaned from MS & Intel was that NO major mobo mfg has been keeping their microcode(addenda) current EXCEPT Intel. Cari claimed to have tried a broad range of 865 and 875 chipset mobos with SP2 and most all failed! She then said that she'd never use anything except an Intel mfged mobo again as if after her eureka moment. Does anyone know more precise details of the overall technology involved here and the overall industry competence with respect to CPU microcode updates. What is the BIOS supposed to be doing here; is there any standard? What does %windir%\system32\drivers\update.sys do exactly? The implication is that most all of us 865/875 chipset mobo owners (and I assume that the issue is MUCH WIDER) have been running with all the CPU bugs/addenda UNFIXED! I don't know why this issue is blown all out of proportion. It is an issue that is not well known which is why I'm trying to find more details and also see what folks know in general. It is like the second coming or something. If an OS is so dependent on microcode being correct, a fairly simple algorithm and small file of microcode segments would fix it. Well then what does this do in XP? %windir%\system32\drivers\update.sys Microsoft should consider moving the microcode loader up in their boot sequence, like before some other kernel files are loaded. I got the impression that there was some condition precedent required in the BIOS and that's why %windir%\system32\drivers\update.sys didn't work and the fix was to rename update.sys ??? Please clarify. Inside an Asus BIOS, there is a file called cpucode.exe and it will consist of perhaps 8 or so 2KB microcode segments. Apparently, at least in some of the older BIOS, there were also a couple of 2KB "cache segments" in the flash chip as well, and if a new processor is detected, the microcode segment that loads successfully, is stored in one of the two cache segments. The BIOS effectively has to "flash itself", and contains the code to do that. There is actually a procedure for Award BIOS, where a user can "write" the cache segment with their own Prescott 2KB code segment, if they want to. (I have done this on a P2B-S, to get microcode support for a Tualatin.) The program is called CTMC from CT Heise magazine. In other words, for the initiated, they can actually prep their BIOS to be "SP2 ready" if they want to, without waiting for Asus (AFAIK works for Award BIOS, no idea if it works for AMI, as the hook and methodology of the AMI BIOS could be different). Asus updates BIOS files on a fairly regular basis. One user here owns a T2-P Asus small form factor system, and while the Asus cpusupport page doesn't currently list his system, he claims it supports Prescott or the advert copy says it supports Prescott. When I extracted the file of microcode segments for the most recent version of that BIOS, there were no Prescott family code segments in the file. So, indeed, in that case, support was lacking. Other users here who have had "SP2 trouble", aren't running the latest BIOS, so the solution there is clear. To keep all these BIOS updated to cover the latest Intel inprovements, means there will always be a gulf between the latest released microcode segments and what is available for download from Asus. Prescotts were shipping in March. I'm sure when a new processor is released at Intel, it even takes Intel a day or two to update their BIOS files, so Cari shouldn't be too smug sitting on an Intel motherboard. And finally, there is probably a small number of users who have stuffed Prescott processors in non-Prescott boards, and whatever happens, is of their own making. If your old motherboard lists Northwood 0.13u processor support, that is what you should be buying for it. Seeing as microcode loading existed in my 440BX based P2B-S motherboard, I would say the "industry competence" is there. Well, the question is whether the appropriate microcode is getting out in a timely fashion and how users are able to easily know what microcode level is right. It also apparently isn't a one time thing but updates continue to be made available by Intel. It appears that most the major mobo mfgs missed this one for the 865/875+Prescott+SP2 release. It wasn't like nobody new SP2 was coming in August. There appears to have been a mobo industry wide(save Intel) collapse on this issue. There is also some evidence that MS did little regarding a headsup to them or its users as this issue was reported in June(over 40 days before SP2 RTM). From your read of the issue how does the rename of %windir%\system32\drivers\update.sys temporarily fix the issue?? |
#10
|
|||
|
|||
In article ,
"Ron Reaugh" wrote: I had BIOS 1016 on a P4C800-E Dlx and the Intel Frequency ID app showed CPU Revision = 7. 7 was reported with both the boot floppy version and the XP version underp XP SP1(one). I have now flashed BIOS 1017. The build date as shown inside BIOS setup on the Information Screen 7/24/04. The Intel Frequency ID app continues to show CPU Revision = 7 using the boot floppy version of the Intel app AND using the XP version under XP SP1(one). Yet as cited in the MS XP NG article below, what is supposed to be there is "at least 8". Now if it's supposed to be 8 and apparently it is 8 on Intel mfg mobos then why isn't 8 here in this recent release Asus BIOS? The industry failure and/or competence level may be a version issue and not a there/not there issue. Anyone? I have a look at P4C800-E Deluxe 1017 BIOS, and you are correct. The microcode for 0F33 is version 7. I selected the p4p800s_se 1006se BIOS and for 0F33 the version was 9. I think what we are missing here, is what precisely triggers a BIOS update. For Asus, when enough crap piles up, or there are enough complaints, or the larger OEM customers complain, they act. Microcode updates have about the same weight as any other bug in the BIOS. If something else is being fixed, then perhaps during the build, they throw in the latest microcode files they have on hand. Now, imagine an Asus BIOS for a mature board - there are few bugs in the queue for the board, which means even though a microcode update is pending, the priority of issuing an update isn't high enough for that update to get done. Every company has priorities, and Asus puts more energy into fixing the egregious bugs in brand new motherboards, than it does into fixing the BIOS of boards near the tail of their sales curve. (Remember, many Asus boards are released with half-finished BIOS - time to market is everything, and a late introduction kills the profit for the product. Some of the Asus BIOS cannot even read the SPD of the memory DIMMs in their first release, and memory timing uses conservative values, until they can finish the code.) Intel, on the other hand, would probably pride itself on releasing a new BIOS for every board it ever made, every time the microcode changes. But doing so, entails regression testing all those motherboards, at huge expense. I guess who you do business with, depends on who provides the things people want most. The un-overclockable Intel boards don't attract the typical home builder, but for the corporate user depending on corporate features, Intel is probably the way to go. And, when we talk about competence, within the last day or two, there was a guy who flashed up his Asus DLS533 server board to the latest BIOS, and noticed his RAID array was no longer detected by the BIOS. When I looked at the BIOS, a module was missing from the new BIOS, so no code to drive that hardware. Asus does have a quality problem with the BIOS they are releasing - two releases of A7N8X-E BIOS were pulled, I believe due to problems with a module for a particular piece of hardware, and a wild-ass guess is newbie employees are doing builds. This is not the only company I've seen this happen to. I put together an update for a Sun workstation years ago, and found some of the patched applications had been compiled in an insecure manner, a newbie mistake that with the availability of build scripts, is inexcusable. To me, this indicates that regression testing of these BIOS is slipping, for stuff like this to get through. Putting it all in perspective, the microcode situation is just a small part of the overall picture. Paul "Ron Reaugh" wrote in message ... "Paul" wrote in message ... In article , "Ron Reaugh" wrote: A very interesting thing has come up regarding SP2 and the motherboard industry in general. An anomaly was detected in the installation of XP SP2 on Intel 865/875 chipset mobos. I FAILED to mention in my opening post that all this is only when using a Prescott CPU. After SP2 install most all such mobos from most all mfgs would HANG on reboot. See this post in: microsoft.public.windowsxp.general http://www.google.com/groups?q=+%22c...phx.gbl&rnum=1 An MVP there Cari had detected the issue and was pursuing it with MS and Intel. Current Intel CPUs have the ability to have their internal microcode updated on the fly(addenda fixed). Apparently that microcode update is done both by the mobo's BIOS during POST and during OS init by %windir%\system32\drivers\update.sys. What was determined is that MOST all the major mobo mfgs around are NOT keeping their microcode current, at least for 865/875 chipset mobos, even with recent BIOS updates! That old CPU microcode(non-existent BIOS microcode update apparently in many cases[=0]) was causing SP2 to hang after install. One can view/report that microcode revision level by running Intel's Frequency ID utility. The entry to look for is "CPU Revision = n" where n = 0 which is the microcode revision level. Cari's conclusion as apparently gleaned from MS & Intel was that NO major mobo mfg has been keeping their microcode(addenda) current EXCEPT Intel. Cari claimed to have tried a broad range of 865 and 875 chipset mobos with SP2 and most all failed! She then said that she'd never use anything except an Intel mfged mobo again as if after her eureka moment. Does anyone know more precise details of the overall technology involved here and the overall industry competence with respect to CPU microcode updates. What is the BIOS supposed to be doing here; is there any standard? What does %windir%\system32\drivers\update.sys do exactly? The implication is that most all of us 865/875 chipset mobo owners (and I assume that the issue is MUCH WIDER) have been running with all the CPU bugs/addenda UNFIXED! I don't know why this issue is blown all out of proportion. It is an issue that is not well known which is why I'm trying to find more details and also see what folks know in general. It is like the second coming or something. If an OS is so dependent on microcode being correct, a fairly simple algorithm and small file of microcode segments would fix it. Well then what does this do in XP? %windir%\system32\drivers\update.sys Microsoft should consider moving the microcode loader up in their boot sequence, like before some other kernel files are loaded. I got the impression that there was some condition precedent required in the BIOS and that's why %windir%\system32\drivers\update.sys didn't work and the fix was to rename update.sys ??? Please clarify. Inside an Asus BIOS, there is a file called cpucode.exe and it will consist of perhaps 8 or so 2KB microcode segments. Apparently, at least in some of the older BIOS, there were also a couple of 2KB "cache segments" in the flash chip as well, and if a new processor is detected, the microcode segment that loads successfully, is stored in one of the two cache segments. The BIOS effectively has to "flash itself", and contains the code to do that. There is actually a procedure for Award BIOS, where a user can "write" the cache segment with their own Prescott 2KB code segment, if they want to. (I have done this on a P2B-S, to get microcode support for a Tualatin.) The program is called CTMC from CT Heise magazine. In other words, for the initiated, they can actually prep their BIOS to be "SP2 ready" if they want to, without waiting for Asus (AFAIK works for Award BIOS, no idea if it works for AMI, as the hook and methodology of the AMI BIOS could be different). Asus updates BIOS files on a fairly regular basis. One user here owns a T2-P Asus small form factor system, and while the Asus cpusupport page doesn't currently list his system, he claims it supports Prescott or the advert copy says it supports Prescott. When I extracted the file of microcode segments for the most recent version of that BIOS, there were no Prescott family code segments in the file. So, indeed, in that case, support was lacking. Other users here who have had "SP2 trouble", aren't running the latest BIOS, so the solution there is clear. To keep all these BIOS updated to cover the latest Intel inprovements, means there will always be a gulf between the latest released microcode segments and what is available for download from Asus. Prescotts were shipping in March. I'm sure when a new processor is released at Intel, it even takes Intel a day or two to update their BIOS files, so Cari shouldn't be too smug sitting on an Intel motherboard. And finally, there is probably a small number of users who have stuffed Prescott processors in non-Prescott boards, and whatever happens, is of their own making. If your old motherboard lists Northwood 0.13u processor support, that is what you should be buying for it. Seeing as microcode loading existed in my 440BX based P2B-S motherboard, I would say the "industry competence" is there. Well, the question is whether the appropriate microcode is getting out in a timely fashion and how users are able to easily know what microcode level is right. It also apparently isn't a one time thing but updates continue to be made available by Intel. It appears that most the major mobo mfgs missed this one for the 865/875+Prescott+SP2 release. It wasn't like nobody new SP2 was coming in August. There appears to have been a mobo industry wide(save Intel) collapse on this issue. There is also some evidence that MS did little regarding a headsup to them or its users as this issue was reported in June(over 40 days before SP2 RTM). From your read of the issue how does the rename of %windir%\system32\drivers\update.sys temporarily fix the issue?? |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
SP2 865/875 Microcode Industry Failure? | Ron Reaugh | Overclocking | 19 | September 14th 04 06:58 AM |
SP2 865/875 Microcode Industry Failure? | Ron Reaugh | Homebuilt PC's | 20 | September 14th 04 06:58 AM |
Why mechanical failure causes HDD being undetectable by bios or OS ? | andy | General | 0 | September 3rd 04 04:02 AM |
SP2 865/875 Microcode Industry Failure? | Ron Reaugh | General | 1 | August 29th 04 06:01 AM |
Tualatin microcode update for P2B-xx BIOS | P2B | Asus Motherboards | 0 | November 27th 03 04:52 AM |