paradis@encore.UUCP (Jim Paradis) (12/08/87)
After many weeks of not quite being able to get around to it, I finally added serial line support to my rewritten MINIX TTY driver. It works, but there's one serious problem: If I test it out by looping back transmit and receive on the serial line and running a quick&dirty terminal program, if I type at it too fast the system will hang. Now, I remember someone else in this newsgroup sometime back who added serial capabilities to the stock TTY driver and ended up with the same problem. Is there some limit to how fast MINIX will take interrupts? If one takes them too fast, will messages get lost? A little background info: I'm running a 12 MHz AT-clone with an AST-sixpack-clone board for serial I/O. The TTY driver takes interrupts for both "data ready" and "transmit register empty". I've tried a number of techniques for minimizing the number of interrupts processed, including doing all writes synchronously (thereby only having to process data-ready interrupts), waiting around for a period of time after a character comes in to see if there's another immediately following, all to no avail. I'm running the serial line at 1200 baud (the default MINIX ioctl structure has no way of specifying baud rates, so it's hard-coded for now. Eventually I'll fix ioctl). Any ideas out there? Am I missing something obvious? +----------------+ Jim Paradis linus--+ +--+-------------+ | Encore Computer Corp. necntc--| | | E N C O R E | | 257 Cedar Hill St. ihnp4--+-encore!paradis | +-------------+--+ Marlboro MA 01752 decvax--| +----------------+ (617) 460-0500 talcott--+ But if we took the bones out it wouldn't be crunchy, now would it?
ast@cs.vu.nl (Andy Tanenbaum) (12/09/87)
In article <2314@encore.UUCP> paradis@encore.UUCP (Jim Paradis) writes: >Is there some limit to how fast MINIX will take interrupts? >If one takes them too fast, will messages get lost? > If you try to force feed MINIX from an Ethernet at 10 Mbps it will probably drop stuff. There is undoubtedly a limit on how many interrupts per second it can handle, but an AT it should be over 1000 per second. The original tty driver was very carefully written to deal with exactly this issue. When characters come in, they are buffered, even if it is not possible to send a message to the tty task. This code is on lines 3528 to 3552 of the book. Assuming you are still using this mechanism, you ought to be able to accept characters at say 2400 baud without losing any. Andy Tanenbaum (ast@cs.vu.nl)
bing@galbp.LBP.HARRIS.COM (Bing Bang) (12/19/87)
In article <2314@encore.UUCP> paradis@encore.UUCP (Jim Paradis) writes: >After many weeks of not quite being able to get around to it, >I finally added serial line support to my rewritten MINIX TTY >driver. It works, but there's one serious problem: If I test >it out by looping back transmit and receive on the serial line >and running a quick&dirty terminal program, if I type at it >too fast the system will hang. Now, I remember someone else in >this newsgroup sometime back who added serial capabilities to >the stock TTY driver and ended up with the same problem. Is there well, i'm glad i'm not the only one having this problem. i've been trying to track this problem down for months. maybe we can team up. here's what i know of the problem. in tty_task, the message structure tty_mess is declared so that it is allocated on the stack. the problem seems to be that some routine corrupts 6 or 8 bytes just below the address of the structure. this of course usually contains the reuturn address and stuff from the receive() call tty_task makes. i know the corruption is relative to the structure address becuse i can make other declarations in tty_task to move the location of the structure. the problem can be "solved" by allocating a char array just below the structure, although memory in the array still get corrupted. i do not care for this solution. -- Bing H. Bang +----------------------------------------------------+ Harris/Lanier |MSDOS and OS/2 (whenever it gets here): just say no.| Atlanta GA +----------------------------------------------------+
colinm@runx.ips.oz (Colin McCormack) (12/20/87)
In article <2314@encore.UUCP> paradis@encore.UUCP (Jim Paradis) writes: >After many weeks of not quite being able to get around to it, >I finally added serial line support to my rewritten MINIX TTY >driver. It works, but there's one serious problem: If I test >it out by looping back transmit and receive on the serial line >and running a quick&dirty terminal program, if I type at it >too fast the system will hang. Now, I remember someone else in >this newsgroup sometime back who added serial capabilities to >the stock TTY driver and ended up with the same problem. Is there >some limit to how fast MINIX will take interrupts? If one takes >them too fast, will messages get lost? I am only working from the published version, and this may have been fixed in later minix versions (later than 1.1), but I think that 8088 interrupts are re-enabled too soon in the function interrupt() in file kernel/proc.c. As soon as interrupts are permitted an interrupt will cause the current machine state to be stored in the process kernel table entry for the process pointed at by the kernel global variable proc_ptr (which represents the process table entry for the interrupted process.) Since the process has effectively been suspended by the time the interrupt function starts, and no new value for proc_ptr is selected until the current interrupt handler finishes, the last thing we want is for the machine state at interrupt() to overwrite the saved machine state at proc_ptr. Doing this will at least cause the pending process to effectively disappear - and if that process was fs or mm..... I suppose a solution would be to leave interrupts suspended until a new process has been restarted, but this would degrade interrupt response time unacceptably. This problem has arisen from my attempts to port minix to the 68000 (which has prioritised interrupts) where we actually _want_ reentrant interrupt handling. If there is a fault in my analysis of minix interrupts, I'd appreciate hearing about it, also if anyone has already hacked minix for 68000 I'd like to know what tack you took to avoid this problem. Colin McCormack. [insert pithy comment here]