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):
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
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.
PNP BIOS present.
RSD PTR found at 0xF5D00
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