I just did a git bisection from 2.6.30 to 2.6.31 because 2.6.31 will
not boot on this system. [email protected]'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
Uniform Multi-Platform E-IDE driver
sis5513 0000:00:02.5: SiS635 ATA 100 (2nd gen) controller
sis5513 0000:00:02.5: IDE controller (0x1039:0x5513 rev 0xd0)
sis5513 0000:00:02.5: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xff00-0xff07
ide1: BM-DMA at 0xff08-0xff0f
Probing IDE interface ide0...
Switched to high resolution mode on CPU 0
hda: ST3250823A, ATA DISK drive
hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
hda: UDMA/100 mode selected
Probing IDE interface ide1...
hdc: _NEC DVD_RW ND-2500A, ATAPI CD/DVD-ROM drive
hdc: host max PIO4 wanted PIO255(auto-tune) selected PIO4
hdc: UDMA/33 mode selected
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
ide_generic: please use "probe_mask=0x3f" module parameter for probing all legacy ISA IDE ports
ide-gd driver 1.18
hda: max request size: 512KiB
hda: 488397168 sectors (250059 MB) w/8192KiB Cache, CHS=30401/255/63
hda: cache flushes supported
hda: hda1 hda2 hda3
ide-cd driver 5.00
ide-cd: hdc: ATAPI 40X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache
Uniform CD-ROM driver Revision: 3.20
<hang>
commit 6029336426a2b43e4bc6f4a84be8789a047d139e
Author: Joao Ramos <[email protected]>
Date: Sun May 17 17:22:54 2009 +0200
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 <[email protected]>
Cc: Sergei Shtylyov <[email protected]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
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,6 +1032,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,
vendor_id : CentaurHauls
cpu family : 6
model : 7
model name : VIA Samuel 2
lspci
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 635 Host (rev 11)
00:01.0 PCI bridge: Silicon Integrated Systems [SiS] Virtual PCI-to-PCI bridge (AGP)
00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS85C503/5513 (LPC Bridge)
00:02.1 SMBus: Silicon Integrated Systems [SiS] SiS961/2 SMBus Controller
00:02.2 USB Controller: Silicon Integrated Systems [SiS] USB 1.1 Controller (rev 07)
00:02.3 USB Controller: Silicon Integrated Systems [SiS] USB 1.1 Controller (rev 07)
00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0)
00:02.6 Modem: Silicon Integrated Systems [SiS] AC'97 Modem Controller (rev a0)
00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] AC'97 Sound Controller (rev a0)
00:03.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet (rev 90)
00:09.0 Multimedia video controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder (rev 05)
00:09.2 Multimedia controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] (rev 05)
01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 315PRO PCI/AGP VGA Display Adapter
--
David Fries <[email protected]>
http://fries.net/~david/ (PGP encryption key available)
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 <[email protected]>
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 <[email protected]>
Cc: Sergei Shtylyov <[email protected]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
---
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 <[email protected]>
http://fries.net/~david/ (PGP encryption key available)
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. [email protected]'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..
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. [email protected]'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 <[email protected]>
http://fries.net/~david/ (PGP encryption key available)
From: David Fries <[email protected]>
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.
On Sun, Oct 04, 2009 at 08:58:48PM -0700, David Miller wrote:
> From: David Fries <[email protected]>
> 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 <[email protected]>
http://fries.net/~david/ (PGP encryption key available)