Red Hat Bugzilla – Bug 126927
Installer hangs when loading sata_promise driver
Last modified: 2013-07-02 22:20:29 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8 Description of problem: When trying to install Fedora Core 2 on a NEC Express 5800/120Ef with SATA S150 SX4 controller anaconda stops working when loading the sata_promise driver. First the system freezes for two to three minutes after the 'Loading sata_promise driver ...' is displayed. After a while it is possible to switch to the virtual consoles. On console 3 the last messages are: * inserted /tmp/aic7xxx.ko * inserted /tmp/libata.ko At console 4 messages from ata2, scsi2, scsi3 and scsi4 are displayed until <6> sda:<3>ata1: DMA timeout <4>scsi1: ERROR on channel 0, id 0, liun 0, CDB ... <4>Current sda: sense key Medium Error <4>Additional sense: Unrecovered read error - auto reallocate failed <4>end_request: I/O error, dev sda, sector 240121720 Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Install FC2 Actual Results: System freezes when attempting to load sata_promise. Expected Results: System recognizes S150 SX4 controller and continues install. Additional info: I tried different disk layouts within the SATA configuration utility: JBOD, RAID5. All resulted in the same behaviour.
I downloaded the Promise driver for Red Hat 9 and installed that, works without problems, so the hardware seems to be working. A Windows install worked as well (not done by me, so no details).
Without any hd on the SATA controller install on an IDE disk works fine.
Still no native support on FC3 final. How would you incorporate the RH 9 driver into the FC3 install CD/DVD?
My guess is that the problem is with anaconda not knowing which driver handles the BIOS Interrupt #11 info for the drive. I'm getting interrupt 11 errors when anaconda is running even though the sata_promise driver is loaded. Recommend bug component change.
update: It's not just anaconda, the stock ata driver is choking on the extra interrupt #11s generated -- even as FC3 starts the xserver, the interrupt errors keep on coming, even when starting FC3 with "linux dd acpi=off" and loading the vendor-supplied driver.
These Promise/installer bugs sound just like the sata_sil bugs that are piling up. Is anything being done so that you will be able to install onto SATA drives with FC4? Is there any add-on PCI SATA card available now that you can install onto with FC3 anaconda?
See bug 115889
This may be fixed with the latest sata_promise update. Trying the upstream 2.6.11-rc kernel would be helpful.
Well, CF4 now can use the sata_promise driver, but it now causes another problem: Disk Druid sees drive individually even thoug hte BIOS ROM has them configured as mirrored. Then when changes are made the MBR is updated asymetrically and breaks the (XP) boot process. e.g. Two 200GB drives mirrored with 20% of the drive unallocated. DD creates the swap partition on drive 1, the ext3 "/" on drive 0. After the install and reboot I only got the GRUB prompt. The BIOS seemed to read the MBR off drive 0 but try to get the partition off drive 1 due to RAID interleaved read so the boot process fails. Rebooting with an XP CD, entering recovery mode and using FIXMBR and BIXBOOT would not work because the wrong MBR would be reset. Only updating the partition table by modifying an entry (like deleting the swap partition) would update both MBR copies to allow XP to boot again. If the BIOS is set to morror then DD should only see one drive and the sata_proose driver should write to both drives.
This is expected. Promise BIOS RAID is not supported by the installer. You need the "dmraid" utility and device-mapper.
Fine, but even if you wanted to use the physical drives separately, the installer/diskdruid nees to know that it may be causing an MBR mismatch problem. How can you get dmraid active during an install?
You would need to modify the installer source code to support BIOS RAID, via device mapper and the dmraid utility.
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.