(2010/11/06 4:11), Mike DeKoker wrote:
(2010/11/04 14:06), Rafael J. Wysocki wrote:
[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:
SNIP
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:
SNIP
That 'Surprise Removal' immediately following the 'Card present on
Slot(5)'
message looks like a potential culprit.
I believe this is just an message problem.
It looks like resource allocation code doesn't work for your
end device...
Could you send the following information
- whole dmesg output after hot-plugging the device (with pciehp_debug=1)
- lspci -vvvxxx output after boot with and without your device (no
hotplug operation required)
------- lspci -vvvxxx (Pre device insertion):
(snip.)
08:00.0 Non-VGA unclassified device: Device 1b94:ec14
Subsystem: Device 1b94:ec14
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium>TAbort-
<TAbort-<MAbort->SERR-<PERR- INTx-
Interrupt: pin A routed to IRQ 255
Kernel modules: sig_ec14
00: 94 1b 14 ec 00 00 20 02 00 00 00 00 00 40 00 00
I guess the following code in setup-bus.c skips your device
whose class code is undefined.
static void __dev_sort_resources(struct pci_dev *dev,
struct resource_list *head)
{
u16 class = dev->class >> 8;
/* Don't touch classless devices or host bridges or ioapics. */
if (class == PCI_CLASS_NOT_DEFINED || class == PCI_CLASS_BRIDGE_HOST)
return;
Can you try with the above two lines commented out?
Regards,
Kenji Kaneshige
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
