Return to BSD News archive
Path: sserve!manuel!munnari.oz.au!samsung!uakari.primate.wisc.edu!sdd.hp.com!wupost!usc!sol.ctr.columbia.edu!eff!news.byu.edu!ux1!fcom.cc.utah.edu!gateway.univel.com!gateway.novell.com!thisbe!terry From: terry@thisbe.npd.Novell.COM (Terry Lambert) Newsgroups: comp.unix.bsd Subject: System hang, working hardware guide Message-ID: <1992Aug7.160048.15061@gateway.novell.com> Date: 7 Aug 92 16:00:48 GMT References: <michaelv.713151876@test.cc.iastate.edu> Sender: terry@thisbe (Terry Lambert) Organization: Novell NPD -- Sandy, UT Lines: 74 Nntp-Posting-Host: thisbe.eng.sandy.novell.com In article <michaelv.713151876@test.cc.iastate.edu>, michaelv@iastate.edu (Michael L. VanLoon) writes: |> In <1992Aug4.175738.7008@Unibase.SK.CA> roe@Unibase.SK.CA (Roe Peterson) writes: |> |> >This is in relation to the many reports of mysterious system hangups |> >during heavy disk load. |> |> >Summary: |> > - regardless of disk controller, heavy disk access (ie: |> > extract, kernel rebuild, libc.a rebuild) seems to |> > cause system lockups at unpredictable intervals. |> |> I'd just like to make it clear that not all machines suffer from this. |> I'm using the latest two-drive kernel patches posted on one machine, and |> the two-drive binary kernel that was put first on uky.edu on the other. |> |> I've pushed the machines VERY hard and have had NO problems whatsoever. |> There were thrashing the drives as well as very heavy network traffic, |> compiling emacs, moving multi-megabyte groups of files around to |> rearrange filesystem partitions, etc. I think this bears repeating. The problems some people have are during heavy disk usage. Other people have nearly no problems at all (although they are generally using MFM drives (any configuration) or IDE drives (no DOS partition). The problem generally occurs on SCSI and ESDI controllers (ie: where you have enough disk on one drive to get something useful done). The worst I have seen it is on a WD1007 ESDI. The lockup with some Adaptek SCSI controllers, notably after the "Changing root to fd0a" or similar message during the boot stage is a different problem. One person has reported that typing 'sync' helps; in the worst case, the lockup occurs in the initial copy-to-disk or in the bin installation, either of which will prevent 'sync' from being a soloution. A tenative (pending 0.2) fix for this has been suggested as a one line kernel change by Bill himself. This is unfortunately not applicable until a dist.fs with the fix in it is posted, at least for those of us locking up in installation, during bin or etc installation, or during compiles, as any of these will prevent getting a kernel with the fix in it. I find it questionable that the fix, which seems from it's context and an examination of the code after unpackng on a Sun to be "heavy use" inclined, can help people with initial lock up anyway. There is nothing to suggest that installation qualifies as heavy use, otherwise no one would be able to run at all (unless the fix is SCSI/ESDI specific, which is not readily apparent from an admittedly brief examination). If this were not the case, no one would have been able to install. Perhaps we are looking at several problems? 1) Is anyone experiencing the "lockup bug" on an MFM drive? 2) Is anyone experiencing the "lockup bug" on an IDE drive? 3) Is anyone else locking up during the "install" after initial boot? Robert Withrow is experiencing the problem AHA1524B, according to mail. I am experiencing the problem with WD1007 ESDI (according to mail, since this qualifies as mail). Anyone without the problem: o What is your controller type? o What is the board revision? o What is the ROM revision (if any)? o What are the jumper settings? o What other problems do you have? This information will also be used to provide a "How to set up the hardware so 386BSD will boot and run without problems the first time" guide. Terry Lambert terry_lambert@gateway.novell.com terry@icarus.weber.edu --- Disclaimer: Any opinions in this posting are my own and not those of my present or previous employers.