On Sat, 2012-09-15 at 21:15 +0200, Stephan Schreiber wrote:
> Hi Jonathan,
>
> > I think we should not do that, if at all possible. The old IDE
> > subsystem has a number of problems --- e.g., see
> >
> > http://www.mail-archive.com/stable@vger.kernel.org/msg15564.html
> >
> > for a recent report.
>
> thanks for pointing me to the right direction ;-).
>
> Back to the unmodified Debian Wheezy kernel.
>
> I realized that ata_piix also has a support for the ICH4-L
> (8086:24cb)
That device ID is documented as being for ICH-4, actually. Though the
PCI device list in your initial bug report was missing many of the PCI
functions that are supposed to be part of the ICH-4 (even fewer than are
included in the L variant).
> but it couldn't initialize.
> A snippet from dmesg:
> ...
> [ 0.065516] pci 0000:00:1f.1: [8086:24cb] type 0 class 0x000101
> [ 0.065530] pci 0000:00:1f.1: reg 10: [io 0x0000-0x0007]
> [ 0.065541] pci 0000:00:1f.1: reg 14: [io 0x0000-0x0003]
> [ 0.065552] pci 0000:00:1f.1: reg 18: [io 0x0000-0x0007]
> [ 0.065563] pci 0000:00:1f.1: reg 1c: [io 0x0000-0x0003]
> [ 0.065574] pci 0000:00:1f.1: reg 20: [io 0x1000-0x100f]
> [ 0.065585] pci 0000:00:1f.1: reg 24: [mem 0x00000000-0x000003ff]
> ...
> [ 1.640965] libata version 3.00 loaded.
> [ 1.641656] ata_piix 0000:00:1f.1: version 2.13
> [ 1.641671] ata_piix 0000:00:1f.1: device not available (can't
> reserve [mem 0x00000000-0x000003ff])
> [ 1.641747] ata_piix: probe of 0000:00:1f.1 failed with error -22
> ...
I would expect the kernel to fix this up - not sure why this isn't being
done.
By the way, the reason the old IDE driver worked is that
drivers/ide/setup-pci.c has a fallback for this:
if (pci_enable_device(dev)) {
ret = pci_enable_device_io(dev);
It was added almost exactly 10 years ago without any specific comment.
[...]
> The ICH4-L IDE works with the ata_piix module now. The DVD drive
> works
> without a flaw.
> What do think about the patch?
> diff -ur linux-3.2.23-old/arch/ia64/pci/fixup.c linux-3.2.23/arch/ia64/pci/fixup.c
> --- linux-3.2.23-old/arch/ia64/pci/fixup.c 2012-09-15 10:53:02.000000000 +0200
> +++ linux-3.2.23/arch/ia64/pci/fixup.c 2012-09-15 10:59:43.000000000 +0200
> @@ -67,3 +67,42 @@
> }
> }
> DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, pci_fixup_video);
> +
> +
> +/*
> + * Fixup the EFI-BIOS bug of Intel's SR870 platform
It's just 'EFI', it has nothing to do with the PC BIOS.
> + * The EFI-BIOS of Intel's SR870BH2 and SR870BN4 including their OEM
> + * equivalents by Fujitsu and Dell doesn't configure the built-in ICH4-L IDE
> + * hostadapter correctly. The 6th resource of the ICH4-L is a memory resource;
> + * Intel's datasheet "Intel 82801DB I/O Controller Hub 4 (ICH4)" (Document
> + * Number: 290744-001) states in section "10.1.15 EXBAR - Expansion Base
> + * Address Register (IDE-D31:F1)" on page 389:
> + * "This is a memory mapped BAR that requires 1 KB of DWord-aligned memory
> + * that is Intel reserved for future functionality. BIOS needs to program the
> + * base address for a 1-KB memory space."
> + * The EFI-BIOS doesn't care about that and doesn't configure the memory
> + * resource. Since the PCI configuration registers have their default values
> + * after reset, the memory resource is configured with 0x0-0x3FF. The Kernel
> + * can't use it due to memory address conflicts, and the ata_piix driver fails
> + * to initialize.
> + *
> + * This quirk function disables the EXBAR memory resource of the device if it
> + * has the default values after reset.
> + */
This is perhaps too verbose. And the Intel documentation doesn't even
make sense (PCI memory BARs always have the same size and alignment, so
1K size implies 1K alignment). I would summarise it as:
"The ICH-4 has an memory BAR for expansion (EXBAR), and ata_piix uses
pcim_enable_device() which enables this along with the I/O BARs.
In systems based on the Intel SR870 platform the firmware does not
initialise the EXBAR and pcim_enable_device() fails because the memory
region 0x0-0x3FF cannot be allocated. Since nothing uses the EXBAR, we
hide it so that only the I/O BARs will be enabled."
> +static void __devinit pci_fixup_sr870_ich4l(struct pci_dev *pdev)
> +{
> + struct resource *r;
> +
> + r = &pdev->resource[5];
> + if ((r->flags & IORESOURCE_MEM)
> + && r->start == 0 && r->end != 0) {
> + dev_info(&pdev->dev,
> + "SR870 EFI-BIOS bug workaround; fake an unimplemented EXBAR "
> + "resource, which is Intel reserved for future functionality.\n");
I don't think it's necessary to log this long message.
> + r->flags = 0;
> + r->end = 0;
> + }
> +}
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801DB_11, pci_fixup_sr870_ich4l);
This seems like it should work, and you have evidence that it does. :-)
But I wonder whether there is a cleaner way that would result in the BAR
being properly reprogrammed.
Anyway: please send your patch to linux-ia64@vger.kernel.org, cc'ing
linux-pci@vger.kernel.org and this bug report, and following the
instructions in Documentation/SubmittingPatches. In particular:
1. Put the patch inline, not as an attachment.
2. Include the Developer's Certificate of Origin.
3. Include a summary (in the subject) and longer description (in the
body) of the problem you're fixing.
4. Indent the new code with tabs (so far as possible).
5. Last line should be wrapped before 80 characters.
Ben.
--
Ben Hutchings
Logic doesn't apply to the real world. - Marvin Minsky
Attachment:
signature.asc
Description: This is a digitally signed message part