Red Hat Bugzilla – Bug 444334
[PATA devices on wrong connectors] Not all IDE disk drives visible
Last modified: 2008-04-29 21:01:31 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:188.8.131.52eol) Gecko/20080418 Ubuntu/dapper-security Firefox/184.108.40.206eol
Description of problem:
Not all IDE drives are visible to fdisk -l.
I have three drives, two on the primary IDE controller, and one as master on the secondary IDE controller. Only the two on the primary IDE controller show up in fdisk -l.
All three hard drives are visible in earlier kernels that map IDE drives to hda hdb hdc etc. With this kernel, they are mapped to sda sdb but there is no sdc.
I initially encountered this problem in Ubuntu Hardy 8.04. When I first attempted to install Ubuntu Hardy, it was on the master on the secondary controller. It installed but failed on reboot. So I swapped IDE cables, and installed on the master on the primary controller. While it now installs, it still does not recognise all three drives.
Running Fedora Core 8 exhibits the same symptoms of not making all IDE hard drives visible. I suspect that were I to attempt an install on a drive on the secondary controller, Fedora would also fail.
Another configuration that also failed in Ubuntu Hardy is two drives, one as master on the primary controller, and the other as master on secondary controller. Only one drive is visible.
More information and details of hardware can be found at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/222322
I believe the problem to be in the kernel. See the above link for more details.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot Live Fedore Core 8 CD
2. Login terminal session as root
3. Run fdisk -l
Only can see two of my three drives. See launchpad for more details.
To be able to access all three hard drives.
Please install the latest errata kernel, (which will likely have the same bug),
and attach the output of the dmesg command here.
Created attachment 303962 [details]
Output of dmesg
The problem still exists and is unchanged after a fresh install and running
yum update to apply the latest updates. The output of uname -a is:
Linux home 220.127.116.11-64.fc8 #1 SMP Sat Mar 29 09:54:46 EDT 2008 i686 i686 i386
The disk should be recognized here as ata2.00:
ata2: port is slow to respond, please be patient (Status 0x80)
ata2: SRST failed (errno=-16)
ata2.01: ATAPI: ASUS DRW-1608P3S, 1.24, max UDMA/66
ata2.01: configured for UDMA/66
Is the cabling right on this channel? libata is a lot pickier than old IDE about
drives being jumpered correctly and connected to the right connector on a
Thanks Chuck. Spot on. The cable end that typically goes in the controller was
in the CD drive, with the center connector in the controller, and the short
lead to the hard drive. The jumpers were correct.
I relocated the hard drive to be near the CD drive, and with the two
connectors that are close to each other, connected one in the CD drive and one
in the hard drive, with the long lead going to the controller on the
Other than relocate the hard drive, the only thing I did was change the IDE
cable around, and it is now working fine.
Once again, thanks Chuck, well spotted.
The only last comment I have, is that older versions of Linux handle the
reversed connection of the IDE cable, and for the less technically competent
user than I, they may find swapping around an IDE cable outside their
abilities. Basically for the average home user, they would be unable to
resolve this problem, and for some users, unable to install Fedora Core 8.
Therefore I encourage that this bug report remain open, until a fix to the
kernel/libata is made to make it more tolerant of cabling.
Maybe Alan can explain why libata is pickier than old-IDE about correct PATA
cabling... I sure can't.
Nor me - and I've also seen the reverse case. With a dodgy cable you are into
timing and luck when the drives come up and it may just be that because we reset
the bus to get a clean start that this happens to cause a timing problem between
the drives due to the wrong cable.
Given PATA command blocks are never checksummed I think I prefer the failure
case to obscure random corruption anyway.
I have been running with this configuration since purchase of this computer
around two years ago. The computer was configured by the assembler in this
configuration prior to my purchase. The only thing I did was to add two drives
on the other controller. Having the center connected to the controller on the
motherboard, has worked fine excepting that now I have changed it around, I can
see that the bios was handling the boot slowly. It is booting much faster now.
I don't believe there to be any physical problem with the cable. It is just that
it was installed in a non optimal direction.
It surprised me that changing the cable around made a difference. Because
Windows and versions of Linux prior to the latest releases, handle the alternate
arrangement of the IDE cable fine. It is just the latest releases of Linux that
have a problem with the non optimal arrangement.
After changing the cable around, and seeing this fixed the problem, I changed it
back. The problem returned. I then changed it around to having the long end to
the controller again, and it works.