lspci output :

00:00.0 Host bridge: Intel Corporation 82P965/G965 Memory Controller Hub (rev 02)
00:01.0 PCI bridge: Intel Corporation 82P965/G965 PCI Express Root Port (rev 02)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 02)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 02)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 02)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 02)
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 02)
00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev f2)
00:1f.0 ISA bridge: Intel Corporation 82801HB/HR (ICH8/R) LPC Interface Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801H (ICH8 Family) 4 port SATA IDE Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 02)
00:1f.5 IDE interface: Intel Corporation 82801H (ICH8 Family) 2 port SATA IDE Controller (rev 02)
01:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. Device 3403
01:00.1 IDE interface: VIA Technologies, Inc. PATA IDE Host Controller (rev a0)
04:01.0 Network controller: RaLink RT2500 802.11g Cardbus/mini-PCI (rev 01)
05:00.0 VGA compatible controller: ATI Technologies Inc RV730XT [Radeon HD 4670]
05:00.1 Audio device: ATI Technologies Inc R700 Audio Device [Radeon HD 4000 Series]

Could you attach /var/log/dmesg please?

Created attachment 365139 [details]
dmesg

attached requested /var/log/dmesg

see the same using Fedora 12 x86_64 on MSI P965 platinum with ICH8R

Same problem with my equipment (also MSI P965 Platinum). I'm also using Fedora 12 x86_64 and the following messages are flooding /var/log/messages:

Feb 21 10:15:01 localhost kernel: pciehp 0000:00:1c.4:pcie04: Card not present on Slot(0)
Feb 21 10:15:01 localhost kernel: pciehp 0000:00:1c.4:pcie04: Card present on Slot(0)

Would be glad to hear, if it's an hardware bug or not.

Created attachment 398353 [details]
My dmesg

Have the same problem on my machine and its very annoying.
This is only in Fedora (Debian, openSuSE, Mandriva, Ubuntu that is what I've tested so far for THIS bug).
videocard: NVidia 9500 GT
>less /var/log/messages | grep NV
>Mar  7 07:36:52 fedora1 kernel: [drm] nouveau 0000:01:00.0: Detected an NV50 >generation card (0x096000a1)

forgot to say that I am using rawhide...
Today the problem is fixed for me!(without any pkg upgrades)

Damian,

What hardware are you seeing this on?

What hardware are you interested in? I attached the dmesg.

However this problem stopped on my computer.(I did *NOT* do any upgrades)

This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

I can reliably reproduce this using 2.6.36-0.10.rc2.git4.fc15 (everything from F12 up to that really), so I'm going to reopen this.  Hardware available on request.  Only happens when I'm using a docking station (IBM 2503) with my z61t laptop.

Created attachment 451095 [details]
loleary's dmesg log for a fresh/clean boot

Created attachment 451096 [details]
lolear's lspci output for a fresh/clean boot

I am seeing this issue too. Using a Thinkpad T60... not certain what hardware would be related but based on the address, seems like the WLAN card.

I see millions of the following:

Oct  1 13:21:34 loleary kernel: pciehp 0000:00:1c.1:pcie04: No new device found
Oct  1 13:21:34 loleary kernel: pciehp 0000:00:1c.1:pcie04: Cannot add device at 0000:03:00
Oct  1 13:21:34 loleary kernel: pciehp 0000:00:1c.1:pcie04: Card not present on Slot(3)
Oct  1 13:21:34 loleary kernel: pciehp 0000:00:1c.1:pcie04: Card present on Slot(3)
Oct  1 13:21:34 loleary kernel: pciehp 0000:00:1c.1:pcie04: Card not present on Slot(3)
Oct  1 13:21:34 loleary kernel: pciehp 0000:00:1c.1:pcie04: Card present on Slot(3)
Oct  1 13:21:34 loleary kernel: pciehp 0000:00:1c.1:pcie04: Card not present on Slot(3)
Oct  1 13:21:34 loleary kernel: pciehp 0000:00:1c.1:pcie04: Card present on Slot(3)
Oct  1 13:21:34 loleary kernel: pciehp 0000:00:1c.1:pcie04: Card not present on Slot(3)
Oct  1 13:21:34 loleary kernel: pciehp 0000:00:1c.1:pcie04: Card present on Slot(3)
Oct  1 13:21:34 loleary kernel: pciehp 0000:00:1c.1:pcie04: Card not present on Slot(3)
Oct  1 13:21:35 loleary kernel: pciehp 0000:00:1c.1:pcie04: Card present on Slot(3)
Oct  1 13:21:35 loleary kernel: pciehp 0000:00:1c.1:pcie04: Card not present on Slot(3)
Oct  1 13:21:35 loleary kernel: pciehp 0000:00:1c.1:pcie04
Oct  1 13:24:20 loleary kernel: imklog 4.4.2, log source = /proc/kmsg started.


This issue did not occur in Fedora 11. Just upgraded this system to Fedora 13 a week ago and have had several system hangs (complete system halt without warning or error). The latest system hang occurred in the middle of the log message Oct 1 13:21:35 above. I had to hard-reset my machine. 

I also noticed that WLAN card isn't being detected on every boot. These messages seem to be related to the time in where the card isn't getting detected. I have had this problem for quite some time (since Fedora 10) where the WLAN card isn't being picked up and is not available to NetworkManager. Normally, a reboot resolves that issue. 

I have attached dmesg and lspci output for reference.

Created attachment 590778 [details]
collection of troubleshooting text files

I just had this exact same situation happen to me on a supermicro motherboard on one of the embedded NICs.

[1566849.329423] pciehp 0000:00:1c.4:pcie04: Card not present on Slot(0-1)
[1566849.341530] pciehp 0000:00:1c.4:pcie04: Card present on Slot(0-1)
[1566849.674251] e1000e 0000:02:00.0: PCI INT A disabled

^ those were the most recent messages in dmesg

that NIC is the first embedded NIC on the motherboard, it's shared with the onboard IPMI - I had to use the IPMI KVM to get at the box's serial console to investigate.  em2 was present, but em1 vanished.

[root@router ~]# ifconfig em1
em1: error fetching interface information: Device not found
[root@router ~]# ifconfig -a
em2       Link encap:Ethernet  HWaddr 00:25:90:3C:25:35
          inet addr:71.126.136.216  Bcast:71.126.136.255  Mask:255.255.255.0
          inet6 addr: fe80::225:90ff:fe3c:2535/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:171741693 errors:0 dropped:0 overruns:0 frame:0
          TX packets:256734230 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:83881242930 (78.1 GiB)  TX bytes:315272175295 (293.6 GiB)
          Interrupt:17 Memory:feae0000-feb00000

[... snipped ...]


This is a supermicro X7SPA-HF running fedora 16.  I'm attaching a zip of text files of dmesg, dmidecode, lsmod, lspci -vnn, redhat-release, rpm -qa and uname -a.

(In reply to comment #18)
I was having exactly the same problem with a Supermicro server with X7SPA-HF board running CentOS 6.3. I'm afraid that's a hardware issue here...

Is there any additional info on this?  

I recently updated a server with an EVGA motherboard to RHEL v6.3 kernel 2.6.32-279.9.1 x86_64 from RHEL v5.8 x86_64.  Now, I'm getting the same error messages as seen in comment 5.  I've searched around the net, but the only two options at this point seem to be; recompile the kernel without hotplug support or suppress the messages with rsyslog.

I'm not thrilled with either option.  Would prefer a kernel cmdline fix to turn pciehp off (we don't need it), but can't seem to locate one.

I'm seeing this on Fedora 18, EVGA SR-2 motherboard. The problem is so bad that it causes the installer to lock up and crash.

We are facing the same error.

Hardware used - Atheros based WLAN module (PCIE).

on Fedora 12.

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Is this still a problem with 3.9 based F19 kernels?

I haven't tried kernels more recent than 3.8.6, which still suffers from the issue.

The only workaround I have found is to manually modify the initramfs and add something like this before the pre-trigger stage:

echo "0000:00:1c.0:pcie04" > /sys/bus/pci_express/drivers/pciehp/unbind

Obviously, substitute the device ID for whichever one is causing problems on your specific system.

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.11.1-200.fc19.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

This issue still manifests on 3.11.x kernels.

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.12.6-200.fc19.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 20, and are still experiencing this issue, please change the version to Fedora 20.

If you experience different issues, please open a new bug report for those.

This is easily fixable by simply including pciehp as a module rather than built into the kernel. That way on hardware that is affected by this bug the pciehp module can be blacklisted, or if needed, it can be wrapped by the install command to immediately detach the offending device once the module is loaded.

Is there an overwhelming reason to not simply do that? This bug seems to have been dragging on for years (since at least F11).

Hi Gordan,

which config option do you have in mind to set as module? I ask because
from a quick glance I see only boolean values (Y/N) no tristate (Y/N/m)
$ grep -A1 -E "config.*PCIE.*" drivers/pci/pcie/Kconfig 
config PCIEPORTBUS
	bool "PCI Express Port Bus support"
--
config HOTPLUG_PCI_PCIE
	bool "PCI Express Hotplug driver"
--
config PCIEASPM
	bool "PCI Express ASPM control" if EXPERT
--
config PCIEASPM_DEBUG
	bool "Debug PCI Express ASPM"
--
config PCIEASPM_DEFAULT
        bool "BIOS default"
--
config PCIEASPM_POWERSAVE
        bool "Powersave"
--
config PCIEASPM_PERFORMANCE
        bool "Performance"
--
config PCIE_PME
	def_bool y


Can you try with "pcie_ports=compat" on the boot command line and see if things
improve?

hth,
Michele

Which kernel version and patches are you using? The relevant Kconfig option is:

config HOTPLUG_PCI_PCIE
        tristate "PCI Express Hotplug driver"

It is bool since a while (v3.11):
commit c10cc483bf3f1d0e8f9f077ca36ecc053de9bbbc
Author: Bjorn Helgaas <bhelgaas>
Date:   Tue Jul 23 10:55:56 2013 -0600

    PCI: pciehp: Convert pciehp to be builtin only, not modular
    
    Convert pciehp to be builtin only, with no module option.
    
    Signed-off-by: Bjorn Helgaas <bhelgaas>
    Acked-by: Rafael J. Wysocki <rafael.j.wysocki>
    Acked-by: Yinghai Lu <yinghai>

Have you tried "pcie_ports=compat"?

I can confirm that in F20, pcie_ports=compat does remove these messages at least.

5154270 messages since yesterday before adding that, 0 after.

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.13.5-100.fc19.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

*********** MASS BUG UPDATE **************
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 4 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.