qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: sparc32 fix spurious dma interrupts


From: Blue Swirl
Subject: [Qemu-devel] Re: sparc32 fix spurious dma interrupts
Date: Sat, 13 Feb 2010 09:52:52 +0200

On Sat, Feb 13, 2010 at 12:32 AM, Artyom Tarasenko
<address@hidden> wrote:
> 2010/2/12 Blue Swirl <address@hidden>:
>> On Thu, Feb 11, 2010 at 12:40 AM, Artyom Tarasenko
>> <address@hidden> wrote:
>>> Don't raise interrupt when not enabled.
>>> Don't set DMA_INTR bit spuriously.
>>> Don't print misleading debug messages "Raise IRQ" when not raising any.
>>
>> This breaks most of my Linux tests. *BSD are unaffected. For example
>> sparc-test 2.0:
>>
>> eth0: LANCE 52:54:00:12:34:56
>> esp0: IRQ 36 SCSI ID 7 Clk 40MHz CCYC=25000 CCF=8 TOut 167 NCR53C9XF(espfast)
>> ESP: Total of 1 ESP hosts found, 1 actually in use.
>> scsi0 : Sparc ESP100A-FAST
>> esp0: Aborting command
>> esp0: dumping state
>> esp0: dma -- cond_reg<a4400311> addr<f0010e64>
>> esp0: SW [sreg<11> sstep<04> ireg<18>]
>> esp0: HW reread [sreg<93> sstep<00> ireg<10>]
>> esp0: current command [tgt<02> lun<00> pphase<CLUELESS> cphase<DATAIN>]
>> esp0: disconnected
>> esp0: Aborting command
>> esp0: dumping state
>> esp0: dma -- cond_reg<a4400310> addr<f0010e64>
>> esp0: SW [sreg<11> sstep<04> ireg<18>]
>> esp0: HW reread [sreg<03> sstep<04> ireg<00>]
>> esp0: current command [tgt<02> lun<00> pphase<UNISSUED> cphase<UNISSUED>]
>> esp0: disconnected
>> esp0: Resetting scsi bus
>> esp0: SCSI bus reset interrupt
>> esp0: Aborting command
>> esp0: dumping state
>> esp0: dma -- cond_reg<a4400211> addr<f000d007>
>> esp0: SW [sreg<03> sstep<04> ireg<80>]
>> esp0: HW reread [sreg<91> sstep<04> ireg<18>]
>> esp0: current command [tgt<02> lun<00> pphase<UNISSUED> cphase<UNISSUED>]
>> esp0: disconnected
>> scsi: Device offlined - not ready after error recovery: host 0 channel
>> 0 id 2 lun 0
>>
>> Since Open/NetBSD still works, there may be yet again another bug that
>> your patch uncovers.
>
> Looks like Linux has problems with the fist part of the patch: not
> raising irqs when they are not enabled.
> The part is actually not relevant for Solaris, so we could just skip
> it. But it would be nicer to find this another bug.
> It seems that there is some asymmetry: Solaris complained about
> spurious interrupts only on write operations.
> Do you have an idea why setting the DMA_INTR bit and raising the irq
> was split between multiple functions?

I'd suspect my sloppiness. ;-)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]