Hmm. I don't think we have spurious IRQs 9. Isn't it possible, that the
AM53C974 chip transfers data on the PCI bus (Busmastering) while the PCnet32
chip tries to do the same but looses. What happens to your network data? Are
the packets OK? Just a little bit slower? Or is network almost stalled when
doing heavy disk IO?
BTW: Did you enable Disconnection, Synchronous transfers and TagQueueing?
(Don't know, if this will save PCI bus allocation time.)
> 3) DC390 (irq 10) + 3C900 (irq 10)
> Dead locks.
>
> the messages ares:
> scsi: aborting command due to timeout: pid 3939,
> scsi 0, chanel 0, id 0, lun 0 0x00 10 28 24 02 00
> SCSI disk error: kost 0 chanel 0 id 0 lun 0 return code = 26030000
>
> and:
> eth0: transmit timed out, tx_status 00 status c601
> eth0: Interrupt posted but not handled -- IRQ blocked by another
> device ?
> Flags; bus_master 1, full 0; dirty 149 current 149.
> Transmit list 00000000 vs. c009aa60.
> 0: 0c009aa10 length 8000002a status 0000002a
> ...
> 15: ...
I don't like this ....
The tmscsim driver is able to share IRQs. If I understand correctly what a
driver has to do to support shared IRQs, then it should be working. The
driver checks, if the IRQ is coming from its device and if not it just
returns. This should be OK, shoulnd't it?
The dc390-1.20g driver will do a printk on each IRQ not caused by the
am53c974 chip. This might cause problems. I changed this in 1.20i.
(Please, don't try 1.20h: As soon as your turn on TagQueuing, you will loose
data due to a stupid bug.)
ftp://student.physik.uni-dortmund.de/pub/linux/kernel/dc390/
> 4) AM53C974 (irq 10) + 3C900 (irq 10)
> Dead locks.
>
> In order to run that way, i have to patch irq.c in order to
> enable irq sharing because the AM53C974 does not defaultly
> allow irq sharing.
Add | SA_SHIRQ to the request_irq() call in the am53c974 driver.
At least, my driver is not the only one to fail. ;-(
>
> >From the many tests i made during this long way to a stable
> 2.1.x kernel, i concluded that what makes my SMP box harder to
> get reliable that many other ones is:
>
> 1) It is old and so the bios does not provide very accurate informations
> (this seams to have been finaly solved by Ingo patches)
>
> 2) It is slow, so it is more likely to get overloaded.
> About this point, i would suggest to Ingo and Linus to slow down their
> processors if they can.
It should be working regardlessly of the CPU speed. (OK, if the CPU is too
slow to serve the timer interrupt, it's not possible to work.)
-- Kurt Garloff, Dortmund <K.Garloff@ping.de> PGP key on http://student.physik.uni-dortmund.de/homepages/garloff- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu