2.6.31 regression sis5513 PIO Mode 0 hang
in [Kernel]
|
From: David Fries on 3 Oct 2009 09:10 On Fri, Oct 02, 2009 at 10:30:56PM -0700, - wrote: > Thank you for finding the problem. The kernel is way too complex > for someone who's not familiar with it (like me) to track these > things down. If you do a reverse apply on the patch, does it work for you? The below is already reversed, so apply it normally, or just open the file with an editor and comment out those lines. From 6029336426a2b43e4bc6f4a84be8789a047d139e Mon Sep 17 00:00:00 2001 From: Joao Ramos <joao.ramos(a)inov.pt> Date: Sun, 17 May 2009 17:22:54 +0200 Subject: [PATCH] ide: try to use PIO Mode 0 during probe if possible Initially set PIO Mode 0 for all host drivers that have a 'set_pio_mode' method before the IDE core figures out the most suited PIO mode for the attached device. Signed-off-by: Joao Ramos <joao.ramos(a)inov.pt> Cc: Sergei Shtylyov <sshtylyov(a)ru.montavista.com> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier(a)gmail.com> --- drivers/ide/ide-probe.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/drivers/ide/ide-probe.c b/drivers/ide/ide-probe.c index 7f264ed..b609a58 100644 --- a/drivers/ide/ide-probe.c +++ b/drivers/ide/ide-probe.c @@ -1032,15 +1032,6 @@ 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, -- 1.5.6.5 -- David Fries <david(a)fries.net> http://fries.net/~david/ (PGP encryption key available) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Robert Hancock on 3 Oct 2009 21:10 On 10/02/2009 08:54 PM, David Fries wrote: > I just did a git bisection from 2.6.30 to 2.6.31 because 2.6.31 will > not boot on this system. d.stussy(a)yahoo.com's post September 12th > looks the same, different CPU but both have sis5513 IDE chips. His > would normally init the ethernet chip next, mine would do PS/2 next, > both hang right after the Uniform CD-ROM message. > > This was bisected down to chaging PIO mode 0 for probing. What > problem was that patch trying to solve? Reverting just that patch at > the top of 2.6.31 tree works. I can test patches. > > Assigned bugzilla.kernel.org bug 14310 Well, it's the right thing to do (libata does it) but presumably doing that in old IDE is triggering some kind of bug. Unless there's a specific problem it was solving, or someone is interested in debugging in detail (I'm certainly not interested in drivers/ide) it should likely be reverted as we've done without it for so long.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David Fries on 4 Oct 2009 23:10 On Sat, Oct 03, 2009 at 06:57:42PM -0600, Robert Hancock wrote: > On 10/02/2009 08:54 PM, David Fries wrote: >> I just did a git bisection from 2.6.30 to 2.6.31 because 2.6.31 will >> not boot on this system. d.stussy(a)yahoo.com's post September 12th >> looks the same, different CPU but both have sis5513 IDE chips. His >> would normally init the ethernet chip next, mine would do PS/2 next, >> both hang right after the Uniform CD-ROM message. >> >> This was bisected down to chaging PIO mode 0 for probing. What >> problem was that patch trying to solve? Reverting just that patch at >> the top of 2.6.31 tree works. I can test patches. >> >> Assigned bugzilla.kernel.org bug 14310 > > Well, it's the right thing to do (libata does it) but presumably doing > that in old IDE is triggering some kind of bug. Unless there's a > specific problem it was solving, or someone is interested in debugging > in detail (I'm certainly not interested in drivers/ide) it should likely > be reverted as we've done without it for so long.. First, if I'm going to do much debugging, how would I force the ethernet device to come up first so I have netconsole? How is the problem patch, + ide_port_for_each_dev(i, drive, hwif) { + if (port_ops && port_ops->set_pio_mode) + port_ops->set_pio_mode(drive, 0); + } Different from using hdparm to set the mode? I do this, hdparm -p 0 /dev/hda hdparm -X pio0 /dev/hda and the benchmarks give me about what I would expect 7MB/s instead of the normal 40MB/s. Then I can re-enable with, hdparm -p 4 /dev/hda hdparm -X udma5 /dev/hda hdparm -d 1 /dev/hda hda: UDMA/100 mode selected and the drive is back up to speed, and obviously the kernel didn't freeze. Should there be anything different between what the patch tried, and and hdparm's doing, other than kernel initiated and start and a user program later on? -- David Fries <david(a)fries.net> http://fries.net/~david/ (PGP encryption key available) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David Miller on 5 Oct 2009 00:10 From: David Fries <david(a)fries.net> Date: Sun, 4 Oct 2009 21:55:50 -0500 > First, if I'm going to do much debugging, how would I force the > ethernet device to come up first so I have netconsole? > > How is the problem patch, > + ide_port_for_each_dev(i, drive, hwif) { > + if (port_ops && port_ops->set_pio_mode) > + port_ops->set_pio_mode(drive, 0); > + } > > Different from using hdparm to set the mode? I do this, > hdparm -p 0 /dev/hda > hdparm -X pio0 /dev/hda > and the benchmarks give me about what I would expect 7MB/s instead of > the normal 40MB/s. > > Then I can re-enable with, > hdparm -p 4 /dev/hda > hdparm -X udma5 /dev/hda > hdparm -d 1 /dev/hda > hda: UDMA/100 mode selected > and the drive is back up to speed, and obviously the kernel didn't > freeze. Should there be anything different between what the patch > tried, and and hdparm's doing, other than kernel initiated and start > and a user program later on? From your original hang trace I can only guess that the problematic sequence is putting your CDROM into PIO0, then putting it into PIO4, and then immediately reading the TOC. This is what the ide-cd.c code does right about where you get the hang. Debugging this further is really totally pointless for a subsystem that should be in deep maintainence mode, so I'm just going to revert. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David Fries on 6 Oct 2009 00:20 On Sun, Oct 04, 2009 at 08:58:48PM -0700, David Miller wrote: > From: David Fries <david(a)fries.net> > Date: Sun, 4 Oct 2009 21:55:50 -0500 > > > First, if I'm going to do much debugging, how would I force the > > ethernet device to come up first so I have netconsole? > > > > How is the problem patch, > > + ide_port_for_each_dev(i, drive, hwif) { > > + if (port_ops && port_ops->set_pio_mode) > > + port_ops->set_pio_mode(drive, 0); > > + } > > > > Different from using hdparm to set the mode? I do this, > > hdparm -p 0 /dev/hda > > hdparm -X pio0 /dev/hda > > and the benchmarks give me about what I would expect 7MB/s instead of > > the normal 40MB/s. > > > > Then I can re-enable with, > > hdparm -p 4 /dev/hda > > hdparm -X udma5 /dev/hda > > hdparm -d 1 /dev/hda > > hda: UDMA/100 mode selected > > and the drive is back up to speed, and obviously the kernel didn't > > freeze. Should there be anything different between what the patch > > tried, and and hdparm's doing, other than kernel initiated and start > > and a user program later on? > > >From your original hang trace I can only guess that the problematic > sequence is putting your CDROM into PIO0, then putting it into > PIO4, and then immediately reading the TOC. You are correct, it is in ide_cd_read_toc, down in the ide_transfer_pc and output_data calls, but it isn't time dependent. I put a five second sleep at the start of ide_cd_read_toc, so I don't think it is a race condition. > This is what the ide-cd.c code does right about where you get the > hang. > > Debugging this further is really totally pointless for a subsystem > that should be in deep maintainence mode, so I'm just going to > revert. Works for me, thanks. > Thanks. Uniform CD-ROM driver Revision: 3.20 ide_cd_read_toc: enter cdrom_check_status: enter ide_cd_queue_pc ide_cd_do_request ide_cd_do_request: dev hdc: type=a, flags=108a440 sector 18446744073709551615, nr/cnr 0/0 cdrom_do_block_pc: rq->cmd[0]: 0x0, rq->cmd_type: 0xa cdrom_do_block_pc: leave calling ide_prep_sense ide_prep_sense returned calling ide_issue_pc calling ide_dma_prepare if 0 ide_dma_prepare returned calling ide_init_packet_cmd ide_init_packet_cmd returned calling do_rw_taskfile do_rw_taskfile returned calling ide_execute_command ide_execute_command returned calling ide_transfer_pc calling hwif->tp_ops->output_data -- David Fries <david(a)fries.net> http://fries.net/~david/ (PGP encryption key available) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|
Pages: 1 Prev: Added PR_SET_PROCTITLE_AREA option for prctl() Next: NFS: introduce writeback wait queue |