Date: 05 May 1999 16:23:07 +0200 From: Anton Berezin <tobez@plab.ku.dk> To: freebsd-questions@FreeBSD.ORG Cc: tobez@plab.ku.dk, voland@plab.ku.dk Subject: Matrox Meteor Rev C problem Message-ID: <86hfprr3xw.fsf@lion.plab.ku.dk>
next in thread | raw e-mail | index | archive | help
Hello, Recently we have had problems with Matrox Meteor video capturing board. Apparently something changed in the hardware which broke the existing FreeBSD Matrox Meteor driver. Older boards work alright. I asked Matrox about this, requesting technical information to try to fix the driver myself, but they did not give me this information. As a last resort, I am writing to this list; probably, someone solved the same problem before; probably, one of you have some clues to what's needed to fix this. Below I am providing the reply I've got from Matrox (through their distributor in Denmark), and my original message to them. Thank you in advance, Anton. -------------------------------------- From: yosif.grunberg@matrox.com To: al@jai.dk Hello Anders, It seems that there is a known incompatibility with the Rev C Meteor/PPB/RGB and the FreeBSD UNIX OS. Some newer chips have been placed onto the Rev C boards that cause an incompatibility for the FreeBSD OS driver. However, since this driver is not a Matrox driver, engineering will not place any priority to fix it. I think that the only solution here is if you can find older Meteor/PPB/RGB Rev 1's to trade with his rev C's. Yosi. -------------------------------------- -------------------------------------- From: tobez@plab.ku.dk To: al@jai.dk Dear Anders, Bjarne Andersen (of BSA Data Consult) told me I can contact you in regard to the problems we experience with our newly purchased Matrox Meteor boards. So I am doing. We in fact have one board which is quite alright. We've been using it for more than three months now, quite heavily. It is Matrox Meteor/PPB/RGB S/N AK13063 M075550 Rev1. Two other boards (with which we *have* problems) are: Matrox Meteor/PPB/RGB S/N AL71122 M010530 Matrox Meteor/PPB/RGB S/N AL81640 M011070 They both don't have ``Rev 1'' on them. Instead, there is ``C1'' mark at the same place the old/good board have ``Rev 1''. All three boards are identically detected by the driver we are using: meteor0: <Philips SAA 7116> rev 0x00 int a irq 11 on pci2.1.0 meteor0: <Philips SAA 7196> rev 0x1 meteor0: <Booktree 254 (RGB module)> During the operation, even with the old (good) board, we have occasionally messages about FIFO overflows: /kernel: meteor0: capture error: even FIFO overflow. or /kernel: meteor0: capture error: odd FIFO overflow. Those normally occur when our program switches between continuous asynchronous flow of frame data to the main memory and ``single capture'' mode. They do not occur every time. They are, in fact, quite rare. From my experience I would say, about 3-5 such messages per 8-hours of heavy usage. With the new boards, however, there is a constant flow of those messages. Luckily, the syslog facility is clever enough to digest the messages into something like this: /kernel: meteor0: capture error: odd FIFO overflow. last message repeated 2 times /kernel: meteor0: capture error: even FIFO overflow. last message repeated 31 times last message repeated 19 times /kernel: meteor0: capture error: odd FIFO overflow. last message repeated 31 times last message repeated 121 times last message repeated 602 times last message repeated 113 times This is not a problem per se, though it is quite annoying. The *real* problem is that the boards don't produce any frames with information, just pure black (of course, there *is* an input signal from the camera). So I think those overflows are indicators of a problem. I realize, that it *might* be that the boards are not defect. It might be a subtle change between different revision/series/whatever which made the driver we are using incompatible with newer boards. This is very unfortunate for us. So, if it indeed is the case, I would be glad if you can find a possibility to obtain a technical description of the changes, so I could incorporate necessary fixes into the driver (I am not the one who originally wrote the driver, but it's the Open Source Software, so there are no any problems here). If this will not be possible for whatever reasons, that would mean that we cannot use those boards with our software. In case such an unfortunate situation arise, I would like to request to change the boards to older & compatible. In case this is not an option, I would like to return the boards. A couple of words about the operating system, the driver and the software. Our workstations are running FreeBSD Unix (http://www.FreeBSD.org), the very stable and well respected Open Source OS. The driver for the meteor board is included into the base system since 1995, and was written by Mark Tinguely and Jim Lowe (I am not aware of any affilication of them with Matrox). The user-end software was written by myself. Hope to here from you soon, Yours sincerely, -- Anton Berezin <tobez@plab.ku.dk> The Protein Laboratory, University of Copenhagen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86hfprr3xw.fsf>