On 10/02/2011 10:36 PM, Blue Swirl wrote:
On Sun, Oct 2, 2011 at 8:31 PM, Avi Kivity<a...@redhat.com> wrote:
>
>> >
>> > In fact these aren't problems. The packet may be sent or data
>> > written, as long as they aren't corrupted. A device is allowed to
>> > "delay" a reset (but not indefinitely).
>>
>> Oh, but corruption could easily happen. Consider for example a disk
>> controller waiting for DMA ready signal a device separate from the
>> DMA
>> controller. Due to reset glitches in the device or signal chain, the
>> DMA ready signal arrives but the DMA controller still contains old
>> information, writing the data to disk from wrong memory location.
>
>
> Would not this corruption also happen on real hardware? If reset to the
disk controller is delayed by a slow gate or extra capacitance on a line?
Maybe, but the delays are probably too short on real HW before any
packets are sent or disk gets written. On QEMU, I/O can be
instantaneous.
As an anecdote, while reading a chip errata I came upon this:
15. CPU May Record Signal Glitches When MCH is Being Reset
Problem: When the MCH is reset via RSTIN# the CPU may record any one or
more of the
following errors: address strobe glitch (MSR IA32_MCi_STATUS bit 23),
data strobe
glitch (MSR IA32_MCi_STATUS bit 22), P/N data strobes out of sync (MSR
IA32_MCi_STATUS bit 21), PIC & FSB data parity (MSR IA32_MCi_STATUS bit
19), RSP
parity (MSR IA32_MCi_STATUS bit 18), or FSB address parity (MSR
IA32_MCi_STATUS
bit 16). This can happen when the MCH asserts CPURST# just after the
MCH drives an
FSB transaction. This may happen because RSTIN# and CPURST# maintain an
asynchronous relationship with each other.
Workaround: None.
Status: No Fix
(of course the situation there is different, there is no global reset
signal)
--
error compiling committee.c: too many arguments to function
