:> > 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 irritates the pig.
:> >
:>
:> I've seen
On Sun, 21 Mar 1999, Alfred Perlstein wrote:
> On Sat, 20 Mar 1999, John S. Dyson wrote:
>
> > Michael E. Mercer said:
> > > Hello,
> > >
> > > This was posted to freebsd-questions with no reply.
> > > I tried this and the child process created a core file.
> > > I also tried the other options a
> Is there any IPSEC support available for current? I've found support for
> 2.2.8, but not so far for current.
KAME has support for 3.1-RELEASE. I don't know how far -current has
diverged, but you might want to try www.kame.net. KAME is IP6 and IPSEC,
but you can compile it with only IPSEC.
Y
> On Sat, 20 Mar 1999, John S. Dyson wrote:
>
> > Michael E. Mercer said:
> > > Hello,
> > >
> > > This was posted to freebsd-questions with no reply.
> > > I tried this and the child process created a core file.
> > > I also tried the other options and they seem to work.
> > > Just RFPROC and RF
On Sat, 20 Mar 1999, John S. Dyson wrote:
> Michael E. Mercer said:
> > Hello,
> >
> > This was posted to freebsd-questions with no reply.
> > I tried this and the child process created a core file.
> > I also tried the other options and they seem to work.
> > Just RFPROC and RFMEM DON'T!
> >
>
John,
With very little experience in assembly, could you or
someone else give me a small example?
Thanks in advance,
Michael Mercer
"John S. Dyson" wrote:
>
> Michael E. Mercer said:
> > Hello,
> >
> > This was posted to freebsd-questions with no reply.
> > I tried this and the child process c
Michael E. Mercer said:
> Hello,
>
> This was posted to freebsd-questions with no reply.
> I tried this and the child process created a core file.
> I also tried the other options and they seem to work.
> Just RFPROC and RFMEM DON'T!
>
rfork(RFMEM) doesn't easily work from C. You need to
create
Hello,
This was posted to freebsd-questions with no reply.
I tried this and the child process created a core file.
I also tried the other options and they seem to work.
Just RFPROC and RFMEM DON'T!
Thanks,
Michael Mercer
Can any one suggest how to use rfork( RFPROC | RFMEM
On Sat, 20 Mar 1999, Scot W. Hetzel wrote:
> If someone does copy the /etc/defaults/rc.conf to /etc/rc.conf, /etc/rc.conf
> will not reload it's self, thus it will never get stuck in an endless loop.
Oh it's too late for that. :)
- alex
To Unsubscribe: send mail to majord...@freebsd.org
with
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 out th
>> 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.
Right. Its duplicated fun
"Scot W. Hetzel" writes:
>if [ $0 != $i ]; then
A more generic fix is for each script to set an environment variable,
and check to make sure that variable was not set already. Analogous to
how C include files prevent recursive inclusion.
--
Rahul Dhesi
To Unsubscribe: send mail to major
What does everyone think about using this at the end of
/etc/defaults/rc.conf?
for i in ${rc_conf_files}; do
if [ $0 != $i ]; then
if [ -f $i ]; then
. $i
fi
else
echo "Error: $0 isn't allowed to re-load $i."
echo "Error: Please do not cop
Hi!
For a couple weeks for now i have a broken world with following reason:
===> usr.sbin/i4b/isdnd
cc -O -pipe -I/usr/src/usr.sbin/i4b/isdnd/../isdnmonitor
-I/usr/src/usr.sbin/i4b/isdnd/../isdntel
-I/usr/obj/usr/src/usr.sbin/i4b/isdnd -DDEBUG -DUSE_RTPRIO -DUSE_CURSES
-I/usr/obj/usr/src/tmp/usr/
>
> > > The major number passed to the kernel is a product of a lot of
> > > guesswork, because the loader has simply not enough information. I
> > > have added a bit of code to my version of loader so you can use the
> > > variable root_device_major_number to override the major number to be
> > >
Mike Smith wrote:
>
> > The major number passed to the kernel is a product of a lot of
> > guesswork, because the loader has simply not enough information. I
> > have added a bit of code to my version of loader so you can use the
> > variable root_device_major_number to override the major number t
> > The major number passed to the kernel is a product of a lot of
> > guesswork, because the loader has simply not enough information. I
> > have added a bit of code to my version of loader so you can use the
> > variable root_device_major_number to override the major number to be
> > passed to t
> The major number passed to the kernel is a product of a lot of
> guesswork, because the loader has simply not enough information. I
> have added a bit of code to my version of loader so you can use the
> variable root_device_major_number to override the major number to be
> passed to the kernel.
> > 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(
Soren, please take a little time to understand what Justin is talking
about. The parts of CAM that are relevant to you are the queueing
support, infrastructure,
Aye, and my LS-120 works great too :) So, que sera sera.
Brian Feldman_ __ ___ ___ ___
gr...@unixhelp.org _ __ ___ | _ ) __| \
http://www.freebsd.org/ _ __ ___ | _ \__ \ |) |
FreeBSD: The Power to Serve!
Ok I've been playing around a bit, an iso sized file (500-600mb) seems to
trigger it, and a quite small file seemed to do it too but I forgot which
one, but just now I made a one byte file and vnconfig'ed it and that
paniced. Please try that if you can :) btw I tried a 32mb file like you,
also a 16
I submitted a PR.
This is not a show-stopper. I have a system running 2.2.7. fd works
on that one. So, I read/write floppies there. It is a pain, though.
tomdean
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
:I seem to be able to reproduce a panic on my 4.0 machine (updated
:yesterday, kernel and world, also could crash with a somewhat older
:build)
:
:I have pseudo-device vn and nfs in my kernel, not as a module.
:
:When I vnconfig -c /dev/vn0c /nfsmountpoint/somefile, the system panics
:reliably.
> > The core files from the panic seem to be useless -- I can't get anything
> > useful out of ``where'' with a kernel w/debugging symbols:
>
> Link CD9660 support statically, instead of using the KLD module.
First thing I tried. :-) Bruce's vfs_bio.c fix was the trick.
--
-- David(obr..
It's been a couple more weeks, anyone now know why fd(4) is broken? It's
really not a good thing :(
Brian Feldman_ __ ___ ___ ___
gr...@unixhelp.org _ __ ___ | _ ) __| \
http://www.freebsd.org/ _ __ ___ | _
"Søren Schmidt" wrote:
>
> > there certainly is a way to work out the name. Perhaps in the autoboot
> > case you'll have to guess, but it would be nice if the current boot
> > mechanism allowed user intervention as a way to boot a kernel with an
> > unknown bdev.
>
> YES!! can we please have th
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 -current that said my
drive, a MITSUMI CR-260
I seem to be able to reproduce a panic on my 4.0 machine (updated
yesterday, kernel and world, also could crash with a somewhat older
build)
I have pseudo-device vn and nfs in my kernel, not as a module.
When I vnconfig -c /dev/vn0c /nfsmountpoint/somefile, the system panics
reliably.
If ther
"David O'Brien" writes:
> The core files from the panic seem to be useless -- I can't get anything
> useful out of ``where'' with a kernel w/debugging symbols:
Link CD9660 support statically, instead of using the KLD module.
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe:
>I half suspect that what Justin had in mind at some point was a set of common
>code that is either #ifdef'ed or otherwise preprocessed to produce a
>standalone 'SCSI-CAM' system versus an 'ATA[PI]-CAM' system. This would
>have the advantage of having all the common code together in one place and
"Steven P. Donegan" wrote:
>
> Is there any IPSEC support available for current? I've found support for
> 2.2.8, but not so far for current.
There is support for 3.1-REL. Work is being done for -current, I
believe.
Keep an eye on http://www.r4k.net/ipsec
Alex
--
+-
>I half suspect that what Justin had in mind at some point was a set of common
>code that is either #ifdef'ed or otherwise preprocessed to produce a
>standalone 'SCSI-CAM' system versus an 'ATA[PI]-CAM' system.
I .75 suspect that such a marriage would be caused by the second
systems syndrome and
Soren Schmidt wrote:
> It seems Justin T. Gibbs wrote:
> > In article <199903171205.naa25...@freebsd.dk> you wrote:
> > > It seems David O'Brien wrote:
> > >> > Boot from an ata disk on major# 30, device name "ad", plain and simple
.
> > >>
> > >> Does this mean ata disks won't come under CAM/
Bob Willcox wrote:
> I have an LS-120 and I'd be happy to test the new boot code with it.
>
>
> Bob
>
Thanks very much. I'll contact you and Andrzej when the changes
are made.
--
Robert Nordier
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the bo
Søren Schmidt wrote:
> It seems Justin T. Gibbs wrote:
> > >> Why not have the boot blocks pass in a device 'name' rather than a
> > >> major number. If the goal is to ditch major numbers entirely with
> > >> a properly working DEVFS, then using major numbers in the new boot
> > >> loader seems t
It seems Justin T. Gibbs wrote:
> >> In article <199903171103.naa13...@ceia.nordier.com> you wrote:
> >> > Søren Schmidt wrote:
> >> >
> >> >> OK, easy enough, this is what I want to do:
> >> >>
> >> >> Boot from an ata disk on major# 30, device name "ad", plain and simple.
> >> >
> >> > I'd b
It seems Justin T. Gibbs wrote:
> In article <199903171205.naa25...@freebsd.dk> you wrote:
> > It seems David O'Brien wrote:
> >> > Boot from an ata disk on major# 30, device name "ad", plain and simple.
> >>
> >> Does this mean ata disks won't come under CAM/da ?
> >
> > Not if I can help it :)
>> In article <199903171103.naa13...@ceia.nordier.com> you wrote:
>> > Søren Schmidt wrote:
>> >
>> >> OK, easy enough, this is what I want to do:
>> >>
>> >> Boot from an ata disk on major# 30, device name "ad", plain and simple.
>> >
>> > I'd be inclined to handle this outside the boot code,
In article <199903171205.naa25...@freebsd.dk> you wrote:
> It seems David O'Brien wrote:
>> > Boot from an ata disk on major# 30, device name "ad", plain and simple.
>>
>> Does this mean ata disks won't come under CAM/da ?
>
> Not if I can help it :)
> It could be done by slamming a translation l
39 matches
Mail list logo
