Messages in this thread | | | Date | Tue, 09 Nov 2010 17:17:34 +0900 | From | Kenji Kaneshige <> | Subject | Re: pciehp - Problems with ExpressCard hotplug |
| |
(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
| |