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 layer ontop of
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, by treating the
passed in
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 :)
It could be done
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 be inclined to handle this outside the
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 to be the wrong
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 body of
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/da ?
Not if I
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
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. This would
have the advantage of having all the common code together in one place and
David O'Brien obr...@nuxi.com 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
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
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
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 that ??
As I
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/ _ __ ___ |
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
: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.
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
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
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!
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, and
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. I'm
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
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 to be
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
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
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 copy
Scot W. Hetzel hetz...@westbend.net 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
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 functionality.
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
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
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 |
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 an
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 created a
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!
rfork(RFMEM)
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!
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.
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 and they seem to
: 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 about 6 people
39 matches
Mail list logo
