Skip to contentSkip to conversation

2.4.21pre6 (__ide_dma_test_irq) called while not waiting

DISCUSSION Soeren Sonnenburg 3 participants 6 messages Apr 9, 2003 – Apr 11, 2003

lore
Share & tools
lore

Soeren Sonnenburg

author
#0 lore raw

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.

#1 lore raw

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

Quoted 38 lines · 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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

#2 lore raw
Quoted 2 lines · 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.

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

#3 lore raw
In reply to Soeren Sonnenburg
Quoted 6 lines · Soeren Sonnenburg

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

author
#4 lore raw
Quoted 6 lines · Alan Cox
Quoted 5 lines · Soeren Sonnenburg

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 }

Quoted 7 lines
Quoted 1 line

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.

author
#5 lore raw
In reply to Alan Cox
Quoted 6 lines · Alan Cox
Quoted 5 lines · Soeren Sonnenburg

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 }

Quoted 7 lines
Quoted 1 line

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.