From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 Description of problem: (This is FC2 test3.) System is an HP Kayak XU7/550X containing 2 Pentium III Xeon 550MHz CPUs. There is an Adaptec AIC-7880 on the motherboard for the two (boot) drives, and a PCI combo-card with a Symbios 53C875JE (sym53c8xx) SCSI chip (with nothing attached to it) and an AMD PCnet-FAST (pcnet32) 10/100 ethernet interface (eth0). Regardless of whether I boot the SMP or UP kernel, I get the following (normal) messages during bootup: Loading scsi_mod.ko module SCSI subsystem initialized Loading sd_mod.ko module Loading sym53c8xx.ko module sym0: <875> rev 0x26 at pci 0000:03:04.0 irq 15 sym0: Symbios NVRAM, ID 7, Fast-20, SE, parity checking sym0: open drain IRQ line driver, using on-chip SRAM sym0: using LOAD/STORE-based firmware. sym0: SCSI BUS has been reset. scsi0 : sym-2.1.18j If I boot the SMP kernel, I next get the following messages (with several-second delays between the "started" and "timed-out" messages), and then the boot hangs (Ctrl-Alt-Delete reboots, so the keyboard itself isn't dead): sym0:0:0: ABORT operation started. sym0:0:0: ABORT operation timed-out. sym0:0:0: DEVICE RESET operation started. sym0:0:0: DEVICE RESET operation timed-out. sym0:0:0: BUS RESET operation started. sym0:0:0: BUS RESET operation timed-out. sym0:0:0: HOST RESET operation started. sym0: SCSI BUS has been reset. If on the other hand I boot the UP kernel (or the SMP kernel with the "nosmp" option), I don't see the above ABORT/RESET messages, and instead bootup continues normally, including the following messages: Loading aic7xxx.ko module ahc_pci:0:8:0: Illegal cable configuration!!. Only two connectors on the adapter may be used at a time! scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36 <Adaptec aic7880 Ultra SCSI adapter> aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs (scsi1:A:0): 40.000MB/s transfers (20.000MHz, offset 8, 16bit) Vendor: SEAGATE Model: ST39102LW Rev: 8320 Type: Direct-Access ANSI SCSI revision: 02 scsi1:A:0:0: Tagged Queuing enabled. Depth 4 SCSI device sda: 17783240 512-byte hdwr sectors (9105 MB) SCSI device sda: drive cache: write back sda: sda1 sda2 sda3 Attached scsi disk sda at scsi1, channel 0, id 0, lun 0 (scsi1:A:1): 40.000MB/s transfers (20.000MHz, offset 8, 16bit) Vendor: SEAGATE Model: ST39102LW Rev: 8320 Type: Direct-Access ANSI SCSI revision: 02 scsi1:A:1:0: Tagged Queuing enabled. Depth 4 SCSI device sdb: 17783240 512-byte hdwr sectors (9105 MB) SCSI device sdb: drive cache: write back sdb: sdb1 Attached scsi disk sdb at scsi1, channel 0, id 1, lun 0 (Regarding the "Illegal cable configuration" error message: I'm not sure why that is; there's only one cable coming out of the motherboard to the drives, with a terminator (it appears) on the end; when I get a chance I'll have to check the drives' jumper settings; in any case the drives seem to work fine.) Version-Release number of selected component (if applicable): kernel-2.6.5-1.327 How reproducible: Always Steps to Reproduce: See above. Actual Results: See above. Expected Results: See above. Additional info:
fixed in 2.6.9 update ?
I guess this is just a 'me too' post; I'm currently using FC3 with the following kernels from updates: kernel-2.6.9-1.724_FC3 kernel-smp-2.6.9-1.724_FC3 Same problem as above; I can boot into the uniprocessor kernel fine, but booting into the SMP kernel results in the same bus resets as above.
I am new to linux and installed Fedora FC3 on HP Kayak Dual PIII 550Mhz. I continue to get the problems mentioned in the original post, though it is mentioned that the problem was identified with FC2 and it was fixed. If changing the kernel is a workaround/solution, then could anyone guide me to install the new version installation process ?
I tried installing a new kernel (2.6.11) using the rpm. I issued the command rpm -Fvh kernel-2.6.11..... It did give an error stat /dev/shm but completing the rpm installation. after rebooting the system continues to hang.
Fedora Core 2 has now reached end of life, and no further updates will be provided by Red Hat. The Fedora legacy project will be producing further kernel updates for security problems only. If this bug has not been fixed in the latest Fedora Core 2 update kernel, please try to reproduce it under Fedora Core 3, and reopen if necessary, changing the product version accordingly. Thank you.