On Wed, 27 Mar 2002, Robert Watson wrote:
On Wed, 27 Mar 2002, Hiten Pandya wrote:
According to me, the utility shouldn't be using a hardcoded path to the
booting kernel, as this would affect kernels which were made by:
makeoptions KERNEL=foo#Build kernel foo and install /foo
Hi all,
According to -current, isnt the kernel file located /boot/kernel?
How come the kgmon(8) is still refering to /kernel? Is this a bug or I
am unaware of something? :) If it is a bug, than I probably someone can
commit the change in behalf of me.. :)
Thanks,
--
Hiten Pandya
On Wed, 27 Mar 2002, Hiten Pandya wrote:
:Hi all,
:
:According to -current, isnt the kernel file located /boot/kernel?
:
:How come the kgmon(8) is still refering to /kernel? Is this a bug or I
:am unaware of something? :) If it is a bug, than I probably someone can
:commit the change in behalf
Generate diffs -- send-pr.
Does this apply to all the manual pages in -CURRENT? where /kernel
should be /boot/kernel/kernel? If this is the case, then I can just
send one or two big PRs which have the patches.
What are your suggestions? :)
Thanks,
--
Hiten Pandya
http://jfs4bsd.sf.net -
On Wed, 27 Mar 2002, Hiten Pandya wrote:
: Generate diffs -- send-pr.
:
:Does this apply to all the manual pages in -CURRENT? where /kernel
:should be /boot/kernel/kernel? If this is the case, then I can just
:send one or two big PRs which have the patches.
:
:What are your suggestions? :)
I've committed a tweak to the man page, but think that the page may
actually be wrong in a more general sense: kgmon appears to use
getbootfile() so will actually use whatever path the sytem booted with.
While by default that will be /boot/kernel/kernel, it may be something
else, in which case
On 2002-03-27 16:44, Hiten Pandya wrote:
--- Robert Watson [EMAIL PROTECTED] wrote:
I've committed a tweak to the man page, but think that the page may
actually be wrong in a more general sense: kgmon appears to use
getbootfile() so will actually use whatever path the sytem booted with.
--- Giorgos Keramidas [EMAIL PROTECTED] wrote:
How about http://people.FreeBSD.org/~keramida/diff/kgmon.txt ?
Hmm, the patch looks pretty good, but we can use a bit of rewording which
will reflect what the code does. Something like the following:
-- START --
Extract the name list from the
On Wed, 27 Mar 2002, Hiten Pandya wrote:
How come the kgmon(8) is still refering to /kernel? Is this a bug or I
am unaware of something? :) If it is a bug, than I probably someone can
commit the change in behalf of me.. :)
Same reason that most man pages that say where the kernel is still
--- Robert Watson [EMAIL PROTECTED] wrote:
I'd avoid your later changes involving describing how getbootfile() relies
on sysctl in the kgmon(8) man page. That's an implementation detail of
the API, not of kgmon, and while it probably won't change, putting the
information there increases the
hi maxime...
thanks very very much.. now i get it...,
its like.. a mutex is a lock, which is used when
things are done in parralel and to avoid corruption of
the data which is being processed... i took an example
of the way i used to lock files in PERL, in order to
avoid multiple writes at the
Hiten Pandya wrote:
hi all,
sorry for running -current.. but i am an enthusiastic
and challenging man...(boy)...
anyways.. whats a mutex and a lock order reversal...
if you could point to some good manual on these
subjects... thanks...
help is appreciated...
thanks again...
A mutex
Hiten Pandya wrote:
one more question... if there is a lock order
reversal.. is there a way that can be solved.. for
e.g. by using on of the MTX_XX things...
The lock order verification is not part of the mtx API. It's debugging
stuff activated by default in -CURRENT. If you do not want to
Hiten Pandya wrote:
MH The lock order verification is not part of the mtx
MH API. It's debugging
MH stuff activated by default in -CURRENT. If you do
MH not want to see these
MH warnings, remove ``options WITNESS'' from your
MH kernel conf or patch the
MH code to solve the problem :-)
MH The lock order verification is not part of the mtx
MH API. It's debugging
MH stuff activated by default in -CURRENT. If you do
MH not want to see these
MH warnings, remove ``options WITNESS'' from your
MH kernel conf or patch the
MH code to solve the problem :-)
hi,
i know that bit.. the
hi all,
sorry for running -current.. but i am an enthusiastic
and challenging man...(boy)...
anyways.. whats a mutex and a lock order reversal...
if you could point to some good manual on these
subjects... thanks...
help is appreciated...
thanks again...
=
regards,
Hiten Pandya
[EMAIL
The "md" driver I committed today is mostly a proof-of-concept thing
which came out of a chat with Peter Wemm.
It acts like a disk in all aspects, although it will be hard to boot
from it :-)
It will do very simple compression, in that a sector (512bytes)
which is filled with the same
:The "md" driver I committed today is mostly a proof-of-concept thing
:which came out of a chat with Peter Wemm.
:
:It acts like a disk in all aspects, although it will be hard to boot
:from it :-)
:
:It will do very simple compression, in that a sector (512bytes)
:which is filled with the same
Re-nicing wont help as I have just confirmed that the problem occurs
if I run MAME, exit MAME and then get on the net.
Very wierd... after running MAME, the serial port is unusable for
ppp unless I reboot. Just doing a DNS lookup causes several silo
overflows. MAME does something very
I have been investigating the silo overflow situation for some time.
I can trigger them every time by the following action:
- Run M.A.M.E. (Multi arcade machine emulator) and then try to
download something. (I am using user mode ppp).
I believe that the sio driver is its own worst enemy in that
On Sun, 2 May 1999, Matthew Thyer wrote:
I have been investigating the silo overflow situation for some time.
I can trigger them every time by the following action:
- Run M.A.M.E. (Multi arcade machine emulator) and then try to
download something. (I am using user mode ppp).
Can you
21 matches
Mail list logo
