Messages in this thread | | | From | F Harvell <> | Subject | Re: 2.1.91pre2 stable? | Date | Mon, 30 Mar 1998 20:23:58 -0500 |
| |
On Sun, 29 Mar 1998 12:14:53 PST, Linus Torvalds wrote: > > On Sun, 29 Mar 1998, Bill Broadhurst wrote: > > > > What I use to test this is a complete rebuild of the entire X11 suite > > which takes over an hour on this machine. I run it on a standard VT > > without anything else running (except top but it crashes without top > > running) and no X. > > > > If the processes are shorter the system seems fine unless I really > > load the machine. I can reproduce the same thing by repeatedly > > running kernel builds on 6 VT's at the same time but it takes longer > > that way. I just ran 30 consecutive builds on two VT's without any > > trouble. > > > > This has been happening since 2.1.88 at least. I don't remember > > seeing it before that but I went from around .72 or so right to .88 in > > a single jump. > > > > How do I find out what causes this? > > Could you please pinpoint which releae this started in, that would > certainly help a _lot_. By using a reasonable binary-search kind of > algorithm it shouldn't take all that long if you can indeed reproduce it > fairly easily and reliably.
For me, my system became unusable at 2.1.85. Prior to that kernel (I am currently running 2.1.84) I have witnessed processes stuck in the "D" state, but they were rare. With the 2.1.85 kernel, just running my nightly dump would leave processes stuck. The problem appears to be exacerbated by the performance increases provided by Ingo's IO-APIC code starting in 2.1.85. Note: the first kernel that I saw a stuck "D" process in was 2.1.36 during an mkisofs run. (Apparently, it got stuck on the incorporation of a large, approximately 30MB if memory serves, file. When I removed the file, I was able to get the mkisofs run to complete.)
The stuck processes appear to occur most frequently when there is significant SCSI I/O within the process. I am able to readily recreate the problem by performing a level 0 dump to SCSI tape of a partition and doing an fsck on another unmounted partition. Either the fsck or the dump will hang. Note, over time, especially with the 2.1.85 and 2.1.86 kernels, I have seen other processes hang. It is especially bad when update (bdflush) hangs. The system will go into a slow spiral and eventually crash.
I tried the 2.1.91 kernel on Saturday, hoping the new SCSI spinlock code would help, and still experienced the problem. I tried to rebuild the kernel with the __asm__ "cpuid" hack but, on reboot, the system hung hard. It took me over an hour to fsck my partitions. I'm skating the razor's edge when the system crashes as, even with the 2.1.84 kernel, there is a very good likelyhood that the boot fsck on an unclean partition will hang. It took 4 reboots to make it through last time! I didn't have the time (or heart ;) to try to reboot the modified kernel again.
My system is on the internet and I am more than willing to let someone more knowledgeable than I on the box to investigate. BTW, my system has the tape drive on a buslogic 946 and two micropolis 8.7G drives in 10 md striped partitions on a second buslogic 958.
Some other possible information, I have received messages from others that a) upgrading the adaptec driver helped their problem (for a change, the adaptec appears to be the better card ;) and b) that turning off read-ahead on the drives helped. I have not tried either as a) I have buslogic cards, and b) I'm not real sure how to do this.
Anything I can do to help, please let me know. I _really_ want to start using Ingo's code.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |