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

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

[Miles Lane]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Andrew Morton]

Miles Lane wrote:
> 
> 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.

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
--- t12p7/linux/drivers/pci/pci.c       Thu Dec  7 15:56:26 2000
+++ linux/drivers/pci/pci.c     Thu Dec  7 12:21:51 2000
@@ -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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Prerelease kernel will not hotplug a USB host-controller when it isinserted into a Cardbus slot.

[David Brownell]

> 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.

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Prerelease kernel will not hotplug a USB host-controller when it isinserted into a Cardbus slot.

[Miles Lane]

David Brownell wrote:

>> 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.
> 
> 
> That's new info ... you'd previously thought that it wasn't even
> invoking /sbin/hotplug!

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.

> 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 !

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Prerelease kernel will not hotplug a USB host-controller when it isinserted into a Cardbus slot.

[Miles Lane]

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
--- v2.4.0-test11/linux/drivers/pci/pci.c       Sun Nov 19 18:44:12 2000
+++ linux/drivers/pci/pci.c     Tue Dec  5 11:04:39 2000
@@ -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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Prerelease kernel will not hotplug a USB host-controller when it isinserted into a Cardbus slot.

[Miles Lane]

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Prerelease kernel will not hotplug a USB host-controller when itisinserted into a Cardbus slot.

[David Brownell]

Hi Miles,

>        The whole
> "Bad PCI invocation" error was a red herring, sorry.

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


> I have since gone in a tested test12-pre5, test12-pre6 and
> test12-pre8.  test12-pre5 works.  test12-pre6 fails utterly.

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).


> 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.

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.


> 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?

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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

[Miles Lane]

David Brownell wrote:

<snip>

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

Yep.

> 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.

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.


>> 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?
> 
> 
> 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.

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/