Description of problem: Stage 1 install hangs during (what I believe to be) kudzu loading kernel modules for detected hardware. Hangs during loading of "sym53c8xx". Hardware is a Netserver LXR 8500 with dual on-board SYMBIOS SCSI busses. If I Alt-F3 I can see the first chipset detection and the SCSI drive detection occur in the bus0, then it goes on to detect devices on 2nd chipset+bus and it ends with the line: ???????? SCSI BUS has been reset. Then nothing further happens. The install process does not complete the module loading. I believe the kernel has completed its module loading however kudzu does not continue. I believe this to be a regression as I believe previous versions of Linux and RH were able to be install onto this hardware. However I can not cite any specific version at this time. Version-Release number of selected component (if applicable): Fedora Code 3 How reproducible: Bootup on install disk 1, wait 2 minutes to get the problematic point. This point occurs before any language selection occurs.
How can I pass sym53c8xx="" options to the installer module loader ? I am thinking of trying: sym53c8xx="verb:2 debug:65535" Does adding to the regular LILO kernel options do the trick ? I would not think so as the module loading occurs later on and the modules options come from /etc/modules.conf at that point in time ? Another work around I maybe trying is to install the OS on another PIII SMP class computer, compile install grade the kernel to see if its specific with 667smp What are your recomendations to me to provide a work around / bug fix ?
There is an issue apparently with "hald" reading PCI config space that can cause card lockup. http://lists.freedesktop.org/archives/hal/2005-May/002541.html I site this so that maybe it is related, since the kernel seems to complete the SCSI bus RESET before the install process stops and at this point in the install process (module loading) I believe FC to be employing some sort of hardware detection system to have found I have SYMBIOS hardware and then load the necessary driver. The thread I quote above goes on to say that all^H^H^Hmost libsysfs usage probably tickles this problem.
A homebrew Kernel 2.6.12.2 compiled with the /boot/config-2.6.9-667smp options boots up find with this machine. Maybe its specific to 2.6.9. I installed the OS in another similar spec computer (P3 SMP, SCSI based) computer, installed a bunch of newer homebew kernels and transfered the HDD over to test. This issue is closed from my side, but I can't retest it for you unless there is a new boot image made with a newer kernel for FC4 or something. I have in my office for another 3 weeks to do that, then it gets deployed.
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you.
Sorry my problem was the original FC3 Disk1 hung on bootup (before the install process). There is no way to upgrade the kernel as the system is not installed yet. I presume there is only ever one version of the FC3 Disk1, meaning that you dont update/rebuild the master Disk1 with a new kernel version? So its no good to test with. As the updates you talk about are packages updates after the initial install is completed. If you can confirm to me that the FC4 Disk1 uses a newer kernel version than 2.6.9, I will give that a try for you. Otherwise I suspect the first version I can test with will be FC5, but I only have the machine in my office for another week, then its being shipped to another country.
yes, FC4 is based on a 2.6.12rc kernel.
FC4 Disk1 hangs as well. The kernel that is installed on the system that does work is 2.6.12.2, so maybe there were changed between 2.6.12rc and 2.6.12.2 that affect the driver ? I no longer have the machine to do any more testing with, its been deployed into service.
The latest errata for FC3/FC4 is based on 2.6.12.2, so if that worked for you, chances are this got fixed. Thanks.