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: 1. 2. 3. Actual results: Expected results: Additional info:
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)
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.
Created attachment 100848 [details] ata_piix.c.patch 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.
Arjan, 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? thanks
Hm. This patch doesn't apply to the FC2 kernel. Which kernel is this patch against?
Ok, the patch does apply with just a very slight massaging. However it does not work. I get the exact same error.
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?
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
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 output. I also tried pulling the libata updates from: http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/2.6.6-rc2-bk3-libata2.patch.bz2 However this didn't work either, same output :/
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.
DEll Poweredge 750, installed FC2, works/boots ok with 2.6.5-1.358smp kernel. following messages indicate the ATA/adapter type etc..using .358smp kernel --- 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.. TIA
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.
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) sdb: I'll attach a jpeg of the failing kernel...
Created attachment 102056 [details] Picture of I/O Errors
Created attachment 102059 [details] contrast adjusted Modified for users viewing from laptop in the sun. ;-)
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?
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...
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? Thanks!
Bill - do you know if the latest U3 fixes this bug?
Yes, RHEL3 U3 kernel 2.4.21-20.EL, when publicly available, fixes this.
I can confirm it works with the latest FC2 kernel update too. Thanks Jeff!
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!