On 02/20/2015 03:24 AM, Radim Krčmář wrote: > Window 8.0 driver has a particular behavior for a small time frame after > it enables rx interrupts: the interrupt handler never clears > E1000_ICR_RXT0. The handler does this something like this: > set_imc(-1) (1) disable all interrupts > val = read_icr() (2) clear ICR > handled = magic(val) (3) do nothing to E1000_ICR_RXT0 > set_ics(val & ~handled) (4) set unhandled interrupts back to ICR > set_ims(157) (5) enable some interrupts > > so if we started with RXT0, then every time the handler re-enables e1000 > interrupts, it receives one. This likely wouldn't matter in real > hardware, because it is slow enough to make some progress between > interrupts, but KVM instantly interrupts it, and boot hangs. > (If we have multiple VCPUs, the interrupt gets load-balanced and > everything is fine.) > > I haven't found any problem in earlier phase of initialization and > windows writes 0 to RADV and RDTR, so some workaround looks like the > only way if we want to support win8.0 on uniprocessors. (I vote NO.) > > This workaround uses the fact that a constant is cleared from ICR and > later set back to it. After detecting this situation, we reuse the > mitigation framework to inject an interrupt 10 microseconds later. > (It's not exactly 10 microseconds, to keep the existing logic intact.) > > The detection is done by checking at (1), (2), and (5). (2) and (5) > require that the only bit in ICR is RXT0. We could also check at (4), > and on writes to any other register, but it would most likely only add > more useless code, because normal operations shouldn't behave like that > anyway. (An OS that deliberately keeps bits in ICR to notify itself > that there are more packets, or for more creative reasons, is nothing we > should care about.) > > Signed-off-by: Radim Krčmář <rkrc...@redhat.com> > --- > The patch is still untested -- it only approximates the behavior of RHEL > patches that worked, I'll try to get a reproducer ... > >
Hi: Two questions: - Does Win8 still support 82540EM. According to https://downloadcenter.intel.com/download/23071/Network-Adapter-Driver-for-Windows-8-1- , it was not in the supported list. As a reference, 82540EM was in the list of win2008: https://downloadcenter.intel.com/download/18720/Network-Adapter-Driver-for-Windows-Server-2008-Final-Release. If it was not supported officially, there's probably no need to workaround a buggy driver in guest. - The issue looks similar to the one that has been addressed by kernel commit 184564efae4d775225c8fe3b762a56956fb1f827. Is this still reproducible with this commit? Thanks
