Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!darwin.sura.net!haven.umd.edu!umd5.umd.edu!roissy.umd.edu!mark From: mark@roissy.umd.edu (Mark Sienkiewicz) Newsgroups: comp.os.386bsd.misc Subject: Not 16550 compatible: MCT-IDEIO+ ? Date: 26 Jul 1993 14:23:25 GMT Organization: University of Maryland Lines: 48 Message-ID: <230pct$obf@umd5.umd.edu> NNTP-Posting-Host: roissy.umd.edu Summary: board fails to generate receive interrupts with fifo enabled? Keywords: 16550 serial interrupt fifo I bought a board called "MCT-IDEIO+" from JDR Microdevices. It has two "NS16550 compatible" serial ports on it. (It also has an IDE controller, floppy controller, game, printer) After I installed it, I discovered that the serial ports just don't work, BUT if I kludge com.c to skip the FIFO check, it works just fine. After quite a bit of poking around, I discovered that if you enable the FIFO's, you no longer get receive interrupts. [ If you use both ports simultaneously, the transmitter-ready interrupt seems to stimulate the receiver on the other port... :) ] I checked the jumpers, etc. Also, note that the board works perfectly when the FIFO is disabled. Identifying marks on the board are: "WB757 (C) 1991" stenciled on the board "Winbond W83757F" is the only interesting chip. (There are 1488/1489 drivers for rs232 and a 556 or some such for the game port, but that's all.) I'm about to call JDR and tell them their board is stupid. Before I do, has anybody else seen / not-seen this problem? Mark S. p.s. history: Initial determination that the fifo's were involved was with Netbsd-0.8. The final determination is on netbsd-current 7/18/93, by having comintr() print the status code in the Interrupt Identification Register. When you would expect receive interrupts, you don't see anything. When you open both ports, writing to port A triggers the receive interrupt on port B and you get 16 characters (from port b) followed by a silo-overflow. [because I was sending input to it.] If you don't send a character to port A, you never receive anything on port B. You also can't close either port-- it hangs waiting for the interrupt handler to finish something. I haven't got this part fully figured out yet. I also disabled all fifo-specific handling in the driver (except enabling it), before I figured out it was bad hardware. It should have worked, just generating more interrupts than in fifo mode. If I got only 1 receive interrupt, I'd still be hunting a driver bug, but I got only * 0 * receive interrupts...