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
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 parts of CAM that
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 the same thing here.
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 postings in
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.conf?
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
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
Leif Neland r...@neland.dk 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
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
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.com | and it
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 calls
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 no
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
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 _ __
: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.
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
: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
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
: :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:
: :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
: 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 stack,
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 stack.
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 that
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
drivers
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 keep it from
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 to
- 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:
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
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
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 behind.
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,
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
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 = AuthenticAMD
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 implementation
bugs), and
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 processor
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,
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 implementation
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, and
given
subscribe freebsd-current
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
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
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: the
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
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,
: :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 function,
44 matches
Mail list logo
