Message ID | 200910070027.45678.bzolnier@gmail.com |
---|---|
State | Accepted |
Delegated to: | David Miller |
Headers | show |
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Date: Wed, 7 Oct 2009 00:27:45 +0200 > The root cause of reported system hangs was (now fixed) sis5513 bug > and not "ide: try to use PIO Mode 0 during probe if possible" change > (commit 6029336426a2b43e4bc6f4a84be8789a047d139e) so the revert was > incorrect (it simply replaced one regression with the other one). What is this older "regression" fixed by the PIO-0 change? You're not explaining it and neither does the commit message for the PIO-0 change. Please, fill us in :-) -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 07 October 2009 00:41:20 David Miller wrote: > From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> > Date: Wed, 7 Oct 2009 00:27:45 +0200 > > > The root cause of reported system hangs was (now fixed) sis5513 bug > > and not "ide: try to use PIO Mode 0 during probe if possible" change > > (commit 6029336426a2b43e4bc6f4a84be8789a047d139e) so the revert was > > incorrect (it simply replaced one regression with the other one). > > What is this older "regression" fixed by the PIO-0 change? > > You're not explaining it and neither does the commit message for the > PIO-0 change. It does: | Subject: [PATCH] sis5513: fix PIO setup for ATAPI devices | | Clear prefetch setting before potentially (re-)enabling it in | config_drive_art_rwp() so the transition of the device type on | the port from ATA to ATAPI (i.e. during warm-plug operation) | is handled correctly. and the empty port defaults to ATA-like behavior for the initial PIO setup. > Please, fill us in :-) Just connect the dots.. :) -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Date: Wed, 7 Oct 2009 00:52:37 +0200 > On Wednesday 07 October 2009 00:41:20 David Miller wrote: >> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> >> Date: Wed, 7 Oct 2009 00:27:45 +0200 >> >> > The root cause of reported system hangs was (now fixed) sis5513 bug >> > and not "ide: try to use PIO Mode 0 during probe if possible" change >> > (commit 6029336426a2b43e4bc6f4a84be8789a047d139e) so the revert was >> > incorrect (it simply replaced one regression with the other one). >> >> What is this older "regression" fixed by the PIO-0 change? >> >> You're not explaining it and neither does the commit message for the >> PIO-0 change. > > It does: > > | Subject: [PATCH] sis5513: fix PIO setup for ATAPI devices Sorry, I wasn't clear. I'm talking about commit 6029336426a2b43e4bc6f4a84be8789a047d139e, it doesn't say why we want to try PIO 0 mode during probe. What was the regression fixed by that change? -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 07 October 2009 00:57:05 David Miller wrote: > From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> > Date: Wed, 7 Oct 2009 00:52:37 +0200 > > > On Wednesday 07 October 2009 00:41:20 David Miller wrote: > >> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> > >> Date: Wed, 7 Oct 2009 00:27:45 +0200 > >> > >> > The root cause of reported system hangs was (now fixed) sis5513 bug > >> > and not "ide: try to use PIO Mode 0 during probe if possible" change > >> > (commit 6029336426a2b43e4bc6f4a84be8789a047d139e) so the revert was > >> > incorrect (it simply replaced one regression with the other one). > >> > >> What is this older "regression" fixed by the PIO-0 change? > >> > >> You're not explaining it and neither does the commit message for the > >> PIO-0 change. > > > > It does: > > > > | Subject: [PATCH] sis5513: fix PIO setup for ATAPI devices > > Sorry, I wasn't clear. > > I'm talking about commit 6029336426a2b43e4bc6f4a84be8789a047d139e, it > doesn't say why we want to try PIO 0 mode during probe. For the same reason that libata wants it. Many embedded controllers/platforms will have junk PIO timings set initially. Now that your manager's ambition is satisfied could you please go help some other subsystem for the moment so we can fix ide in the meantime? :) -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Date: Wed, 7 Oct 2009 01:13:05 +0200 > Many embedded controllers/platforms will have junk PIO timings set initially. Thanks, that helps a lot. When David reports back on testing I'll push this stuff around and queue up patch #1 for -stable. -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/ide/ide-probe.c b/drivers/ide/ide-probe.c index 4d76ba4..63c53d6 100644 --- a/drivers/ide/ide-probe.c +++ b/drivers/ide/ide-probe.c @@ -1046,6 +1046,15 @@ static void ide_port_init_devices(ide_hwif_t *hwif) if (port_ops && port_ops->init_dev) port_ops->init_dev(drive); } + + ide_port_for_each_dev(i, drive, hwif) { + /* + * default to PIO Mode 0 before we figure out + * the most suited mode for the attached device + */ + if (port_ops && port_ops->set_pio_mode) + port_ops->set_pio_mode(drive, 0); + } } static void ide_init_port(ide_hwif_t *hwif, unsigned int port,