Date: Tue, 11 Dec 2001 01:12:43 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Danny Braniss <danny@cs.huji.ac.il> Cc: Bernd Walter <ticso@cicely8.cicely.de>, Mike Smith <msmith@FreeBSD.ORG>, freebsd-hackers@FreeBSD.ORG Subject: Re: irq Message-ID: <3C15CE0B.FA53281B@mindspring.com> References: <E16DiiV-000AEf-00@pampa.cs.huji.ac.il>
next in thread | previous in thread | raw e-mail | index | archive | help
Danny Braniss wrote: > well, if it's not software it must be hardware problem (true or false ?) > the test: > video capture (using a modified meteor driver) > doing full size 24bit colour, the meteor would complain about FIFO errors > (which probably mean that the dma did not finish in time - correct?) > and sometimes, the adaptec would also complain. > > so i moved cards around. > > 1st try: disaster, the adaptec realy complained, had to reboot. > 2nd try: Success, fifo errors are down to less than .1% (before it > used to be 90%). It looks like IRQ sharing is the only issue here. I don't see this as a hardware problem, unless tou are complaining about the Meteor design (which I'd probably agree with). Sharing of IRQs is supposed to be possible, but if you have incredible bus on times and incredible "I caused this interrupt" register access latency, and are stacking captures into writes ont disk serviced at the same interrupt, well, then, you should expect problems. But I would still blame software (in particular, the firmware on your Meteor). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C15CE0B.FA53281B>