lenny@icus.islp.ny.us (Lenny Tropiano) (04/29/89)
In article <1215@oswego.Oswego.EDU> dab@oswego.oswego.edu.Oswego.EDU (Dave Bozak) writes: |>In the May '89 issue of _UNIX World_ Jim Pickering writes (in the |>Reader's Comments section) that he understands that 3.51c is about |>to be released. |> |>Is this true? How will we know? |> |>Whatever happened to 3.51b? I've got 3.51a, and never knew of a 3.51b |>(and I don't want that to happen with 3.51c!). |> I did see Jim's comments in _UNIX World_ magazine this month, and I wanted to thank him for recognizing us dedicated hardware hackers too. As far as the "3.51c" fixdisk, 3.51c is unfortunately long gone as far as the kernel hackers at AT&T are concerned. Currently I'm running 3.51dA (yes, that's hex for 10th copy of 3.51d...) Yes, there were many a kernel my way, some worse, some good, some indifferent. Right now there is a serious bug with the "clists" just disappearing. This has held up the forthcoming fixdisk for quite some time. Myself, and a few other UNIX pc'ers out there are sorta "beta" testing these kernels on our machines. The clist buffer problem is also known as the "slow down and die symptoms" ... What happens if NCLIST (tunable parameter) clists are all allocated (and never get released) the next time the machine goes to request a clist buffer [which happens quite often for character devices :-)] it will just wait indefinitely until one becomes available ... then the [Working] icon will just sit and stare you in the face. Right now my average uptime is less than two days ... I should have 150 clists maximum ... right now I have: Fri Apr 28 22:28:47 1989 cblocks = 105 And that's with less than 1 day of uptime... where did 45 cblocks go. That is what has the AT&T "guru" perplexed ... We all want to see this You can check your clists by doing: # adb /unix /dev/kmem cfreelist+6/d The number at that location is your total cblocks currently available... I'd be curious to know if this is happening to everyone out there (even those on the 3.5 release of the kernel). # ktune -d nbuf 100 ninode 400 nfile 300 nproc 100 ntext 75 nclist 150 <-- that's your maximum npbuf 16 ncall 32 nttyhog 1024 That's it for now ... -Lenny -- Lenny Tropiano ICUS Software Systems [w] +1 (516) 582-5525 lenny@icus.islp.ny.us Telex; 154232428 ICUS [h] +1 (516) 968-8576 {talcott,decuac,boulder,hombre,pacbell,sbcs}!icus!lenny attmail!icus!lenny ICUS Software Systems -- PO Box 1; Islip Terrace, NY 11752
jcs@tarkus.chi.il.us (John C. Sucilla) (05/01/89)
In article <687@icus.islp.ny.us> lenny@icus.islp.ny.us (Lenny Tropiano) writes: >You can check your clists by doing: > ># adb /unix /dev/kmem >cfreelist+6/d Ok, adb tells me I have 138 >I'd be curious to know if this is happening to everyone out there (even >those on the 3.5 release of the kernel). Nope, no slow down n die problem over here. And I'm basically running 3.50 funked up to 3.5.1.4 with 7 hours over one week of uptime. Normally this thing is up 4 or 5 weeks continuously but I moved the machine a little last week... ># ktune -d >nbuf 100 >ninode 400 >nfile 300 >nproc 100 >ntext 75 >nclist 150 <-- that's your maximum >npbuf 16 >ncall 32 >nttyhog 1024 nbuf 100 ninode 400 nfile 300 nproc 100 ntext 75 nclist 150 npbuf 16 ncall 32 nttyhog 1024 Hope this helps... -- "We do what we can, but this little guy called Fate will do what he pleases anyway. All we can do is give him enough to work with and hope it goes the way we want." - S.S.