Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
On Tue, 19 Dec 2006 15:26:00 -0800 (PST) Luben Tuikov <[EMAIL PROTECTED]> wrote: > The reason was that my dev tree was tainted by this bug: > > if (good_bytes && > - scsi_end_request(cmd, 1, good_bytes, !!result) == NULL) > + scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL) > return; > > in scsi_io_completion(). I had there !!result which is wrong, and when > I diffed against master, it produced a bad patch. Oh. I thought that got sorted out. It's a shame this wasn't made clear to me.. > As James mentioned one of the chunks is good and can go in. Please send a new patch, not referential to any previous patch or email, including full changelogging. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
--- [EMAIL PROTECTED] wrote: > From: Andrew Morton <[EMAIL PROTECTED]> > Date: Sun, Dec 17, 2006 at 03:05:39AM -0800 > > On Sun, 17 Dec 2006 12:00:12 +0100 > > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > > > > > Okay, I have identified the patch that causes the problem to appear, > > > which is > > > > > > fix-sense-key-medium-error-processing-and-retry.patch > > > > > > With this patch reverted -rc1-mm1 is happily running on my test box. > > > > That was rather unexpected. Thanks. > > > I can confirm that 2.6.20-rc1-mm1 with this patch reverted mounts my > raid6 partition without problems. This is x86_64 with SMP. > The reason was that my dev tree was tainted by this bug: if (good_bytes && - scsi_end_request(cmd, 1, good_bytes, !!result) == NULL) + scsi_end_request(cmd, 1, good_bytes, result == 0) == NULL) return; in scsi_io_completion(). I had there !!result which is wrong, and when I diffed against master, it produced a bad patch. As James mentioned one of the chunks is good and can go in. Luben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
From: Andrew Morton <[EMAIL PROTECTED]> Date: Sun, Dec 17, 2006 at 03:05:39AM -0800 > On Sun, 17 Dec 2006 12:00:12 +0100 > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > > > Okay, I have identified the patch that causes the problem to appear, which > > is > > > > fix-sense-key-medium-error-processing-and-retry.patch > > > > With this patch reverted -rc1-mm1 is happily running on my test box. > > That was rather unexpected. Thanks. > I can confirm that 2.6.20-rc1-mm1 with this patch reverted mounts my raid6 partition without problems. This is x86_64 with SMP. Kind regards, Jurriaan -- HORROR FILM WISDOM: 9. If your car runs out of gas at night, do not go to the nearby deserted-looking house to phone for help. Debian (Unstable) GNU/Linux 2.6.20-rc1 2x2011 bogomips load 7.42 the Jack Vance Integral Edition: http://www.integralarchive.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
Rafael J. Wysocki wrote: > Okay, I have identified the patch that causes the problem to appear, which is > > fix-sense-key-medium-error-processing-and-retry.patch > > With this patch reverted -rc1-mm1 is happily running on my test box. Yes! Here too. Good work. regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
On Sun, 17 Dec 2006 12:00:12 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > Okay, I have identified the patch that causes the problem to appear, which is > > fix-sense-key-medium-error-processing-and-retry.patch > > With this patch reverted -rc1-mm1 is happily running on my test box. That was rather unexpected. Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
On Saturday, 16 December 2006 12:16, Rafael J. Wysocki wrote: > On Saturday, 16 December 2006 10:56, Rafael J. Wysocki wrote: > > On Saturday, 16 December 2006 00:38, Rafael J. Wysocki wrote: > > > On Friday, 15 December 2006 23:24, Jeff Garzik wrote: > > > > Rafael J. Wysocki wrote: > > > > > On Friday, 15 December 2006 22:39, Andrew Morton wrote: > > > > >> On Fri, 15 Dec 2006 13:05:52 -0800 > > > > >> Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > >> > > > > >>> Jeff, I shall send all the sata patches which I have at you one > > > > >>> single time > > > > >>> and I shall then drop the lot. So please don't flub them. > > > > >>> > > > > >>> I'll then do a rc1-mm2 without them. > > > > >> hm, this is looking like a lot of work for not much gain. Rafael, > > > > >> are > > > > >> you able to do a quick chop and tell us whether these: > > > > >> > > > > >> pci-move-pci_vdevice-from-libata-to-core.patch > > > > >> pata_cs5530-suspend-resume-support-tweak.patch > > > > >> ata-fix-platform_device_register_simple-error-check.patch > > > > >> initializer-entry-defined-twice-in-pata_rz1000.patch > > > > >> pata_via-suspend-resume-support-fix.patch > > > > >> sata_nv-add-suspend-resume-support.patch > > > > >> libata-simulate-report-luns-for-atapi-devices.patch > > > > >> user-of-the-jiffies-rounding-patch-ata-subsystem.patch > > > > >> libata-fix-oops-with-sparsemem.patch > > > > >> sata_nv-fix-kfree-ordering-in-remove.patch > > > > >> libata-dont-initialize-sg-in-ata_exec_internal-if-dma_none-take-2.patch > > > > >> pci-quirks-fix-the-festering-mess-that-claims-to-handle-ide-quirks-ide-fix.patch > > > > >> > > > > >> are innocent? > > > > > > > > > > Yes, they are. > > > > > > > > We all really appreciate your patience :) This is good feedback. > > > > > > > > To narrow down some more, does applying 2.6.20-rc1 + the attached patch > > > > work? (ignoring -mm tree altogether) > > > > > > Yes, it does. > > > > I've applied the patches from -rc1-mm1 up to and including > > > > problem-phy-probe-not-working-properly-for-ibm_emac-ppc4xx.patch > > > > on top of 2.6.20-rc1 and they don't seem to break anything. Will try some > > more. > > The patch that breaks things is somewhere between > > dont-export-device-ids-to-userspace.patch > > and > > funsoft-is-bust-on-sparc.patch > > inclusive. > > Now I'll need to resync my disk arrays so if anyone has any suggestions > what to try next, I'll be grateful. ;-) Okay, I have identified the patch that causes the problem to appear, which is fix-sense-key-medium-error-processing-and-retry.patch With this patch reverted -rc1-mm1 is happily running on my test box. Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
On Saturday, 16 December 2006 10:56, Rafael J. Wysocki wrote: > On Saturday, 16 December 2006 00:38, Rafael J. Wysocki wrote: > > On Friday, 15 December 2006 23:24, Jeff Garzik wrote: > > > Rafael J. Wysocki wrote: > > > > On Friday, 15 December 2006 22:39, Andrew Morton wrote: > > > >> On Fri, 15 Dec 2006 13:05:52 -0800 > > > >> Andrew Morton <[EMAIL PROTECTED]> wrote: > > > >> > > > >>> Jeff, I shall send all the sata patches which I have at you one > > > >>> single time > > > >>> and I shall then drop the lot. So please don't flub them. > > > >>> > > > >>> I'll then do a rc1-mm2 without them. > > > >> hm, this is looking like a lot of work for not much gain. Rafael, are > > > >> you able to do a quick chop and tell us whether these: > > > >> > > > >> pci-move-pci_vdevice-from-libata-to-core.patch > > > >> pata_cs5530-suspend-resume-support-tweak.patch > > > >> ata-fix-platform_device_register_simple-error-check.patch > > > >> initializer-entry-defined-twice-in-pata_rz1000.patch > > > >> pata_via-suspend-resume-support-fix.patch > > > >> sata_nv-add-suspend-resume-support.patch > > > >> libata-simulate-report-luns-for-atapi-devices.patch > > > >> user-of-the-jiffies-rounding-patch-ata-subsystem.patch > > > >> libata-fix-oops-with-sparsemem.patch > > > >> sata_nv-fix-kfree-ordering-in-remove.patch > > > >> libata-dont-initialize-sg-in-ata_exec_internal-if-dma_none-take-2.patch > > > >> pci-quirks-fix-the-festering-mess-that-claims-to-handle-ide-quirks-ide-fix.patch > > > >> > > > >> are innocent? > > > > > > > > Yes, they are. > > > > > > We all really appreciate your patience :) This is good feedback. > > > > > > To narrow down some more, does applying 2.6.20-rc1 + the attached patch > > > work? (ignoring -mm tree altogether) > > > > Yes, it does. > > I've applied the patches from -rc1-mm1 up to and including > > problem-phy-probe-not-working-properly-for-ibm_emac-ppc4xx.patch > > on top of 2.6.20-rc1 and they don't seem to break anything. Will try some > more. The patch that breaks things is somewhere between dont-export-device-ids-to-userspace.patch and funsoft-is-bust-on-sparc.patch inclusive. Now I'll need to resync my disk arrays so if anyone has any suggestions what to try next, I'll be grateful. ;-) Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
On Saturday, 16 December 2006 00:38, Rafael J. Wysocki wrote: > On Friday, 15 December 2006 23:24, Jeff Garzik wrote: > > Rafael J. Wysocki wrote: > > > On Friday, 15 December 2006 22:39, Andrew Morton wrote: > > >> On Fri, 15 Dec 2006 13:05:52 -0800 > > >> Andrew Morton <[EMAIL PROTECTED]> wrote: > > >> > > >>> Jeff, I shall send all the sata patches which I have at you one single > > >>> time > > >>> and I shall then drop the lot. So please don't flub them. > > >>> > > >>> I'll then do a rc1-mm2 without them. > > >> hm, this is looking like a lot of work for not much gain. Rafael, are > > >> you able to do a quick chop and tell us whether these: > > >> > > >> pci-move-pci_vdevice-from-libata-to-core.patch > > >> pata_cs5530-suspend-resume-support-tweak.patch > > >> ata-fix-platform_device_register_simple-error-check.patch > > >> initializer-entry-defined-twice-in-pata_rz1000.patch > > >> pata_via-suspend-resume-support-fix.patch > > >> sata_nv-add-suspend-resume-support.patch > > >> libata-simulate-report-luns-for-atapi-devices.patch > > >> user-of-the-jiffies-rounding-patch-ata-subsystem.patch > > >> libata-fix-oops-with-sparsemem.patch > > >> sata_nv-fix-kfree-ordering-in-remove.patch > > >> libata-dont-initialize-sg-in-ata_exec_internal-if-dma_none-take-2.patch > > >> pci-quirks-fix-the-festering-mess-that-claims-to-handle-ide-quirks-ide-fix.patch > > >> > > >> are innocent? > > > > > > Yes, they are. > > > > We all really appreciate your patience :) This is good feedback. > > > > To narrow down some more, does applying 2.6.20-rc1 + the attached patch > > work? (ignoring -mm tree altogether) > > Yes, it does. I've applied the patches from -rc1-mm1 up to and including problem-phy-probe-not-working-properly-for-ibm_emac-ppc4xx.patch on top of 2.6.20-rc1 and they don't seem to break anything. Will try some more. Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
From: Jeff Garzik <[EMAIL PROTECTED]> Date: Fri, Dec 15, 2006 at 04:48:44PM -0500 > The "Re: Linux 2.6.20-rc1" sub-thread that had Jens and Alistair John > Strachan replying seemed to implicate some core block layer badness. > The original problem (not mounting my raid6 partition) is observable in 2.6.20-rc1-mm1, but not in 2.6.20-rc1; ie. 2.6.20-rc1 is good for me. Linux version 2.6.20-rc1 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #3 SMP Fri Dec 15 21:19:54 CET 2006 md: Autodetecting RAID arrays. md: autorun ... md: considering sdh1 ... md: adding sdh1 ... md: adding sdg1 ... md: adding sdf1 ... md: adding sde1 ... md: adding sdd1 ... md: adding sdc1 ... md: adding sdb1 ... md: adding sda1 ... md: hdc9 has different UUID to sdh1 md: hdc8 has different UUID to sdh1 md: hdc7 has different UUID to sdh1 md: hdc6 has different UUID to sdh1 md: hdc5 has different UUID to sdh1 md: hda9 has different UUID to sdh1 md: hda8 has different UUID to sdh1 md: hda7 has different UUID to sdh1 md: hda6 has different UUID to sdh1 md: hda5 has different UUID to sdh1 md: created md0 md: bind md: bind md: bind md: bind md: bind md: bind md: bind md: bind md: running: raid5: device sdh1 operational as raid disk 1 raid5: device sdg1 operational as raid disk 0 raid5: device sdf1 operational as raid disk 5 raid5: device sde1 operational as raid disk 6 raid5: device sdd1 operational as raid disk 7 raid5: device sdc1 operational as raid disk 3 raid5: device sdb1 operational as raid disk 2 raid5: device sda1 operational as raid disk 4 raid5: allocated 8462kB for md0 raid5: raid level 6 set md0 active with 8 out of 8 devices, algorithm 2 RAID5 conf printout: --- rd:8 wd:8 disk 0, o:1, dev:sdg1 disk 1, o:1, dev:sdh1 disk 2, o:1, dev:sdb1 disk 3, o:1, dev:sdc1 disk 4, o:1, dev:sda1 disk 5, o:1, dev:sdf1 disk 6, o:1, dev:sde1 disk 7, o:1, dev:sdd1 md0: bitmap initialized from disk: read 15/15 pages, set 1 bits, status: 0 created bitmap (233 pages) for device md0 md: considering hdc9 ... md: adding hdc9 ... md: hdc8 has different UUID to hdc9 md: hdc7 has different UUID to hdc9 md: hdc6 has different UUID to hdc9 md: hdc5 has different UUID to hdc9 md: adding hda9 ... md: hda8 has different UUID to hdc9 md: hda7 has different UUID to hdc9 md: hda6 has different UUID to hdc9 md: hda5 has different UUID to hdc9 md: created md4 md: bind md: bind md: running: raid1: raid set md4 active with 2 out of 2 mirrors md4: bitmap initialized from disk: read 10/10 pages, set 45 bits, status: 0 EXT3 FS on md0, internal journal EXT3-fs: mounted filesystem with ordered data mode. Jurriaan -- And I thought that the Borg were bad... Debian (Unstable) GNU/Linux 2.6.20-rc1 2x4023 bogomips load 5.55 the Jack Vance Integral Edition: http://www.integralarchive.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
On Friday, 15 December 2006 23:24, Jeff Garzik wrote: > Rafael J. Wysocki wrote: > > On Friday, 15 December 2006 22:39, Andrew Morton wrote: > >> On Fri, 15 Dec 2006 13:05:52 -0800 > >> Andrew Morton <[EMAIL PROTECTED]> wrote: > >> > >>> Jeff, I shall send all the sata patches which I have at you one single > >>> time > >>> and I shall then drop the lot. So please don't flub them. > >>> > >>> I'll then do a rc1-mm2 without them. > >> hm, this is looking like a lot of work for not much gain. Rafael, are > >> you able to do a quick chop and tell us whether these: > >> > >> pci-move-pci_vdevice-from-libata-to-core.patch > >> pata_cs5530-suspend-resume-support-tweak.patch > >> ata-fix-platform_device_register_simple-error-check.patch > >> initializer-entry-defined-twice-in-pata_rz1000.patch > >> pata_via-suspend-resume-support-fix.patch > >> sata_nv-add-suspend-resume-support.patch > >> libata-simulate-report-luns-for-atapi-devices.patch > >> user-of-the-jiffies-rounding-patch-ata-subsystem.patch > >> libata-fix-oops-with-sparsemem.patch > >> sata_nv-fix-kfree-ordering-in-remove.patch > >> libata-dont-initialize-sg-in-ata_exec_internal-if-dma_none-take-2.patch > >> pci-quirks-fix-the-festering-mess-that-claims-to-handle-ide-quirks-ide-fix.patch > >> > >> are innocent? > > > > Yes, they are. > > We all really appreciate your patience :) This is good feedback. > > To narrow down some more, does applying 2.6.20-rc1 + the attached patch > work? (ignoring -mm tree altogether) Yes, it does. Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
On Friday, 15 December 2006 23:19, Jeff Garzik wrote: > Alan wrote: > > On Fri, 15 Dec 2006 13:39:27 -0800 > > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > >> On Fri, 15 Dec 2006 13:05:52 -0800 > >> Andrew Morton <[EMAIL PROTECTED]> wrote: > >> > >>> Jeff, I shall send all the sata patches which I have at you one single > >>> time > >>> and I shall then drop the lot. So please don't flub them. > >>> > >>> I'll then do a rc1-mm2 without them. > >> hm, this is looking like a lot of work for not much gain. Rafael, are > >> you able to do a quick chop and tell us whether these: > > > > The md one and the long history of reports about parallel I/O causing > > problems sounds a lot more like the kmap stuff you were worried about > > Andrew. I'd be very intereste dto know if it happens on x86_32 built with > > a standard memory split and no highmem > > 2.6.20-rc1 works, and 2.6.20-rc1 does not have the kmap_atomic() fix. > > Upstream does kmap_atomic(KM_USER0) and -mm does kmap_atomic(KM_IRQ0) On x86_64 that shouldn't be a problem, I think, and my machine is an x86_64 one. Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
Rafael J. Wysocki wrote:
On Friday, 15 December 2006 22:39, Andrew Morton wrote:
On Fri, 15 Dec 2006 13:05:52 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
Jeff, I shall send all the sata patches which I have at you one single time
and I shall then drop the lot. So please don't flub them.
I'll then do a rc1-mm2 without them.
hm, this is looking like a lot of work for not much gain. Rafael, are
you able to do a quick chop and tell us whether these:
pci-move-pci_vdevice-from-libata-to-core.patch
pata_cs5530-suspend-resume-support-tweak.patch
ata-fix-platform_device_register_simple-error-check.patch
initializer-entry-defined-twice-in-pata_rz1000.patch
pata_via-suspend-resume-support-fix.patch
sata_nv-add-suspend-resume-support.patch
libata-simulate-report-luns-for-atapi-devices.patch
user-of-the-jiffies-rounding-patch-ata-subsystem.patch
libata-fix-oops-with-sparsemem.patch
sata_nv-fix-kfree-ordering-in-remove.patch
libata-dont-initialize-sg-in-ata_exec_internal-if-dma_none-take-2.patch
pci-quirks-fix-the-festering-mess-that-claims-to-handle-ide-quirks-ide-fix.patch
are innocent?
Yes, they are.
We all really appreciate your patience :) This is good feedback.
To narrow down some more, does applying 2.6.20-rc1 + the attached patch
work? (ignoring -mm tree altogether)
The attached patch should /basically/ be the contents of Andrew's
git-netdev-all patch.
Jeff
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 984ab28..fb1de86 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -292,7 +292,7 @@ config PATA_ISAPNP
If unsure, say N.
config PATA_IT821X
- tristate "IT821x PATA support (Experimental)"
+ tristate "IT8211/2 PATA support (Experimental)"
depends on PCI && EXPERIMENTAL
help
This option enables support for the ITE 8211 and 8212
@@ -301,6 +301,15 @@ config PATA_IT821X
If unsure, say N.
+config PATA_IT8213
+ tristate "IT8213 PATA support (Experimental)"
+ depends on PCI && EXPERIMENTAL
+ help
+ This option enables support for the ITE 821 PATA
+ controllers via the new ATA layer.
+
+ If unsure, say N.
+
config PATA_JMICRON
tristate "JMicron PATA support"
depends on PCI
@@ -337,6 +346,15 @@ config PATA_MARVELL
If unsure, say N.
+config PATA_MPC52xx
+ tristate "Freescale MPC52xx SoC internal IDE"
+ depends on PPC_MPC52xx
+ help
+ This option enables support for integrated IDE controller
+ of the Freescale MPC52xx SoC.
+
+ If unsure, say N.
+
config PATA_MPIIX
tristate "Intel PATA MPIIX support"
depends on PCI
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index bc3d81a..a0df15d 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -33,11 +33,13 @@ obj-$(CONFIG_PATA_HPT3X2N) += pata_hpt3x2n.o
obj-$(CONFIG_PATA_HPT3X3) += pata_hpt3x3.o
obj-$(CONFIG_PATA_ISAPNP) += pata_isapnp.o
obj-$(CONFIG_PATA_IT821X) += pata_it821x.o
+obj-$(CONFIG_PATA_IT8213) += pata_it8213.o
obj-$(CONFIG_PATA_JMICRON) += pata_jmicron.o
obj-$(CONFIG_PATA_NETCELL) += pata_netcell.o
obj-$(CONFIG_PATA_NS87410) += pata_ns87410.o
obj-$(CONFIG_PATA_OPTI)+= pata_opti.o
obj-$(CONFIG_PATA_OPTIDMA) += pata_optidma.o
+obj-$(CONFIG_PATA_MPC52xx) += pata_mpc52xx.o
obj-$(CONFIG_PATA_MARVELL) += pata_marvell.o
obj-$(CONFIG_PATA_MPIIX) += pata_mpiix.o
obj-$(CONFIG_PATA_OLDPIIX) += pata_oldpiix.o
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index f36da48..dbae6d9 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -645,8 +645,6 @@ static int ahci_reset_controller(void __iomem *mmio, struct
pci_dev *pdev)
u32 cap_save, impl_save, tmp;
cap_save = readl(mmio + HOST_CAP);
- cap_save &= ( (1<<28) | (1<<17) );
- cap_save |= (1 << 27);
impl_save = readl(mmio + HOST_PORTS_IMPL);
/* global controller reset */
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index c7de0bb..7959e4c 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -226,14 +226,26 @@ static const struct pci_device_id piix_pci_tbl[] = {
{ 0x8086, 0x27c0, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich6_sata_ahci },
/* 2801GBM/GHM (ICH7M, identical to ICH6M) */
{ 0x8086, 0x27c4, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich6m_sata_ahci },
- /* Enterprise Southbridge 2 (where's the datasheet?) */
+ /* Enterprise Southbridge 2 (631xESB/632xESB) */
{ 0x8086, 0x2680, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich6_sata_ahci },
- /* SATA Controller 1 IDE (ICH8, no datasheet yet) */
+ /* SATA Controller 1 IDE (ICH8) */
{ 0x8086, 0x2820, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_ahci },
- /* SATA Controller 2 IDE (ICH8, ditto) */
+ /* SATA Controller 2 IDE (ICH8) */
{ 0x8086, 0x2825, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_ahci }
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
On Friday, 15 December 2006 22:39, Andrew Morton wrote: > On Fri, 15 Dec 2006 13:05:52 -0800 > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > Jeff, I shall send all the sata patches which I have at you one single time > > and I shall then drop the lot. So please don't flub them. > > > > I'll then do a rc1-mm2 without them. > > hm, this is looking like a lot of work for not much gain. Rafael, are > you able to do a quick chop and tell us whether these: > > pci-move-pci_vdevice-from-libata-to-core.patch > pata_cs5530-suspend-resume-support-tweak.patch > ata-fix-platform_device_register_simple-error-check.patch > initializer-entry-defined-twice-in-pata_rz1000.patch > pata_via-suspend-resume-support-fix.patch > sata_nv-add-suspend-resume-support.patch > libata-simulate-report-luns-for-atapi-devices.patch > user-of-the-jiffies-rounding-patch-ata-subsystem.patch > libata-fix-oops-with-sparsemem.patch > sata_nv-fix-kfree-ordering-in-remove.patch > libata-dont-initialize-sg-in-ata_exec_internal-if-dma_none-take-2.patch > pci-quirks-fix-the-festering-mess-that-claims-to-handle-ide-quirks-ide-fix.patch > > are innocent? Yes, they are. Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
Alan wrote: On Fri, 15 Dec 2006 13:39:27 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: On Fri, 15 Dec 2006 13:05:52 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: Jeff, I shall send all the sata patches which I have at you one single time and I shall then drop the lot. So please don't flub them. I'll then do a rc1-mm2 without them. hm, this is looking like a lot of work for not much gain. Rafael, are you able to do a quick chop and tell us whether these: The md one and the long history of reports about parallel I/O causing problems sounds a lot more like the kmap stuff you were worried about Andrew. I'd be very intereste dto know if it happens on x86_32 built with a standard memory split and no highmem 2.6.20-rc1 works, and 2.6.20-rc1 does not have the kmap_atomic() fix. Upstream does kmap_atomic(KM_USER0) and -mm does kmap_atomic(KM_IRQ0) Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
On Friday, 15 December 2006 23:06, Alan wrote: > On Fri, 15 Dec 2006 13:39:27 -0800 > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > On Fri, 15 Dec 2006 13:05:52 -0800 > > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > Jeff, I shall send all the sata patches which I have at you one single > > > time > > > and I shall then drop the lot. So please don't flub them. > > > > > > I'll then do a rc1-mm2 without them. > > > > hm, this is looking like a lot of work for not much gain. Rafael, are > > you able to do a quick chop and tell us whether these: > > The md one and the long history of reports about parallel I/O causing > problems sounds a lot more like the kmap stuff you were worried about > Andrew. I'd be very intereste dto know if it happens on x86_32 built with > a standard memory split and no highmem But my box is a x86_64, so ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
On Fri, 15 Dec 2006 13:39:27 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > On Fri, 15 Dec 2006 13:05:52 -0800 > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > Jeff, I shall send all the sata patches which I have at you one single time > > and I shall then drop the lot. So please don't flub them. > > > > I'll then do a rc1-mm2 without them. > > hm, this is looking like a lot of work for not much gain. Rafael, are > you able to do a quick chop and tell us whether these: The md one and the long history of reports about parallel I/O causing problems sounds a lot more like the kmap stuff you were worried about Andrew. I'd be very intereste dto know if it happens on x86_32 built with a standard memory split and no highmem - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
On Friday, 15 December 2006 22:49, Jeff Garzik wrote: > Rafael J. Wysocki wrote: > > The other box is mine and it works just fine with 2.6.20-rc1. > > > >> I think something bad happened in sata land just recently. > > > > Yup. Please see, for example: > > > > http://marc.theaimsgroup.com/?l=linux-kernel&m=116621656432500&w=2 > > > > It looks like the breakage is in sata, in the patches that went in after > > 2.6.19-rc6-mm2 (that one worked for me like charm). > > > So 2.6.20-rc1 works for you? Yes. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
The "Re: Linux 2.6.20-rc1" sub-thread that had Jens and Alistair John Strachan replying seemed to implicate some core block layer badness. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
Rafael J. Wysocki wrote: The other box is mine and it works just fine with 2.6.20-rc1. I think something bad happened in sata land just recently. Yup. Please see, for example: http://marc.theaimsgroup.com/?l=linux-kernel&m=116621656432500&w=2 It looks like the breakage is in sata, in the patches that went in after 2.6.19-rc6-mm2 (that one worked for me like charm). So 2.6.20-rc1 works for you? Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
On Friday, 15 December 2006 22:39, Andrew Morton wrote: > On Fri, 15 Dec 2006 13:05:52 -0800 > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > Jeff, I shall send all the sata patches which I have at you one single time > > and I shall then drop the lot. So please don't flub them. > > > > I'll then do a rc1-mm2 without them. > > hm, this is looking like a lot of work for not much gain. Rafael, are > you able to do a quick chop and tell us whether these: > > pci-move-pci_vdevice-from-libata-to-core.patch > pata_cs5530-suspend-resume-support-tweak.patch > ata-fix-platform_device_register_simple-error-check.patch > initializer-entry-defined-twice-in-pata_rz1000.patch > pata_via-suspend-resume-support-fix.patch > sata_nv-add-suspend-resume-support.patch > libata-simulate-report-luns-for-atapi-devices.patch > user-of-the-jiffies-rounding-patch-ata-subsystem.patch > libata-fix-oops-with-sparsemem.patch > sata_nv-fix-kfree-ordering-in-remove.patch > libata-dont-initialize-sg-in-ata_exec_internal-if-dma_none-take-2.patch > pci-quirks-fix-the-festering-mess-that-claims-to-handle-ide-quirks-ide-fix.patch > > are innocent? Will do in a while and report back. Stay tuned. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
On Fri, 15 Dec 2006 13:05:52 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > Jeff, I shall send all the sata patches which I have at you one single time > and I shall then drop the lot. So please don't flub them. > > I'll then do a rc1-mm2 without them. hm, this is looking like a lot of work for not much gain. Rafael, are you able to do a quick chop and tell us whether these: pci-move-pci_vdevice-from-libata-to-core.patch pata_cs5530-suspend-resume-support-tweak.patch ata-fix-platform_device_register_simple-error-check.patch initializer-entry-defined-twice-in-pata_rz1000.patch pata_via-suspend-resume-support-fix.patch sata_nv-add-suspend-resume-support.patch libata-simulate-report-luns-for-atapi-devices.patch user-of-the-jiffies-rounding-patch-ata-subsystem.patch libata-fix-oops-with-sparsemem.patch sata_nv-fix-kfree-ordering-in-remove.patch libata-dont-initialize-sg-in-ata_exec_internal-if-dma_none-take-2.patch pci-quirks-fix-the-festering-mess-that-claims-to-handle-ide-quirks-ide-fix.patch are innocent? Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
I don't think it's in -rc1, please see below. On Friday, 15 December 2006 21:50, Neil Brown wrote: > On Friday December 15, [EMAIL PROTECTED] wrote: > > From: Neil Brown <[EMAIL PROTECTED]> > > Date: Wed, Dec 06, 2006 at 06:20:57PM +1100 > > > i.e. current -mm is good for 2.6.20 (though I have a few other little > > > things I'll be sending in soon, they aren't related to the raid6 > > > problem). > > > > > 2.6.20-rc1-mm1 doesn't boot on my box, due to the fact that e2fsck gives > > > > Buffer I/O error on device /dev/md0, logical block 0 > > > > But before that > > raid5: device sdh1 operational as raid disk 1 > > raid5: device sdg1 operational as raid disk 0 > > raid5: device sdf1 operational as raid disk 5 > > raid5: device sde1 operational as raid disk 6 > > raid5: device sdd1 operational as raid disk 7 > > raid5: device sdc1 operational as raid disk 3 > > raid5: device sdb1 operational as raid disk 2 > > raid5: device sda1 operational as raid disk 4 > > raid5: allocated 8462kB for md0 > > raid5: raid level 6 set md0 active with 8 out of 8 devices, algorithm 2 > > RAID5 conf printout: > > --- rd:8 wd:8 > > disk 0, o:1, dev:sdg1 > > disk 1, o:1, dev:sdh1 > > disk 2, o:1, dev:sdb1 > > disk 3, o:1, dev:sdc1 > > disk 4, o:1, dev:sda1 > > disk 5, o:1, dev:sdf1 > > disk 6, o:1, dev:sde1 > > disk 7, o:1, dev:sdd1 > > md0: bitmap initialized from disk: read 15/15 pages, set 1 bits, status: 0 > > created bitmap (233 pages) for device md0 > > md: super_written gets error=-5, uptodate=0 > > raid5: Disk failure on sde1, disabling device. Operation continuing on 7 > > devices > > md: super_written gets error=-5, uptodate=0 > > raid5: Disk failure on sdg1, disabling device. Operation continuing on 6 > > devices > > md: super_written gets error=-5, uptodate=0 > > raid5: Disk failure on sdf1, disabling device. Operation continuing on 5 > > devices > > md: super_written gets error=-5, uptodate=0 > > raid5: Disk failure on sdc1, disabling device. Operation continuing on 4 > > devices > > md: super_written gets error=-5, uptodate=0 > > raid5: Disk failure on sdb1, disabling device. Operation continuing on 3 > > devices > > md: super_written gets error=-5, uptodate=0 > > raid5: Disk failure on sdh1, disabling device. Operation continuing on 2 > > devices > > md: super_written gets error=-5, uptodate=0 > > raid5: Disk failure on sdd1, disabling device. Operation continuing on 1 > > devices > > md: super_written gets error=-5, uptodate=0 > > raid5: Disk failure on sda1, disabling device. Operation continuing on 0 > > devices > > Oh dear, that array isn't much good any more.! > That is the second report I have had of this with sata drives. This > was raid456, the other was raid1. Two different sata drivers are > involved (sata_nv in this case, sata_uli in the other case). The other box is mine and it works just fine with 2.6.20-rc1. > I think something bad happened in sata land just recently. Yup. Please see, for example: http://marc.theaimsgroup.com/?l=linux-kernel&m=116621656432500&w=2 It looks like the breakage is in sata, in the patches that went in after 2.6.19-rc6-mm2 (that one worked for me like charm). Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
On Friday, 15 December 2006 22:05, Andrew Morton wrote: > On Sat, 16 Dec 2006 07:50:01 +1100 > Neil Brown <[EMAIL PROTECTED]> wrote: > > > On Friday December 15, [EMAIL PROTECTED] wrote: > > > From: Neil Brown <[EMAIL PROTECTED]> > > > Date: Wed, Dec 06, 2006 at 06:20:57PM +1100 > > > > i.e. current -mm is good for 2.6.20 (though I have a few other little > > > > things I'll be sending in soon, they aren't related to the raid6 > > > > problem). > > > > > > > 2.6.20-rc1-mm1 doesn't boot on my box, due to the fact that e2fsck gives > > > > > > Buffer I/O error on device /dev/md0, logical block 0 > > > > > > > But before that > > > raid5: device sdh1 operational as raid disk 1 > > > raid5: device sdg1 operational as raid disk 0 > > > raid5: device sdf1 operational as raid disk 5 > > > raid5: device sde1 operational as raid disk 6 > > > raid5: device sdd1 operational as raid disk 7 > > > raid5: device sdc1 operational as raid disk 3 > > > raid5: device sdb1 operational as raid disk 2 > > > raid5: device sda1 operational as raid disk 4 > > > raid5: allocated 8462kB for md0 > > > raid5: raid level 6 set md0 active with 8 out of 8 devices, algorithm 2 > > > RAID5 conf printout: > > > --- rd:8 wd:8 > > > disk 0, o:1, dev:sdg1 > > > disk 1, o:1, dev:sdh1 > > > disk 2, o:1, dev:sdb1 > > > disk 3, o:1, dev:sdc1 > > > disk 4, o:1, dev:sda1 > > > disk 5, o:1, dev:sdf1 > > > disk 6, o:1, dev:sde1 > > > disk 7, o:1, dev:sdd1 > > > md0: bitmap initialized from disk: read 15/15 pages, set 1 bits, status: 0 > > > created bitmap (233 pages) for device md0 > > > md: super_written gets error=-5, uptodate=0 > > > raid5: Disk failure on sde1, disabling device. Operation continuing on 7 > > > devices > > > md: super_written gets error=-5, uptodate=0 > > > raid5: Disk failure on sdg1, disabling device. Operation continuing on 6 > > > devices > > > md: super_written gets error=-5, uptodate=0 > > > raid5: Disk failure on sdf1, disabling device. Operation continuing on 5 > > > devices > > > md: super_written gets error=-5, uptodate=0 > > > raid5: Disk failure on sdc1, disabling device. Operation continuing on 4 > > > devices > > > md: super_written gets error=-5, uptodate=0 > > > raid5: Disk failure on sdb1, disabling device. Operation continuing on 3 > > > devices > > > md: super_written gets error=-5, uptodate=0 > > > raid5: Disk failure on sdh1, disabling device. Operation continuing on 2 > > > devices > > > md: super_written gets error=-5, uptodate=0 > > > raid5: Disk failure on sdd1, disabling device. Operation continuing on 1 > > > devices > > > md: super_written gets error=-5, uptodate=0 > > > raid5: Disk failure on sda1, disabling device. Operation continuing on 0 > > > devices > > > > Oh dear, that array isn't much good any more.! > > That is the second report I have had of this with sata drives. This > > was raid456, the other was raid1. Two different sata drivers are > > involved (sata_nv in this case, sata_uli in the other case). > > I think something bad happened in sata land just recently. > > The device driver is returning -EIO for a write without printing any > > messages. > > > > OK, this is bad. The wheels do appear to have fallen off sata in rc1-mm1. I think it's happened in 2.6.19-mm1 already, since that kernel breaks md RAID1 on my box (the sata_uli case above). Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
On Sat, 16 Dec 2006 07:50:01 +1100 Neil Brown <[EMAIL PROTECTED]> wrote: > On Friday December 15, [EMAIL PROTECTED] wrote: > > From: Neil Brown <[EMAIL PROTECTED]> > > Date: Wed, Dec 06, 2006 at 06:20:57PM +1100 > > > i.e. current -mm is good for 2.6.20 (though I have a few other little > > > things I'll be sending in soon, they aren't related to the raid6 > > > problem). > > > > > 2.6.20-rc1-mm1 doesn't boot on my box, due to the fact that e2fsck gives > > > > Buffer I/O error on device /dev/md0, logical block 0 > > > > But before that > > raid5: device sdh1 operational as raid disk 1 > > raid5: device sdg1 operational as raid disk 0 > > raid5: device sdf1 operational as raid disk 5 > > raid5: device sde1 operational as raid disk 6 > > raid5: device sdd1 operational as raid disk 7 > > raid5: device sdc1 operational as raid disk 3 > > raid5: device sdb1 operational as raid disk 2 > > raid5: device sda1 operational as raid disk 4 > > raid5: allocated 8462kB for md0 > > raid5: raid level 6 set md0 active with 8 out of 8 devices, algorithm 2 > > RAID5 conf printout: > > --- rd:8 wd:8 > > disk 0, o:1, dev:sdg1 > > disk 1, o:1, dev:sdh1 > > disk 2, o:1, dev:sdb1 > > disk 3, o:1, dev:sdc1 > > disk 4, o:1, dev:sda1 > > disk 5, o:1, dev:sdf1 > > disk 6, o:1, dev:sde1 > > disk 7, o:1, dev:sdd1 > > md0: bitmap initialized from disk: read 15/15 pages, set 1 bits, status: 0 > > created bitmap (233 pages) for device md0 > > md: super_written gets error=-5, uptodate=0 > > raid5: Disk failure on sde1, disabling device. Operation continuing on 7 > > devices > > md: super_written gets error=-5, uptodate=0 > > raid5: Disk failure on sdg1, disabling device. Operation continuing on 6 > > devices > > md: super_written gets error=-5, uptodate=0 > > raid5: Disk failure on sdf1, disabling device. Operation continuing on 5 > > devices > > md: super_written gets error=-5, uptodate=0 > > raid5: Disk failure on sdc1, disabling device. Operation continuing on 4 > > devices > > md: super_written gets error=-5, uptodate=0 > > raid5: Disk failure on sdb1, disabling device. Operation continuing on 3 > > devices > > md: super_written gets error=-5, uptodate=0 > > raid5: Disk failure on sdh1, disabling device. Operation continuing on 2 > > devices > > md: super_written gets error=-5, uptodate=0 > > raid5: Disk failure on sdd1, disabling device. Operation continuing on 1 > > devices > > md: super_written gets error=-5, uptodate=0 > > raid5: Disk failure on sda1, disabling device. Operation continuing on 0 > > devices > > Oh dear, that array isn't much good any more.! > That is the second report I have had of this with sata drives. This > was raid456, the other was raid1. Two different sata drivers are > involved (sata_nv in this case, sata_uli in the other case). > I think something bad happened in sata land just recently. > The device driver is returning -EIO for a write without printing any messages. > OK, this is bad. The wheels do appear to have fallen off sata in rc1-mm1. Jeff, I shall send all the sata patches which I have at you one single time and I shall then drop the lot. So please don't flub them. I'll then do a rc1-mm2 without them. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
