Revision 93d2175d3d31f11ba04fcfa0e9a496a1b4bc8b34 authored by Yinghai Lu on 14 May 2011, 01:06:17 UTC, committed by Linus Torvalds on 17 May 2011, 01:33:35 UTC
During pci remove/rescan testing found:
pci 0000:c0:03.0: PCI bridge to [bus c4-c9]
pci 0000:c0:03.0: bridge window [io 0x1000-0x0fff]
pci 0000:c0:03.0: bridge window [mem 0xf0000000-0xf00fffff]
pci 0000:c0:03.0: bridge window [mem 0xfc180000000-0xfc197ffffff 64bit pref]
pci 0000:c0:03.0: device not available (can't reserve [io 0x1000-0x0fff])
pci 0000:c0:03.0: Error enabling bridge (-22), continuing
pci 0000:c0:03.0: enabling bus mastering
pci 0000:c0:03.0: setting latency timer to 64
pcieport 0000:c0:03.0: device not available (can't reserve [io 0x1000-0x0fff])
pcieport: probe of 0000:c0:03.0 failed with error -22
This bug was caused by commit c8adf9a3e873 ("PCI: pre-allocate
additional resources to devices only after successful allocation of
essential resources.")
After that commit, pci_hotplug_io_size is changed to additional_io_size
from minium size. So it will not go through resource_size(res) != 0
path, and will not be reset.
The root cause is: pci_bridge_check_ranges will set RESOURCE_IO flag for
pci bridge, and later if children do not need IO resource. those bridge
resources will not need to be allocated. but flags is still there.
that will confuse the the pci_enable_bridges later.
related code:
static void assign_requested_resources_sorted(struct resource_list *head,
struct resource_list_x *fail_head)
{
struct resource *res;
struct resource_list *list;
int idx;
for (list = head->next; list; list = list->next) {
res = list->res;
idx = res - &list->dev->resource[0];
if (resource_size(res) && pci_assign_resource(list->dev, idx)) {
...
reset_resource(res);
}
}
}
At last, We have to clear the flags in pbus_size_mem/io when requested
size == 0 and !add_head. becasue this case it will not go through
adjust_resources_sorted().
Just make size1 = size0 when !add_head. it will make flags get cleared.
At the same time when requested size == 0, add_size != 0, will still
have in head and add_list. because we do not clear the flags for it.
After this, we will get right result:
pci 0000:c0:03.0: PCI bridge to [bus c4-c9]
pci 0000:c0:03.0: bridge window [io disabled]
pci 0000:c0:03.0: bridge window [mem 0xf0000000-0xf00fffff]
pci 0000:c0:03.0: bridge window [mem 0xfc180000000-0xfc197ffffff 64bit pref]
pci 0000:c0:03.0: enabling bus mastering
pci 0000:c0:03.0: setting latency timer to 64
pcieport 0000:c0:03.0: setting latency timer to 64
pcieport 0000:c0:03.0: irq 160 for MSI/MSI-X
pcieport 0000:c0:03.0: Signaling PME through PCIe PME interrupt
pci 0000:c4:00.0: Signaling PME through PCIe PME interrupt
pcie_pme 0000:c0:03.0:pcie01: service driver pcie_pme loaded
aer 0000:c0:03.0:pcie02: service driver aer loaded
pciehp 0000:c0:03.0:pcie04: Hotplug Controller:
v3: more simple fix. also fix one typo in pbus_size_mem
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Reviewed-by: Ram Pai <linuxram@us.ibm.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
1 parent df8d06a
Kconfig
#
# Configuration for initramfs
#
config INITRAMFS_SOURCE
string "Initramfs source file(s)"
default ""
help
This can be either a single cpio archive with a .cpio suffix or a
space-separated list of directories and files for building the
initramfs image. A cpio archive should contain a filesystem archive
to be used as an initramfs image. Directories should contain a
filesystem layout to be included in the initramfs image. Files
should contain entries according to the format described by the
"usr/gen_init_cpio" program in the kernel tree.
When multiple directories and files are specified then the
initramfs image will be the aggregate of all of them.
See <file:Documentation/early-userspace/README> for more details.
If you are not sure, leave it blank.
config INITRAMFS_ROOT_UID
int "User ID to map to 0 (user root)"
depends on INITRAMFS_SOURCE!=""
default "0"
help
This setting is only meaningful if the INITRAMFS_SOURCE is
contains a directory. Setting this user ID (UID) to something
other than "0" will cause all files owned by that UID to be
owned by user root in the initial ramdisk image.
If you are not sure, leave it set to "0".
config INITRAMFS_ROOT_GID
int "Group ID to map to 0 (group root)"
depends on INITRAMFS_SOURCE!=""
default "0"
help
This setting is only meaningful if the INITRAMFS_SOURCE is
contains a directory. Setting this group ID (GID) to something
other than "0" will cause all files owned by that GID to be
owned by group root in the initial ramdisk image.
If you are not sure, leave it set to "0".
config RD_GZIP
bool "Support initial ramdisks compressed using gzip" if EXPERT
default y
depends on BLK_DEV_INITRD
select DECOMPRESS_GZIP
help
Support loading of a gzip encoded initial ramdisk or cpio buffer.
If unsure, say Y.
config RD_BZIP2
bool "Support initial ramdisks compressed using bzip2" if EXPERT
default !EXPERT
depends on BLK_DEV_INITRD
select DECOMPRESS_BZIP2
help
Support loading of a bzip2 encoded initial ramdisk or cpio buffer
If unsure, say N.
config RD_LZMA
bool "Support initial ramdisks compressed using LZMA" if EXPERT
default !EXPERT
depends on BLK_DEV_INITRD
select DECOMPRESS_LZMA
help
Support loading of a LZMA encoded initial ramdisk or cpio buffer
If unsure, say N.
config RD_XZ
bool "Support initial ramdisks compressed using XZ" if EXPERT
default !EXPERT
depends on BLK_DEV_INITRD
select DECOMPRESS_XZ
help
Support loading of a XZ encoded initial ramdisk or cpio buffer.
If unsure, say N.
config RD_LZO
bool "Support initial ramdisks compressed using LZO" if EXPERT
default !EXPERT
depends on BLK_DEV_INITRD
select DECOMPRESS_LZO
help
Support loading of a LZO encoded initial ramdisk or cpio buffer
If unsure, say N.
choice
prompt "Built-in initramfs compression mode" if INITRAMFS_SOURCE!=""
help
This option decides by which algorithm the builtin initramfs
will be compressed. Several compression algorithms are
available, which differ in efficiency, compression and
decompression speed. Compression speed is only relevant
when building a kernel. Decompression speed is relevant at
each boot.
If you have any problems with bzip2 or LZMA compressed
initramfs, mail me (Alain Knaff) <alain@knaff.lu>.
High compression options are mostly useful for users who are
low on RAM, since it reduces the memory consumption during
boot.
If in doubt, select 'gzip'
config INITRAMFS_COMPRESSION_NONE
bool "None"
help
Do not compress the built-in initramfs at all. This may
sound wasteful in space, but, you should be aware that the
built-in initramfs will be compressed at a later stage
anyways along with the rest of the kernel, on those
architectures that support this.
However, not compressing the initramfs may lead to slightly
higher memory consumption during a short time at boot, while
both the cpio image and the unpacked filesystem image will
be present in memory simultaneously
config INITRAMFS_COMPRESSION_GZIP
bool "Gzip"
depends on RD_GZIP
help
The old and tried gzip compression. It provides a good balance
between compression ratio and decompression speed.
config INITRAMFS_COMPRESSION_BZIP2
bool "Bzip2"
depends on RD_BZIP2
help
Its compression ratio and speed is intermediate.
Decompression speed is slowest among the four. The initramfs
size is about 10% smaller with bzip2, in comparison to gzip.
Bzip2 uses a large amount of memory. For modern kernels you
will need at least 8MB RAM or more for booting.
config INITRAMFS_COMPRESSION_LZMA
bool "LZMA"
depends on RD_LZMA
help
The most recent compression algorithm.
Its ratio is best, decompression speed is between the other
three. Compression is slowest. The initramfs size is about 33%
smaller with LZMA in comparison to gzip.
config INITRAMFS_COMPRESSION_XZ
bool "XZ"
depends on RD_XZ
help
XZ uses the LZMA2 algorithm. The initramfs size is about 30%
smaller with XZ in comparison to gzip. Decompression speed
is better than that of bzip2 but worse than gzip and LZO.
Compression is slow.
config INITRAMFS_COMPRESSION_LZO
bool "LZO"
depends on RD_LZO
help
Its compression ratio is the poorest among the four. The kernel
size is about 10% bigger than gzip; however its speed
(both compression and decompression) is the fastest.
endchoice
Computing file changes ...
