or certain
systems, I'm still waiting for some feedback on that.
Either way, I have a patch which I need to burn in in my lab, but
right now I have a hard time getting my SMP box to even print out
"Copyright..." when it boots :-(
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3
genius.systems.pavilion.net 5.0-CURRENT FreeBSD 5.0-CURRENT #11: Tue Sep 5
12:45:45 BST 2000 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENIUS
i386
On Mon, Sep 04, 2000 at 06:41:14PM +0200, Poul-Henning Kamp wrote:
I'm looking for the remaining victims of the dreaded "microuptime
TAILQs.
Various nitpicking here and there.
The patch to i386/include/atomic.h is taken from SMPng to which
I added atomic_cmpset_ptr().
--
With this patch DEVFS has the features and properties it should
have with respect to the "main mount".
--
Poul-Henning Kamp
"i8254" /* name */
};
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail
even referenced by
the conf file.
What does everyone think?
Make it a port...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained
In message [EMAIL PROTECTED], John Baldwin writes:
Poul-Henning Kamp wrote:
If I boot this machine on a -current kernel, it doesn't find the
fxp#'s at all:
Do you have Peter's latest commits to pci/pci.c pci/pcisupport.c and
i386/isa/pcibus.c? Without that, mulitple PCI busses is b0rked
?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubs
udmamode=4 cblid=1
Works with tagged queueing:
ad1: IBM-DJNA-351520/J56OA30K ATA-4 disk at ata1-master
ad1: 14664MB (30033360 sectors), 29795 cyls, 16 heads, 63 S/T, 512 B/S
ad1: 16 secs/int, 31 depth queue, tagged UDMA66
ad1: piomode=4 dmamode=2 udmamode=4 cblid=1
--
Poul-Henning Kamp |
0
ad0: 9768MB ST310212A [19846/16/63] at ata0-master using UDMA66
Mounting root from ufs:/dev/ad0s1a
ttt#
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice wha
, or
is there a new problem in sys/conf.h?
To me, it looks like sys/conf.h should pull sys/time.h in for
itself, although I understand that pollution comes along with that.
Ciao,
Sheldo.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD
ng "almost cloning).
WARNING: Not tested!
Wed Aug 30 23:27:05 CEST 2000
---
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to
this?
Hmm, which exact names are you missing ?
Have you tried accessing them directly, for instance:
ls -l /dev/da0s2e
or whatever their names are ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since
In message [EMAIL PROTECTED], Matthew
Jacob writes:
On Mon, 28 Aug 2000, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Matthew
Jacob writes:
I compiled and booted on alpha. It sees my ad0 now. Plus it also sees the 3
'da' disks that were found.
The only real problem
]. I mostly
was raising this to see if someone else has tried alpha in this regard.
If not- I can help debug this and fix it, but next week.
Hmm, can you send me a ls -l /dev from a !devfs alpha so I can
see what it looks like ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL
In message [EMAIL PROTECTED], Sheldon Hearn writes:
On Sun, 27 Aug 2000 21:35:26 +0200, Poul-Henning Kamp wrote:
Do you have devfs in /etc/fstab ? That is *not* needed, /sbin/init
will mount devfs on /dev automatically.
Out of curiosity, what's the motivation behind this decision? Why
added device nodes after boot where dev_mkdb
was run.
I think the DTRT solution is a sysctl where kern_conf.c can answer
the question.
It's on my list.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3
d solution for this can be found in the bio/buf paper
I wrote.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To U
In message [EMAIL PROTECTED], Boris Popov
writes:
On Fri, 18 Aug 2000, Poul-Henning Kamp wrote:
Missing:
Rename
Subdirs.
Close some race conditions using guaranteed atomic operations.
Mountoption (ro ?) to prevent new devices from appearing in an instance
that was the point
of my work on fdescfs.
I'm not quite ready to embrace fdescfs yet, I want to get devfs
fully debugged first.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what
? That is *not* needed, /sbin/init
will mount devfs on /dev automatically.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incomp
There is an official DEVFS patch at
http://phk.freebsd.dk/patch/devfs.patch
This incorporates the functional bits from the patch Boris posted
here earlier as I've been able to extract them from his patch.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED
12, 1 Dec 31 1969 ttyv1
crw--- 1 root wheel 12, 2 Dec 31 1969 ttyv2
crw--- 1 root wheel 12, 3 Dec 31 1969 ttyv3
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
In message [EMAIL PROTECTED],
Siobhan Patricia Lynch writes:
On Wed, 23 Aug 2000, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED],
Siobhan Patricia Lynch writes:
this is cute:
notice the dates, they predate the epoch.
Because of your timezone.
nod, figured that out already
In message [EMAIL PROTECTED], Sheldon Hearn writes:
On Sat, 19 Aug 2000 21:26:24 +0200, Poul-Henning Kamp wrote:
Ahh, right, this is something else than I thought: These are
symlinks in the normal case, for instance:
/dev/audio - /dev/audio0
What's the plan for things like
/dev/fd*
ls -l /dev/fd0a
ls -l /dev/fd0.1200
ls -l /dev/fd*
Have fun,
Sorry it's taken so long to get to here...
Poul-Henning
In message [EMAIL PROTECTED], Poul-Henning Kamp writ
es:
phk 2000/08/20 14:34:39 PDT
Modified files:
sys/c
E3DC660AE0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
In 84513.966631292@critter, Poul-Henning Kamp [EMAIL PROTECTED]
wrote:
Please look at, test and review:
http://phk.freebsd.dk/patch/devfsIII.patch
[...]
When booting the kernel built from a sys tr
Ok, I belive this one is fixed now, please try again.
Poul-Henning
In message [EMAIL PROTECTED], Robert Drehmel writes:
In 84513.966631292@critter, Poul-Henning Kamp [EMAIL PROTECTED]
wrote:
Please look at, test and review:
http://phk.freebsd.dk/patch/devfsIII.patch
[...]
When
y
$ ps
ps: proc size mismatch (8448 total, 1048 chunks)
$
"""
This is the usual excercise with recompiling libkvm, ps, top and
friends when certain central kernel structures changes size.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP
In message [EMAIL PROTECTED], Robert Drehmel writes:
In 86054.966696645@critter, Poul-Henning Kamp wrote:
Ok, I belive this one is fixed now, please try again.
Yes, it boots. But when using a kernel with ``options DEVFS'',
there is no /dev/audio or /dev/mouse, for example; devfs has
mounted
In message [EMAIL PROTECTED], Robert Drehmel writes:
In 86054.966696645@critter, Poul-Henning Kamp wrote:
Ok, I belive this one is fixed now, please try again.
Yes, it boots. But when using a kernel with ``options DEVFS'',
there is no /dev/audio or /dev/mouse, for example; devfs has
mounted
md(4), tun(4), bpf(4)
If DEVFS add -d flag to /sbin/inits args to make it mount devfs.
Add commented out DEVFS to GENERIC
-- end --
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-t
In message [EMAIL PROTECTED], Boris Pop
ov writes:
On Wed, 16 Aug 2000, Poul-Henning Kamp wrote:
Please test and review this patch:
http://phk.freebsd.dk/patch/vop_stdaccess.patch
Looks fine to me except vop_stdaccess() itself. Since VREAD,
VWRITE and VEXEC bits are carefully layed
guidance,
and a double-check to see if I have messed up on the expected
behaviour might be in order (look for "prison").
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute
syv# make -k
linking kernel
umodem.o: In function `umodem_set_line_coding':
umodem.o(.text+0xe6a): undefined reference to `memcmp'
*** Error code 1 (continuing)
`all' not remade because of errors.
syv#
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP
Linecount: removes: 243 adds: 79 net change: -164
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe:
/hpfs/../../fs/hpfs/hpfs_vnops.c:89: warning: `hpfs_abortop' used
but never defined
*** Error code 1
Stop in /syv/s0/sys/modules/hpfs.
syv#
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never
n't needed.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
on before proceeding.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL
ouptime()
(depending on it being UTC locked or not).
This has also always been the case.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be expla
In message [EMAIL PROTECTED], "David O'Brien" writes:
Quite sorry, my contrib/gdb/ activities were suppose to be sheilded from
users.
And vice-versa I pressume :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coret
, nvp);
if (error) {
*vpp = NULLVP;
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
install
a hostroute to the other end when it is reachable.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Un
to give you more randomness.
In other words, and more bluntly: Please shut up now, will you ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately
In message [EMAIL PROTECTED], Kri
s Kennaway writes:
On Sun, 23 Jul 2000, Poul-Henning Kamp wrote:
Obviously, if you need more randomness than a stock FreeBSD system
can provide you with, you add hardware to give you more randomness.
This won't help if it's fed through Yarrow.
Nobody has
lar I fear that the current implementation already has
killed battery lifetimes on laptops :-(
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be
with some kernel option which can
be used to get a copy of the entropy so we can study the quality
off it.
BTW: You have *no* idea how much I envy your access to high quality
timing hardware :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
offsets as you. What does that give him? Not much, but it
could reduce the bits that he needs to guess. By how much? I don't
know.
Mark, this is one of the reasons why we need a way to measure the
quality of our entropy, please
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL
ause.
You forget; a snooper watching your (ether)net has access to nearly
all of this information.
No, he doesn't have access to the offset from the machines local clock.
I ran a quick dirty test here on some logfiles: that offset is
very close to white noise.
--
Poul-Henning Kamp | UNIX s
about your hardware, he cannot predict
all bits.
If he could, ntp would have a longer poll period :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be
:-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED
ight after install.
Principle of "tools, not politics": You can configure it stupidly if
you want, you can also strengthen it beyond practical use if you want.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member |
noise amplitude?
What do you mean by "amplitude" ? The frequency deviation ?
The phase error ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can
t;, measured
in bits.
OK, then the answer is: "a couple of bits"
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incomp
is that we compare the received data
with our unpredictable local clock. It is the result of this comparison
which is good entropy bits.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never
In message [EMAIL PROTECTED], Vadim Belman writes:
On Mon, Jul 17, 2000 at 04:14:50PM +0200, Poul-Henning Kamp wrote:
NTP is the perfect way to gather entropy at bootup!
Only if in reach of an NTP server ?
Obviously :-)
And what if no network at all?
Your need for random
clients. At least some of the clients are being treated as
untrusted (consider public terminals) and server has some critical
information on it.
Nobody talked about relying on *only* NTP for entropy, quite the
contrary in fact.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL
, the output from getnanotime()
is not very random at all, unless you dive into the timecounter
code to find out what the parameters are.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never
ught about adding a entropy server to my array of weird
servers in my lab. Something like a Geiger counter and a smokedetector
could do wonders.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
In message [EMAIL PROTECTED], Alexander Langer writ
es:
Thus spake Poul-Henning Kamp ([EMAIL PROTECTED]):
I have thought about adding a entropy server to my array of weird
servers in my lab. Something like a Geiger counter and a smokedetector
could do wonders.
HA! Cool!
Do that please!
I
In message [EMAIL PROTECTED], "Steve O'Hara-Smith" writes
:
On 17-Jul-00 Poul-Henning Kamp wrote:
NTP is the perfect way to gather entropy at bootup!
Only if in reach of an NTP server ?
Obviously :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL
think we first need to figure out the security implications.
I think the security implications of having no entropy are much
worse than having entropy which a truly superhuman *maybe* could
guess *some* of the bits in, are far worse.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROT
ght On Top ...
After searching the freebsd-current mailling list i located the bit about
malloc.conf
ln -sf j /etc/malloc.conf --- fixed the problems i was having
No, not "fixing the problems", "obscuring the problems".
The tintin++ code contains errors, and you should f
In message [EMAIL PROTECTED], "Thomas D. Dean" writes:
I turned off the malloc AJ flags, via malloc.conf. It improved 'make
world' by something like 17% == mean_aj/mean_AJ.
Make sense, make world is dominated by gcc/cc1 which is doing a
lot of malloc/free operations.
--
Poul-He
it if you want to run benchmarks:
ln -sf aj /etc/malloc.conf
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
he install menu came up.
That has been fixed.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe:
'A' option of phkmalloc and examine the core.
ln -sf A /etc/malloc.conf
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by in
In message [EMAIL PROTECTED], Kri
s Kennaway writes:
I intend to MFC this stuff in 4 or 5 days assuming it doesn't present any
problems,
I'm sorry, but isn't that a tad fast, considering the scope of these
changes ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED
consensus for moving filesystems
under /sys/fs but not for moving net*. The reason for the difference
in concensus is probably that net* is a systematic prefix.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since
executable version (5.00503) at Config.p
m line 18.
*** Error code 255
Stop in /syv/src/gnu/usr.bin/perl/perl.
*** Error code 1
Stop in /syv/src/gnu/usr.bin/perl.
*** Error code 1
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD
In message [EMAIL PROTECTED], Matthew Dillon writes:
:
:Right, but if mounting with -osoftdep, does what a "tunefs -n enable"
:does (and vice versa) fsck will have that knowledge and the tunefs
:step would be un-needed.
:
:--
:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
).
This one was a misunderstanding, in fact vinum/raid5 works more
reliably with softupdates than without I belive.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice
it to the new state.
Right, but if mounting with -osoftdep, does what a "tunefs -n enable"
does (and vice versa) fsck will have that knowledge and the tunefs
step would be un-needed.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBS
me to
'ffs' in the kernel and in the userland? If not, I'll volunteer to
find all kernel/userland uses I can and provide a diff.
The correct way to do this is to make it accept both for some
limited time, and then warn about the obsolete for a few months,
then discontinue it.
--
Poul-Henning Kamp |
Am I the only person who miss a brief document which tells what
the outcome of the meeting was ?
Can we get to see the slides ?
Audio ?
Video ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3
not sure now is the time to do it either.
So: No I don't like -current being toast anymore than you do, but
I don't think there is a viable alternative.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3
In message [EMAIL PROTECTED], Warner Losh writes:
In message [EMAIL PROTECTED] Poul-Henning Kamp writes:
: I think core has approved in principle, and several core members
: were present at the meeting (at least peter, dg, gibbs, dfr), that
: being said, I think we need to see some more concrete
In message [EMAIL PROTECTED], Brian Somers writes:
What about doing the changes on a branch with the understanding that
the branch will *replace* HEAD when it stabilises ?
"CVS branches suck" is the reason I belive.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL
, and Matt Dillon's webpage gives a pretty good summary of
the work too (at http://apollo.backplane.com/FreeBSDSmp/)
But we're not looking for a summary of the meeting, we're looking
for all the gory details...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP
- read there" I/O registers in existence.
Obviously the video driver will need to send a signal or clue to the
Xserver saying "you own the device, you'd better do something"
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
In message [EMAIL PROTECTED], "Daniel O'Connor" write
s:
On 15-Jun-00 Poul-Henning Kamp wrote:
Remove the "wd" compatibility name from the "ad" driver.
WARNING: If you have not updated to use /dev/wd* in your /etc/fstab
You mean 'If you have not update
, I'm not sure it is correct to go the detour around Vnodes,
if we do, we need to add VOP_BAWRITE, VOP_BDWRITE and all those
other operations as well.
But what vnode would you use for a buffer associated with a freeblock
bitmap ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL
--- Forwarded Message
Message-Id: [EMAIL PROTECTED]
From: Poul-Henning Kamp [EMAIL PROTECTED]
Date: Thu, 15 Jun 2000 13:30:53 -0700 (PDT)
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: cvs commit: src/sys/dev/ata ata-disk.c src/sys/i386/i386
autoconf.c src/sys/kern subr_disk.c
}
}
splx(s);
- return (UFS_UPDATE(vp, wait));
+ error = UFS_UPDATE(vp, wait);
+ if (error == 0 vp-v_mount (vp-v_mount-mnt_flag MNT_SOFTDEP))
+ error = softdep_fsync(vp);
+ return (error);
}
--
Poul-Henning Kamp | UNIX since Zi
.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubs
.
I have yet to see any signs of "massive breakage".
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetenc
commit hiding the fact that this is
"(elm)-field.sle_next". Anyway, curelm must be a pointer to a struct.
Not just any struct; the struct must contain a "field" declared using
SLIST_ENTRY().
It could be an union or class as well...
--
Poul-Henning Kamp | UNIX since Zi
to back this out.
I'm for.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL
g new read/write/poll/ioctl/etc
routines?
I ask, as my RNG is a kld, and I want it to be as separate as possible
without getting ridiculous.
make_dev() takes a pointer to your struct cdevsw{} for this particular
minor.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED]
the other crap?
If so, way cool!
yes, enjoy :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send
into this before.
Which host are you pilling from? I am slurping things out of
cvsup.uk.freebsd.org and see the same messages. I thought it was crappy
modem connection.
Try to disable the newreno stuff.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since
in src/bin/csh a make clean tries to delete csh.1 this fails if
src is mounted Read-Only.
Why is this file checked in in the first place if make clean wants
to remove it ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam
it with real floppies up until
the point where we went to two-floppy install...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by
of dev_t's get an error because the device has gone away.
destroy_dev will clear the necessary fields in a dev_t, cdevsw_remove
will not.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never
).
disk_destroy is different from destroy_dev, and I'll get to it real soon.
Also, while you still can, that should be dev_destroy().
No, because the corresponding is called make_dev().
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD
program and see if that stops the warning Manfred ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe
he problem when I cvsup over a lossy line, goes
away when newreno is disabled.
Who wants packet traces to look at ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malic
should use.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED
t.
Make it
MAKEDEV -num_of_devs dev_name
and there will be no ambiguity.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by i
describe it with some debugging added.
Thanks for the hint!
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
In message [EMAIL PROTECTED], Dan Nelson writes:
In the last episode (May 08), Poul-Henning Kamp said:
In message [EMAIL PROTECTED], Erik de Zeeuw writes:
I installed FreeBSD 5.0-2506-CURRENT on an AMD K6-2, 64Mb, 4Gb, and
when I first launch /stand/sysinstall after the system has start
1101 - 1200 of 1649 matches
Mail list logo
