Bug 139146

Created attachment 106636 [details]
Anaconda dump

Too big up upload uncompressed

There are a lot of db errors in the log which have me wonder about
writes to the disk not succeeding.  Does it do better if you boot with
'linux ide=nodma'?

Saw that as a suggestion for another bug report and tried it last 
night....same crash.  I'll see if I can do it again and upload the 
dump with ide=nodma set.

Created attachment 106772 [details]
Anaconda dump w/ ide=nodma

Here's the anaconda dump when installing with ide=nodma.  I also deleted the
partitions on the second drive and made a simple partitioning scheme w/ ext3
partitions on the first drive to see if software-RAID was causing any problems.

Anyone have other suggestions to try?  This system works fine with 
Windows and is the only box that I've ever had problems with Linux on.

The motherboard is an ECS P4S5A2, is running the most recent BIOS, 
and appears to use an XP4 (?) northbridge.  The primary IDE 
controller reports to be a SIS 961.  Given the ide=nodma suggestion 
earlier, I've even tried installing using an add-in PCI IDE card 
(which uses the CMD649 chipset).

The install CD-ROM passes the self-check and the ISO that it was 
created from has a valid md5 sum.  I've also attempted to do an HTTP 
install (booting via PXE).

The motherboard supports either PC133 or DDR266 RAM, and I've tried 
with both (not at the same time).  I've tried disabling all cache 
options in the BIOS.  I've even swapped video cards (both are AGP).

I've tried booting with acpi=off, apm=off, nousb, pci=bios, 
pci=nobios, pnpbios=off, etc.

I've tried using LVM partitioning, and making the root filesystem 
ext2 rather than ext3.

I've also just completed an attempt at installing with a 9gig SCSI 
drive attached to an Adaptec 2940UW controller (with the IDE drives 
unplugged from the motherboard).

No matter what, every install fails with the same error.  Would I be 
correct in guessing that this is some sort of incompatibility with 
the motherboard itself?  If so, what options are available for 
tracking this further?

Ok last comment (unless someone can suggest something).....

I did some regression testing - FC3 is obviously having problems, FC2 
produces the same error, as does FC1.  However, RedHat 9 installs and 
runs without any problems!

I suppose I could try doing an upgrade to FC3 and see what happens, 
but would like some feedback from someone in the know to see if that 
would even produce any useful results.  I'm a little out of my league 
trying to debug further.

I also get this exact same error on FC3.

I have a IBM NetVista 6833 P4 system.  I tried a FTP and HTTP install
and after installing all the packages it crashes out.  Using a
recovery CD it looks as if everything installed fine up to the point
of crash.

I also have a anaconda dump if you would like to see it, but it looks
the same as the already attached.

I've finally given up.  I put the drives into another system, 
installed FC3 without a problem, and then put the drives back into 
this system which is now working fine.  The box will be going into 
production tomorrow so I won't be able to do any additional testing 
on this.

This is the same bug as #106372

*** Bug 140284 has been marked as a duplicate of this bug. ***

I submitted a similar bug (bug #140284) about a month ago.  Same
problems.  I've likewise tried a variety of command line args and
such, to no avail.  If you would like additional information
(anacdump, specs, ...) I'll be happy to provide them.  
PLEASE NOTE, though, that I WAS able to install and am currently
running FC2.  This is (to me) a new problem in FC3.

I have the same problem as Jason (#11). FC2 instals without any 
problems. FC3 experiences problems described above in the text and 
graphical installation mode. The install media (DVD ISO image) is 
checked and ok. I tried different command line options described in 
comments to many bugs. Without results.
P4 1.4GHz, Mainboard ECS P4VXASD with latest BIOS (48bit LBA), 512MB 
RAM, 160GB HDD. System is multiboot with Windows and FC2.
Because of its size, dumps and logs may be deliveried if will be 
helpful.
Some errors from ttys:
rpmdb: PANIC: fatal region detected; run recovery
db4 error (-30978)
No volume groups found
/usr/sbin/kudzu can not be run

I got FC3 to install, but in a very limped and backwards way:
1) Install FC2, standard install.  No prbs.
2) Install FC3 as upgrade with the DO NO MESS WITH THE BOOT LOADER
option on.  Install gets past death point at the window labeled "Post
Installation configuration" but shows "rpmdb panic:  run recovery" all
the way up the screen.
FC3 seems to boot fine, and I am typing the bug report on it now. 
HOWEVER, an attempt to install additional packages via the
"start">system settings>add/remove applications util brings up the
following error:
Packages Not Found

The following packages could not be found on your system. 
Installation cannot continue until they are installed.
followed by a long, long list of packages not installed.

I don't know what quite to think of this, but I'm going to follow my
more-than-likely red herring intuition and try to install FC3, clean,
with no boot loader, hope that works, and install boot loader
manually.  Will report back when I've got some results.

Attached: upgrade.log

Created attachment 109172 [details]
Jason's "successful" install of FC3 via upgrade form FC2

Procedure in #13 is not the problem solution. You obtain strange 
compilation of FC2 i FC3, which cannot fully operate. I think that 
the problem is somwhere between the rpm database or hardware. I 
compared the results in text and graphical installation. The text 
installation aborts somwhere in the middle of rpms installation with 
totally wasted screen. The graphical continues to the postinstalation 
procedures. However, in the graphical environment errors observed on 
tty (console) occurs earlier, after installation of openssh in my 
case. In my case and in #13 problems are connected with rpm database. 
Not everything is installed - ex.: kudzu is not present what I 
checked manually. On the other hand, there are people who perform 
this installation without problems. So, it may be connected with 
hardware. I have no idea what to do. It is my third day (and night) 
with this problem. The most strange is that FC2 installation is 
correct.

Agree with #15.  Sorry if I messlead anyone, I certenly did not mean 
this to be a work around, just some valuable information.
Installing w/o GRUB lead to the same errors as reported before.  I'm 
out of ideas.

Some additinal tests were performed by me. I installed FC3 on Virtual 
PC on the same machine. The installation proces achieved reboot 
corectly! 
Only 2 errors were observed during installation on tty6:
No volume groups found
No volume groups found
The first appeard after the detection of the installed systems.
The second after the settings for partitions were established in Disk 
Druid.
So, I'm sure that the installation media is not the problem. I 
performed the minimal instalation. After reboot, I obtained very 
strange errors:
INIT: Id "1" respawning too fast: disabled for 5 minutes
INIT: Id "2" respawning too fast: disabled for 5 minutes
INIT: Id "1" respawning too fast: disabled for 5 minutes
INIT: Id "2" ....
and the above continues to infinity. These errors may be casued by 
Virtual PC, it works fine only with MS OSes. The conclusion is that 
errors in the FC3 installation process depend on hardware or disk 
configuration.

Installation from CD-ROMs (not DVD) gives the same results as in #12. 
Do you have any idea what to check in my system?

Unless I'm missing anything, everyone experiencing this bug seems to
have a Pentium 4 in the 1.4-1.7GHz range...

IMO it would be interesting to know what "/sbin/lspci" and "cat
/proc/cpuinfo" say on the affected systems -- it would be interesting
to see if any other patterns emerge.


The respawning error in comment #17 is probably the bad interaction
between Virtual PC and the 4g4g patch. If I remember correctly, Fedora
Core 4's default kernel will not have 4g4g -- that will prevent the
probelm from happening when that release happens.


Comment #13 isn't the solution, sure, but it might allow somebody
experienced with RPM and/or Berkeley DB to look at the database and
see what kind of corruption is happening. (Chances are that the RPM
database will be too big to attach to this bug, however.)

Created attachment 109505 [details]
Hardware info for ECS P4S5A2 / P4-1.7GHz system

Output from /proc/cpuinfo and lspci

Created attachment 109521 [details]
cpuinfo and lspci under FC2

"cat /proc/cpuinfo" and "/sbin/lspci" made under running correctly Fedra Core 2

In my opinion the problem is not in processor type. I described 
installation under Virtual PC because it uses the processor which is 
mounted on board and gives the rest of environment, bios, hardware 
emulation, etc. There was no problem during instalation till reboot 
oposite to the "real" PC. I think, that problem depends on hardware 
or disk configuration, but no processor. 
I may perform additional tests, ex: on rpm databases, but someone 
have to tell me what to do, because I am not so experienced in Linux.

Is someone working around this problem? I saw the same (or very 
similar) problem in bug #141084 which has still status NEW. I may 
help, but I'm not expert in linux. It is importatnt to me to obtain  
solution or to know that there will not be any solution. I have to 
choose linux distribution in a short term.

I suggest to increase the priority of this bug to high. I cannot do 
that. Only the owner or submitter of the bug, or a sufficiently 
empowered user, may change that field. I saw some bugs devoted to 
this problem, ex. bug 119447 for fc2, which was closed without any 
explanation as solved by the current release, ie. fc3. I think, that 
problem has no solution yet and only the group of computers affected 
by this bug changed as the release changed, because I can install fc2 
without any problem.

I seem to be unable to change the priority as well.  I guess we need 
to get Jeremy Katz to weigh in with his thoughts.  So far, I've seen 
only one comment from him regarding this bug.

Created attachment 109640 [details]
Specs for my system

So, we have a full review of computer chipsets and periferials as may 
be conluded from attachements: SiS, VIA, INTEL. They are not 
especially exotic. I cannot see nothing similar. Maybe you will find 
out something. Processors are really similar but no identical. Maybe 
processor is relly the problem. But it is opposite to my tests with 
Virtual PC. I have no idea. I tried to install with removed 
unnecessary periferials, such as additional USB 2.0 PCI controller, 
additional video card and without results.

Virtual PC is not a 100% transparent virtualization. That's why it
fails to boot FC3 after installation. If this is a processor-related
issue here, then Virtual PC could be changing thngs enough to keep it
from happening in that case.

Also...
> Processors are really similar but no identical.

AFAICT they're all the same core (Willamette).


Does anaconda apply microcode updates? I doubt it; it would be
interesting to make a version of the FC3 installer that applies
microcode updates shortly after boot, and see if that fixes the
problem at all.

That gives me another idea for trying to get some more clues, but I
don't have time to describe it right now. I should have time in the
next day or so.

I understand that Virtual PC is not 100% virtualization, but uses the 
processor installed on motherboard and does not emulate it, if I 
understand how VPC works. I only stated, that installation goes 
further on VPC than on real PC using the same processor - nothing 
more, and it was my aim. Errors after reboot may be casued by VPC. 
Problem with VPC is for separate bug, but not this. I cannot achieve 
postinstallation procedures and reboot after installation on "real" 
PC and this is my problem and all of us.

Your observation about the core of processors is interesting. We are 
waiting for any idea of solution. On my computer, FC2 installs 
without problems. Problem is with FC3. Why anaconda in FC2 does not 
demand microcode update? I do not expect downgrade of procedures in 
anaconda. It would be strange. However, I may be wrong.

I never implied there was any "downgrade of procedures in anaconda".
Rather, I'm thinking it could be a strange CPU bug which hits only
under very specific circumstances, or something of that kind. In that
case, it may be fixed by newer microcode -- that's why Intel releases
the microcode updates in the first place.

Hopefully I have something for you to try in the next day or two.
(Maybe even in the next few hours.)

You may be right. But those circumstances may be very specific. I may 
debug installation or gather additional information from system, but 
I need guide "what" and "how".
Regards, Chris

I'm working on that right now.

I'm waiting :-)

Created attachment 109679 [details]
floppy disk with microcode driver/util/data for testing

These instructions assume you have a working Linux system that you can use for
creating a floppy disk. If you don't (e.g. if you have to create the disk from
Windows), my next attachment will probably be easier to use (but functionally
equivalent).

Instructions:

1. On a working Linux system, download the attachment and save it as
"microcode-disk.img.gz" or something like that.

2. Insert a floppy disk and run the following command to copy the file's
contents onto the floppy:
zcat microcode-disk.img.gz > /dev/fd0

3. Boot into the Fedora Core 3 installer on the system which shows this bug.

4. Skip the media test (you've probably done it already, I assume).

5. Once the "Welcome to Fedora Core" screen appears, press Control-Alt-F2.

6. Run the following command:
tar zxvf /dev/fd0

You should see the following output before the shell prompt reappears:
microcode_ctl
microcode.dat
microcode.ko
m

If you see any errors about timestamps being in the future, just ignore
them.

7. Then run the following command:
./m

8. It will produce about half a screen of output. Write down the lines of
output that start with "./microcode_ctl" or "microcode:". This will probably
be the first two lines and the last line or two. When you get a chance,
type that information into this Bugzilla bug.

9. Press Alt-F1 (for a text install) or Alt-F7 (for a graphical install) and
proceed with installation. See if it works this time or if it still has
problems.

Created attachment 109681 [details]
microcode driver/utils/data tar file for testing

Here are the steps that differ from the previous attachment's instructions:

1. On a working system, download the attachment and save it as
"microcode-test.tar.bz2" or something like that.

2. Copy that file onto a floppy disk.

...

6a. Run the following commands:
mkdir /x
mount /dev/fd0 /x
tar jxvf /x/microcode-test.tar.bz2
umount /x

You should see the following output from the tar command before the shell 
prompt reappears:
microcode_ctl
microcode.dat
microcode.ko
m

If you see any errors about timestamps being in the future, just ignore
them.

6b. If step 6a doesn't work, try again with these commands instead:
mcopy a:microcode-test.tar.bz2 .
tar jxvf microcode-test.tar.bz2


All of the other instructions remain unchanged.

OK, I'm starting test.

OK, I have perfomed test.
Output you ask for:
"
./microcode_ctl: writing microcode (length:208896)
./microcode_ctl: microcode successfuly writen to /dev/cpu/microcode
(some others)
microcode: CPU0 updated from version 0x0 to 0x13, date 07162002
"
Installation process goes to the reboot without any problems.
However, after reboot, system starts and freezes in line 
"checking for new hardware".
You waited so long because I have performed two installation minimal 
and then everything (second takes on my computer more than hour).
After minimal installation system starts in runlevel 3 and freezes in 
above line.
After everything installation, runlevel 5 starts andsystem freezes in 
graphic interface in above line too and only a sign in the top right 
corner turns around. After a some time system changes to text tty1. 
The graphic environment may be returned by Alt-F8 but is still 
frozen. I was waiting about 5 minutes and nothing happened, hdd does 
not work - silence.
Your procedure is really a step forward :-)
but something should be corrected more :-(.
Do you have any idea? Now I believe that problem is with the 
processor. You were right.

Wow... we have progress!

BTW, what version of Windows did you use to run Virtual PC? I think
Windows XP (and maybe 2000 as well) also applies a microcode update so
that may be why it worked under Virtual PC.

Anyone who has this problem should check if a BIOS update is available
for their computer. If so, they should apply it -- a new BIOS often
contains microcode updates, and it's better for the BIOS to apply it
than the operating system, if possible.

If anyone who is hitting this bug is also running the latest BIOS,
that would be a useful piece of information to know.

Chris, regarding your current freeze problems, I might have some
advice later today, or maybe tomorrow.

You right about windows :-) I did not know that windows updates 
microcode. It is for me really new information.

I have the newest possible BIOS for my mobo (if I remember this BIOS 
is about 2 years old). I had to update BIOS, because I had mounted 
160GB HDD and my old BIOS had problems above 120GB, so LBA 48 bits 
was instaled with new BIOS and works correctly.

Maybe new microcode should be installed during fedora startup?
Unfortunately, at the stage when it freezes any tty is not available.
Only Ctr+Alt+Del works :-)

So, Barry, thank you very much for help and cooperation. We really 
have progress. I am waiting for your next advices :-) I am working 
some time with computers, but today i feel as a student. It was a 
good lesson for me. Thanks.

I think that someone else should perform your procedure and we would 
compare results. Stuart, Jason, Eric - we look for volunteer! ;-)

For me is enough for today. Please tomorrow :-)
Regards, Chris

I am also running the latest BIOS made for my system.

At the moment I can't test the microcode hack because I am now using
the  machine for several services.  I was able to get FC3 installed
and running by installing the HD in another IBM P4 system, also a
Willamette 1.6GHz oddly enough.  It installed fine and I moved the HD
back to my troubled system and it has run flawlessly now for a few
weeks.  After the install Kudzu had no problems whatsoever.

Chris, does FC3 update the microcode during boot before Kudzu runs
(the "checking for new hardware")?  If not you should change the order
of the init scripts so the microcode gets updated first.

BTW: When FC3 runs the microcode update at boot I get updated from
"revision 0x3 to 0x12, date = 07162002"

In the perfect world, the BIOS updates the microcode to a sane level.
If there is a new bios, please upgrade to that (even though the
changelog of the bios vendor usually doesn't mention microcode
updates, they often do include them silently)

The OS doing this behind the bios' back is rather awkward, and it can
even be dangerous in that the bios may still work around issues that
no longer are in the cpu, and that may even blow up.

Arjan, as you said: in the perfect world. But in real world we do 
have updated BIOSes by the most recent releases available for our 
mobos. Our mobos are not new rather.
Have you any suggestion, idea or better solution than microcode 
update in OS? What should I do?

If there are no better solution I would like to incorporate a newer 
microcode into Fedora. The system is installed but freezes on the 
hardware check. No ttys are available at this stage. I may boot 
Knoppix from CD and correct demanded files. Do you know what should 
be gathered (files, tools, guides, howtos, etc.) and how to perform 
this operation or where may I find such a procedure? Eric wrote 
something about init files. May I ask for more precise explanation?

Maybe any other suggestion?
Regards, Chris

SUCCESS!!! This message is writem from running Fedora Core 3!
So, I describe the full procedure:

1) Install system according to Barrys comments #35 and #36 and reboot
system as demanded at the end of installation.

2) If your system works correctly - just work and dont read the
remaining procedure.

3) If your system freezes on "Checking for new hardware", as mine, you
may try the following (the idea is based on Erics comment #41 - thanks
Eric :-) )

3a) Extract from attachment in Barrys comment #36 file microcode.dat
and write it into floppy.

3b) Run any linux bootable from CD, ex.: Knoppix and connect to
partition with fedora.

3c) Rename /etc/firmware/microcode.dat to microcode.dat.orig (you may
revert then to the original in case of any problems)

3d) Mount floppy and copy microcode.dat into /etc/firmware/

3e) Open file /etc/rc.d/rc.sysinit and go almost to the end. You find
 comment "# Now that we have all of our basic modules loaded and the
kernel going,"

3f) BEFORE the above comment, write in a new line as follows:
/etc/rc.d/init.d/microcode_ctl

3g) Restart computer - my works fine after that.


I know that this procedure is not convenient - but it works and I will
test if everything works fine.
The best would be to prepare a floppy used during installation - my
knowledge is to poor - maybe someone try to prepare such a floppy?

I would like to thank especially Barry:
- Barry this is your solution - not mine - thank you very much! :-)))
and thanks to everyone who worked around this bug :-)

I think that more convenient solution should be prepared and so more
important, correctness of may solution should be confirmed. If
demanded, the solution should be corrected

Best regards, Chris

Looks like we need to make sure the microcode service gets installed
and started by default on these machines.

Chris, that is a pretty complicated way.  Guess I didn't get that
e-mail out to you fast enough ;-).

If the installation goes okay and the reboot into the system doesn't,
you can start FC3 in single user mode (init 1).  At the grub prompt
hit 'e' and add 'init 1' to the end of the boot command.  If I
remember correctly no services get started so kudzu shouldn't run.

Now you should be able to turn on the microcode service by typing:
chkconfig microcode_ctl on
and you may turn off kudzu if you wish:
chkconfig kudzu off

The microcode already in /etc/firmware/ is the same one that is
attached in this bug report.

Now reboot and all should be well.

Eric

Eric, you right.
The service is turned off.

[root@AAA ~]# chkconfig --list microcode_ctl
microcode_ctl   0:off   1:off   2:off   3:off   4:off   5:off   6:off

I will check your procedure in a few days and describe results.
Now I want to have some fun with FC3. I was waitng for correct
installation over a month :-). I have just installed the driver for
nvidia GForce and have to perform some other configurations.

Thanks & regards, Chris

Re: comment #44 and #45

No, that's not my solution for once the system is already installed.
Mine would be virtually identical to comment #45. FC3 does ship with a
slightly older version of the microcode updater and the microcode data
file, but the Willamette CPU core is old enough that it makes no
difference there.


Re: comment #42

Yes, it's awkward for the OS to update the microcode. For what it's
worth, Windows XP does it by default -- but this caused a problem with
Service Pack 2 on Prescott CPU's:
http://support.microsoft.com/?kbid=885626

Intel's and Microsoft's recommended solution is a BIOS update. If
that's not possible, Microsoft has an update to the Windows XP
microcode loader/data. Unfortunately I don't know if the MS update
uses more recent Prescott microcode or if it just disables microcode
updates on those CPU's.

Created attachment 109882 [details]
Anaconda dump, lspci, and cpuinfo.

I too encountered this bug.  I have attached my Anaconda dump, lspci output,
and cpuinfo output.

My system board is an Elite Group P4VXASD2+ PCB 5.x running the latest
available BIOS.  (http://www.ecsusa.com/downloads/p4vxasd2_5x.html)

Comment #35 resolved the problem from me, and this was the output from the ./m
command.

./microcode_ctl writing microcode (length 208896)
./microcode_ctl: microcode successfully written to /dev/cpu/microcode
microcode: CPU0 updated from revision 0x0 to 0x14, date = 07162002

I did not have to perform the steps noted in Comment #44 or Comment #45.  The
system rebooted and ran find with chkconfig showing microcode_ctl off.

(In reply to comment #48)
> Created an attachment (id=109882) [edit]
> Anaconda dump, lspci, and cpuinfo.
> 
> I too encountered this bug.  I have attached my Anaconda dump, lspci output,
> and cpuinfo output.
> 
> My system board is an Elite Group P4VXASD2+ PCB 5.x running the latest
> available BIOS.  (http://www.ecsusa.com/downloads/p4vxasd2_5x.html)
> 
> Comment #35 resolved the problem from me, and this was the output from the ./m
> command.
> 
> ./microcode_ctl writing microcode (length 208896)
> ./microcode_ctl: microcode successfully written to /dev/cpu/microcode
> microcode: CPU0 updated from revision 0x0 to 0x14, date = 07162002
> 
> I did not have to perform the steps noted in Comment #44 or Comment #45.  The
> system rebooted and ran find with chkconfig showing microcode_ctl off.


Yeeesh!  That's what I get for trying to talk to my children and type this up at
the same time.  "problem from me" should read "problem for me".  "ran find"
should read "ran fine".

The lspci and cpuinfo files in your attachment are both corrupted beyond
recognition (at least for me). unzip doesn't give me any errors, it's just that
the output files are unreadable garbage. The anacdump.txt file came through however.

I would strongly suggest running 'chkconfig microcode_ctl on'; if you need to
use my attachments/instructions from comment 35 or 36, and if that lets you
install, that means (a) your CPU has a data corruption bug and (b) the BIOS is
failing to apply the microcode update that fixes it. That means the OS has to
apply it instead (the alternative seems to be data corruption). And the way to
make Fedora Core do it is to make sure it runs the microcode_ctl service at each
boot.

Don't bother attaching any more lspci output to this bug unless anyone else asks
for it. It's probably irrelevant at this point. The contents of /proc/cpuinfo
may still be useful though.

To clarify my last comment: Matt, in your case, the contents of /proc/cpuinfo
will be useful. Your system seems to be updating with a different microcode
revision, so I'm wondering if it's a different CPU stepping that what we've seen
so far.

I've had success too!!!
I did the microcode update (comment #36) and got the same output as
commetn #38.  HOWEVER, I did not have to do anything in comment #44 /
comment #45.  Basicly, I did the microcode update and it worked! 
Thanks so much, guys!

~Jason

In case I didn't make it clear enough earlier: The microcode update
has to be reapplied *with every reboot*. This isn't a very big deal to
set up: you just need to run "chkconfig microcode_ctl on" (as root)
after the system is installed. Then reboot, or (if you *really* don't
want to reboot) run "/etc/init.d/microcode_ctl start". Afterward,
Fedora Core will automatically reapply it.

If you don't activate microcode_ctl, then the CPU's data corruption
bug will still be present in the running system and could still cause
problems down the road.

Sorry, missed that somehow.  Thanks.

There's something else I should clarify: My workaround is *not* a full
and final fix for this problem (but it's better than nothing, of course).

I've read through some of the Intel CPU documentation, and I now think
that a real fix for this problem (for people who have already updated
to the latest BIOS) is going to involve running something off a
FreeDOS bootable floppy, or something along those lines. (This would
be a one-time matter, not something that needs to be done at each
boot.) Perhaps I'll elaborate on this later.

Created attachment 109917 [details]
this is a bit closer to a real solution

Instructions:

1. Download the attachment and save it as "microcode-boot.img.gz" or whatever.

2. zcat microcode-boot.tar.gz > /dev/fd0 (or the equivalent), with a formatted
floppy disk in the drive

3. Download ftp://ftp.heise.de/pub/ct/ctsi/ctmc10.zip and unzip it somewhere.

4. Copy the file ctmc.exe (from ctmc10.zip) onto the floppy disk. (You have to
copy it onto the floppy separately for licensing reasons.)

5. Boot from the disk and follow any instructions. It will ask for permission
before installing the microcode update into your BIOS. It may take a while to
read everything off the floppy disk.

6. When/if the update finishes sucessfully (see below), turn the computer off
and back on, and repeat step 5. This time, the computer should see that the
latest microcode is already installed, so it won't reinstall it (it won't ask
for permission).


Unfortunately I have only one test system at home that gets as far as asking
for permission, and then it suddenly goes to sleep and won't wake up until I
press the reset button. However, while the update doesn't take, it still
doesn't do any damage. Also, this system is a Pentium II, not a Pentium IV, so
on a P4 things might work better.

When/if the update gets applied successfully, it will stick until the next time
the BIOS is flashed. Once this is in place, my previous method of updating the
microcode should no longer be necessary. (If you need to undo this for any
reason, just reapply the latest BIOS update.)

This is not quite the final word -- it would be better if the microcode
installer was open-source -- but it's less of a hack than my previous methods.
Give it a try and see what happens (but make sure you have all your data backed
up, etc.)

Re: Comment #50 and Comment #51
My apologies Barry.  No clue what happened to the zip.  Anyway, I
turned on microcode_ctl as recommended and here's my /proc/cpuinfo.

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 0
model name      : Intel(R) Pentium(R) 4 CPU 1500MHz
stepping        : 10
cpu MHz         : 1500.556
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips        : 2957.31

I haven't had a chance to try the suggestions from Comment #56.

*** Bug 141084 has been marked as a duplicate of this bug. ***

Comment #56 has consistently failed on any computer I've tried it on,
thus far. :(

*Maybe* I'll see if I can write a microcode flasher this weekend. If I
don't get it done this weekend then I probably won't be able to do it
until at least summer, though.

Comment on attachment 109917 [details]
this is a bit closer to a real solution

Marking my attachment from comment #56 as obsolete, because it's simply broken.

This isn't something we can generally do as it will cause problems on other
CPUs.  The main thing that can be done here is really just to lean on hardware
makers to fix their hardware :/

*** Bug 166961 has been marked as a duplicate of this bug. ***

*** Bug 160618 has been marked as a duplicate of this bug. ***

*** Bug 168579 has been marked as a duplicate of this bug. ***

*** Bug 179158 has been marked as a duplicate of this bug. ***

*** Bug 163220 has been marked as a duplicate of this bug. ***