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-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
sata badness in 2.6.20-rc1? [Was: Re: md patches in -mm]
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. NeilBrown - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-kernelm=116621656432500w=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-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-kernelm=116621656432500w=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-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-kernelm=116621656432500w=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-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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 = ( (128) | (117) );
- 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 },
- /* Mobile SATA
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-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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 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: bindsda1 md: bindsdb1 md: bindsdc1 md: bindsdd1 md: bindsde1 md: bindsdf1 md: bindsdg1 md: bindsdh1 md: running: sdh1sdg1sdf1sde1sdd1sdc1sdb1sda1 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: bindhda9 md: bindhdc9 md: running: hdc9hda9 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 - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
