Bug 186557 - PCI: Cannot allocate resource region
Summary: PCI: Cannot allocate resource region
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 5
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
URL: http://www.fedoraforum.org/forum/show...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-03-24 12:24 UTC by milver nisay
Modified: 2015-01-04 22:26 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-11-12 05:44:57 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Complete output of dmesg... (19.24 KB, text/plain)
2006-07-07 06:08 UTC, Arthur Wilkinson
no flags Details

Description milver nisay 2006-03-24 12:24:16 UTC
Description of problem:
The message appears while booting FC4/FC5 right after the line 
that says "Uncompressing..."
PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.0
PCI: Cannot allocate resource region 8 of bridge 0000:00:1c.0
PCI: Cannot allocate resource region 9 of bridge 0000:00:1c.0


Version-Release number of selected component (if applicable):
Fedora Core 4 and 5

How reproducible:
Do fresh install FC4/FC5 with HP zd8000 (zd8342) notebook with
PCI/Express Card port/slot

Actual results:

dmesg shows (stripped) :
PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.0
PCI: Cannot allocate resource region 8 of bridge 0000:00:1c.0
PCI: Cannot allocate resource region 9 of bridge 0000:00:1c.0


Expected results:
Ideas or solutions why it should be appearing with dmesg afterall it was detected.

Additional info:

lspci (stripped) shows:
00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI
Express Port 1 (rev 03)

lspci (verbose/stripped) shows:
00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI
Express Port 1 (rev 03) (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0
        Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
        Capabilities: [40] Express Root Port (Slot+) IRQ 0
        Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-
        Capabilities: [90] #0d [0000]
        Capabilities: [a0] Power Management version 2
        Capabilities: [100] Virtual Channel
        Capabilities: [180] Unknown (5)


Passing acpi=noirq and pci=routeirq did not fix the issue.

When passing below parameters:
acpi=noirq - makes Gnome responses very poor. Clicking and choosing menus are
very slow, reading/writing to harddisk takes very slow.

pci=routeirq - same dmesg output with "cannot allocate", did not noticed any
differences after being logged-in with Gnome.

Comment 1 Arthur Wilkinson 2006-03-27 05:22:59 UTC
I have had the same issue on an 8000 series HP laptop with FC4, and on my new 
ASUS Z71V laptop with both FC4 and FC5.

It was the exact same PCI resource error. I have PCI-Express video, two cardbus 
slots, and a mini-PCI. I always assumed it was a resource allocation error on 
the two cardbus slots, and the mini-PCI, since none of them work, even with 
devices I used in my old laptop with FC4, and my video works fine (the high 
framerate in Quake4 is a testiment to that). I doubt it's caused by the PCI-
Express.

Since I had both Windows XP, SuSe 10, and Fedora Core 4 on the 8000 series HP 
laptop, and the wireless worked in Windows, and not in a single distro of Linux 
(not even Knoppix), I would have to surmise that this is a kernel level issue. 
The kernel doesn't seem to be capable of assigning the needed resources to the 
PCI/cardbus slots for them to be accessable.

Both of these laptops have ICH6 series motherboards. The ASUS has a 2GHz 
Pentium M, and DDR-2 memory. I also cannot install Linux off of the optical 
drive (I had to use an external), but it works fine when booted into FC4/FC5 
and using CD or DVD media. I think kernel support for this series of Intel 
motherboards is a little flaky. I've been looking for drivers, but have not 
been able to find them.


Comment 3 Arthur Wilkinson 2006-03-27 13:38:14 UTC
My initial description of the HP laptop I had first encountered this on was not 
acurate. I just realized this morning that it was an AMD Turion processor, and 
not an Intel. It had an ATI chipset, with integrated ATI video using shared 
memory, while the ASUS laptop has an Intel Pentium M, and as far as I know an 
Intel chipset with a PCI-Express GeForce card.

I will test the pcmciautils package when I get home tonight, and report on it's 
effectivness. Hopefully it will solve the problem, as I have never been able to 
get the cardbus or the mini-PCI to work on either of those laptops.

Comment 4 Arthur Wilkinson 2006-03-28 00:40:18 UTC
No, the changes made to /etc/pcmcia/config.opts by that updated package do not 
help. I believe that this is an issue assigning resources to the cardbus/mini-
PCI controllers themselves, and not the devices in them. It doesn't matter what 
is in my cardbus slot, I always get the error. I typically have nothing in my 
cardbus anyway, since it doesn't work. And I know the mini-PCI is empty, and I'
m not even sure how to get the second cardbus slot open on this laptop (still 
need to consult the instructions on that). I know it's a new form of cardbus, 
and that a standard cardbus card won't fit in it, but I don't remember what it'
s called.

Perhaps this issue is caused by the second cardbus slot? Since it's a new form 
of cardbus, it may be confusing either the kernel, or hotplug.


Comment 5 Arthur Wilkinson 2006-04-05 18:43:31 UTC
Updated to kernel version 2.6.16-1.2080_FC5 and problems still persist on the 
ASUS Z71V notebook.


Comment 6 milver nisay 2006-04-06 17:59:12 UTC
Oh, I need to test it asap!

Comment 7 milver nisay 2006-04-06 19:51:57 UTC
First of all, with default FC5 kernel, I do not have any boot and logging in 
problems with this issue. I can boot without hanging ups.

Now, upgraded my kernel version to 2.6.16-1.2080_FC5smp.
I still do not have any hanging ups issue. 
And still have the same results from dmesg of:
PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.0
PCI: Cannot allocate resource region 8 of bridge 0000:00:1c.0
PCI: Cannot allocate resource region 9 of bridge 0000:00:1c.0

Passed boot parameters pci=routeirq and acpi=noirq with and without the 
upgraded version of  pcmciautils, will show the same above dmesg.
With acpi=noirq will give me equal system performance of pentium 286 systems.

I am planning to play pcmciautils files, will post back.






Comment 8 Mike Cohler 2006-04-11 16:40:56 UTC
I am seeing this series of boot messages on a new Samsung Q35 (with Intel Core
Duo processor) running FC5 stock SMP kernel as above. i.e. the lines
PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.0
PCI: Cannot allocate resource region 8 of bridge 0000:00:1c.0
PCI: Cannot allocate resource region 9 of bridge 0000:00:1c.0
Appear during boot.  There is no kernel hangup though and the machine continues
to boot successfully.

I will try to gather further information and post back in a day or two.

Comment 9 Arthur Wilkinson 2006-04-12 21:20:03 UTC
Further information on the hardware configuration of my ASUS Z71V notebook. 
Hardware Browser says that my Cardbus slots are Ricoh Co Ltd RL5c476 II (and 
there are two of them in the list, and they are identical), using driver yenta_
socket.


Comment 10 jouni 2006-04-13 19:26:38 UTC
I am installing FC5 on brand new IBM xSeries 100 type 8486 server:

Apr 13 22:16:55 server kernel: PCI: Using ACPI for IRQ routing
Apr 13 22:16:55 server kernel: PCI: If a device doesn't work, try
"pci=routeirq".  If it helps, post a report
Apr 13 22:16:55 server kernel: PCI: Cannot allocate resource region 7 of bridge
0000:00:01.0
Apr 13 22:16:55 server kernel: PCI: Cannot allocate resource region 8 of bridge
0000:00:01.0
Apr 13 22:16:55 server kernel: PCI: Cannot allocate resource region 9 of bridge
0000:00:01.0
Apr 13 22:16:55 server kernel: PCI: Cannot allocate resource region 7 of bridge
0000:00:1c.1
Apr 13 22:16:55 server kernel: PCI: Cannot allocate resource region 8 of bridge
0000:00:1c.1
Apr 13 22:16:55 server kernel: PCI: Cannot allocate resource region 9 of bridge
0000:00:1c.1

lspci -v:
00:00.0 Host bridge: Intel Corporation E7230 Memory Controller Hub (rev 81)
        Subsystem: IBM Unknown device 02ef
        Flags: bus master, fast devsel, latency 0
        Capabilities: [e0] Vendor Specific Information

00:01.0 PCI bridge: Intel Corporation E7230 PCI Express Root Port (rev 81)
(prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
        Capabilities: [88] #0d [0000]
        Capabilities: [80] Power Management version 2
        Capabilities: [90] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-
        Capabilities: [a0] Express Root Port (Slot+) IRQ 0
        Capabilities: [100] Virtual Channel
        Capabilities: [140] Unknown (5)

00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1
(rev 01) (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0
        Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
        Memory behind bridge: d0100000-d01fffff
        Capabilities: [40] Express Root Port (Slot+) IRQ 0
        Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-
        Capabilities: [90] #0d [0000]
        Capabilities: [a0] Power Management version 2
        Capabilities: [100] Virtual Channel
        Capabilities: [180] Unknown (5)

00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2
(rev 01) (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0
        Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
        Capabilities: [40] Express Root Port (Slot+) IRQ 0
        Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-
        Capabilities: [90] #0d [0000]
        Capabilities: [a0] Power Management version 2
        Capabilities: [100] Virtual Channel
        Capabilities: [180] Unknown (5)

00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev
01) (prog-if 00 [UHCI])
        Subsystem: IBM Unknown device 02ef
        Flags: bus master, medium devsel, latency 0, IRQ 19
        I/O ports at 3000 [size=32]

00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev
01) (prog-if 00 [UHCI])
        Subsystem: IBM Unknown device 02ef
        Flags: bus master, medium devsel, latency 0, IRQ 18
        I/O ports at 3020 [size=32]

00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev
01) (prog-if 00 [UHCI])
        Subsystem: IBM Unknown device 02ef
        Flags: bus master, medium devsel, latency 0, IRQ 20
        I/O ports at 3040 [size=32]

00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI
Controller (rev 01) (prog-if 20 [EHCI])
        Subsystem: IBM Unknown device 02ef
        Flags: bus master, medium devsel, latency 0, IRQ 19
        Memory at d0000000 (32-bit, non-prefetchable) [size=1K]
        Capabilities: [50] Power Management version 2
        Capabilities: [58] Debug port

00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) (prog-if 01
[Subtractive decode])
        Flags: bus master, fast devsel, latency 0
        Bus: primary=00, secondary=0a, subordinate=0a, sec-latency=32
        I/O behind bridge: 00004000-00004fff
        Memory behind bridge: d0200000-d02fffff
        Prefetchable memory behind bridge: 00000000d8000000-00000000dff00000
        Capabilities: [50] #0d [0000]

00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface
Bridge (rev 01)
        Subsystem: IBM Unknown device 02ef
        Flags: bus master, medium devsel, latency 0
        Capabilities: [e0] Vendor Specific Information

00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) Serial ATA
Storage Controllers cc=IDE (rev 01) (prog-if 80 [Master])
        Subsystem: IBM Unknown device 02ef
        Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 18
        I/O ports at <unassigned>
        I/O ports at <unassigned>
        I/O ports at <unassigned>
        I/O ports at <unassigned>
        I/O ports at 3090 [size=16]
        Capabilities: [70] Power Management version 2

00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01)
        Subsystem: IBM Unknown device 02ef
        Flags: medium devsel, IRQ 10
        I/O ports at 3060 [size=32]

02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5721 Gigabit
Ethernet PCI Express (rev 11)
        Subsystem: IBM Unknown device 02c6
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at d0100000 (64-bit, non-prefetchable) [size=64K]
        Capabilities: [48] Power Management version 2
        Capabilities: [50] Vital Product Data
        Capabilities: [58] Message Signalled Interrupts: 64bit+ Queue=0/3 Enable-
        Capabilities: [d0] Express Endpoint IRQ 0
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [13c] Virtual Channel

0a:04.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 01) (prog-if
00 [VGA])
        Subsystem: IBM Unknown device 0325
        Flags: bus master, stepping, fast Back2Back, medium devsel, latency 32,
IRQ 10
        Memory at d8000000 (32-bit, prefetchable) [size=128M]
        I/O ports at 4000 [size=256]
        Memory at d0200000 (32-bit, non-prefetchable) [size=64K]
        [virtual] Expansion ROM at d0220000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 2

starting X freezes very often.  Found also following in the /var/log/messages:
Apr 13 22:12:56 server kernel: [drm] Initialized drm 1.0.1 20051102
Apr 13 22:12:56 server kernel: ACPI: PCI Interrupt 0000:0a:04.0[A] -> GSI 16
(level, low) -> IRQ 16
Apr 13 22:12:56 server kernel: [drm] Initialized radeon 1.22.0 20051229 on minor 0
Apr 13 22:12:57 server kernel: irq 20: nobody cared (try booting with the
"irqpoll" option)
Apr 13 22:12:57 server kernel:  [<c01388f7>] __report_bad_irq+0x2b/0x69    
[<c0138ab8>] note_interrupt+0x183/0x1af
Apr 13 22:12:57 server kernel:  [<c0138412>] handle_IRQ_event+0x23/0x4c    
[<c01384d5>] __do_IRQ+0x9a/0xcd
Apr 13 22:12:57 server kernel:  [<c0104bde>] do_IRQ+0x5c/0x77    
=======================
Apr 13 22:12:57 server kernel:  [<c010358e>] common_interrupt+0x1a/0x20
Apr 13 22:12:57 server kernel:  [<c0101e7d>] mwait_idle+0x1a/0x31    
[<c0101e4e>] cpu_idle+0x3a/0x4f
Apr 13 22:12:57 server kernel:  [<c03a26a3>] start_kernel+0x28c/0x28e   
<3>handlers:
Apr 13 22:12:57 server kernel: [<c025b810>] (usb_hcd_irq+0x0/0x4f)
Apr 13 22:12:57 server kernel: Disabling IRQ #20

This happened at the time of X-freeze

Comment 11 Arthur Wilkinson 2006-07-07 06:08:32 UTC
Created attachment 132041 [details]
Complete output of dmesg...

Comment 12 Arthur Wilkinson 2006-07-07 06:11:56 UTC
Comment on attachment 132041 [details]
Complete output of dmesg...

Updated to new kernel, 2.6.17-1.2145_FC5, and error persists. Also updated
BIOS.

With kernel update came two new lines in the error messages, just after the
kernel is loaded into memory, which now read as follows:

PCI: BIOS Bug: MCFG area is not E820-reserved
PCI: Not using MMCONFIG.
PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.0
PCI: Cannot allocate resource region 8 of bridge 0000:00:1c.0
PCI: Cannot allocate resource region 9 of bridge 0000:00:1c.0

Note: I only updated my BIOS after the kernel update, and the new error
messages. It was in the hopes that there really was a bug in my BIOS, and that
it had been fixed.

I also tried the command line argument "pci+assign-busses" as was sugested in
the output of dmesg, but with no luck. Error still persists. Full output of
dmesg is attached.

BTW: There is no bug report open on this issue at kernel.org. Is there any
reason why a bug report shouldn't be opened there as well?

Comment 13 Kent Luther 2006-07-08 01:33:58 UTC
Same problem (PCI: regions 7,  8 and 9)

IBM Thinkpad Model A31

Boot proceeds but no USB devices (disk and mouse) are found. 

System seems to run OK with the limited testing I have done (using the built-in
mouse).



Comment 14 Arthur Wilkinson 2006-08-18 11:50:50 UTC
Possible fix listed in changelog at Kernel.org for kernel version 2.6.17.8

Quoted from: http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.17.8

"commit ef2a8a41fdd6f0c8079e6fd4cad1eebdce99aa9a
Author: Chuck Ebbert <76306.1226>
Date:   Thu Jun 15 04:41:52 2006 -0400

    PCI: fix issues with extended conf space when MMCONFIG disabled because of
    e820
    
    On 15 Jun 2006 03:45:10 +0200, Andi Kleen wrote:
    > Anyways I would say that if the BIOS can't get MCFG right then
    > it's likely not been validated on that board and shouldn't be used.
    
    According to Petr Vandrovec:
    
     ... "What is important (and checked) is address of MMCONFIG reported by
     MCFG table...  Unfortunately code does not bother with printing that
     address :-(
    
     "Another problem is that code has hardcoded that MMCONFIG area is 256MB
     large. Unfortunately for the code PCI specification allows any power of
     two between 2MB and 256MB if vendor knows that such amount of busses (from
     2 to 128) will be sufficient for system.  With notebook it is quite
     possible that not full 8 bits are implemented for MMCONFIG bus number."
    
    So here is a patch.  Unfortunately my system still fails the test because
    it doesn't reserve any part of the MMCONFIG area, but this may fix others.
    
    Booted on x86_64, only compiled on i386.  x86_64 still remaps the max area
    (256MB) even though only 2MB is checked... but 2.6.16 had no check at all
    so it is still better.
    
    PCI: reduce size of x86 MMCONFIG reserved area check
    
    1.  Print the address of the MMCONFIG area when the test for that area
        being reserved fails.
    
    2.  Only check if the first 2MB is reserved, as that is the minimum.
    
    Signed-off-by: Chuck Ebbert <76306.1226>
    Acked-by: Arjan van de Ven <arjan.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh>
    Signed-off-by: Chris Wright <chrisw>"

Comment 15 Partha Bagchi 2006-10-08 15:22:26 UTC
x86_64 kernel 2.6.19-rc1 - still the same error
PCI: Cannot allocate resource region 7 of bridge 0000:00:04.0
PCI: Cannot allocate resource region 8 of bridge 0000:00:04.0

Interrestingly, 00:04 is the PCI Bridge and on this machine the PCI Express
video card is on this bridge - So would this be the reason that DRI does not work?

Comment 16 Dave Jones 2006-10-16 20:52:41 UTC
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.

Comment 17 jouni 2006-10-18 06:50:43 UTC
Remotely checked IBM xSeries 100 type 8486 server.  Seems to work (still), but 
gives following complaints:

kernel: PCI: Cannot allocate resource region 7 of bridge 0000:00:01.0
kernel: PCI: Cannot allocate resource region 8 of bridge 0000:00:01.0
kernel: PCI: Cannot allocate resource region 9 of bridge 0000:00:01.0
kernel: PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.1
kernel: PCI: Cannot allocate resource region 8 of bridge 0000:00:1c.1
kernel: PCI: Cannot allocate resource region 9 of bridge 0000:00:1c.1

# uname -r
2.6.18-1.2200.fc5smp

Comment 18 Dave Jones 2006-10-18 07:20:42 UTC
These are harmless, but I've silenced them in CVS anyway. The next update won't
print them during boot (They'll still be in dmesg output however).

Comment 19 Oskar von Reeuenta 2006-10-30 08:11:42 UTC
Messages still showed at  Acer TravelMate 3262WXMi while booting up

PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.0
PCI: Cannot allocate resource region 8 of bridge 0000:00:1c.0
PCI: Cannot allocate resource region 9 of bridge 0000:00:1c.0
PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.1
PCI: Cannot allocate resource region 8 of bridge 0000:00:1c.1
PCI: Cannot allocate resource region 9 of bridge 0000:00:1c.1
PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.2
PCI: Cannot allocate resource region 8 of bridge 0000:00:1c.2
PCI: Cannot allocate resource region 9 of bridge 0000:00:1c.2
PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.3
PCI: Cannot allocate resource region 8 of bridge 0000:00:1c.3
PCI: Cannot allocate resource region 9 of bridge 0000:00:1c.3
PCI: Failed to allocate mem resource #6:20000@d0000000 for 0000:01:00.0

# uname -r
2.6.18-1.2200.fc5smp

The problematic resouces are
1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation Unknown device 01d7 (rev a1)


Comment 20 Dave Jones 2006-11-12 05:44:57 UTC
should be fixed in 2.6.18-1.2239.fc5 now in updates.



Note You need to log in before you can comment on or make changes to this bug.