available if I could
offer better PR for donations, but it is really outside my power
to do so.
Does that answer your questions ?
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never
In message [EMAIL PROTECTED], Wm. Da
ryl Hawkins writes:
I've written a driver for the Intel i8xx TCO watchdog timer for
both FreeBSD-CURRENT and FreeBSD-STABLE.
Is this written against the sys/watchdog.h API in -current ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL
with giant.
Brownie points: Get slashdotted when they discover you did it.
--
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
.
--
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.
___
[EMAIL PROTECTED
to define
something closer.
--
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
or march this year.
Poul-Henning
--
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
, learn to code if need be,
donate money so somebody else can code if you can't do anything
else.
--
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
instead of the current cdevsw.
Don't be mislead by these four easy steps, there is a lot of stuff to
do in vinum to get these done, a lot of then undoing things as Greg
has already remarked, but if you do it in this order, GEOM will not be
your biggest problem in this.
--
Poul-Henning Kamp
--
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.
___
[EMAIL PROTECTED
(Greg) agree to remove it from -current?
My proposal is to do just that with both vinum and raidframe until
one or possibly both are up to full strength again.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD
at them.
Poul-Henning
--
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
, you
have got it all _TOTALLY_ wrong! :-)
Poul-Henning
--
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
.
--
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.
___
[EMAIL PROTECTED
of problems going forward.
GPT is our current candidate.
--
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
support. I'm pretty certain we don't want that either.
--
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
is no longer a risk to the data.
Now *that* is a DIY project for the dedicated hobbyist :-)
The terminology and principle, is from atomic weapons which have a
similar security profile:
http://nuclearweaponarchive.org/Usa/Weapons/Pal.html
enjoy
--
Poul-Henning Kamp | UNIX since Zilog Zeus
In message [EMAIL PROTECTED], Wilko Bulte writes:
On Fri, Nov 28, 2003 at 12:43:30PM +0100, Poul-Henning Kamp wrote:
I have already described one solution to this in my GBDE paper at
BSDcon.
...
Now *that* is a DIY project for the dedicated hobbyist :-)
The terminology and principle
of the attack scenarios to protect against ?
(Not meaning, that secure erase would really solve
that problem ...)
See my paper for a suggestion about using weak-link/strong-link
methods for that.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
cannot reliably overwrite
data on a magnetic media. In particular the difference in read/write
geometry and lack of fine control over head placement makes this
impossible.
The only reliable way to loose data is to encrypt them and throw the
key away.
Live with it.
--
Poul-Henning Kamp
1. Look for BIO_DELETE in the kernel.
2. Use GBDE or other encryption.
3. Stop bikeshed now, please.
--
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
ljmp $0xf000,$0xfff0).
committed to FreeBSD -current.
--
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
day down the road, somebody will pick up on the
consolidation idea, or maybe he will instead show it to be hopelessly
idealistic and burried it firmly.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3
projects is of course a different matter).
I, and I think other members of FreeBSD, would appreciate it if
the members of DragonflyBSD would adhere to this peace-keeping
rule as well.
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC
Sorry, I'm reducing my email load by dropping off [EMAIL PROTECTED]
If you want my attention on a problem, send me private email, Cc' me
or send it to another list were I'm subscribed.
Sorry...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since
have the code anymore, but the idea is available to anyone
who wants it :-)
--
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
-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.
___
[EMAIL PROTECTED] mailing list
.
:-)
--
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.
___
[EMAIL
just fixed 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 by incompetence
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 by incompetence.
___
[EMAIL
or less all the
places in the kernel which uses makedev().
As you may have noticed I've started evicting these from the
console related code.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never
will contain large files.
It strikes me that driving the block size up (as far as 1M) and having
a 256 (or so) fragments might become appropriate.
Sounds like a _great_ project for somebody :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD
and actually fsck them.
I am not sure I would advocate 64k blocks yet.
I tend to stick with 32k block, 4k fragment myself.
This is a problem which is in the cross-hairs for 6.x
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer
than I need, it also saves fsck time.
--
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
it will give you more I/O bandwidth.
--
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
expected loss of IO be?
The loss will mostly be from latency, but how much is impossible to
tell I think.
The statistics of this, even with my trusty old Erlang table would
still be too uncertain to be of any value.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED
. This includes various WITNESS-
] related kernel options, INVARIANTS, malloc debugging flags
] in userland, and various verbose features in the kernel. Many
] developers choose to disable these features on build machines
] to maximize performance.
--
Poul-Henning
: 5791796 bytes/sec (file was exported)
GG write file: 4071411 bytes/sec (file was exported)
GG read device:4635277 bytes/sec (disk device was exported)
GG write device: I wasn't able to test
Please use /usr/src/tools/tools/ministat to do a proper statistical
benchmark.
--
Poul-Henning Kamp
In message [EMAIL PROTECTED], Peter Jeremy wri
tes:
[Redirected to -hackers because this isn't directly relevant to the
actual code committed]
On Fri, Aug 15, 2003 at 05:04:02AM -0700, Poul-Henning Kamp wrote:
Suggested replacement command sequence on the client:
dd if=/dev/zero
devices mounting through the network.
COOL
http://garage.freebsd.pl/geom_gate.tbz
I'll look over it when I have a second.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never
) can attach to 'mmcr'.
This seems straight forward. Maybe I'm missing something. 8-)
That's my take too. And MMCR belongs on nexus not on legacy from an
architectural point of view.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD
.
In fact what you may want to do is hang the entire MMCR off the nexus
as a bus, and hang the various drivers off that bus.
--
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
a bio.
Throughout geom bio's are created a destroyed which have no
relation to any specific buf, for instance to read the key
sectors in gbde.
--
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], Bernd Walter writes:
On Wed, Aug 06, 2003 at 12:18:28PM +0200, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Bernd Walter writes:
I need to add I2C support for a Elan520 based soekris system.
The system has the required GPIO pins and there is the iicbb
In message [EMAIL PROTECTED], Bernd Walter writes:
On Wed, Aug 06, 2003 at 12:45:43PM +0200, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Bernd Walter writes:
On Wed, Aug 06, 2003 at 12:18:28PM +0200, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Bernd Walter writes:
From
people at when they
run benchmarks.
Source: http://phk.freebsd.dk/patch/ministat
Poul-Henning
--
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
of calls in the ATM code that have just
M_ZERO or even 0 flags.
Anything against this check?
Good point, please implement!
--
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
the distribution (to the extent
that they could).
--
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
imgact_gzip.c was heavily a.out aware.
--
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
,
+*, *},
+ /*quirks*/ DA_Q_NO_6_BYTE|DA_Q_NO_SYNC_CACHE
}
};
--
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
find it odd, that the quirks are not assigned in the umass code and
passed to scsi_da some way, that would be much more reliable.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never
In message [EMAIL PROTECTED], Bernd Walter writes:
On Thu, Jun 05, 2003 at 04:10:59PM +0200, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Bernd Walter writes:
Mine works fine without quirks:
port 3 addr 3: full speed, power 100 mA, config 1, Travel Flash(0x1307),
PQI(0x0483
the kernel code, so expect a few
non-BDE-complying mistakes. Sorry
for that.
Thanks,
Jason
--
Jason Stryker
[EMAIL PROTECTED]
--
http://www.fastmail.fm - IMAP accessible web-mail
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD
in the tree: Yeah, right, and sell me the Eifel tower too.
There is one count where I will concede that the FreeBSD project
sucks: We have really lousy incompetent stupid boring trolls.
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
trolling our mailing lists.
--
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
, mostly that it may
screw up other time-critical things in the system.
--
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
. MII access functions are
quite time consuming almost any way you look at it.
I'm not sure the _tick functions should even be called from a timeout().
In many ways it seems preferable to me to have then run sequentially
from a single thread, possibly via a task-queue.
--
Poul-Henning Kamp
-base: What length of delays are you
looking for ?
--
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
multiple respiratory
failures in the re@ team if I even think about it until the RELENG_5
branch has been laid down, so for now you're on your own.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
new header files
get installed properly when I do a make installworld?
None.
... which is a bug.
--
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
etc
--
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
-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-hackers
-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-hackers
/stdlib/calloc.c:49
I think we can more or less conclude that something has trashed your
memory.
I'd suggest you try to run your program with ElectricFence or similar.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer
or is it just a stale feature?
I havn't checked it lately, but it should be brought to work again
I think, it is a very valuable provider of insight into what code
is really executed.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD
there !
--
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
.
I'm pretty sure I heard them say that it was all your fault they
got started on this, but then again, I may be totally wrong.
Luigi@ had sent a part of his crew from Torino to talk about VPN
and other cool networking stuff in FreeBSD.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL
-cr_prison) {
return (EBUSY);
--
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
the same prison:
:
:} else if (pti-pt_prison != td-td_ucred-cr_prison) {
:return (EBUSY);
:
:
:--
:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
:[EMAIL PROTECTED] | TCP/IP since RFC 956
Ah, excellent. Is there a limit inside the prison so a jail cannot
think running out of ptys is a problem compared to
other resource limitations (number of processes etc etc).
--
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
: You can use up
any resource you can get your hand on: processes, disk, filedescriptors,
ptys, mbuf clusters, you name it.
If you want to add resource limitations to jails, then do it right from
the bottom, instead of as local hacks in random drivers or other hotspots.
--
Poul-Henning Kamp
crunchgen.
--
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
snapshot feature
available for 4.X-STABLE (only 5.0)?
It works most of the time, but not always. There is no way for dump(8)
to realize what has changed under its feet and therefore it sometimes
ends up with a bunch of negative blocknumbers.
--
Poul-Henning Kamp | UNIX since Zilog Zeus
circumstances? If other circumstances, which ones?
The fix is to not run dump(8) on a live filesystem. You should
either use a snapshot or umount the device.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3
-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-hackers
In message [EMAIL PROTECTED], Hanspeter Roth writes:
On Oct 29 at 18:34, Poul-Henning Kamp spoke:
That's a slightly more involved issue because you would have to
actually try to write to it before you find out that you can't.
Isn't there a means to determine the state of the protection
In message [EMAIL PROTECTED], David Schultz writes:
IMO, the retry-forever bug is the
real problem, but I'm a bit skeptical that it's easy to solve
safely.
Just revert the commit which added it recently.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP
In message [EMAIL PROTECTED], David Schultz writes:
Thus spake Poul-Henning Kamp [EMAIL PROTECTED]:
In message [EMAIL PROTECTED], David Schultz writes:
IMO, the retry-forever bug is the
real problem, but I'm a bit skeptical that it's easy to solve
safely.
Just revert the commit which
anything about
performance, but run a server where you actually have RAM pressure
and you might notice the difference.
Progress may be overrated, but it seldom goes too far...
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD
In message [EMAIL PROTECTED], David Schultz writes:
Thus spake Poul-Henning Kamp [EMAIL PROTECTED]:
In message [EMAIL PROTECTED], David Schultz writes:
You can find a somewhat more thorough comparison of malloc
implementations at http://citeseer.nj.nec.com/440671.html .
There are many
promise to fix all the issues which come up, but I will do my
very best...
--
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], [EMAIL PROTECTED]
.de writes:
Is sysinstall still supposed to copy the contents of the mfsroot-
image to /stand ? This at least results in two copies of sysinstall,
one in /stand and the other one in /usr/sbin.
That is intentional
--
Poul-Henning Kamp | UNIX
In message [EMAIL PROTECTED], [EMAIL PROTECTED]
.de writes:
On Tue, Oct 22, 2002 at 10:39:32PM +0200, Poul-Henning Kamp wrote:
That is intentional
Is it ok then that the sysinstall in /stand of the 0917-JPSNAP
immediately dumps core with signal 10 when run on a 1017 -current ?
Current
Never, ever retry.
--
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
In message [EMAIL PROTECTED], Bakul Shah writes:
Oh well.
I am not going to argue about this over and over and over
again.
Thankyou, a very wise decision sir!
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD
In message [EMAIL PROTECTED], n0go013 writes
:
On 04.10-18:27, Poul-Henning Kamp wrote:
In message n0go013 writes :
On 04.10-15:40, fergus wrote:
On 04.10-14:20, Poul-Henning Kamp wrote:
[...]
I suspect vinum uses this sysctl to get an inventory of disks in
the system, so can I
In message [EMAIL PROTECTED], Ju
lian Elischer writes:
No, it is established principal tha the importer of new features has the
responsibility to make older subsystems work.
I'm _so_ glad to hear _you_ say that:
When will you have made KSE work on sparc64 and ia64 ?
--
Poul-Henning Kamp
In message [EMAIL PROTECTED], Daniel E
ischen writes:
On Fri, 4 Oct 2002, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Ju
lian Elischer writes:
No, it is established principal tha the importer of new features has the
responsibility to make older subsystems work.
I'm _so_ glad
, and good riddance.
If a buffered access-mode on block devices is desired, it should
be implemented either as an ioctl controllable feature, or as
a GEOM module. The latter is probably by far the easiest way.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP
close to the point where it can happen...
--
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
to start.
There will also be a tutorial friday afternoon about GEOM
at BSDCONeuro2002 in amsterdam next month.
--
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
as 64 bit byte offsets, so as such
GEOM will solve the problem, and provided the disk-driver authors
follow suit, this entire thing can be fixed before 5.0.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3
easy now :-)
I'm discussing the issue with core@ right now, and if they agree
that this should go in the tree, I'll be your designated committer
for the first period of time.
Stay tuned, I'll get back to you when core@ gives me their conclusion.
--
Poul-Henning Kamp | UNIX since Zilog Zeus
In message [EMAIL PROTECTED], Mark Santcroos writes:
On Wed, Sep 25, 2002 at 07:41:44PM +0200, Poul-Henning Kamp wrote:
The fact that this did work, was it a bug or did this come out due to some
other change. The stacktrace from read(2) is below.
This hasn't worked for a long time
In message [EMAIL PROTECTED], Daniel O'Connor
writes:
On Thu, 2002-09-26 at 14:18, Poul-Henning Kamp wrote:
Have you seen ports/security/vncrypt?
Or src/sys/geom/geom_aes ?
Whoo :)
I have what I hope is industry-strenght encryption in my development
tree with only a few more issues
In message [EMAIL PROTECTED], Bruce M Simpson writes:
What I'd like to do is modify a Soekris net4501 for this.
There is a hardware watchdog in the Elan CPU used in the Soekris,
I plan to add support for it to the elan-mmcr driver when I get
a timeslot for it.
--
Poul-Henning Kamp
In message [EMAIL PROTECTED], Nate Lawson wri
tes:
On Sat, 7 Sep 2002, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Ju
lian Elischer writes:
On Sat, 7 Sep 2002, Poul-Henning Kamp wrote:
IP-over-SCSI ?
Well I've just been reading about SCSI over IP so
That's
and stability.
IP-over-SCSI ?
--
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
In message [EMAIL PROTECTED], Ju
lian Elischer writes:
On Sat, 7 Sep 2002, Poul-Henning Kamp wrote:
IP-over-SCSI ?
Well I've just been reading about SCSI over IP so
That's different. IP-over-SCSI is a much wanted Myrinet-light over here.
--
Poul-Henning Kamp | UNIX since
In message [EMAIL PROTECTED], Seva Tonkonoh writ
es:
Hi,
I have recently come across an old little discussion about InterMezzo.
I 've got the impression that it wasn't really welcome to FreeBSD.
What is it ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED
the appropriate allocations?
If so, how do I get at the resource?
If not, how would I go about doing this myself in the driver?
And what would I want to put in my driver's xxx_probe() routine?
Suggest you look at the sys/dev/sio/sio_pccard.c file...
--
Poul-Henning Kamp | UNIX since Zilog
101 - 200 of 606 matches
Mail list logo
