🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.next.misc
Article #2937

Re: Kernel patches continued... (Was: Ramdisk coming for NeXT)

#2937
From: Geoff Kuenning
Date: Sun, 11 Oct 1992 09:32
126 lines
6362 bytes
In article <1992Aug18.091316.29278@Informatik.TU-Muenchen.DE> meyergru@Informatik.TU-Muenchen.DE (Uwe Meyer-Gruhl) writes:

> 5. Phew. I don't know, either. The list made by Richard "Terminally
>    curious" O'Neill is something I had also done to find out the
>    names of kernel flags. It seems pretty complete and follows here:
> 
> |>   hz phz nbuf bufpages pagesize mem dspicr dspcvr dspisr dspivr
> |>   dsph dspm dspl debug maxphys ncallout breakpoint rmtdebug
> |>   od_frmr od_land od_spin od_noverify od_maxecc od_maxecc_l1
> |>   od_maxecc_h1 od_maxecc_l2 od_maxecc_h2 od_write_retry od_flgstr1
> |>   od_flgstr2 mi_rv_delay mi_expire mi_expire_sh mi_expire_sh2
> |>   mi_expire_jmp mi_expire_max od_errmsg_filter
> |>   od_id_r od_id_v od_id_o od_requested od_dbug init rootdir
> |>   rootdev rootrw astune_rate astune_calls
> |> 
> 
> |> I've got little idea which ones one can safely play with, or what
> |> they do.  'rootdir', 'rootdev' and 'rootrw' look like they could
> |> be useful to some people. 'bufpages' also looks interesting, since
> |> it seems related to 'nbuf'.

Well, based on extensive experience with the Unix (*not* Mach!)
kernel, here are some educated and uneducated guesses, with the latter
marked by question marks:

hz		Interrupt frequency of the (hardware) system clock;
		usually in the range 50-100.  Changing this will make
		your clock run fast or slow.
phz		Unknown.  Maybe it's "Precise Hz", giving the rate at
		which the high-resolution clock runs.
nbuf		Number of disk blocks to cache in memory to improve
		performance.
bufpages	Number of pages of memory devoted to disk buffers.  I
		seem to remember that this has to do with the BSD fast
		file system, but I'm not in a mood to explain the
		details right now.  It might be useful to make this
		slightly smaller than the value implied by nbuf.
		Making it larger probably isn't useful.
pagesize	??? Maybe the size of the hardware page in the
		virtual memory mechanism, though I don't know why it
		would be a variable.  Or maybe it's the page size in
		the swap file.  Your guess is as good as mine.
mem		??? The amount of memory on the system?
dspicr		??? Probably the address or contents of various DSP
		control registers.  You should be able to match up the
		suffixes with register names in the DSP manual.
dspcvr		...
dspisr		...
dspivr		...
dsph		...
dspm		...
dspl		...
debug		One suspects that setting this nonzero will send lots
		of cute debugging information somewhere, possibly to a
		serial port.
maxphys		??? Usually it's the address of the highest byte of
		physical memory.
ncallout	Size of the callout list.  In standard Unix, the
		callout list is used to store short-term kernel
		timeouts, such as network retransmission timeouts.
		There is no reason to expand this unless you're
		getting messages indicating that the list overflowed.
breakpoint	??? No idea
rmtdebug	??? If I had to guess, I'd bet that you have to set
		this nonzero to enable remote debugging.
od_frmr		??? Something to do with formatting the OD?
od_land		??? Maybe it's set NZ when the OD has landed?  Do OD
		heads even land?
od_spin		??? Maybe NZ if the OD is spinning?
od_noverify	??? I'd bet that setting it nonzero would cause the OD
		to skip the verify pass on writes (the famous
		3-revolution erase-write-read cycle).  This could
		speed up OD write performance by 33%, at a cost of
		increasing the probability of errors.
od_maxecc	??? ECC, of course, stands for Error Correcting Code.
		Maybe this is the maximum number of retries on ECC errors.
od_maxecc_l1	??? No idea, except that these probably represent a
		128-bit variable of some sort.
od_maxecc_h1	...
od_maxecc_l2	...
od_maxecc_h2	...
od_write_retry	??? If NZ, maybe it retries OD write errors that many
		times?
od_flgstr1	??? OD Flag string?  Sounds interesting.
od_flgstr2	...
mi_rv_delay	??? You've got me.  Anybody know what MI stands for?
mi_expire	...
mi_expire_sh	...
mi_expire_sh2	...
mi_expire_jmp	...
mi_expire_max	...
od_errmsg_filter ??? No idea
od_id_r		??? R for read?
od_id_v		??? V for verify?
od_id_o		??? No idea
od_requested	??? Maybe set NZ if somebody needs an OD inserted?
od_dbug		??? Set to NZ to get OD debugging info
init		Typically, this contains the name of the init program,
		/etc/init.  Because /etc/init is absolutely critical
		to getting Unix running (without it, you might as well
		not have a kernel), it's very dangerous to test new
		versions by simply replacing the old one.  Instead,
		you name the test version "/etc/init.new" and then use
		"bsd init=/etc/init.new" to boot, so you're not hosed
		if the test version is completely broken.  DON'T
		CHANGE THIS IN THE BINARY!  And don't even experiment
		with it unless you know what you're doing.
rootdir		??? The inode number of the root directory?  I don't
		know why you'd need this, since root should always be
		inode 2.  Maybe it's for debugging.
rootdev		??? In standard unix, the major and minor number of
		the root device.  The format varies.  This is how the
		kernel knows which disk to mount as "root".  Again,
		don't change it in the binary unless you know what
		you're doing, since you can't run without important
		root software like /etc/init and some sort of shell.
rootrw		??? Maybe it controls whether the root is mounted
		read-write?  That would be pretty neat, since standard
		Unix always insists on read-write mounting and
		sometimes you'd really like to boot read-only.
astune_rate	??? No idea.
astune_calls	??? No idea.

Hope this all helps.
-- 
	Geoff Kuenning   geoff@itcorp.com   uunet!desint!geoff
Technical Details
Message-ID: <1992Oct11.093218.18245@ITcorp.com>
Path: arc1-ca.pugleaf.net!sparky!uunet!tcsi.com!iat.holonet.net!news!usc!sdd.hp.com!nigel.msen.com!spool.mu.edu!think.com!cass.ma02.bull.com!ladcgw.ladc.bull.com!desint!geoff
References: <2A8A9B76.17419@noiro.acs.uci.edu> <1992Aug14.075240.8875@Informatik.TU-Muenchen.DE> <1992Aug18.091316.29278@Informatik.TU-Muenchen.DE>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!tcsi.com!iat.holonet.net!news!usc!sdd.hp.com!nigel.msen.com!spool.mu.edu!think.com!cass.ma02.bull.com!ladcgw.ladc.bull.com!desint!geoff
From: geoff@ITcorp.com (Geoff Kuenning)
Newsgroups: comp.sys.next.misc
Subject: Re: Kernel patches continued... (Was: Ramdisk coming for NeXT)
Keywords: Questions, questions...
Message-ID: <1992Oct11.093218.18245@ITcorp.com>
Date: 11 Oct 92 09:32:18 GMT
References: <2A8A9B76.17419@noiro.acs.uci.edu> <1992Aug14.075240.8875@Informatik.TU-Muenchen.DE> <1992Aug18.091316.29278@Informatik.TU-Muenchen.DE>
Organization: Interrupt Technology Corporation, Chatsworth, CA
Lines: 126