dillon@CORY.BERKELEY.EDU (Matt Dillon) (04/30/87)
I think I've found a bug in the serial.device ... You can crash your Amiga by doing the following: -Set terminal program and modem @ 1200 baud - Make sure it is NOT using the RAD_BOOGIE bit -Tell modem to send it's help screen (or test chars..) continuously. -While the modem is sendin, change the baud rate of the terminal program (and thus serial.device) to 20000 Your Amiga should freeze up. Using RAD_BOOGIE seems to fix the the problem. This is a *real* bug because it would seem that changing the the baud rate to anything, at any time when the serial.device isn't using RAD_BOOGIE creates a window or something... (20000 almost always causes a crash. 1200->2400 does so every once in a while) I have no idea why RAD_BOOGIE seems to fix the problem... perhaps the bug in the serial.device is associated with parity checking????? ******* People using DTERM should use the -f option to force DTERM to use the RAD_BOOGIE bit. DTERM is particulary sensitive since one usually programs the state machine to automatically reset the baud rate to the highest his modem can take on disconnect.... -Matt
papa@bacall.UUCP (05/02/87)
Matt Dillon writes: > I think I've found a bug in the serial.device ... You can crash your > Amiga by doing the following: > > -Set terminal program and modem @ 1200 baud > - Make sure it is NOT using the RAD_BOOGIE bit > -Tell modem to send it's help screen (or test chars..) continuously. > -While the modem is sendin, change the baud rate of the terminal > program (and thus serial.device) to 20000 > > Your Amiga should freeze up. Using RAD_BOOGIE seems to fix the > the problem. This is a *real* bug because it would seem that changing the > the baud rate to anything, at any time when the serial.device isn't using > RAD_BOOGIE creates a window or something... (20000 almost always causes > a crash. 1200->2400 does so every once in a while) > You do not mention if you have oustanding I/O requests when you do the SETPARMS (to change the baud rate). RKM mentions that " a parameter change cannot be performed while actually processing and I/O request .... therefore you must use SDCMD_SETPARAMES only when you have no serial I/O requests pending". This means executing an AbortIO(readrequest) before resetting the baudrate (or any other comm parameter) if, as usually done by comm programs, one has started an input request. I do not have your code handy, so this might not apply if you do indeed use AbortIO. -- Marco -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Marco Papa 3175 S. Hoover St., Ste. 275 (213)747-8498 Los Angeles, CA 90007 USC: (213)743-3752 F E L S I N A Now working for ::::::: BIX: papa But in no way :: :: Officially representing ::::::: ...!oberon!bacall!papa S O F T W A R E papa@cse.usc.edu -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
dillon@CORY.BERKELEY.EDU.UUCP (05/07/87)
>You do not mention if you have oustanding I/O requests when you do the >SETPARMS (to change the baud rate). RKM mentions that " a parameter >change cannot be performed while actually processing and I/O request .... I *do* do an AbortIO(). But even if I didn't, the SETPARAMS would simply return with an error code. The bug I mentioned occurs when SETPARAMS actually changes the baud rate -Matt
andy@cbmvax.UUCP (05/08/87)
In article <8705071832.AA07417@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >>You do not mention if you have oustanding I/O requests when you do the What you are seeing might be related to the known serial.device bug of crashing when faced with a serial input stream of characters with a baud rate radically different that the one the serial.device is set to. Setting RAD_BOOGIE causes the serial.device to skip most of its handshaking logic, where it got confused. Sound like your problem ? > -Matt -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore/Amiga /or/ pyramid!amiga!andy } "Do not meddle with the affairs of wizards, for it makes them soggy and hard to light." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
dillon@CORY.BERKELEY.EDU.UUCP (05/08/87)
>What you are seeing might be related to the known serial.device bug >of crashing when faced with a serial input stream of characters >with a baud rate radically different that the one the serial.device >is set to. Setting RAD_BOOGIE causes the serial.device to skip That's it! No, I didn't know it was a well known bug. However, it is not as trivial as it may seem to avoid it... you *have* to set RAD_BOOGIE. If not, DTERM is very vulnerable since it can switch baud rates under state machine control (and does). -Matt