pmacdona@sol.uvic.ca (Peter MacDonald) (03/27/91)
The following problem (or variations thereof) has been posted by
a number of people over the last few months. The problem manifests
itself as unexpected interrupts during disk reads in protected mode,
causing the 386 to hang, usually with the drive light stuck on.
In my case, I can invariably induce this condition by running
fsck /dev/hd2.
I have been wrestling with this problem since last October and think
I finally have a (kludgy) fix. After all this time, elegance has
ceased to be an issue.
After reading an article about IDE drives in the Mar 90 issue of byte
(Under The Hood) about how some IDE drives can't keep up with the
command streams when doing loads of reads in protected mode,
I began to suspect that minix was doing just that to my IDE.
Therefore, inserting an artificial delay before reading each sector,
should slow down the entire stream. Add to w_transfer in wini.c
the lines preceeded with a plus (+):
if (wn->wn_opcode == DISK_READ) {
for (i=0; i<BLOCK_SIZE/SECTOR_SIZE; i++) {
+ int j,k;
+ for (j=0;j<300;j++)
+ k=k*3+j;
End of problem. (Actually I haven't exhastively tested the results,
but rather ran fsck several dozen times both sequentially and
in two different consoles concurrently.)
For those interested, I ran some variations on the upper bound of
j and measured the results with time on fsck. These results which
are summerized below, indicate that further reductions in this upper
bound has diminishing returns.
j(wini) time
----------------------------------------
BIOS real:49 user:2.5 system:46.7
3000 real:48 user:1.7 system:7.8
300 real:41 user:1.9 system:2.3
30 real:41 user:1.6 system:1.8 # Machine locked up later.ast@cs.vu.nl (Andy Tanenbaum) (03/27/91)
In article <1991Mar27.080437.6998@sol.UVic.CA@ pmacdona@sol.uvic.ca (Peter MacDonald) writes:
@Therefore, inserting an artificial delay before reading each sector,
@should slow down the entire stream. Add to w_transfer in wini.c
@the lines preceeded with a plus (+):
@
@ if (wn-@wn_opcode == DISK_READ) {
@ for (i=0; i<BLOCK_SIZE/SECTOR_SIZE; i++) {
@ + int j,k;
@ + for (j=0;j<300;j++)
@ + k=k*3+j;
@
@
@End of problem.
I don't have any IDE drives here, so I can't verify this. If enough other
IDE drive owners verify that this works, I will add it to the code protected
by #ifdef IDE. Is it needed in at_wini.c or xt_wini.c or both? Are there
other changes needed for IDE?
Andy Tanenbaum (ast@cs.vu.nl)
P.S. The @ is an attempt to trick the user-friendly news software which, like
much user-friendly software, thinks it knows better than I what I should and
should not post and will not accept the message with > signs.cechew@sol0.cs.monash.edu.au (Earl Chew) (03/29/91)
ast@cs.vu.nl (Andy Tanenbaum) writes: >I don't have any IDE drives here, so I can't verify this. If enough other >IDE drive owners verify that this works, I will add it to the code protected >by #ifdef IDE. Is it needed in at_wini.c or xt_wini.c or both? Are there >other changes needed for IDE? I hasten to add that this is only needed for brain damaged IDE drives. IDE drives look to the software like the old AT drives (ie they respond at the old WD IO addresses). In theory :-) no changes are required for IDE. I suggest that the code be protected by #if SLOW_IDE (which is describes the problem better). My IDE drive needs no changes to the AT driver. Earl -- Earl Chew, Dept of Computer Science, Monash University, Australia 3168 EMAIL: cechew@bruce.cs.monash.edu.au PHONE: 03 5655778 FAX: 03 5655146 ----------------------------------------------------------------------
ghelmer@dsuvax.uucp (Guy Helmer) (04/04/91)
In <1991Mar27.080437.6998@sol.UVic.CA> pmacdona@sol.uvic.ca (Peter MacDonald) writes: >The following problem (or variations thereof) has been posted by >a number of people over the last few months. The problem manifests >itself as unexpected interrupts during disk reads in protected mode, >causing the 386 to hang, usually with the drive light stuck on. >In my case, I can invariably induce this condition by running >fsck /dev/hd2. >I have been wrestling with this problem since last October and think >I finally have a (kludgy) fix. After all this time, elegance has >ceased to be an issue. This change seems to help my machine, a DTK 386sx with WD-1006 RLL controller. fsck /dev/hd2 (a 59Mb partition on my machine) used to hang my machine quite consistently with the CPU running at full speed, but I haven't been able to lock up my machine since I applied this change. Thanks for the fix. -- Guy Helmer, Dakota State University Computing Services helmer@sdnet.bitnet, dsuvax!ghelmer@wunoc.wustl.edu, wupost!dsuvax!ghelmer "I'm a cowboy, on a keyboard I ride..." -- with apologies to Bon Jovi