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
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 0xf
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 No
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).
Than
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 there
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
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=0x1960100
On Sun, 27 Aug 2006, Kostik Belousov wrote:
On server,
tcpdump -p -s 1500 -w file -i host
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 longer to fail this time
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
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 lo
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 host
Recent tcpdumps appear to want the ethernet frame size rather than
the MTU: Specifying 1500 appears to truncate full-size frames.
Try '-
On Sun, 2006-Aug-27 22:55:55 +0300, Kostik Belousov wrote:
>On server,
>tcpdump -p -s 1500 -w file -i host
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
pgpozGke7ZjM8.p
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
> =
13 matches
Mail list logo