From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: "Mike DeKoker" <mdekoker@signatec.com>
Cc: linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
Bjorn Helgaas <bjorn.helgaas@hp.com>
Subject: Re: pciehp - Problems with ExpressCard hotplug
Date: Thu, 4 Nov 2010 06:06:33 +0100 [thread overview]
Message-ID: <201011040606.33889.rjw@sisk.pl> (raw)
In-Reply-To: <007f01cb7bc5$76c99fd0$645cdf70$@com>
[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
next prev parent reply other threads:[~2010-11-04 5:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-04 2:10 Mike DeKoker
2010-11-04 5:06 ` Rafael J. Wysocki [this message]
2010-11-05 5:57 ` Kenji Kaneshige
2010-11-05 19:11 ` Mike DeKoker
2010-11-09 8:17 ` Kenji Kaneshige
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201011040606.33889.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=bjorn.helgaas@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mdekoker@signatec.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome