Prerelease kernel will not hotplug a USB host-controller when it is inserted into a Cardbus slot.

Hi Linus and Co.,

I am writing to let you know that in all test12-pre6+ kernels, I get a "Bad PCI invocation" error when hotplug attempts to handle the insertion of a USB host-controller into a Cardbus slot.

I am aware that you most likely will ship 2.4.0 anyway, but thought you should at least know about the bug.

I have tried your latest call_usermodehelper patch, Andrew, which appears to have not made it into the kernel, but it did not solve the problem.

What follows is test results from three configurations:

prerelease with ds.o as a modular driver -- hotplug fails prerelease with ds.o in-kernel -- hotplug fails test11 with ds.o as a modular driver -- hotplug succeeds
and usb-ohci loads

At the end of the message, you'll find the lspci output for the BusPort Mobile generated using prerelease.

2.4.0-prerelease with ds.o built as a modular driver:
----------------------------------------------------

PCI: Enabling device 05:00.0 (0000 -> 0002)
PCI: Found IRQ 11 for device 05:00.0
PCI: The same IRQ used for device 00:04.0
Jan 3 03:22:27 agate kernel: cs: cb_alloc(bus 5): vendor 0x1045, device 0xc861
Jan 3 03:22:27 agate kernel: PCI: Enabling device 05:00.0 (0000 -> 0002) Jan 3 03:22:27 agate kernel: PCI: Found IRQ 11 for device 05:00.0 Jan 3 03:22:27 agate kernel: PCI: The same IRQ used for device 00:04.0 Jan 3 03:22:28 agate /sbin/hotplug: Bad PCI invocation

2.4.0-prerelease with ds.o built in-kernel:
------------------------------------------

PCI: Enabling device 05:00.0 (0000 -> 0002)
PCI: Found IRQ 11 for device 05:00.0
PCI: The same IRQ used for device 00:04.0

Jan  3 03:55:14 agate kernel: cs: cb_alloc(bus 5): vendor 0x1045, device
0xc861
Jan  3 03:55:14 agate kernel: PCI: Enabling device 05:00.0 (0000 -> 0002)
Jan  3 03:55:14 agate kernel: PCI: Found IRQ 11 for device 05:00.0
Jan  3 03:55:14 agate kernel: PCI: The same IRQ used for device 00:04.0
Jan  3 03:55:15 agate /sbin/hotplug: Bad PCI invocation
Jan  3 03:55:15 agate cardmgr[402]: initializing socket 0
Jan  3 03:55:15 agate cardmgr[402]: socket 0: Anonymous Memory
Jan  3 03:55:15 agate cardmgr[402]: executing: 'modprobe sram_mtd'
Jan  3 03:55:15 agate cardmgr[402]: + modprobe: Can't locate module sram_mtd
Jan  3 03:55:15 agate cardmgr[402]: modprobe exited with status 255
Jan  3 03:55:15 agate cardmgr[402]: module
/lib/modules/2.4.0-test11/pcmcia/sram_mtd.o not available
Jan  3 03:55:15 agate cardmgr[402]:   Common memory region at 0x38e00:
Generic or SRAM
Jan  3 03:55:15 agate cardmgr[402]:   Common memory region at 0xe00:
Generic or
SRAM
Jan  3 03:55:15 agate cardmgr[402]: executing: 'modprobe memory_cs'
Jan  3 03:55:15 agate cardmgr[402]: + modprobe: Can't locate module
memory_cs
Jan  3 03:55:15 agate cardmgr[402]: modprobe exited with status 255
Jan  3 03:55:15 agate cardmgr[402]: module
/lib/modules/2.4.0-test11/pcmcia/memory_cs.o not available
Jan  3 03:55:16 agate cardmgr[402]: get dev info on socket 0 failed:

Resource temporarily unavailable

2.4.0-test11 with ds.o built as a modular driver:
------------------------------------------------

cs: socket c3105000 timed out during reset. Try increasing setup_delay.
PCI: Enabling device 05:00.0 (0000 -> 0002)
PCI: Found IRQ 11 for device 05:00.0
PCI: The same IRQ used for device 00:04.0

Jan  3 02:39:52 agate kernel: cs: socket c3105000 timed out during
reset.  Try increasing setup_delay.
PCI: Setting latency timer of device 05:00.0 to 64
Jan  3 02:39:53 agate kernel: cs: cb_alloc(bus 5): vendor 0x1045, device
0xc861
Jan  3 02:39:53 agate kernel: PCI: Enabling device 05:00.0 (0000 -> 0002)
Jan  3 02:39:53 agate kernel: PCI: Found IRQ 11 for device 05:00.0
Jan  3 02:39:53 agate kernel: PCI: The same IRQ used for device 00:04.0
Jan  3 02:39:53 agate kernel: PCI: Setting latency timer of device
05:00.0 to 64Jan  3 02:39:53 agate kernel: usb-ohci.c: USB OHCI at
membase 0xc5867000, IRQ 11Jan  3 02:39:53 agate kernel: usb-ohci.c:
usb-05:00.0, PCI device 1045:c861
Jan  3 02:39:53 agate kernel: usb.c: new USB bus registered, assigned
bus number 1
Jan  3 02:39:53 agate kernel: Product: USB OHCI Root Hub
Jan  3 02:39:53 agate kernel: SerialNumber: c5867000
Jan  3 02:39:53 agate kernel: hub.c: USB hub found
Jan  3 02:39:53 agate kernel: hub.c: 2 ports detected
Jan  3 02:39:53 agate /sbin/hotplug: arguments (usb) env (TYPE=9/0/0

ACTION=add
DEVFS=/proc/bus/usb TERM=dumb DEVICE=/proc/bus/usb/001/001 HOSTTYPE=i386 PATH=/bin:/sbin:/usr/sbin:/usr/bin HOME=/ SHELL=/bin/bash DEBUG=kernel OSTYPE=Linux PRODUCT=0/0/0 SHLVL=1 _=/usr/bin/env)

Here is what lspci has to say about the BusPort PCI entry when running prerelease. I checked the lspci output running under test11 and found no discrepancies.

05:00.0 USB Controller: OPTi Inc. 82C861 (rev 10) (prog-if 10 [OHCI])
Subsystem: OPTi Inc.: Unknown device c861
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 11
Region 0: Memory at 11000000 (32-bit, non-prefetchable) [size=4K]

00:04.1 CardBus bridge: Texas Instruments PCI1131 (rev 01)

	Subsystem: Dell Computer Corporation: Unknown device 007e
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
	ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
	<TAbort- <MAbort- >SERR- <PERR-
	Latency: 168 set, cache line size 08
	Interrupt: pin B routed to IRQ 11
	Region 0: Memory at 10001000 (32-bit, non-prefetchable)
	[size=4K]
	Bus: primary=00, secondary=05, subordinate=05, sec-latency=176
	Memory window 0: 10c00000-10fff000 (prefetchable)
	Memory window 1: 11000000-113ff000
	I/O window 0: 00001800-000018ff
	I/O window 1: 00001c00-00001cff
	BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt-
	PostWrite+
	16-bit legacy interface ports at 0001

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

That message is coming from your hotplug scripts.

At approximately test12-o'clock the following change was made:

diff -u --recursive --new-file t12p7/linux/drivers/pci/pci.c linux/drivers/pci/pci.c
@@ -360,9 +360,9 @@
        if (!hotplug_path[0])
                return;
 
-       sprintf(class_id, "PCI_CLASS=%X", pdev->class);
-       sprintf(id, "PCI_ID=%X/%X", pdev->vendor, pdev->device);
-       sprintf(sub_id, "PCI_SUBSYS_ID=%X/%X", pdev->subsystem_vendor, pdev->subsystem_device);
+       sprintf(class_id, "PCI_CLASS=%04X", pdev->class);
+       sprintf(id, "PCI_ID=%04X:%04X", pdev->vendor, pdev->device);
+       sprintf(sub_id, "PCI_SUBSYS_ID=%04X:%04X", pdev->subsystem_vendor, pdev->subsystem_device);
        sprintf(bus_id, "PCI_SLOT_NAME=%s", pdev->slot_name);
 
        i = 0;

So I guess your PCI hotplug script hasn't caught up with this change in the format of its arguments.

-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

That's new info ... you'd previously thought that it wasn't even invoking /sbin/hotplug!

The scripts I know about will produce that message when they're invoked without PCI_CLASS set. That's a sanity check which was needed for the intial PCI hotplug support, which wouldn't pass that info -- needed to hotplug devices using class drivers, such as USB host controllers.

But they'll also dump all the arguments and environment of hotplug before they get that far, if you set DEBUG=yes; please enable that and let us know the whole environment that's getting passed !

- Dave

p.s. Re that patch Andrew mentioned, it shouldn't have made
a difference unless "PCI_CLASS=%04X" truncated the top eight bits of the class (it's 24 bits, not 16: 8 bits each of class, subclass, prog-if.) That would have had a different failure mode: only class 0 devices (pci.ids says is "unclassified" devices) would PCI hotplug.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

I fscked up that test. The results I reported as being with prerelease were actually with a messed up test11. The whole "Bad PCI invocation" error was a red herring, sorry.

I have since gone in a tested test12-pre5, test12-pre6 and test12-pre8. test12-pre5 works. test12-pre6 fails utterly. It looks like Cardbus was just completely hosed in that tree, because I can't get my network card (3c575) to be recognized by that kernel, either. I checked the patches and Andrew's "04X" change went into test12-pre8. I just tested test12-pre8 with both your latest hotplug script, David, and with the pertinent "0x" locations changed to "04x". Both scripts fail to load usb-ohci.

Bottom line, I have yet to see a test12-pre6+ kernel load usb-ohci whether or not I use "04x" in the hotplug script. Something else is messed up here.

For the Cardbus hotplug event, is it expected that the hotplug debug info would be dumped after the insert event is processed and the required driver is loaded?

With test12-pre5, I get this when I insert the BusPort Mobile:

Jan  3 15:00:15 agate kernel: cs: cb_alloc(bus 5): vendor 0x1045, device 0xc861 Jan  3 15:00:15 agate kernel:   got res[11000000:11000fff] for resource 0 of PCI device 1045:c861
Jan  3 15:00:15 agate kernel: PCI: Enabling device 05:00.0 (0000 -> 0002)
Jan  3 15:00:15 agate kernel: PCI: Found IRQ 11 for device 05:00.0
Jan  3 15:00:15 agate kernel: PCI: The same IRQ used for device 00:04.0
Jan  3 15:00:15 agate kernel: PCI: Setting latency timer of device 05:00.0 to 64
Jan  3 15:00:15 agate kernel: usb-ohci.c: USB OHCI at membase 0xc5850000, IRQ 11
Jan  3 15:00:15 agate kernel: usb-ohci.c: usb-05:00.0, PCI device 1045:c861
Jan  3 15:00:15 agate kernel: usb.c: new USB bus registered, assigned bus number 1
Jan  3 15:00:15 agate kernel: Product: USB OHCI Root Hub
Jan  3 15:00:15 agate kernel: SerialNumber: c5850000
Jan  3 15:00:15 agate kernel: hub.c: USB hub found
Jan  3 15:00:15 agate kernel: hub.c: 2 ports detected
Jan  3 15:00:16 agate /sbin/hotplug: arguments (usb) env (TYPE=9/0/0 ACTION=add DEVFS=/proc/bus/usb TERM=dumb DEVICE=/proc/bus/usb/001/001 HOSTTYPE=i386 PATH=/bin:/sbin:/usr/sbin:/usr/bin HOME=/ SHELL=/bin/bash DEBUG=kernel OSTYPE=Linux PRODUCT=0/0/0 SHLVL=1 _=/usr/bin/env)

Thanks and sorry for the inaccurate info last night.

Miles

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Here's the pci.c patch from test12-pre6. Does anything in this patch look like it might cause the cardbus device detection and calling of hotplug to break?

diff -u --recursive --new-file v2.4.0-test11/linux/drivers/pci/pci.c linux/drivers/pci/pci.c
@@ -354,16 +354,16 @@
 run_sbin_hotplug(struct pci_dev *pdev, int insert)
 {
        int i;
-       char *argv[3], *envp[7];
-       char id[20], sub_id[24], bus_id[64], class_id[20];
+       char *argv[3], *envp[8];
+       char id[20], sub_id[24], bus_id[24], class_id[20];
 
        if (!hotplug_path[0])
                return;
 
-       sprintf(class_id, "PCI_CLASS=%X", pdev->class >> 8);
+       sprintf(class_id, "PCI_CLASS=%X", pdev->class);
        sprintf(id, "PCI_ID=%X/%X", pdev->vendor, pdev->device);
        sprintf(sub_id, "PCI_SUBSYS_ID=%X/%X", pdev->subsystem_vendor, 

pdev->subsystem_device);
- sprintf(bus_id, "PCI_BUS_ID=%s", pdev->slot_name);
+ sprintf(bus_id, "PCI_SLOT_NAME=%s", pdev->slot_name);

        i = 0;
        argv[i++] = hotplug_path;
@@ -376,6 +376,7 @@
        envp[i++] = "PATH=/sbin:/bin:/usr/sbin:/usr/bin";

        /* other stuff we want to pass to /sbin/hotplug */
+       envp[i++] = class_id;
        envp[i++] = id;
        envp[i++] = sub_id;
        envp[i++] = bus_id;
@@ -539,15 +540,9 @@
 static void pci_read_bases(struct pci_dev *dev, unsigned int howmany, 
int rom)
 {
        unsigned int pos, reg, next;
-       u32 l, sz, tmp;
-       u16 cmd;
+       u32 l, sz;
        struct resource *res;

-       /* Disable IO and memory while we fiddle */
-       pci_read_config_word(dev, PCI_COMMAND, &cmd);
-       tmp = cmd & ~(PCI_COMMAND_IO | PCI_COMMAND_MEMORY);

- pci_write_config_word(dev, PCI_COMMAND, tmp);
-

        for(pos=0; pos<howmany; pos = next) {
                next = pos+1;
                res = &dev->resource[pos];
@@ -578,10 +573,10 @@
                        res->start |= ((unsigned long) l) << 32;
                        res->end = res->start + sz;
                        pci_write_config_dword(dev, reg+4, ~0);
-                       pci_read_config_dword(dev, reg+4, &tmp);
+                       pci_read_config_dword(dev, reg+4, &sz);
                        pci_write_config_dword(dev, reg+4, l);

- if (l)
- res->end = res->start + (((unsigned long) ~l) << 32);
+ if (sz)
+ res->end = res->start + (((unsigned long) ~sz) << 32);
#else
if (l) {
printk(KERN_ERR "PCI: Unable to handle
64-bit address for device %s\n", dev->slot_name); }

                res->name = dev->name;
        }

- pci_write_config_word(dev, PCI_COMMAND, cmd);
}

void __init pci_read_bridge_bases(struct pci_bus *child)
@@ -755,7 +749,7 @@

pci_read_config_dword(dev, PCI_PRIMARY_BUS, &buses); DBG("Scanning behind PCI bridge %s, config %06x, pass %d\n",
dev->slot_name, buses & 0xffffff, pass);
- if ((buses & 0xffffff) && !pcibios_assign_all_busses()) {
+ if ((buses & 0xffff00) && !pcibios_assign_all_busses()) {
/*
* Bus already configured by firmware, process it in
the first
* pass and just note the configuration.
@@ -772,8 +766,10 @@

                        if (cmax > max) max = cmax;
                } else {
                        int i;
+                       unsigned int cmax = child->subordinate;
                        for (i = 0; i < 4; i++) 
        child->resource[i] = &dev->resource[PCI_BRIDGE_RESOURCES+i];
+                       if (cmax > max) max = cmax;
                }
        } else {
                /*

Thanks,

Miles

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

There was also a big change to pci/setup_bus.c and pci/setup_bus.h from Ivan Kokshaysky in test12-pre6. Those changes seem like another likely candidate.

Miles

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Hi Miles,

Not an endangered species ... even if Tux does like to snack on them! :-)

That's for "Cardbus hotplug". I've had USB hotplugging fine, with the iffy bits being when it combines with the network hotplugging ... those async changes seem to have created some deadlocking paths (while removing some others).

The root cause seems to be the Cardbus/PCI hotplug invocation not happening for you.

Was this with or without the "pcmcia_cs" package installed? My own take on it is that 2.4 _should_ hotplug that controller just fine if "pcmcia_cs" isn't installed. Otherwise, I'd be pleasantly surprised to know it works properly.

No -- you were seeing the USB hotplug event, not the cardbus one.

Plugging a cardbus OHCI into your machine should cause two hotplug events ... first for PCI, eventually modprobing "usb-ohci", and then as that module initializes you'll get a second one for USB, reporting a new (root) hub.

So you should see an invocation "arguments (pci) env (...)" followed by "arguments (usb) env (...)"; but you reported the second one.

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

David Brownell wrote:

<snip>

Yep.

You are more or less correct. I've looked a little bit at the source and now understand a little bit better. It turns out that parts of the Cardbus code in the kernel source includes code from the pcmcia_cs package. The "cs:" messages in the log are generated by this code. I *think* this code reads configuration files from /etc/pcmcia, but I haven't found the place in the code that does it. Anyhow, these messages:

cs: IO port probe 0x0c00-0x0cff: clean.
cs: IO port probe 0x0800-0x08ff: clean.
cs: IO port probe 0x0100-0x04ff: excluding 0x280-0x28f 0x378-0x37f
0x3a0-0x3a7 0x4d0-0x4d7
cs: IO port probe 0x0a00-0x0aff: clean.

change when I modify /etc/pcmcia/config.opts.
The /etc/pcmcia/config* files get installed by the pcmcia_cs package, so even when I am only using the cardbus functionality, there seems to be some need to pcmcia_cs, since the config.opts file contains "magic" good defaults numbers for safe irqs, ports and memory ranges.

As I have already discussed with David Brownell, there is huge a problem getting a usable cardbus solution with the current pcmcia_cs package. Even when I tell it I am using a 2.4.0 kernel and that I want to use the development kernel's drivers, it maps loads of device IDs to the pcmcia_cs drivers which don't exist in this configuration! For example, it maps the 3c575 device ID to 3c575_cb instead of 3c59x.

Well, I have no idea why the "arguments (pci) env (...)" message wasn't emitted. I do know that with the test12-pre5 kernel I get working hotplug for the BusPort Mobile.

Thanks for all your help!

Miles

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/