:> :proc B returns since proc B is going to immediately switch over to a new
:> :stack?
:>
:> The return address for the procedure call is on the stack. If something
:> munges the stack after the physical rfork occurs but before both
processes
:> can return from the rfork() clib func
The problem with putting code in /etc/defaults/rc.conf is that
simplistic parsers which read it as ``var = value # optional comment''
get very confused by for loops or function declarations or what have
you. It also makes it more difficult to read in /etc/{*,.}rc.conf
from an admin program, permut
I'd like to add safeguards to keep syslogd from cascading its own
error messages. To describe more fully:
I just came back from a weekend getaway and discovered my crash box
screaming bloody murder. I haven't had any odd experiments running
for quite some time now.
A quick look at the top of /v
Matthew Dillon wrote:
> :Hence the NEW flag RFSTACK. Why would this be a bad thing? This would keep
> :the old behavior and allow much nicer new behavior. I didn't suggest
> :changing the old behavior. This would just greatly simplify things so all of
>
> I think Richard Seaman has it right:
On 22-Mar-99 Jordan K. Hubbard wrote:
> OK, so it seems everyone's found something to like and dislike about
> the new scheme. In that regard, it seems pretty much equivalent to
> the previous layout when that was first introduced. :)
If it makes you feel any better, I kind of like the new system
subscribe freebsd-current
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
>> >And you submit that this is an acceptable solution?
>>
>> Of course. The FreeBSD device name won't change (modulo implementation
>> bugs), and even when it does, changing the config file is easier than
>> changing /etc/fstab.
>
>Since this entire thread came about due to a device name change,
> >> >> I pass "foo" from 1:foo(2s1a)kernel in my version of the old boot
> >> >> blocks.
> >> >
> >> >And you determine "foo" how?
> >>
> >> I type it into the config file or the command line.
> >
> >And you submit that this is an acceptable solution?
>
> Of course. The FreeBSD device name won
OK, so it seems everyone's found something to like and dislike about
the new scheme. In that regard, it seems pretty much equivalent to
the previous layout when that was first introduced. :)
However, incremental refinement for this stuff has always been the
order of the day, so in that spirit, he
On Mon, 22 Mar 1999, Greg Lehey wrote:
> On Monday, 22 March 1999 at 0:54:12 +, Brian Feldman wrote:
> > Does anyone want a CPU_WT_ALLOC_DISABLE and CPU_WT_ALLOC_ENABLE as
> > separate
> > options? I see a couple changes that should be made to the kernel now:
> >
> > CPU: AMD-K6(tm) 3D pro
>> >> I pass "foo" from 1:foo(2s1a)kernel in my version of the old boot blocks.
>> >
>> >And you determine "foo" how?
>>
>> I type it into the config file or the command line.
>
>And you submit that this is an acceptable solution?
Of course. The FreeBSD device name won't change (modulo implement
On Monday, 22 March 1999 at 0:54:12 +, Brian Feldman wrote:
> Does anyone want a CPU_WT_ALLOC_DISABLE and CPU_WT_ALLOC_ENABLE as separate
> options? I see a couple changes that should be made to the kernel now:
>
> CPU: AMD-K6(tm) 3D processor (300.69-MHz 586-class CPU)
> Origin = "Authent
Does anyone want a CPU_WT_ALLOC_DISABLE and CPU_WT_ALLOC_ENABLE as separate
options? I see a couple changes that should be made to the kernel now:
CPU: AMD-K6(tm) 3D processor (300.69-MHz 586-class CPU)
Origin = "AuthenticAMD" Id = 0x58c Stepping=12
Features=0x8021bf
There should be ano
Any hope of the aic driver gracing -current anytime soon? I'm really itching
to port my burning software over.
Cheers,
--
Dan Moschuk (tfreak...@globalserve.net)
Senior Systems/Network Administrator
Globalserve Communications Inc., a Primus Canada Company
"If at first you don't succeed, redefin
> >> I pass "foo" from 1:foo(2s1a)kernel in my version of the old boot blocks.
> >
> >And you determine "foo" how?
>
> I type it into the config file or the command line.
And you submit that this is an acceptable solution?
--
\\ Sometimes you're ahead, \\ Mike Smith
\\ sometimes you're
>> I pass "foo" from 1:foo(2s1a)kernel in my version of the old boot blocks.
>
>And you determine "foo" how?
I type it into the config file or the command line.
Bruce
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
> >Correct. I was looking for a field in the disklabel that I could spam
> >with a suitable number based on the time from the RTC, and I'd then
>
> There isn't one. Especially when there is no disklabel or a read-only
> disklabel.
>
> >> Again, same objections... :-)
> >
> >Same solutions. P
>> >> - Peripheral driver to device routing
>> >
>> >Such as ?
>>
>> Such as the ability to have more than one driver share the
>> same device, command generation counts and priority queuing
>> to allow correct 'replay' of overlapped commands when an
>> error occurs, etc. See:
>>
>> http://www.f
>Correct. I was looking for a field in the disklabel that I could spam
>with a suitable number based on the time from the RTC, and I'd then
There isn't one. Especially when there is no disklabel or a read-only
disklabel.
>> Again, same objections... :-)
>
>Same solutions. Plus we'd be likely
> > However Justin's random number comment speaks back to a technique I was
> > working on earlier, where such a number would be secreted in the
> > disklabel of the disk to be booted. This number would have to be
> > generated in a fairly unique fashion (I planned to use the TOD to try
> > to kee
> I have a couple of 905B 3com cards. I'm interested in running diskless
> (especially since a harddisk in the one machine just died).
>
> After reading the handbook, I found the diskless information to be extreamly
> outdated. Does netboot now support the 905 line of 3com cards? (Any test
> dr
In message <84061.921771...@axl.noc.iafrica.com> Sheldon Hearn writes:
: 19990316:
: The name of the old wd.c and atapi.c based CDROM driver has
: been changed back to wcd. So update your config file to use
: "device wcd" instead of "device acd".
:
: Am I right in thinking
On Sun, 21 Mar 1999, Matthew Dillon wrote:
> :> If you are making a subroutine *call* to the rfork() routine, where
> :> do you think the return PC address is stored? On the stack. The
> :> rfork() routine is going to 'ret' *after* doing the rfork syscall.
> :> 'ret' pops the sta
:> If you are making a subroutine *call* to the rfork() routine, where
:> do you think the return PC address is stored? On the stack. The
:> rfork() routine is going to 'ret' *after* doing the rfork syscall.
:> 'ret' pops the stack. While this in itself is not modifying the stac
On Sun, 21 Mar 1999, Matthew Dillon wrote:
> :> :the assembly wouldn't be needed. Hmm... actually... if one were to mmap()
> a
> :> :stack and as soon as the rfork() returned movl newstack,%esp and whatnot,
> :> :wouldn't this be a pretty simple solution?
> :>
> :> No, because one of the pr
:> :the assembly wouldn't be needed. Hmm... actually... if one were to mmap() a
:> :stack and as soon as the rfork() returned movl newstack,%esp and whatnot,
:> :wouldn't this be a pretty simple solution?
:>
:> No, because one of the processes may overrun the stack before the other
:> one
On Sun, 21 Mar 1999, Matthew Dillon wrote:
> :Hence the NEW flag RFSTACK. Why would this be a bad thing? This would keep
> :the old behavior and allow much nicer new behavior. I didn't suggest
> :changing the old behavior. This would just greatly simplify things so all of
>
> I think Richard
:as the subject says, i recently noticed that the 'de' driver on 3.1
:machines seems not to update regularly the Opkt field as shown
:by netstat. I have seen this in two different ways; on a de-only
:machine, the count seems to be updated every few seconds (i.e. i see
:two-three times the same coun
as the subject says, i recently noticed that the 'de' driver on 3.1
machines seems not to update regularly the Opkt field as shown
by netstat. I have seen this in two different ways; on a de-only
machine, the count seems to be updated every few seconds (i.e. i see
two-three times the same count doi
:Hence the NEW flag RFSTACK. Why would this be a bad thing? This would keep
:the old behavior and allow much nicer new behavior. I didn't suggest
:changing the old behavior. This would just greatly simplify things so all of
I think Richard Seaman has it right: the stack needs to be passed.
On Sat, Mar 20, 1999 at 11:43:14PM -0800, Matthew Dillon wrote:
> :For the suggest something, you realize that with Richard's VM_STACK code it
> :should be relatively trivial to make this automatic (suggestion: add
> :RFSTACK flag).
> :
> : Brian Feldman _ _
Daniel,
I'm guessing here, but check your existing make.conf file in /etc
against the one in /usr/src/etc/make.conf. I know the newer one
has an option MAKE_KERBEROSIV. See if that helps...
As far as how to start where it failed, I have no idea..SORRY.
I would like to know that myself.
later
Mi
On Sunday, 21st March 1999, Richard Wackerbarth wrote:
>Why do we need to have ANY of the file inclusion in /etc/defaults/rc.conf?
>Shouldn't that file simply be definitions of variables?
>IMHO, the "logic" should be in "rc" itself.
Yeah! What he said!
Having code in rc.conf sucks. If there is
On Sun, Mar 21, 1999 at 12:48:07AM -0800, Matthew Dillon wrote:
> This is an example only. It takes a *BUNCH* of arcane assembly to make
> it work.
>
> I would suggest *EXTREME* caution when using a completely cloned address
> space such as RFPROC|RFMEM generate. Normal library c
On Sat, 20 Mar 1999, Matthew Dillon wrote:
>
> :> > rfork(RFMEM) doesn't easily work from C. You need to
> :> > create an assembly stub.
> :> >
> :> > --
> :> > John | Never try to teach a pig to sing,
> :> > dy...@iquest.net | it makes one look stupid
> :> > jdy...@nc.co
Hiho,
I'm using a 3.1-STABLE system, up to date with a current
CVS-tree.
No I would like to install a few other boxes as well, so I
thought 'make release' would be the thing.
I set the RELEASETAG to RELENG_3,
make release then seems to run fine, until it wants to
build kerberosIV. This fails wi
Leif Neland writes:
> Will frontpage (fp30.bsdi3.tar.Z) run on current 4.0?
Only if your kernel is configured for a 256 MB address space. See
section 13.15 in the FAQ for instructions on how to do this.
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to majord...
Leif Neland wrote:
>
> But fpsrvadm.exe just dumps core when make install runs.
>
> So is current 4.0 and fp30 compatible?
>
Some mods were recently committed to cater for support of large (in
terms of RAM) systems; these break BSDI compatibility and might be the
root of your problems.
Best Re
A quick crossposted letter; continue in the most appropriate group at your
choice.
Will frontpage (fp30.bsdi3.tar.Z) run on current 4.0?
I tried building apache13-fp from the ports.
I had to edit apache's configure to accept the parameter i386--freebsd4.0
(I guess it should be i386-unknown-freeb
Why do we need to have ANY of the file inclusion in /etc/defaults/rc.conf?
Shouldn't that file simply be definitions of variables?
IMHO, the "logic" should be in "rc" itself.
On Sat, 20 Mar 1999, Scot W. Hetzel wrote:
> What does everyone think about using this at the end of
> /etc/defaults/rc.c
It seems Christopher J. Michaels wrote:
> Well, I'm sorry to say that it looks like I've found the answer to my own
> question. I found after this posting (by looking at dmesg) that I was
> getting the following error.
> acd0: rezero failed
>
> I did some searching and found several posting
It seems Justin T. Gibbs wrote:
> >> My main complaint so far about the new ATAPI stuff is that it duplicates
> >> or lacks (assuming it will be implemented) much of what CAM would have
> >> given for almost free:
> >>
> >> - Interrupt driven configuration
> >
> >That there allready, if we mean th
It seems Mike Smith wrote:
> > > But hey, I don't have the time to work on ATAPI. Soren does, so he gets
> > > to call the shots.
> >
> > Right :)
>
> ... so we lose. 8(
Well, depends on POV I guess...
> Soren, please take a little time to understand what Justin is talking
> about. The part
This is an example only. It takes a *BUNCH* of arcane assembly to make
it work.
I would suggest *EXTREME* caution when using a completely cloned address
space such as RFPROC|RFMEM generate. Normal library calls cannot be made
by the child safely. Thread libraries will also
44 matches
Mail list logo
