Bug 135644

Summary: Installer doesn't work with SATA drive
Product: [Fedora] Fedora Reporter: Rexioo <rexiooman>
Component: kernelAssignee: Jeff Garzik <jgarzik>
Status: CLOSED CANTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3CC: davej, nobody+pnasrat, peterm, rafiq_maniar, tjb
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-10-03 00:03:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 123268, 136451    

Description Rexioo 2004-10-13 23:28:40 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3)
Gecko/20041001 Firefox/0.10.1

Description of problem:
Boot kernel from Fedora Core Test 3 doesn't work on Abit KV8-MAX3
Chipset VIA with Serial ATA drive. During the SCSI drivers loading the
installer always stops. Especially during the sata_via driver loading.
This problem always occur in the Fedora Core versions.

Hardware:
Hard disk: Seagate 80GB Serial ATA
Mainboard: Abit KV8-MAX3 with chipset VIA
Processor: AMD 64 (Fedora Core uses under 32-bit or 64-bit architecture)

Version-Release number of selected component (if applicable):
sata_via

How reproducible:
Sometimes

Steps to Reproduce:
1. Boot Fedora Core Test 3 installer
2. Load SCSI -> sata_via
3.
    

Additional info:

Comment 1 Rexioo 2004-10-14 01:50:46 UTC
How reproducible:
Always

Comment 2 Thomas J. Baker 2004-10-28 13:55:43 UTC
I have the same problem with a Dell Precision 370 using the Intel 925x
chipset. The ata_piix and libata modules are loaded but no disks are
seen. I'm using FC3RC2 for X86_64.

Comment 3 Thomas J. Baker 2004-10-28 13:57:23 UTC
To be clear, the installer informs me that no disks are found and
quits. Nothing crashes or hangs.

Comment 4 Thomas J. Baker 2004-10-28 15:19:45 UTC
Turns out to be a BIOS setting. I ordered the machine with two 80GB
disks and Dell set the BIOS SATA configuration to RAID. Setting it to
COMBINATION works.

Comment 5 Pavol Federl 2004-12-28 20:21:53 UTC
The problem with the above solution is that after I make the BIOS
changes, my windows XP won't boot - that is until I change the BIOS
settings back. That means that every time I want to boot the other OS,
I have to adjust the BIOS. It is slightly inconvenient - especially
when I need to reboot the machine remotely...

Comment 6 Rafiq Maniar 2005-01-14 12:56:06 UTC
An additional problem with the solution listed above is that setting 
the BIOS to Combination mode in effect enables Parallel-ATA emulation 
of the hard drives, resulting in a performance drop.

Possibly a better solution is to set it to RAID Autodetect/ATA 
instead. This will allow the drives to operate in native SATA mode.

See http://linux.dell.com/storage.shtml for more information.

Caveat: You can't use the "hardware" RAID (its actually the 
driver/firmware that performs the RAID functions)... Linux software 
RAID is a good option though.

The root cause of the problem is that Dell ship the 370 with the SATA 
operation mode set to RAID Autodetect/AHCI as default. The kernels up 
to and including FC3 (and possibly the very latest kernel.org one, I 
don't know offhand) don't have the AHCI support needed for this to 
work.

Comment 7 Dave Jones 2005-07-15 19:24:46 UTC
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.

Comment 8 Dave Jones 2005-10-03 00:03:10 UTC
This bug has been automatically closed as part of a mass update.
It had been in NEEDINFO state since July 2005.
If this bug still exists in current errata kernels, please reopen this bug.

There are a large number of inactive bugs in the database, and this is the only
way to purge them.

Thank you.