Xref: utzoo comp.unix.sysv386:7720 comp.sys.att:12235 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!samsung!olivea!apple!mauxci!robohack!eci386!woods From: woods@eci386.uucp (Greg A. Woods) Newsgroups: comp.unix.sysv386,comp.sys.att Subject: Re: sar -d and ESDI drives Keywords: sar Message-ID: <1991May3.221321.14977@eci386.uucp> Date: 3 May 91 22:13:21 GMT References: <1991May1.153257.18685@bradley.bradley.edu> <1991May02.135710.7757@chinet.chi.il.us> Reply-To: woods@eci386.UUCP (Greg A. Woods) Organization: Elegant Communications Inc. Lines: 28 In article <1991May02.135710.7757@chinet.chi.il.us> randy@chinet.chi.il.us (Randy Suess) writes: > In article <1991May1.153257.18685@bradley.bradley.edu> fred@bradley.bradley.edu (Fred Jaggi) writes: > ]i'm trying to do performance graphs of some 6386 machines running UNIX > ]System V R 3.2.2, but sar -d doesn't show me anything. this seems to > ]be the case for all the machines with ESDI drives (SCSI and IDE seem > ]to work just fine). is there any fix available for this? > > sar -d is broke in most (all?) 386 unix's. Seems no-one > is able to convert the 3b2 based routines in sar for disk > monitoring to the pc-bused controllers. AT&T tried to > fix it in their 3.2.3 release, but broke everything else. It's not a matter of converting 3b2 drivers, (though the 3b2 drivers do indeed work correctly) but rather a matter of a very few simple lines of code in the 386 drivers to update the system accounting records. Some people are just plain lazy. Then again, I don't recall any clear documentation in the BCI Guide that tells what needs to be done... It's real easy for char drivers, since the line discipline usually takes care of the accounting, but block drivers, if I understand correctly, must do it on their own. -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP ECI and UniForum Canada +1-416-443-1734 [h] +1-416-595-5425 [w] VE3TCP Toronto, Ontario CANADA Political speech and writing are largely the defense of the indefensible-ORWELL