Article View: comp.sys.next.misc
Article #2937Re: Kernel patches continued... (Was: Ramdisk coming for NeXT)
From: Geoff Kuenning
Date: Sun, 11 Oct 1992 09:32
Date: Sun, 11 Oct 1992 09:32
126 lines
6362 bytes
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!geoffReferences:
<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