RE: [patch]: ide dma timeout retry in pio

RE: [patch]: ide dma timeout retry in pio

[Diefenbaugh, Paul S]

Chris/All:

I think your assumptions are correct.  I'm guessing that IDE DMA activity is
not being properly handled when the CPU is in C3, resulting in memory (and
therefore file system) corruption.  We haven't seen corruption on our
development systems, but this is probably due to the fact that we don't
explicitly enable IDE DMA transfers (?).

I'm concerned that the CPU is being put into C3 during what appears to be
times of high bus mastering activity.  The default policy (prpolicy.c) is
configured to only use C3 when bus mastering (BM_STS) is silent for 4 or
more 'quantums'.  You can see if this is working by causing disk activity
while cat'ing the file '/proc/acpi/processor/0/status': the C3 counter
should not be incrementing (or not by much, anyway).

The C3 handler should block bus master activity while the CPU is in C3.  DMA
activity (writes) during C3 would result in cache-incoherency (since the CPU
is not snooping) and thus memory corruption.  The idea is to block bus
mastering activity while in C3 (ARB_DIS), but allow the CPU to wakeup
whenever bus mastering is requested (BM_RLD).  I'm betting that DMA is
happening during C3 resulting in fs corruption.

To verify if C3 is really the culprit we should try disabling its use on a
vulnerable system.  I'd recommend mapping the C3 handler to use C2 instead,
which could be done by modifying the switch statement in pr_power_idle()
within prpower.c (see below).  Note that we'll still be setting BM_RLD for
C3's during pr_power_activate_state(), but this shouldn't be an issue.

	case PR_C2:
	case PR_C3:
		/* Interrupts must be disabled during C2 transitions */
		disable();
		/* See how long we're asleep for */
		acpi_get_timer(&start_ticks);
		/* Invoke C2 */
		acpi_os_in8(processor->power.p_lvl2);
		/* Dummy op - must do something useless after P_LVL2 read */
		acpi_hw_register_bit_access(ACPI_READ, ACPI_MTX_DO_NOT_LOCK,

			BM_STS);
		/* Compute time elapsed */
		acpi_get_timer(&end_ticks);
		/* Re-enable interrupts */
		enable();
		break;
	
	<remove previous 'case PR_C3'>

Could somebody give this a try and let me know?

Thanks,

-- Paul Diefenbaugh
   Intel Corporation


-----Original Message-----
From: Christopher B. Liebman [mailto:liebman@sponsera.com]
Sent: Monday, May 28, 2001 1:13 PM
To: Jens Axboe; Mark Hahn
Cc: Acpi@Phobos. Fachschaften. Tu-Muenchen. De;
linux-kernel@vger.kernel.org; alan@lxorguk.ukuu.org.uk;
andre@linux-ide.org
Subject: RE: [patch]: ide dma timeout retry in pio


I think that this may be an issue with ACPI processor power saving...  I
have documented issues with ide DMA timeouts when the processor is put into
the C3 power state.  One of the things that happens in this state is that
buss master arbitration is *disabled*.....  bus master activity is
*supposed* to transition the system back to a C0 power state.  I'll bet
there are some issues with the Linux IDE dma and disabling bus master
arbitration......  ideas?  thoughts?  patches? ;-)

	-- Chris

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org
> [mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Mark Hahn
>
> I seem to recall Andre saying that the problem arises when the
> ide DMA engine looses PCI arbitration during a burst.  shorter
> bursts would seem like the best workaround if this is the problem...
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [Acpi] RE: [patch]: ide dma timeout retry in pio

[Christopher B. Liebman]

> -----Original Message-----
> From: acpi-admin@phobos.fachschaften.tu-muenchen.de
> [mailto:acpi-admin@phobos.fachschaften.tu-muenchen.de]On Behalf Of
> Diefenbaugh, Paul S
>
> Chris/All:
>
> I think your assumptions are correct.  I'm guessing that IDE DMA
> activity is
> not being properly handled when the CPU is in C3, resulting in memory (and
> therefore file system) corruption.  We haven't seen corruption on our
> development systems, but this is probably due to the fact that we don't
> explicitly enable IDE DMA transfers (?).
>
> I'm concerned that the CPU is being put into C3 during what appears to be
> times of high bus mastering activity.  The default policy (prpolicy.c) is
> configured to only use C3 when bus mastering (BM_STS) is silent for 4 or
> more 'quantums'.  You can see if this is working by causing disk activity
> while cat'ing the file '/proc/acpi/processor/0/status': the C3 counter
> should not be incrementing (or not by much, anyway).

Hmmmm  I'll have to look at this a bit more....  but you can also keep from
C3 *and* C2 states by not having an idle CPU.  For instance
"./setiathome -verbose -nice 19" Prevents the C3 state quite nicely! :-)

>
> The C3 handler should block bus master activity while the CPU is
> in C3.  DMA
> activity (writes) during C3 would result in cache-incoherency
> (since the CPU
> is not snooping) and thus memory corruption.  The idea is to block bus
> mastering activity while in C3 (ARB_DIS), but allow the CPU to wakeup
> whenever bus mastering is requested (BM_RLD).  I'm betting that DMA is
> happening during C3 resulting in fs corruption.

*or* that the bus master request wakes up the cpu but for some reason the
requestor is not granted the bus?  So that you end up with DMA timeouts and
the FS gets corrupt because no data is getting written?

>
> To verify if C3 is really the culprit we should try disabling its use on a
> vulnerable system.  I'd recommend mapping the C3 handler to use
> C2 instead,
> which could be done by modifying the switch statement in pr_power_idle()
> within prpower.c (see below).  Note that we'll still be setting BM_RLD for
> C3's during pr_power_activate_state(), but this shouldn't be an issue.
>
[example code snipped]
>
> Could somebody give this a try and let me know?
>

I've already done something very similar to this.  I set
"processor->power.state[PR_C3].is_valid" to false near the end of
pr_power_set_default_policy().  And did not have any hang/corruption
problems. The test I was using was three "find / >/dev/null" instances
running 10-15 seconds apart.  Without C3 disabled it would hang/crash within
the first few minutes.  With this disabled it ran fine all the way thru.
Would it help if I tried this as you suggested and still calling
pr_power_activate_state()?

	-- Chris