|
From: | Avi Kivity |
Subject: | Re: [Qemu-devel] [PATCH 11/22] i8259: Update IRQ state after reset |
Date: | Tue, 04 Oct 2011 14:12:25 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 |
On 10/02/2011 10:36 PM, Blue Swirl wrote:
On Sun, Oct 2, 2011 at 8:31 PM, Avi Kivity<address@hidden> 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 ResetProblem: 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 (MSRIA32_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
[Prev in Thread] | Current Thread | [Next in Thread] |