Date: Thu, 22 Nov 2001 17:35:07 +0100 From: Stephan Mantler <step@acm.org> To: freebsd-hackers@freebsd.org Subject: Re: meteor driver problems Message-ID: <20011122173507.B32065@step.cg.tuwien.ac.at> In-Reply-To: <200111221505.fAMF5I796001@web.cs.ndsu.nodak.edu>; from tinguely@web.cs.ndsu.nodak.edu on Thu, Nov 22, 2001 at 09:05:18AM -0600 References: <20011122115948.A25406@step.cg.tuwien.ac.at> <200111221505.fAMF5I796001@web.cs.ndsu.nodak.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> the original meteor card's PCI chipset had a known and uncorrectable > hardware incompatibility with PCI 2.0 chipsets that caused lockup. > [...] oh. I'm guessing that it is the Meteor card that locks up; this does make sense. I've realized that since tsleep is called with METPRI (which does include PCATCH) it's fairly obvious that any signal (that's not ignored) will break the process out of the frozen tsleep. So, a properly scheduled SIGALRM .... Still, I don't really see how the Meteor gets out of its lockup. The process simply proceeds to grab the next image (successfully), which hardly resets the frame grabber or suchlike. > My guess every computer that you used to test the card uses the > PCI 2.x chipset. Correct. In fact, they're all identical: Asus P2B-D(S) dual PII mainboards (at various clock speeds), so I'm a bit surprised that I'm only having issues with two of them (so far, *knocking on wood*). Anyway, thanks for the help. -stephan -- stephan mantler: endurance sports maniac reality is in fact virtual. http://step.wastelander.org/ step@acm.org gnu pgp fingerprint: 0A25 EBE7 8AD3 A65D FEB5 C40E 88F9 DF4C 12CB C848 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?20011122173507.B32065>