On Sun, 2005-12-04 at 08:40 -0800, Gerhard Magnus wrote: > I've been running FC4 for several months now and have been using yum > update without problems. The system has been automatically selecting > kernels with names ending in "smp". This morning, for no apparent > reason, I kept getting a kernel panic when I tried to boot and the > system hung repeatedly. I was only able to get past this by selecting > 2.6.14.1.1644_FC4 instead of 2.6.14.1.1644_FC4smp from the boot I'm having the same problem. My SCSI based Dual Opteron machine (x86-64) fails to boot with 1644. Somehow, the adatec79xx driver init fails, leaving me without the root LVM. (From there, attempt to kill init, panic.) Can you post your machine configuration? > configuration menu. > > It was just a guess. I have no idea why this worked. > > According to webopedia.com, SMP is "Short for Symmetric Multiprocessing, > a computer architecture that provides fast performance by making > multiple CPUs available to complete individual process simultaneously. > Unlike asymmetrical processing, any idle processor can be assigned any > task, and additional CPUs can be added to improve performance and handle > increased loads." I doubt that this has anything to do with SMP. machines. However, it is possible that the SMP configuration on 1644 is burked. Did you try older kernels? > > Does this refer to other processors on the same computer or on different > machines on a network? The other machines on this very minimally > networked LAN (just for ssh) aren't always up or running FC4 when they > are up. None of these computers are dual core. I'm not trying to do > any smp-type processing at this time. No. SMP means: Single machine with multiple logical or physical processors. In general, you can view an SMP machine as car with multiple engines working concurrently. (Instead of a single engine) > > Could the smp kernel ran into some sort of synchronization problem with > the other machines and now be "parametrically confused" about something? > I'd like to either (1) reset it or (2) fix the update process so that > the default is for non-smp kernels. Thanks for any suggestions. > Again, I doubt it. Gilboa
