johnc@rtmvax.UUCP (John Connin) (08/26/88)
In article <1119@ndsuvax.UUCP> ncoverby@ndsuvax.UUCP (Glen Overby) writes: > and cranking MAX_WIN_RETRY all the way up to 65535 (I guess the board is > a bit slow). Tell us when you get it to work! Be careful, you may have introduced a bug waiting to happen -- and if it happens your system will hang. I was not able to quickly put my fingers on xt_wini.c however, but at_wini.c has the follow construct which I will assume is similar to xt_wini.c. register int i; int r; if (drive_busy()) return(ERR); for (i=0, r=0; i<MAX_WIN_RETRY && (r&8) == 0; i++) port_in(WIN_REG8, &r); The point being that if MAX_WIN_RETRY is larger that 32767 the for-loop exit condition may never be satisfied, and if not satisfied the system will hang. Reason, wini is a kernel task and thus not subject to preemption. F9 will not even break you out of this one. This situation suggests that it might be prudent in the above and similar instances to (a) change 'i' to unsigned int or (2) add a warning comment to the _limit_ definition. On a related note, I noticed some mention of TURBO-C in recent articles. Since TC seems to be a sensitive 'lint', perhaps it would be helpful for someone to send AST a listing of all warnings produced by TC when compiling minix code.