Red Hat Bugzilla – Bug 62031
New IDE controller not recognized
Last modified: 2007-04-18 12:41:14 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.2.1) Gecko/20010901 Description of problem: The PIIX derived IDE controller in the Intel i7500 chipset used in dual P4 Xeon systems is not recognized by the IDE driver. UDMA5 and DMA are not enabled as a result and performance suffers dramatically. The new PCI ID's are VID: 8086 DID: 248b Will attach syslog from installer BOOT kernel when install completes. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Boot skipjack on i7500 based motherboard Actual Results: As reported by /proc/ide/hda/settings: current_speed = 0 using_dma = 0 Expected Results: current_speed = 69 using_dma = 1 Additional info:
Created attachment 50684 [details] Portion of /tmp/syslog from installer
I would have included the entire syslog, but as the install completed, I got a spew of EEPRO100_WAIT_FOR_CMD timeouts and the machine locked up. I was doing an NFS install.
Assuming that the new DID:248b is the same as DID:248a, I have created the attached patch. This causes the PCI device to be identitfied as a PIIX4, but still no joy due to a "resource collision". Not sure how to track down the resource collision. DMIDECODE reports "checksum error" and fails to print much of any use to me. # dmidecode PNP BIOS present. RSD PTR found at 0xF5D00 checksum failed. OEM ACPIAM Any ideas on how to track down the resource collision?
Created attachment 50765 [details] Patch to make piix.c service 8086:248b
Created attachment 50766 [details] dmesg from patched kernel
Resource collisions are bios bugs....
We need to get confirmation from one of the ide people that this chip in deed is a piix4; this might or might not make the release..... at least it works even without the ident.
please test 2.4.18-0.19 or 2.4.18-0.20 in rawhide It should have this working (some of these messages are still bios bugs it seems, but unavoidable if the hw needs to pass MSFT certification)
I find 2.4.18-0.21 in Rawhide today. Will download it then install skipjack/beta4 and that kernel and see what happens. Is there a new dmidecode as well? What are the MSFT compatibility issues?
No new dmidecode; that looks like a bios bug Microsoft seems to require the PCI BAR's to be in a certain state (off mostly :) and ACPI is the only thing that can enable them then.
any news on the kernel ?
Sorry for the delay... The 0.21 kernel did not solve the problem. However, the following sledgehammer of a patch did... Basically, I told the pci-i386.c functions to ignore the fact that a region on a PCI device had not been allocated an address. Reading the Intel specs for the 82801CA chip suggest that it has a "legacy" and "native" mode now where the first 4 regions (0 to 3) can be used to decode the command and control registers for the primary and secondary interfaces independantly. Perhaps this makes a device driver easier to write? In any case, this would seem to clearly suggest that Tyan's got a BIOS bug. They either need to allocate the regions, or disable them. Either way, the Linux device driver doesn't (currently) use them and won't care.
Created attachment 53904 [details] Disable PCI EINVAL on unallocated regions
Your change will cause random machine hangs
Correct fix in current errata