2.4.21pre6 (__ide_dma_test_irq) called while not waiting

2.4.21pre6 (__ide_dma_test_irq) called while not waiting

[Soeren Sonnenburg]

I have a hpt370 based controller which shares an irq with a broadcom
bcm4401 network adaptor.

when transferring stuff over the network the ide controller drops the
dma for all disks on the controller repeatedly... so it is not a
cable/disk problem but a problem in the nic's driver/the hpt driver.

however this stuff only happens when I put high load on the nic. the
drives form a software raid and reconstructing it does not cause any
trouble...

here is my setup:
7:   28328328          XT-PIC  ide4, ide5, eth0


hdi: 4 bytes in FIFO
hdi: timeout waiting for DMA
hdi: (__ide_dma_test_irq) called while not waiting
hdi: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest }

hdk: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest }

hdk: status timeout: status=0xd0 { Busy }

hdk: DMA disabled
hdk: drive not ready for command
ide4: reset: success
ide5: reset: success

Thanks,
Soeren.

Re: 2.4.21pre6 (__ide_dma_test_irq) called while not waiting

[Andre Hedrick]

Does the broadcom driver have a test for who owns the intq?
If it is eating the hpt370's interrupt, well you already see the picture.

Andre Hedrick
LAD Storage Consulting Group

On 9 Apr 2003, Soeren Sonnenburg wrote:

> I have a hpt370 based controller which shares an irq with a broadcom
> bcm4401 network adaptor.
> 
> when transferring stuff over the network the ide controller drops the
> dma for all disks on the controller repeatedly... so it is not a
> cable/disk problem but a problem in the nic's driver/the hpt driver.
> 
> however this stuff only happens when I put high load on the nic. the
> drives form a software raid and reconstructing it does not cause any
> trouble...
> 
> here is my setup:
> 7:   28328328          XT-PIC  ide4, ide5, eth0
> 
> 
> hdi: 4 bytes in FIFO
> hdi: timeout waiting for DMA
> hdi: (__ide_dma_test_irq) called while not waiting
> hdi: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest }
> 
> hdk: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest }
> 
> hdk: status timeout: status=0xd0 { Busy }
> 
> hdk: DMA disabled
> hdk: drive not ready for command
> ide4: reset: success
> ide5: reset: success
> 
> Thanks,
> Soeren.
> 
> -
> 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: 2.4.21pre6 (__ide_dma_test_irq) called while not waiting

[Alan Cox]

On Mer, 2003-04-09 at 10:29, Andre Hedrick wrote:
> Does the broadcom driver have a test for who owns the intq?
> If it is eating the hpt370's interrupt, well you already see the picture.

IRQ's always go to both drivers, so that cannot be happening

Re: 2.4.21pre6 (__ide_dma_test_irq) called while not waiting

[Alan Cox]

On Mer, 2003-04-09 at 10:18, Soeren Sonnenburg wrote:
> hdi: 4 bytes in FIFO
> hdi: timeout waiting for DMA
> hdi: (__ide_dma_test_irq) called while not waiting
> hdi: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest }
> 
> hdk: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest }

This looks like a shared IRQ occurred while a command was being
sent. The IDE layer apparently tested for the IRQ before it 
was ready to do so as part of finding out what is going on. The
-ac tree (and pre7) may possibly have fixed it with the command
delay stuff that Ross Biro figured out

Re: 2.4.21pre6 (__ide_dma_test_irq) called while not waiting

[Soeren Sonnenburg]

On Wed, 2003-04-09 at 12:47, Alan Cox wrote:
> On Mer, 2003-04-09 at 10:18, Soeren Sonnenburg wrote:
> > hdi: 4 bytes in FIFO
> > hdi: timeout waiting for DMA
> > hdi: (__ide_dma_test_irq) called while not waiting
> > hdi: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest }
> > 
> > hdk: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest }
> 
> This looks like a shared IRQ occurred while a command was being
> sent. The IDE layer apparently tested for the IRQ before it 
> was ready to do so as part of finding out what is going on. The
> -ac tree (and pre7) may possibly have fixed it with the command
> delay stuff that Ross Biro figured out

ok, so I will upgrade to pre7 ASAP and let you know about the result.

thanks.

Soeren.

Re: 2.4.21pre6 (__ide_dma_test_irq) called while not waiting

[Chuck Ebbert]

ANdre Hedrick wrote:

>Does the broadcom driver have a test for who owns the intq?
>If it is eating the hpt370's interrupt, well you already see the picture.


 Using edge-triggered interrupts with sharing is a bad idea, no?


--
 Chuck
 I am not a number!

Re: 2.4.21pre6 (__ide_dma_test_irq) called while not waiting

[Alan Cox]

On Mer, 2003-04-09 at 13:13, Chuck Ebbert wrote:
> ANdre Hedrick wrote:
> 
> >Does the broadcom driver have a test for who owns the intq?
> >If it is eating the hpt370's interrupt, well you already see the picture.
> 
> 
>  Using edge-triggered interrupts with sharing is a bad idea, no?

PCI IRQ lines are level triggered

Re: 2.4.21pre6 (__ide_dma_test_irq) called while not waiting

[Alan Cox]

On Mer, 2003-04-09 at 15:35, Chuck Ebbert wrote:
>  Even when /proc/interrupts says XT-PIC?  I have uniprocessor
> MPS 1.4 machines and build IO-APIC kernels for them because
> I thought it was safer to share interrupts that way.  The
> four extra IRQ lines help, too. :)

IDE is a bit more complex than basic stuff but

PCI lines to the PIC are level triggered
Legacy IRQ for host IDE controllers may be edge triggered but
if so won't be shared

Re: 2.4.21pre6 (__ide_dma_test_irq) called while not waiting

[Chuck Ebbert]

Alan Cox wrote:


> >  Using edge-triggered interrupts with sharing is a bad idea, no?
>
> PCI IRQ lines are level triggered


 Even when /proc/interrupts says XT-PIC?  I have uniprocessor
MPS 1.4 machines and build IO-APIC kernels for them because
I thought it was safer to share interrupts that way.  The
four extra IRQ lines help, too. :)

--
 Chuck

Re: 2.4.21pre6 (__ide_dma_test_irq) called while not waiting

[Soeren Sonnenburg]

On Wed, 2003-04-09 at 12:47, Alan Cox wrote:
> On Mer, 2003-04-09 at 10:18, Soeren Sonnenburg wrote:
> > hdi: 4 bytes in FIFO
> > hdi: timeout waiting for DMA
> > hdi: (__ide_dma_test_irq) called while not waiting
> > hdi: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest }
> > 
> > hdk: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest }
> 
> This looks like a shared IRQ occurred while a command was being
> sent. The IDE layer apparently tested for the IRQ before it 
> was ready to do so as part of finding out what is going on. The
> -ac tree (and pre7) may possibly have fixed it with the command
> delay stuff that Ross Biro figured out

Ok, I copied 2*25GB over the network trying all sorts of things to make
the compu crash. I was not successful :-)

However a hdparm -S0 -d1 -Xudma5 -c 1 -u 1 -m 16 /dev/hde was enough to
get that message again which I could not simple reproduce by just
copying things over the network. So it seems the actual bug was fixed in
pre7 but hdparm tweaking seems to need another fix to be safe...

Thanks,
Soeren.