Bug 430916 - Wrong sata module probe order prevents hard disk detection on Toshiba S100
Summary: Wrong sata module probe order prevents hard disk detection on Toshiba S100
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 8
Hardware: i686
OS: Linux
low
low
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-01-30 16:12 UTC by Stuart Rowan
Modified: 2011-12-13 22:29 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-01-09 07:55:53 UTC
Type: ---


Attachments (Terms of Use)

Description Stuart Rowan 2008-01-30 16:12:01 UTC
Description of problem:
Toshiba Portege S100. Problem also on ubuntu bugzilla somewhere.

Boot the installer. It modprobes ata_piix first and then ahci second
ata_piix (erroneously) grabs the hardware, fails to drive it, and doesn't
release it.
ahci then doesn't see it.

You can't install as the machine apparently has no disk.

Once installed via a workaround the errata kernel 2.6.23.14-107.fc8 has the same
issue.

Version-Release number of selected component (if applicable):
Fedora Core 8

How reproducible:
Always

Workaround:
Must do this before disk detection kicks in (we have a kickstart / preinstall
that facilitates this) as you can't go back and force anaconda to retry.

Alt-F2
rmmod ata_piix
rmmod ahci
modprobe /tmp/ahci.ko
(modprobe ahci does nothing, helpfully)

disk now detected

Once installed ...
vim /etc/modprobe.conf
switch ahci and ata_piix lines around (change the numbers too!)
mkinitrd /path/to/initrd.img <kernel-ver>
vim /etc/modprobe.d/blacklist
add:
blacklist ata_piix

Desire:
ata_piix is taught to not bind to this controller
The current work around of loading ahci first works well though.

I'll provide suitable lspci output if someone tells me what incantation they want.

This bug could equally have been titled ata_piix is defective ... I presume the
current ordering of ata_piix and then ahci is to work around similar bugs on
other machines?

This all said, it's the only machine we've had trouble with so thanks for all
the hard work you guys put in.

Comment 1 Stuart Rowan 2008-01-30 16:16:56 UTC
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/19749 is the
ubuntu bug which even has the lspci information.

Comment 2 Chuck Ebbert 2008-01-30 21:19:09 UTC
0000:00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW
(ICH6 Family) IDE Controller (rev 03) (prog-if 8a [Master SecP PriP])
 Subsystem: Toshiba America Info Systems: Unknown device 0001
 Flags: bus master, medium devsel, latency 0, IRQ 225
 I/O ports at <ignored>
 I/O ports at <ignored>
 I/O ports at <ignored>
 I/O ports at <ignored>
 I/O ports at bf30 [size=16]


Comment 3 Chuck Ebbert 2008-01-31 22:49:02 UTC
This is a problem that can't be solved at the kernel level. There is no way to
tell which mode the controller is in. Will assign to anaconda to see if the
maintainers there can do something.

Comment 4 Stuart Rowan 2008-02-01 10:18:16 UTC
(In reply to comment #3)
> This is a problem that can't be solved at the kernel level. There is no way to
> tell which mode the controller is in. Will assign to anaconda to see if the
> maintainers there can do something.

full sudo lspci -vxxx output:
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/19749/comments/51

and Matthew Garrett's response:
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/19749/comments/52

suggest ata_piix should have enough information from the PCI info to not be
taking this device.

Chuck -- note there is an IDE controller (as you posted above, 1f.1) *and* a
SATA controller (1f.2). The IDE controller is used for the CDROM drive.

Also why can't the kernel use e.g. a DMI blacklist with ata_piix, worst case?


Comment 5 Stuart Rowan 2008-02-07 11:00:31 UTC
Assigning back to kernel component pending confirmation from Chuck that Ubuntu
are wrong.


Comment 6 Chuck Ebbert 2008-02-07 18:02:23 UTC
This might fix it:

Gitweb:    
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c4f7792c021cda9bbf65d0bc2253a593fd652b91
Commit:     c4f7792c021cda9bbf65d0bc2253a593fd652b91
Parent:     d1aa690a7d1afa673c3383bfcd6e96ddb350939a
Author:     Tejun Heo <htejun@gmail.com>
AuthorDate: Thu Dec 6 15:09:43 2007 +0900
Committer:  Jeff Garzik <jeff@garzik.org>
CommitDate: Fri Dec 7 15:27:54 2007 -0500

    ahci: don't attach if ICH6 is in combined mode
    
    ICH6 R/Ms share PCI ID between piix and ahci modes and we've been
    allowing ahci to attach regardless of how BIOS configured it.
    However, enabling AHCI mode when the controller is in combined mode
    can result in unexpected behavior.  Don't attach if the controller is
    in combined mode.
    
    Signed-off-by: Tejun Heo <htejun@gmail.com>
    Cc: Bill Nottingham <notting@redhat.com>
    Signed-off-by: Jeff Garzik <jeff@garzik.org>
---
 drivers/ata/ahci.c |   18 ++++++++++++++++++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 588ab2f..cb7853b 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -193,6 +193,8 @@ enum {
 					  ATA_FLAG_ACPI_SATA | ATA_FLAG_AN |
 					  ATA_FLAG_IPM,
 	AHCI_LFLAG_COMMON		= ATA_LFLAG_SKIP_D2H_BSY,
+
+	ICH_MAP				= 0x90, /* ICH MAP register */
 };
 
 struct ahci_cmd_hdr {
@@ -2273,6 +2275,22 @@ static int ahci_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
 	if (rc)
 		return rc;
 
+	if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
+	    (pdev->device == 0x2652 || pdev->device == 0x2653)) {
+		u8 map;
+
+		/* ICH6s share the same PCI ID for both piix and ahci
+		 * modes.  Enabling ahci mode while MAP indicates
+		 * combined mode is a bad idea.  Yield to ata_piix.
+		 */
+		pci_read_config_byte(pdev, ICH_MAP, &map);
+		if (map & 0x3) {
+			dev_printk(KERN_INFO, &pdev->dev, "controller is in "
+				   "combined mode, can't enable AHCI mode\n");
+			return -ENODEV;
+		}
+	}
+
 	hpriv = devm_kzalloc(dev, sizeof(*hpriv), GFP_KERNEL);
 	if (!hpriv)
 		return -ENOMEM;


Comment 7 Chuck Ebbert 2008-02-07 18:04:17 UTC
Above patch is in 2.6.24, so can someone try the Fedora 9 Alpha and see if it
detects the drives?

Comment 8 peter 2008-07-08 20:37:16 UTC
This issue seems still to be present in 2.6.25.9-40.fc8. I installed the LiveCD onto a Dell 530s and it 
worked OK (version was 2.6.23.1-42.fc8). Then I installed updates and it wouldn't boot. Booting back to 
the earlier version in grub works fine.

Fedora 9 (released version) also has the problem. It will install but the reboot fails.

Comment 9 Chuck Ebbert 2008-07-10 16:24:15 UTC
Should be fixed in 2.6.25.10-90

Comment 10 Fedora Update System 2008-07-21 13:57:01 UTC
kernel-2.6.25.11-97.fc9 has been submitted as an update for Fedora 9

Comment 11 Fedora Update System 2008-07-23 07:17:24 UTC
kernel-2.6.25.11-97.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update kernel'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-6634

Comment 12 Bug Zapper 2008-11-26 09:38:34 UTC
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 13 Bug Zapper 2009-01-09 07:55:53 UTC
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.