On Sun, Aug 18, 2013 at 4:05 AM, Michael Schmitz <[email protected]> wrote:
>>>> [ 301.880000] esp: esp0: Reconnect IRQ2 timeout
Beware that this message (incl. the number) is hardcoded in
drivers/scsi/esp_scsi.c:
if (i == ESP_RESELECT_TAG_LIMIT) {
printk(KERN_ERR PFX "esp%d: Reconnect IRQ2 timeout\n",
esp->host->unique_id);
return NULL;
}
The driver prints "IRQ1" or "IRQ2".
Fortunately, IRQ_AMIGA_PORTS is 2, but this is purely coincidentally...
>>> Are there interrupts logged for IRQ2 at all (cat /proc/interrupts)? It
>>> looks to me as though all DMA transfers fail (the first command to fail is
>>> READ_CAPACITY which would usually be issued right after IDENTIFY IIRC).
>>
>> root@amiga:/# cat /proc/interrupts
>> CPU0
>> 2: 1066320 auto CIAA, zorro8390, ide0, Amiga Zorro ESP
>> 6: 456970 auto CIAB
>> 8: 38239 amiga serial TX
>> 9: 0 amiga floppy_dma
>> 12: 315934 amiga fb vertb handler
>> 13: 315741 amiga serial status
>> 15: 0 amiga DMA sound
>> 19: 401 amiga serial RX
>> 23: 1 cia floppy_timer
>> 25: 0 cia amikbd
>> 27: 456971 cia timer
>> ERR: 0
>>
>> Seems like IRQ2 is very popular, so it's hard to say which device has
>> generated the interrupts...
>
>
> Yep - you'll be guaranteed to get a few IDE interrupts just by calling up
> cat - might be possible to get away without too much interrupts generated if
> it's all in the buffer cache - try whether the interrupt count changes after
> a few repetitions of that command.
>
> Might require more elaborate IRQ bookkeeping though.
I guess scsi_esp_intr() is called a lot, as it's a shared interrupt?
Can you add some debug prints there, to see if any of the conditions the
esp core checks are met?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
