Dmitry Pryanishnikov wrote:
Hmm, let me cite your letter in this thread:
This isn't a court of law. :)
sysutils/portconf does not have that limitation. If you specify flags using
that method, they will always be used.
FYI,
Doug
On Sun, 2006-Aug-27 22:55:55 +0300, Kostik Belousov wrote:
On server,
tcpdump -p -s 1500 -w file -i iface host client host ip
Recent tcpdumps appear to want the ethernet frame size rather than
the MTU: Specifying 1500 appears to truncate full-size frames.
Try '-s 1516' instead.
--
Peter Jeremy
Hello!
On Mon, 28 Aug 2006, Peter Jeremy wrote:
On Sun, 2006-Aug-27 22:55:55 +0300, Kostik Belousov wrote:
On server,
tcpdump -p -s 1500 -w file -i iface host client host ip
Recent tcpdumps appear to want the ethernet frame size rather than
the MTU: Specifying 1500 appears to truncate
Well, the result I have to report is so interesting, I'll give the
executive summary right away:
If rpc.lockd is run with -d255 it works perfectly
If rpc.lockd is run with -d1 (or no -d option) it locks up
Sweet.
Does anyone out there who understands rpc.lockd fancy a deeper
On Mon, Aug 28, 2006 at 09:48:48AM +, Michael Abbott wrote:
An alternative would be to update to RELENG_6 (or at least RELENG_6_1)
and then try again.
This machine is so painfully slow that I'll probably have to do that
overnight, and then I'm out of time until next weekend. Just
On Sun, 27 Aug 2006, Kostik Belousov wrote:
On server,
tcpdump -p -s 1500 -w file -i iface host client host ip
Ok. I've run
saturn# tcpdump -p -s 1500 -w tcpdump.out -i xl0 host 10.0.0.105
and run the failing test on venus (with `rpc.lockd -d1`). The failing
lockf has moved -- it took
Hi,
I've also seen this kernel: kern.maxpipekva exceeded, please see
tuning(7) on the console of our Dell PE6650, which (again) had lost its
amr (LSI RAID/Perc). This machine isn't under load but runs rsync every 5
minutes.
[EMAIL PROTECTED]:1:0: class=0x010400 card=0x05181028 chip=0x19601000
Michael Abbott wrote:
What about the non-interruptible sleep? Is this regarded as par for the
course with NFS, or as a problem?
I know that hard NFS mounts are treated as completely unkillable, though
why `kill -9` isn't made to work escapes me, but a locking operation which
Torfinn Ingolfsen wrote:
Are 16 Megs of RAM to little to install FreeBSD 6.0 or newer?
As others have pointed out, installation via sysinstall
requires at least 24 MB of RAM. So you either have to
prepare your own installation media, or put the harddisk
in a different PC, install FreeBSD
On Mon, 28 Aug 2006, Oliver Fromme wrote:
SIGKILL _does_ always work. However, signal processing can be delayed
for various reasons.
[...]
Well, in theory, a special case could be made for SIGKILL, but it's
quite difficult if you don't want break existing semantics (or creating
holes).
Torfinn Ingolfsen [EMAIL PROTECTED] wrote:
On Sun, 27 Aug 2006 18:13:12 +0200
Fabian Keil [EMAIL PROTECTED] wrote:
For information: I'm still trying to find a sodimm card for this
machine, as everything would be easier if it had more memory.
We'll see how I manage that; here in Norway it
I got a panic on my workstation (6.1-RELEASE-p2 amd64).
-
panic: lockmgr: thread 0xff007b910be0, not exclusive lock holder
0xff001c114720 unlocking
cpuid = 1
KDB: enter: panic
[thread pid 43 tid 100037 ]
Stopped at kdb_enter+0x2f: nop
db bt
Tracing pid 43 tid 100037 td
After previous panic, I got another panic... (6.1-REL-p2 amd64)
-
panic: snapblkfree: inconsistent block type
cpuid = 1
KDB: enter: panic
[thread pid 844 tid 100110 ]
Stopped at kdb_enter+0x2f: nop
db bt
Tracing pid 844 tid 100110 td 0xff0055e07260
kdb_enter() at kdb_enter+0x2f
13 matches
Mail list logo
