Description of problem:
The new kernel-2.6.20-1.2925.fc6 doesn't recognize the PATA disk attached to
my sata_promise SATA/PATA controller (in non-RAID PATA mode). This is a
regression from kernel-2.6.19-1.2911.6.5.fc6, where it is detected
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Find a motherboard with a dual-mode SATA/PATA Promise RAID controller.
2. Set the controller to normal IDE mode (no RAID) and attach a PATA drive.
(In my case, this is out of necessity because I have 5 IDE/PATA devices: 3
HDDs, a DVD-ROM and a DVD writer, and the regular IDE controller can only
handle 4 of them.)
3. Enter at least one of its partitions in /etc/fstab.
4. Try booting kernel-2.6.19-1.2911.6.5.fc6, this works.
5. Try booting kernel-2.6.20-1.2925.fc6.
The boot stops with an error during the fsck phase because the disk is not
The kernel boots successfully like the previous version.
lspci entry for the Promise controller:
03:04.0 RAID bus controller: Promise Technology, Inc. PDC20378 (FastTrak
378/SATA 378) (rev 02)
Output of hdparm -I /dev/sda:
ATA device, with non-removable media
Model Number: ST3250823A
Serial Number: 3ND12F54
Firmware Revision: 3.03
Supported: 7 6 5 4
Likely used: 7
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
CHS current addressable sectors: 16514064
LBA user addressable sectors: 268435455
LBA48 user addressable sectors: 488397168
device size with M = 1024*1024: 238475 MBytes
device size with M = 1000*1000: 250059 MBytes (250 GB)
LBA, IORDY(can be disabled)
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = ?
Recommended acoustic management value: 128, current value: 0
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=240ns IORDY flow control=120ns
* SMART feature set
Security Mode feature set
* Power Management feature set
* Write cache
* Host Protected Area feature set
* WRITE_BUFFER command
* READ_BUFFER command
SET_MAX security extension
* 48-bit Address feature set
* Device Configuration Overlay feature set
* Mandatory FLUSH_CACHE
* SMART error logging
* SMART self-test
* General Purpose Logging feature set
Master password revision code = 65534
not expired: security count
not supported: enhanced erase
HW reset results:
CBLID- above Vih
Device num = 0 determined by CSEL
Is the sata_promise-pata patch still not upstream? If it's not, can it please
be rebased? If it is, why doesn't it work?
Please post output of "lspci -vxn" for that controller.
Here it is:
03:04.0 0104: 105a:3373 (rev 02)
Flags: bus master, 66MHz, medium devsel, latency 96, IRQ 21
I/O ports at df00 [size=64]
I/O ports at dfa0 [size=16]
I/O ports at dc00 [size=128]
Memory at feafe000 (32-bit, non-prefetchable) [size=4K]
Memory at feac0000 (32-bit, non-prefetchable) [size=128K]
Capabilities:  Power Management version 2
00: 5a 10 73 33 17 01 30 02 02 00 04 01 91 60 00 00
10: 01 df 00 00 a1 df 00 00 01 dc 00 00 00 e0 af fe
20: 00 00 ac fe 00 00 00 00 00 00 00 00 43 10 f5 80
30: 00 00 00 00 60 00 00 00 00 00 00 00 0a 01 04 12
(Note that this output is from 2.6.19-1.2911.6.5.fc6.)
*** Bug 232656 has been marked as a duplicate of this bug. ***
Should be fixed in next release.
Just out of curiousity, what was the cause of the bug? (and also, when can we
expect the next release...)
To satisfy this kind of curiosity is what the Fedora CVS is for. ;-) The
problem was that support for PATA ports on Promise mixed SATA/PATA controllers
has still not made it upstream for 2.6.20, and the patch which was in Fedora's
2.6.19 kernels was lost during the rebase, now this has been applied:
Could this 'exceptional' treatment for the Promise mixed SATA/PATA controllers
also explain the bug report I originally submitted back in November regarding
the fact that the 'dmraid' section in the rc.sysinit script doesn't properly set
up partitions of disks mounted on the PATA part of the controller
(see bug # 216078 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=216078)
Given that these Promise controllers are effectively already using libata even
for PATA, any dmraid problems with them are likely to be closely related to
problems with dmraid in F7 (which uses libata for _all_ PATA drives), so
anything done there to fix this problem will probably also help with yours, if
it's ever backported.
Any idea when the next fixed kernel version will be released into the 'updates'
I am eager to use some of the other fixes in the 2.4.20 kernel but can't until
this Promise FastTrak issue is resolved.
Well, you can try 2932, which is up at:
In fact, that's what I'm going to do right now. :-)
I can confirm that kernel-2.6.20-1.2932.fc6 works here.
When will the kernel be moved over to updates? (because I use several 3rd party
kernel modules that won't be re-compiled until the kernel moves over to updates).
*** Bug 232547 has been marked as a duplicate of this bug. ***