Bug 123087 - Dell PowerEdge 750: SATA drives not recognized by RHEL3U2 or FC2
Dell PowerEdge 750: SATA drives not recognized by RHEL3U2 or FC2
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Jeff Garzik
Depends On:
  Show dependency treegraph
Reported: 2004-05-12 03:15 EDT by Jonathan Chan
Modified: 2014-01-21 17:49 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-08-27 13:44:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
ata_piix.c.patch (778 bytes, patch)
2004-06-03 14:29 EDT, Matt Domsch
no flags Details | Diff
Picture of I/O Errors (503.31 KB, image/jpeg)
2004-07-19 17:43 EDT, Bill Peck
no flags Details
contrast adjusted (490.09 KB, image/jpeg)
2004-07-19 18:08 EDT, Bill Peck
no flags Details

  None (edit)
Description Jonathan Chan 2004-05-12 03:15:32 EDT
Description of problem:

In a Dell PowerEdge 750, the SATA harddisk cannot be reconized by the 
kernel (causing a kernel panic) if the cdrom drive is taken away.

If the cdrom drive is put back, everything works fine!!!

Interesting enough, if I use the ata-piix driver provided by the Dell 
CDROM, it works fine with Fedora core 1 if I detach the cdrom drive.

I have tried Fedora core 1 and core 2 test 3, Mandrake 10.0 and 
Debian Dell-specific cd image, they all have the same problem!!!

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

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Jonathan Chan 2004-05-12 03:16:16 EDT
These are the output before the kernel panic:

VFS: Mounted root (ext2 filesystem).
Red Hat nash version 3.5.21 starting
SCSI subsystem initialized
ata_piix: combined mode detected
ACPI: No IRQ known for interrupt pin A of device 0000:00:1f.2
ata1: PATA max UDMA/33 cdm 0x1F0 ctl 0x3F6 bmdma 0xFEA0 irq 14
ata1: port disabled. ignoring.
scsi0: ata_piix
Using cfq io scheduler
ata2: SATA max UDMA/133 cdm 0x170 ctl 0x376 bmdma 0xFEA8 irq 15
ata2: port disabled. ignoring.
scsi1 : ata_piix
VFS: Cannot open root device "LABEL=/" or unknown-block(0,0)
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on unknown-block(0,0)

Comment 2 Jonathan Chan 2004-05-16 21:17:30 EDT
This problem has been notified to the developer of ata_piix and 
hopefully a fix will be available for kernel 2.6.

A patch for kernel 2.4 is available from Dell.
Comment 3 Matt Domsch 2004-06-03 14:29:00 EDT
Created attachment 100848 [details]

From Stuart Hayes @ Dell.
A Poweredge 750 will not boot to or install RHEL3U2 using one SATA drive and no
CD-ROM drive is present.

ata_piix is disabling the SATA channel.

It appears that code in piix_sata_phy_reset() is checking to see if I/O
decoding is enabled in ICH5 config register 41h/43h (bit 7), and, if not, it is
disabling the port.  *However*, it is checking config register 41h for our SATA
port, even though our SATA is the secondary controller in combined mode, and is
at 170h (that is to say, it SHOULD be checking the config register at 43h, not
at 41h, for SATA).  Since our PATA controller has no CD-ROM, config register
41h shows the port to be disabled.
Comment 4 Seth Vidal 2004-06-03 14:31:09 EDT
 what are odds on this patch: 
1. getting into upstream 2.6
2. getting into a test-update kernel for fc2?
3. getting into a kernel update for RHEL3?

Comment 5 Colin Walters 2004-06-03 21:19:40 EDT
Hm.  This patch doesn't apply to the FC2 kernel.  Which kernel is this
patch against?
Comment 6 Colin Walters 2004-06-04 16:48:52 EDT
Ok, the patch does apply with just a very slight massaging.  However
it does not work.  I get the exact same error.
Comment 7 Colin Walters 2004-06-04 16:49:28 EDT
Oh by the way, Matt Domsch says the patch is relative to RHEL3U2. 
Perhaps there is more code in RHEL3U2 that isn't in the FC2 kernel?
Comment 8 Colin Walters 2004-06-08 19:14:40 EDT
Ok, I can confirm that RHEL3U1 works still on this machine.

However I do get the following output:
ata_piix version 0.93
ata_piix combined mode detected
abnormal status 0XFF on port 0X1F7
ata1: PATA max udma/33 cmd 0X1F0 ctl 0X3F6 bmdma
ata1 is slow to respond, please be patient
Comment 9 Colin Walters 2004-06-08 19:19:30 EDT
Two other things I forgot to mention in the last update:

The patch Matt forwarded does not work for me - I get the exact same

I also tried pulling the libata updates from:

However this didn't work either, same output :/
Comment 10 Colin Walters 2004-06-12 19:51:29 EDT
Ok, I take that back.  I must have not built the initrd correctly. 
After starting from scratch, applying the patch to the FC2 kernel and
rebuilding the initrd, I can confirm the patch works!  My SATA drives
are correctly recognized, and I can go through anaconda.  However upon
reboot it fails, presumably because the stock kernel rpm was
installed.   I'm trying to rebuild that now.

But it would be great if this patch could be applied.
Comment 11 sink 2004-06-17 16:39:37 EDT
DEll Poweredge 750, installed FC2, works/boots ok with 2.6.5-1.358smp

following messages indicate the ATA/adapter type etc..using .358smp

Red Hat/Adaptec aacraid driver (1.1.2-lk1 May  8 2004)
AAC0: kernel 4.1.4 build 7028
AAC0: monitor 4.1.4 build 7028
AAC0: bios 4.1.0 build 7028
AAC0: serial bb63bffafaf001
scsi0 : aacraid
Vendor: DELL      Model: CERC Mirror       Rev: V1.0
Type:   Direct-Access                      ANSI SCSI revision: 02
SCSI device sda: 488213504 512-byte hdwr sectors (249965 MB)
sda: Write Protect is off
SCSI device sda: drive cache: write through
sda: sda1 sda2 sda3 sda4 < sda5 >
Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0
ata_piix: combined mode detected
ACPI: No IRQ known for interrupt pin A of device 0000:00:1f.2
ata: 0x1f0 IDE port busy
ata1: SATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xFEA8 irq 15
ata1: SATA port has no device.
sink kernel: scsi1 : ata_piix

when I update the kernel to the latest Fedora Core (2.6.6-1.435smp),
system will not boot..kernel panics..the symptoms are similar to the 
above thread.. so am not sure what got broken or changed for
this raid controller/devices in this kernel..
same panic behaviour with the previous release of FC2 kernel
2.6.6-1.427smp..so only works with the default/stock one came on FC2
CD disks/release..

this behaviour is not dependent on CDROM drive for me..

any solutions or fixes??..or need to keep working with srock .358smp..
especially with the latest kernel security fixes..

Comment 12 Tramada 2004-07-19 12:44:53 EDT
This bug or a related bug causes a panic on boot, with kernel
2.4.21-15.0.3 on Dell 750 SATA, where as, for example, 2.4.21-9.0.3 is
fine.  Both refer to RHEL3 ES.  Systems are not in an environment that
lends itself to application of the supplied source patch.
Comment 13 Bill Peck 2004-07-19 17:40:38 EDT
Experiencing a similar problem in Westford QA.

Manufacturer: Dell Computer Corporation
Product Name: PowerEdge 750
00:1f.2 IDE interface: Intel Corp. 6300ESB SATA Storage Controller
(rev 02)

But this system boots fine with RHEL3U2 and FC2.  Its the latest
RHEL3U3 that fails.

Kernel : 2.4.21-17.EL RHEL3-U3-Beta-RC-re0715.0/i386/i386-as

Here is the dmesg on the working system..

SCSI subsystem driver Revision: 1.00
libata version 1.01 loaded.
ata_piix version 1.00
ata_piix: combined mode detected
ata: 0x1f0 IDE port busy
PCI: Setting latency timer of device 00:1f.2 to 64
ata1: SATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xFEA8 irq 15
ata1: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4003 85:7c69 86:3e01
87:4003 88:207f
ata1: dev 0 ATA, max UDMA/133, 488281250 sectors (lba48)
ata1: dev 1 cfg 49:2f00 82:3469 83:7f21 84:4003 85:3469 86:3e01
87:4003 88:203f
ata1: dev 1 ATA, max UDMA/100, 488281250 sectors (lba48)
ata1: dev 0 configured for UDMA/100
ata1: dev 1 configured for UDMA/100
scsi0 : ata_piix
  Vendor: ATA       Model: Maxtor 7Y250M0    Rev: 1.01
  Type:   Direct-Access                      ANSI SCSI revision: 05
  Vendor: ATA       Model: WDC WD2500JD-75G  Rev: 1.01
  Type:   Direct-Access                      ANSI SCSI revision: 05
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
Attached scsi disk sdb at scsi0, channel 0, id 1, lun 0
SCSI device sda: 488281250 512-byte hdwr sectors (250000 MB)
Partition check:
 sda: sda1 sda2 sda3
SCSI device sdb: 488281250 512-byte hdwr sectors (250000 MB)

I'll attach a jpeg of the failing kernel...
Comment 14 Bill Peck 2004-07-19 17:43:30 EDT
Created attachment 102056 [details]
Picture of I/O Errors
Comment 15 Bill Peck 2004-07-19 18:08:35 EDT
Created attachment 102059 [details]
contrast adjusted

Modified for users viewing from laptop in the sun. ;-)
Comment 16 Tramada 2004-07-26 20:18:05 EDT
Since this was 'broken' after previous working kernels, and since the
Dell PowerEdge 750 has a 'Certified' status for RHEL3, an ETA on
errata release of the patch would be much appreciated.  If an ETA or
release schedule for this is already available, where can it be found?
Comment 17 Colin Walters 2004-07-26 21:53:34 EDT
I'd also appreciate a lot if the patch could go in a FC2 kernel update
at some point.  I've had to ignore the FC2 kernel updates since they
wouldn't boot my machine...
Comment 18 Colin Walters 2004-08-11 00:28:20 EDT
Matt - the patch conflicts with the latest work in Linux 2.6.7. It
looks like quite a nontrivial conflict.  Do you think you might be
able to get an updated patch?

Comment 19 Colin Walters 2004-08-26 23:24:01 EDT
Bill - do you know if the latest U3 fixes this bug?
Comment 20 Matt Domsch 2004-08-27 13:09:26 EDT
Yes, RHEL3 U3 kernel 2.4.21-20.EL, when publicly available, fixes this.
Comment 21 Colin Walters 2004-08-27 13:44:55 EDT
I can confirm it works with the latest FC2 kernel update too.  Thanks
Comment 22 Tramada 2004-09-02 21:08:00 EDT
We have tested with the just released 2.4.21-20.EL ( SMP, RHEL3 ) and
can confirm that the issue decribed above is resolved.  Thanks!

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