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.
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/19749 is the ubuntu bug which even has the lspci information.
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]
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.
(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?
Assigning back to kernel component pending confirmation from Chuck that Ubuntu are wrong.
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> AuthorDate: Thu Dec 6 15:09:43 2007 +0900 Committer: Jeff Garzik <jeff> 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> Cc: Bill Nottingham <notting> Signed-off-by: Jeff Garzik <jeff> --- 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;
Above patch is in 2.6.24, so can someone try the Fedora 9 Alpha and see if it detects the drives?
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.
Should be fixed in 2.6.25.10-90
kernel-2.6.25.11-97.fc9 has been submitted as an update for Fedora 9
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
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
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.