Description of problem: I found what libata and ata_piix modules in RHEL5.2 kernel cannot properly recognize the SATA storage at intel Q33 chipset. This is same of the following reports. http://www.centos.org/modules/newbb/viewtopic.php?topic_id=16334 SATA is recognized a hd* device, but I use kernel option "ide0=noprobe ide1=noprobe", a sd* device. When SATA is recognized a hd* device, the bus speed is 3MB/s. Fedora8's kernlel recognizes normaly, a sd* device. Version-Release number of selected component (if applicable): Red Hat EL 5.2 2.6.18-92.el5 How reproducible: RHEL5.2 install on the following machine. HP Compaq dx7400 http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&objectID=c01155744&jumpid=reg_R1002_USEN Actual results: The following messages appeares at boot. -- ... ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx Probing IDE interface ide0... hda: ST3250310AS, ATA DISK drive Probing IDE interface ide1... hdc: HL-DT-ST DVD-RAM GH15L, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: max request size: 512KiB hda: 488397168 sectors (250059 MB) w/8192KiB Cache, CHS=30401/255/63 hda: cache flushes supported hda: hda1 hda2 ...(snip) SCSI subsystem initialized libata version 3.00 loaded. ata_piix 0000:00:1f.2: version 2.12 ata_piix 0000:00:1f.2: MAP [ P0 -- P1 -- ] ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 19 (level, low) -> IRQ 225 ata_piix 0000:00:1f.2: 0x1F0 IDE port busy ata_piix 0000:00:1f.2: 0x170 IDE port busy ata_piix 0000:00:1f.2: no available legacy port ata_piix 0000:00:1f.5: MAP [ P0 -- P1 -- ] ACPI: PCI Interrupt 0000:00:1f.5[A] -> GSI 19 (level, low) -> IRQ 225 PCI: Setting latency timer of device 0000:00:1f.5 to 64 scsi0 : ata_piix scsi1 : ata_piix ata1: SATA max UDMA/133 cmd 0xf500 ctl 0xf400 bmdma 0xf100 irq 225 ata2: SATA max UDMA/133 cmd 0xf300 ctl 0xf200 bmdma 0xf108 irq 225 ... -- I attach my machines dmesg. Expected results: ex.) On Fedora8 at boot. -- ... SCSI subsystem initialized Driver 'sd' needs updating - please use bus_type methods libata version 3.00 loaded. ...(snip) ata_piix 0000:00:1f.2: version 2.12 ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 19 (level, low) -> IRQ 19 ata_piix 0000:00:1f.2: MAP [ P0 -- P1 -- ] PCI: Setting latency timer of device 0000:00:1f.2 to 64 scsi0 : ata_piix scsi1 : ata_piix ata1: SATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xf800 irq 14 ata2: SATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xf808 irq 15 ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata1.00: ATA-7: ST3250310AS, 3.AHB, max UDMA/100 ata1.00: 488397168 sectors, multi 16: LBA48 NCQ (depth 0/32) ata1.00: configured for UDMA/100 ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata2.00: ATAPI: HL-DT-ST DVD-RAM GH15L, RA02, max UDMA/100 ata2.00: configured for UDMA/100 scsi 0:0:0:0: Direct-Access ATA ST3250310AS 3.AH PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 488397168 512-byte hardware sectors (250059 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 488397168 512-byte hardware sectors (250059 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sd 0:0:0:0: [sda] Attached SCSI disk scsi 1:0:0:0: CD-ROM HL-DT-ST DVD-RAM GH15L RA02 PQ: 0 ANSI: 5 ACPI: PCI Interrupt 0000:00:1f.5[A] -> GSI 19 (level, low) -> IRQ 19 ata_piix 0000:00:1f.5: MAP [ P0 -- P1 -- ] PCI: Setting latency timer of device 0000:00:1f.5 to 64 scsi2 : ata_piix scsi3 : ata_piix ata3: SATA max UDMA/133 cmd 0xf500 ctl 0xf400 bmdma 0xf100 irq 19 ata4: SATA max UDMA/133 cmd 0xf300 ctl 0xf200 bmdma 0xf108 irq 19 ata3: SATA link down (SStatus 0 SControl 300) ata4: SATA link down (SStatus 0 SControl 300) ... -- Additional info: This problem is possible to avoid by setting "ide0=noprobe ide1=noprobe" in the kernel arguments. But I think that to fix kernel is better.
Created attachment 330964 [details] /var/log/dmesg at this problem
Hi, This is a result of RHEL5 supporting combined mode where the IDE driver may claim the device(s) if the SATA controller is setup in IDE mode. And in this case, any devices controlled by the IDE driver will be in PIO mode which explains your slow throughput. In RHEL5, in order to have libata (ata_piix) claim the devices and run them in DMA mode, you will need to use the "ideX=noprobe" kernel parameter, or "combined_mode=libata" or if possible set the SATA controller in AHCI mode and let the ahci driver control the devices. The combined mode has been removed in the upstream kernels, but, we have to maintain it for RHEL5. The only kernel change we can make for RHEL5 is if the "combine_mode" parameter doesn't work, in that case re-open this BZ and supply your PCI device IDS and I can supply a test kernel. Thanks.
Hi, I practiced the "combine_mode" parameter on RHEL5, but didn't change occuring. When I set the "ideX=noprobe" kernel parameter, it works to be good. I attach dmesg when I set the "combine_mode" parameter.
Created attachment 332165 [details] /var/log/dmesg file when I set the "combine_mode" parameter. /var/log/dmesg file when I set the "combine_mode" parameter on RHEL5. Following is /proc/cmdline: ro root=LABEL=/ rhgb quiet elevator=deadline combined_mode=libata Following is "uname -a": Linux osspc015b 2.6.18-128.el5 #1 SMP Wed Dec 17 11:42:39 EST 2008 i686 i686 i386 GNU/Linux
Ok, thanks. Would you also attach the output of "lspci -vvxxx"?
Created attachment 332521 [details] lspci -vvxxx on Intel Q33 SATA Hi, Thanks you for the reaction. I get the output of "lspci -vvxxx", so it attaches. It shall be good if this output helps you.
Hi, Would you please boot kernel-2.6.18-131.el5.bz484173.1 with the "combined_mode=libata" kernel parameter and attach the dmesg output after booting? This test kernel will print out the combined mode register for your sata ide controller. Thank you. http://people.redhat.com/dmilburn/
Hi, Thanks you for test kernel. I will boot this on the reproducible environment, and report the result afresh.
Created attachment 334596 [details] dmesg on the test kernel Hi, This is boot dmesg on the test kernel 2.6.18-131.el5. best regards,
Hi, Our previous quirks to handle this for ich6, ich7, and ich8 read the map address register (0x90) and look at bits 1:0 to determine if configured in combined mode. I was not expecting this register to return 0x0 for the 8086:2921 device in your configuration, looking at the ich9 documentation we may not be able to depend on that register value to setup a quirk, I will need to investigate furthur.
Hi, I have looked thru the ICH9 documentation, the SATA controller has three different modes of operation - Native IDE, legacy, and ahci/raid. In order for us to quirk off the Map Address Register (0x90) your BIOS would have to configure the SATA controller in Legacy or Combined mode. If you have a system that you can experiment on, if the system BIOS will allow you to change the mode to legacy you could try the test kernel (Comment #7) with the kernel parameter "combined_mode=libata". Another possibility is changing the setting to ahci mode if possible, of course you would need to make sure ahci driver is loaded in your initrd. If neither of those options works out, then you will probably have to continue using the "ideX=noprobe" option. Please be careful changing any BIOS settings, you probably want to try this only on a test system at first.
We inquired of the support charge of HP Desktop. HP's support said, "The BIOS setting of HP Compaq Business Desktop dx7400 MT (Intel Q33 Express (ICH9)) doesn't have AHCI or Legacy or Combined mode. It is not possible to correspond to various modes even if the BIOS is updated." Therefore, we hope to corrected to work normaly without "ide[01]=noprobe".
It is the same matter as the content contributed of "NAKANO hiroaki <nakano.hiroaki.co.jp>".
Sorry, we will not be able to change this behavior in RHEL5, please continue to use the "ideX=noprobe" option on the kernel command line.
I see. We gave up fixing it this time. To execute the alternate solution (ide[01]=noprobe), we want to persuade our customer.