From: Neil Brown <hidden> Date: 2006-12-15 20:49:48
On Friday December 15, thunder7@xs4all.nl wrote:
From: Neil Brown <redacted>
Date: Wed, Dec 06, 2006 at 06:20:57PM +1100
quoted
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.
NeilBrown
From: Andrew Morton <hidden> Date: 2006-12-15 21:06:15
On Sat, 16 Dec 2006 07:50:01 +1100
Neil Brown [off-list ref] wrote:
On Friday December 15, thunder7@xs4all.nl wrote:
quoted
From: Neil Brown <redacted>
Date: Wed, Dec 06, 2006 at 06:20:57PM +1100
quoted
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....
quoted
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.
From: Rafael J. Wysocki <hidden> Date: 2006-12-15 21:13:17
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, thunder7@xs4all.nl wrote:
quoted
From: Neil Brown <redacted>
Date: Wed, Dec 06, 2006 at 06:20:57PM +1100
quoted
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....
quoted
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
From: Rafael J. Wysocki <hidden> Date: 2006-12-15 21:16:11
On Friday, 15 December 2006 22:05, Andrew Morton wrote:
On Sat, 16 Dec 2006 07:50:01 +1100
Neil Brown [off-list ref] wrote:
quoted
On Friday December 15, thunder7@xs4all.nl wrote:
quoted
From: Neil Brown <redacted>
Date: Wed, Dec 06, 2006 at 06:20:57PM +1100
quoted
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....
quoted
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
From: Andrew Morton <hidden> Date: 2006-12-15 21:39:47
On Fri, 15 Dec 2006 13:05:52 -0800
Andrew Morton [off-list ref] 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.
From: Rafael J. Wysocki <hidden> Date: 2006-12-15 21:44:38
On Friday, 15 December 2006 22:39, Andrew Morton wrote:
On Fri, 15 Dec 2006 13:05:52 -0800
Andrew Morton [off-list ref] wrote:
quoted
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?
On Fri, 15 Dec 2006 13:39:27 -0800
Andrew Morton [off-list ref] wrote:
On Fri, 15 Dec 2006 13:05:52 -0800
Andrew Morton [off-list ref] wrote:
quoted
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....
From: Rafael J. Wysocki <hidden> Date: 2006-12-15 22:02:40
On Friday, 15 December 2006 23:06, Alan wrote:
On Fri, 15 Dec 2006 13:39:27 -0800
Andrew Morton [off-list ref] wrote:
quoted
On Fri, 15 Dec 2006 13:05:52 -0800
Andrew Morton [off-list ref] wrote:
quoted
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....
From: Jeff Garzik <hidden> Date: 2006-12-15 22:19:56
Alan wrote:
On Fri, 15 Dec 2006 13:39:27 -0800
Andrew Morton [off-list ref] wrote:
quoted
On Fri, 15 Dec 2006 13:05:52 -0800
Andrew Morton [off-list ref] wrote:
quoted
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
From: Rafael J. Wysocki <hidden> Date: 2006-12-15 22:20:22
On Friday, 15 December 2006 22:39, Andrew Morton wrote:
On Fri, 15 Dec 2006 13:05:52 -0800
Andrew Morton [off-list ref] wrote:
quoted
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
From: Jeff Garzik <hidden> Date: 2006-12-15 22:24:46
Rafael J. Wysocki wrote:
On Friday, 15 December 2006 22:39, Andrew Morton wrote:
quoted
On Fri, 15 Dec 2006 13:05:52 -0800
Andrew Morton [off-list ref] wrote:
quoted
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
From: Rafael J. Wysocki <hidden> Date: 2006-12-15 22:25:09
On Friday, 15 December 2006 23:19, Jeff Garzik wrote:
Alan wrote:
quoted
On Fri, 15 Dec 2006 13:39:27 -0800
Andrew Morton [off-list ref] wrote:
quoted
On Fri, 15 Dec 2006 13:05:52 -0800
Andrew Morton [off-list ref] wrote:
quoted
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
From: Rafael J. Wysocki <hidden> Date: 2006-12-15 23:35:57
On Friday, 15 December 2006 23:24, Jeff Garzik wrote:
Rafael J. Wysocki wrote:
quoted
On Friday, 15 December 2006 22:39, Andrew Morton wrote:
quoted
On Fri, 15 Dec 2006 13:05:52 -0800
Andrew Morton [off-list ref] wrote:
quoted
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
From: Jeff Garzik <redacted>
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 (jurriaan@middle) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #3 SMP Fri Dec 15 21:19:54 CET 2006
<snip>
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<sda1>
md: bind<sdb1>
md: bind<sdc1>
md: bind<sdd1>
md: bind<sde1>
md: bind<sdf1>
md: bind<sdg1>
md: bind<sdh1>
md: running: <sdh1><sdg1><sdf1><sde1><sdd1><sdc1><sdb1><sda1>
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<hda9>
md: bind<hdc9>
md: running: <hdc9><hda9>
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
<snip>
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
From: Rafael J. Wysocki <hidden> Date: 2006-12-16 09:54:28
On Saturday, 16 December 2006 00:38, Rafael J. Wysocki wrote:
On Friday, 15 December 2006 23:24, Jeff Garzik wrote:
quoted
Rafael J. Wysocki wrote:
quoted
On Friday, 15 December 2006 22:39, Andrew Morton wrote:
quoted
On Fri, 15 Dec 2006 13:05:52 -0800
Andrew Morton [off-list ref] wrote:
quoted
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
From: Rafael J. Wysocki <hidden> Date: 2006-12-16 11:13:45
On Saturday, 16 December 2006 10:56, Rafael J. Wysocki wrote:
On Saturday, 16 December 2006 00:38, Rafael J. Wysocki wrote:
quoted
On Friday, 15 December 2006 23:24, Jeff Garzik wrote:
quoted
Rafael J. Wysocki wrote:
quoted
On Friday, 15 December 2006 22:39, Andrew Morton wrote:
quoted
On Fri, 15 Dec 2006 13:05:52 -0800
Andrew Morton [off-list ref] wrote:
quoted
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
From: Rafael J. Wysocki <hidden> Date: 2006-12-17 10:57:55
On Saturday, 16 December 2006 12:16, Rafael J. Wysocki wrote:
On Saturday, 16 December 2006 10:56, Rafael J. Wysocki wrote:
quoted
On Saturday, 16 December 2006 00:38, Rafael J. Wysocki wrote:
quoted
On Friday, 15 December 2006 23:24, Jeff Garzik wrote:
quoted
Rafael J. Wysocki wrote:
quoted
On Friday, 15 December 2006 22:39, Andrew Morton wrote:
quoted
On Fri, 15 Dec 2006 13:05:52 -0800
Andrew Morton [off-list ref] wrote:
quoted
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
From: Andrew Morton <hidden> Date: 2006-12-17 11:06:17
On Sun, 17 Dec 2006 12:00:12 +0100
"Rafael J. Wysocki" [off-list ref] 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.
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.
From: Andrew Morton <redacted>
Date: Sun, Dec 17, 2006 at 03:05:39AM -0800
On Sun, 17 Dec 2006 12:00:12 +0100
"Rafael J. Wysocki" [off-list ref] wrote:
quoted
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
From: Andrew Morton <redacted>
Date: Sun, Dec 17, 2006 at 03:05:39AM -0800
quoted
On Sun, 17 Dec 2006 12:00:12 +0100
"Rafael J. Wysocki" [off-list ref] wrote:
quoted
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
From: Andrew Morton <hidden> Date: 2006-12-20 00:09:26
On Tue, 19 Dec 2006 15:26:00 -0800 (PST)
Luben Tuikov [off-list ref] 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.