Re: pciehp - Problems with ExpressCard hotplug

[Kenji Kaneshige]

(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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/