agree. Chart me up in the "kernel architecture" category
and lets find somebody else do the PR writing...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malic
th sending a Fore and a efficient card
to our new maintainer if we get one...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by in
t resulted in. Sometimes ascii is the right API.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail
Are there anybody out there playing with LonWorks and FreeBSD ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
In message [EMAIL PROTECTED], Dennis writes:
It seems that only 256 bpf devices are supported. How painful would it be
to increase that number...I assume its an 8bit varable somewhere? Are there
other caveats?
It's pretty trivial. Send a patch when you are done.
--
Poul-Henning Kamp
In message [EMAIL PROTECTED], Dennis writes:
At 01:32 PM 03/28/2001, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Dennis writes:
It seems that only 256 bpf devices are supported. How painful would it be
to increase that number...I assume its an 8bit varable somewhere
ntries can be negative
entries. You can monitor the number of negative entries with the
sysctl
debug.numneg: 305
the value of "16" was rather arbitrarily chosen and better defaults
may exist.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP s
,
involving creation of vnode and very likely a vm object again.
We can safely say that you cannot profitably _increase_ the size of
the namecache, except for the negative entries where raw statistics
will have to be the judge of the profitability of the idea.
--
Poul-Henning Kamp | UNIX since
the underlying vnode.
Right, but doing so means that to refind that vnode from the name
is (comparatively) very expensive.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what
) very expensive.
:
:--
:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
:[EMAIL PROTECTED] | TCP/IP since RFC 956
The only thing that is truely expensive is having to physically
scan a large directory in order to instantiate a new namei
record. Everything else is inexpensive
in the
cache_purgeleafdirs(), considering how often it is called,
Do you have measured the performance impact of this to be an
insignificant overhead ?
Once we have that figured out I will commit the patch for you...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP
uot;vmstat -vm" ?
That is entirely different from the vfs-namecache, I think it is
a per process one-slot directory cache. I have never studied it's
performance, but I belive a good case was made for it in the 4.[34]
BSD books.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL
er tonight.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL
vnode * + v_id).
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "
"soft references" using "struct vnode * + v_id).
:
:--
:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
I don't think NFS relies on vnodes never being freed.
It does, in some case nfs stashes a vnode pointer and the v_id
value away, and some time later tries to use that pair t
: if (vpid == vp-v_id
:nfs_vnops.c:vpid = newvp-v_id;
:nfs_vnops.c:if (vpid == newvp-v_id) {
:
:--
:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
hahahahahahahaha.. Look at the code more closely. v_id is not
managed by NFS
way of dealing with
it for remote operations, but the trouble is that it prevents us from
ever lowering their number again.
If Matt can device a smart way to loose the soft reference in nfs,
vnodes can be a truly dynamic thing.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL
worries in trying to change that.
The namecache can do without the use of soft references.
The only reason vnodes are stable storage any more is that NFS
uses soft references to vnodes.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
n it is OK
for you to commit it yourself.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail
reference.
Well, if that's the case, yank all uses of v_id from the nfs code,
I'll do the namecache and vnodes can be deleted to the joy of our users...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
In message [EMAIL PROTECTED], Kirk McKusick writes:
Every vnode in the system has an associated object.
No: device vnodes dont...
I think the correct solution to that is to move devices away from
vnodes and into the fdesc layer, just like fifo's and sockets.
--
Poul-Henning Kamp | UNIX
In message [EMAIL PROTECTED], Rober
t Watson writes:
On Wed, 18 Apr 2001, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Kirk McKusick writes:
Every vnode in the system has an associated object.
No: device vnodes dont...
I think the correct solution to that is to move devices
argument of them
all for doing this...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail
In message [EMAIL PROTECTED], Julian Elischer writes:
If we merged vnodes and vm objects,
then if devices were not vnodes, how would you represent
a vm area that maps a device?
You would use a VM object of course, but it would be a special
kind of VM object, just like today...
--
Poul-Henning
ll devices are handled by a magic
filesystem (specfs) in the same "orphan" mode by all filesystems
which support devices is another good reason.
I think I'll kick back tonight and try to see what it actually
takes to do it...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROT
*should* run
through the VM object first:
We guarantee that today my mapping the actual hardware and my having
all read/writes be synchronouse. I remember at least one other
UNIX which didn't make that guarantee.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED
resolution.
The pps driver implements the RFC2783 PPS-API for timestamping
external events.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately
In message [EMAIL PROTECTED], Warner Losh writes:
In message 60546.987709317@critter Poul-Henning Kamp writes:
: Use the pps driver and you get microsecond jitter with nanosecond
: resolution.
While I usually see microsecond jitter, I have seen it as high as a
few milliseconds when the interrupt
demed nice proof of concept but not the right way ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe
In message [EMAIL PROTECTED], Dennis writes:
At 01:06 AM 04/27/2001, Mark Sergeant wrote:
I guess you missed the POINT, [...]
And I have to hand that to you Dennis: when it comes to missing points
you are the master...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED
will be the future of semiconductors.
Hitachi has a GaAs SPARC chip; it is used in Satellites.
The CRAY-3 was GaAs based, if I'm not mistaken.
And Convex made a GaAs based supercomputer, the 3800 I belive.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since
forwarded message -
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
--
Poul-Henning Kamp | UNIX since Zilog
vfs.devfs.topinode: 118
:-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED
track of cloned dev_t's so we can nuke them
at various strategic points, havn't gotten to that yet.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can
and purposes is a separate protocol
(at least it has it's own namespace, that's close enough for me)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can
!
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd
introduced the $1$ marker,
which allows the algorithm to be replaced in a backwards compatible
way (as already done by OpenBSD).
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute
applications.
If we have abandoned the no changes to API or ABI in -stable
paradigm, it would be a good idea, but it serious rains on that
rule...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3
In message [EMAIL PROTECTED], David O'Brien writes:
On Tue, Jun 05, 2001 at 06:33:17PM +0200, Poul-Henning Kamp wrote:
Others see it differently, it would seriously break a lot of
people who are using -stable in embedded applications.
Can you expand on this? I assume you know we
In message [EMAIL PROTECTED], Ruslan Ermilov writes:
On Tue, Jun 05, 2001 at 07:43:38PM +0200, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], David O'Brien writes:
On Tue, Jun 05, 2001 at 06:33:17PM +0200, Poul-Henning Kamp wrote:
Others see it differently, it would seriously break
In message [EMAIL PROTECTED], Dima Dorfman write
s:
Poul-Henning Kamp [EMAIL PROTECTED] writes:
In message [EMAIL PROTECTED], David O'Brien writes:
On Mon, Jun 04, 2001 at 07:46:18PM -0700, Dima Dorfman wrote:
Is there any reason not to MFC the new md(4) functionality
Zero reason
-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd
.
As I already said: a device with no other precense in /dev has only
quickdirty reasons for using DEVFS cloning.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what
as the hills, proving prior art
would probably be relatively straightforward.
Well, the application date is what counts, and that's mar1992, but I'm
pretty sure that Bill Jolitz had them beat to that date already...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP
which contains an explanation and the
grep(1)'able line:
This PR can be closed
Remember: Each open PR is a pissed off contributor...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never
is stop HIRING them. :)
You know, there is almost a fortune in that...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained
PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
*Wollongong*cough*hack*wheeze* (THUD!)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail
to get hold
of a media copy of FreeBSD, when absolutely nothing prevents
me or anybody else from rolling a net distribution ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute
.
Right, and what are you going to do about some random company
in Elbonia who labels and unapproved cd as Official ?
One should never makes rules one can't enforce...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD
two people come across a bit
grumpy on email.
--
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:
uot;?
How is the microcode loading handled in LinuxBIOS ? As far as I know
getting hold of the microcode-supplemental data from Intel is a process
which is (impossible - epsilon) and certainly not open source compatible ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL
uot; people to agree with this: Just do it, if it
works, people will use it and it will become a success, if it doesn't
work...well you can say that you tried :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
- 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
I have a card here, and I am making good progress, I have the
framers up and running and am working on the HDLC controller. I
expect to pass the first HDLC frames today or tomorrow.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD
even when Im root on the jail (it says
operation not permitted?)
Because implementation would be tricky (filtering raw IP packets)
and nobody has done it yet.
--
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], Dennis writes:
I asked this on the hackers list and noone answered, so maybe some of the
isps know?
Why don't you spend some time testing it and tell us the result ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since
if I can find it again when I
have time.
--
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
there
any objections to changing this?
this should be more portable and future-save, right?
Isn't there an issue with NFS server side ?
--
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
/etc/passwd: $VAR1"
Let me see you replicate that in C in less than 2 lines...
Nick, I can do it in one line, but it will suck style wise because I
cannot use #includes.
Can we stop this pissing contest now before anybody starts flouting
APL single-liners ?
Thanks.
--
Poul-He
invlpg when PentiumPro with
cpuid 0x619 is found.
Please comment to this patch.
I'm against this patch. This is so specific and marginal to a
out-of-spec hardware configuration, that it should not be put in
the FreeBSD tree.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED
just fine if your motherboards BIOS have the right
microcode update for your cpu stepping.
This hack should be maintained by the person who need it, it should
not be lobotomizing FreeBSD in general.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since
know Intel never released the errata
which the microcode updates fixes anyway.
I'm still against.
--
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
is that it is the beginning of an
"almost-clone" implementation.
--
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 Unsubsc
precedents already for
this type of thing. And yes, in this case, the CPU is not performing
as advertised.
So far we have set the limit at hardware being used correctly.
Either way, this patch was not the correct way to fix this particular
erratum.
--
Poul-Henning Kamp | UNIX since Zilog
ant voices on this issue so that I can decide whether to
just drop this entire thing and forget about it. (in other words, what do
committers and/or core have to say about this?)
If you can improve it, and show it to be improved, I think it is a good
idea.
--
Poul-Henning Kamp | UNIX s
e to be used to make any decisions
however.
--
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
was unused ?
Could that freeing be done by a timeout routine which runs every
N seconds ?
--
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
nario is to have a SIGVMSTATE defaulting to
ignore which gets sent when the variable changes, but that would
have thundering herd issues if a lot of processes was paged out.)
If only somebody would add that variable, I don't feel like diving
into the VM system right now.
--
Poul-Henning Kamp | UNI
ld and new testament.
--
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
"configure"
routine, and the module can do whatever it damn pleases with
the passed arguments.
--
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 adequatel
with
devfs (root-mount, jail, cloning etc etc)
--
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
have you tried looking at ptys under devfs..
as you use them, more are created.. (a bit of a hack but kinda cute).
Cute, but not cute enough. We have several devices which do this
by now, but we need full cloning ability.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED
it is suitable.
--
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
--
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 "unsubscribe fr
track the
discussion and ideas that are floated.
--
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
In message [EMAIL PROTECTED], Bernd Walter writes:
The point I never digged deeper here is because you already sugested
changing the driver layer to 64bit byte numbers which was accepted if
I remember right.
Yes, I have this on my plate.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
In message [EMAIL PROTECTED], takawata@shidahara
1.planet.sci.kobe-u.ac.jp writes:
Hi, I want major number for ACPI device.
I will use the device interface to enable/disable ACPI and access to
switches defined in ACPI.
I have allocated major 152 for ACPI.
--
Poul-Henning Kamp | UNIX
MD, for "put my /tmp on
ram/swap" it's VN.
--
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
:!1/5%NV55/6H6*QX0U-(-+XA,GU]AB/H#-Q?VVW!UEY+?
M^9BD@;21+]:QLCGU/QD$+58RQ9$B!!:SD9UOA=;#6=*C1G#7\*_!M7'E\
M8%6XS6LN*F(_.)T0]:F?([`VOF-:9?KN`=XSH(KA`.-27(2G+[2H/NG75
MM!=N`V]S\X@SE@3@:6*75I$H1%8L(7\1BI6_(,$N56J!7J=R-4**[Y]HI!3
MN4VFY3JRK9/K"_W@S5FK$B,M?[$_4ET_@-7;'7B\5##I2,^63/WHUC:
M`89];@`QDUP+HK`?A.
In message [EMAIL PROTECTED], Matthew Seaman writes:
Poul-Henning Kamp wrote:
Ok, some people just can't leave an open end dangling (people like
me for instance :-)
I located a surplus german geiger counter cheaply [1], I have always
wanted to have one anyway, and in my junkbox I already
In message [EMAIL PROTECTED]
e, Paul Herman writes:
But, if you are gathering a geek lobby to convince Intel to have an
onboard geiger counter, you just might have a new member ;-)
"Cesium-137 inside"
Yeah, it does have a ring to it, doesn't it ? :-)
--
Poul-Henning Kamp
In message [EMAIL PROTECTED], "Jonathan M. Bresler"
writes:
http://www.fourmilab.ch/hotbits/
Yup, that's where I got the idea. Difference is that I interface the
geiger directly to a UNIX system, he has all sorts of magic stuff
in the middle...
--
Poul-Henning Kamp | UNIX s
In message [EMAIL PROTECTED], Yingf
ei Dong writes:
hi, folks,
I am revising a driver for a network interface. I need have a fine-grain
timer (33us). Could anyone tell me how to get it?
You will have to use DELAY(33).
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED
In message [EMAIL PROTECTED], Warner Losh writes:
In message [EMAIL PROTECTED] Poul-Henning Kamp writes:
: The earphone output of the geiger counter with a 1kOhm load generates
: a nice TTL level pulse which can be fed onto pin 10 of the parallel
: port and timestamped with the PPS-API device
me routine maintenance...is there any hope of alleviating this deboggle?
Sure: send us your patches!
--
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
rd lookup != reverse lookup)
R? [$+] $: BAD [$1]
# pass to name server to make hostname canonical
--
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 ade
measure regarding 'ps' command.
By using the 'ps' command, any user logged in the system can view all
the running processes, including root's one and processes of other
users. My idea is to limit a bit this behaviour.
You can possibly make jail(8) do this for you...
--
Poul-Henning Kamp
run your program again...
--
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
:)
Look at the kernel_sysctl() function in src/sys/kern/kern_sysctl.c
--
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
variables, so you pass it the "new" value and
a buffer for the "old" value.
--
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 ade
?
--
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 |
"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
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
havn't tried it yet, so if you feel adventurous
you can try to add it to the ad_tagsupported function in ata-disk.c
and see what happens
Gee. You can upgrade F/W in SCSI drives. How about ATA drives?
Same thing, the trick is to get the update microcode out of IBM.
--
Poul-Henning Kamp
In message [EMAIL PROTECTED], awr writ
es:
Also, shouldn't /usr/src/sys/dev/vn/vn.c use make_dev() and destroy_dev()
calls instead of cdevsw_add()??
Yes :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD
e we ditch it...
--
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
In message [EMAIL PROTECTED], Ben Smithurs
t writes:
Poul-Henning Kamp wrote:
I must admit that I think in general that /dev/std{in,out,err} and /dev/fd
is bogus. It looks like something which happened "because we can" more
than something which has a legitimate need.
You think add
clue where
to even try modifying this for my device. Is anyone using the DS1820 on a
1-Wire Lan with FreeBSD?
http://firtal.freebsd.dk/weather/
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
101 - 200 of 606 matches
Mail list logo
