On Mon, 13 Nov 2006 14:44:37 +0100
Remi <[email protected]> wrote:
> => Step 1 : with the patch applied, the resource of the pci device
> dev->resource[x] are initialized to claim legacy I/O ports from 0x01f0 up to
> 0x01f7 with the flag IORESOURCE_IO (drivers/pci/probe.c).
This is correct behaviour. The resource addresses are implied resources.
> => Step 2 : then, these resources are allocated from the I/O port resources, by
> pcibios_allocate_resources (arch/i386/pci/i386.c).
That is correct, the implied resources end up in the tree as they should
so we now have a correct map of the PCI resources
> which requests the same resources but with the IORESOURCE_BUSY flag. I/O ports
> resources are then :
>
> 01f0-01f7 : 0000:00:1f.2
> 01f0-01f7 : libata
This is an ugly hack that is done by the libata code to deal with old v
new IDE handling. All is still correct however
>
> => Step 4 : then the libata tries to allocate once more the same ressources and
> fails.
>
> [<f00e3eed>] ata_pci_init_one+0xad/0x423 [libata]
> [<f001f9c1>] piix_init_one+0x4b7/0x4d4 [ata_piix]
ata_pci_init_one should have followed the legacy_mode path at this point,
and the legacy mode path should not be trying to request the legacy
regions the quirk code already reserved.
I suspect the code should only do the pci_request_regions() call if the
device on if (!legacy_mode), and the legacy code should
pci_request_region(pdev, 4, ...);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
