Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753757Ab0KDFHZ (ORCPT ); Thu, 4 Nov 2010 01:07:25 -0400 Received: from ogre.sisk.pl ([217.79.144.158]:49459 "EHLO ogre.sisk.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751263Ab0KDFHY (ORCPT ); Thu, 4 Nov 2010 01:07:24 -0400 From: "Rafael J. Wysocki" To: "Mike DeKoker" Subject: Re: pciehp - Problems with ExpressCard hotplug Date: Thu, 4 Nov 2010 06:06:33 +0100 User-Agent: KMail/1.13.5 (Linux/2.6.35-rjw+; KDE/4.4.4; x86_64; ; ) Cc: linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, Bjorn Helgaas References: <007f01cb7bc5$76c99fd0$645cdf70$@com> In-Reply-To: <007f01cb7bc5$76c99fd0$645cdf70$@com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011040606.33889.rjw@sisk.pl> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5071 Lines: 112 [CCing linux-pci and Bjorn] On Thursday, November 04, 2010, Mike DeKoker wrote: > Hello everyone, I hope this is the correct forum. > > I'm having a problem with hotplug working for a PCIe-based ExpressCard > device that I'm developing a driver module for. If not hot-plugged, > everything works great. Further, running the exact same laptop/device > hardware but different OS (XP or Win7-64) hot-plugging works okay so I don't > think this is a simple hardware/BIOS error. > > I've tried several stock kernel versions from 2.6.18 (the version my > customer intends to use) up to 2.6.34.7 (version for all verbiage below) and > have had fairly consistent behavior. > > The driver module (sig_ec14) is using the pci_register_driver interface and > in the subsequent probe callback function (after a hot-plug) an error occurs > when calling pci_enable_device. Here's the relevant dmesg data: > > Insert device: > pciehp 0000:00:1c.5:pcie04: Card present on Slot(5) > pci 0000:07:00.0: supports D1 > pci 0000:07:00.0: PME# supported from D0 D1 D3hot > pci 0000:07:00.0: PME# disabled > pci 0000:07:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it > with 'pcie_aspm=force' > pci 0000:08:00.0: reg 10: [mem 0x00000000-0x0000001f] > pci 0000:08:00.0: reg 14: [mem 0x00000000-0x0000007f] > pci 0000:08:00.0: reg 18: [mem 0x00000000-0x0000003f] > pci 0000:07:00.0: PCI bridge to [bus 08-ff] > pci 0000:07:00.0: bridge window [io 0x0000-0x0000] (disabled) > pci 0000:07:00.0: bridge window [mem 0x00000000-0x000fffff] (disabled) > pci 0000:07:00.0: bridge window [mem 0x00000000-0x000fffff pref] > (disabled) > pci 0000:07:00.0: BAR 14: assigned [mem 0xd9000000-0xd90fffff] > pci 0000:07:00.0: PCI bridge to [bus 08-08] > pci 0000:07:00.0: bridge window [io disabled] > pci 0000:07:00.0: bridge window [mem 0xd9000000-0xd90fffff] > pci 0000:07:00.0: bridge window [mem pref disabled] > pcieport 0000:00:1c.5: PCI bridge to [bus 07-09] > pcieport 0000:00:1c.5: bridge window [io 0x1000-0x1fff] > pcieport 0000:00:1c.5: bridge window [mem 0xd9000000-0xd9ffffff] > pcieport 0000:00:1c.5: bridge window [mem 0xd8000000-0xd8ffffff 64bit > pref] > pcieport 0000:00:1c.5: setting latency timer to 64 > pci 0000:07:00.0: enabling device (0000 -> 0002) > pci 0000:07:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 > pci 0000:07:00.0: setting latency timer to 64 > pci 0000:07:00.0: no hotplug settings from platform > pci 0000:08:00.0: no hotplug settings from platform > pci 0000:08:00.0: using default PCI settings > sig_ec14 : Driver module loading > sig_ec14 : Verbose module output enabled (development build) > sig_ec14 : Dynamic major number: 248 > sig_ec14 : PCI probe: New EC14 device > sig_ec14 0000:08:00.0: device not available (can't reserve [mem > 0x00000000-0x0000001f]) > sig_ec14 : Failed to enable PCI device: -22 > sig_ec14: probe of 0000:08:00.0 failed with error -22 > . > > It looks like the requested memory spaces are not allocated properly. I'm a > little uncertain about the entity that's actually responsible for allocating > the resources. Is this a failure of the BIOS or does system software play a > role in PNP resource allocation for hot-plug? I'm a little out of my element > here. > > I've also run with pciehp_debug=1 in the event that the extra info makes > sense to someone: > > Insert device: > pciehp 0000:00:1c.5:pcie04: pcie_isr: intr_loc 8 > pciehp 0000:00:1c.5:pcie04: Presence/Notify input change > pciehp 0000:00:1c.5:pcie04: Card present on Slot(5) > pciehp 0000:00:1c.5:pcie04: Surprise Removal > pciehp 0000:00:1c.5:pcie04: pciehp_check_link_status: lnk_status = 3011 > pci 0000:07:00.0: supports D1 > pci 0000:07:00.0: PME# supported from D0 D1 D3hot > pci 0000:07:00.0: PME# disabled > pci 0000:07:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it > with 'pcie_aspm=force' > . > > That 'Surprise Removal' immediately following the 'Card present on Slot(5)' > message looks like a potential culprit. > > When the device is connected cold and the system is powered up I have no > problems: > sig_ec14 : Driver module loading > sig_ec14 : Verbose module output enabled (development build) > sig_ec14 : Dynamic major number: 248 > sig_ec14 : PCI probe: New EC14 device > sig_ec14 0000:0a:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 > sig_ec14 : Memory IO region 0 -> Start: 0xD90000C0, Len: 0x0020 > sig_ec14 : Memory IO region 1 -> Start: 0xD9000000, Len: 0x0080 > sig_ec14 : Memory IO region 2 -> Start: 0xD9000080, Len: 0x0040 > . > > Any advice would be greatly appreciated; I'd like to be able to test the > module's handling of surprise removal, etc. > > I am off-list, please CC me at: mdekoker at the domain of signatec dot com. > > Thank you all for your time and the great work you do. > > Regards, > Mike DeKoker -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/