Am Sun, 19 Feb 2023 06:19:04 -0800
Rick Macklem schrieb:
> I committed a patch that would cause crashes if
> the system was using jails on Feb. 11, but it was
> fixed the next day. It bogusly had a prison_cleanup()
> method in it.
>
> But if you kernel wasn't from main on about Feb. 11
> or you
:If you notice, both times it crashed on vm_map_insert.
Try bumping up PMAP_SHPGPERPROC. From LINT:
#
# Set the number of PV entries per process. Increasing this can
# stop panics related to heavy use of shared memory. However, that can
# (combined with large amounts of physical
: that doesn't work, and there's any chance of getting a kernel dump,
: try getting a kernel dump. Make sure you use a debug (compiled -g)
: kernel.
:
:
:While I can't say I truly see the correlation, you definitely know more
:about how it works then me. I've cvsupp'd and upped it
:the timeout to kill it off because of the interactive mode. Otherwise
:there was ~960,000 accumulated exec()'s altogether in a 5 hour period.
:
:As you can see, cron is the process that crashed it. Two weeks ago it
:was an eggdrop. I've not had any crashes in -CURRENT while this program
:was not
PROTECTED]
Subject: Re: -current crash
...
OK, this is what I was afraid of. I'm committing some fixes.
Thanks.
I'm leaving for the USA in a few hours. If you could test that
before, it would help; otherwise it might be a while before I can look
at it again.
Greg
--
Finger [EMAIL PROTECTED
[EMAIL PROTECTED]
Subject: Re: -current crash
...
Have you rebuilt the kld?
kernel,modules,world are in sync.
The same configuration worked for several weeks without problems.
BTW: where does the 0xdeadc0de (0xDeadCode ?) below come from?
Info to frame5:
(kgdb) rq
Request:
{
bp
: -current crash
Doesn't tell *me* a lot maybe a broken driver that's a KLD? It looks
like something from spec_strategy is being called that's not in the
/kernel space- could be a KLD- are your KLDs up to date for the new
kernel? Like, is this vinum perhaps?
Seems so. After using
On Sunday, 17 October 1999 at 22:42:51 +0200, Michael Reifenberger wrote:
Hi,
I got the following crash since a couple of time since upgrading one machine to
-current as of today. It seems to occurs during somewhat heavier diskaccess.
Sorry no detailed backtrace for now because I deleted my
Well, a DDB traceback would help. Failing that, at least what does
0xc101891b correspond to otherwise, it's all ENOGUESS
On Sun, 17 Oct 1999, Michael Reifenberger wrote:
Hi,
I got the following crash since a couple of time since upgrading one machine to
-current as of today. It
On Sun, 17 Oct 1999, Matthew Jacob wrote:
...
Well, a DDB traceback would help. Failing that, at least what does
0xc101891b correspond to otherwise, it's all ENOGUESS
Next try, next crash. No problem. Easy crashing :-)
I tried to find the address 0xc101891b using nm(1) but can't seem
On Sun, Oct 17, 1999 at 10:42:51PM +0200, Michael Reifenberger wrote:
[...]
#3 0xc02117b1 in trap_pfault ()
#4 0xc0211313 in trap ()
#5 0xc101891b in ?? ()
#6 0xc1018752 in ?? ()
#7 0xc101854e in ?? ()
#8 0xc0186a66 in spec_strategy ()
#9 0xc018601d in spec_vnoperate ()
[...]
What
Doesn't tell *me* a lot maybe a broken driver that's a KLD? It looks
like something from spec_strategy is being called that's not in the
/kernel space- could be a KLD- are your KLDs up to date for the new
kernel? Like, is this vinum perhaps?
On Sun, 17 Oct 1999, Matthew Jacob wrote:
...
On Mon, Oct 18, 1999 at 12:16:08AM +0200, Michael Reifenberger wrote:
The combination of vinum raid5 and softupdates is known to trigger a bug
which may look just as you described.
I might help if you disable softupdates on the vinum volumes.
--
B.Walter COSMO-Project
On Mon, 18 Oct 1999, Bernd Walter wrote:
...
On Mon, Oct 18, 1999 at 12:16:08AM +0200, Michael Reifenberger wrote:
The combination of vinum raid5 and softupdates is known to trigger a bug
which may look just as you described.
I might help if you disable softupdates on the vinum volumes.
On Mon, 18 Oct 1999, Greg Lehey wrote:
Date: Mon, 18 Oct 1999 12:50:04 +1300
From: Greg Lehey [EMAIL PROTECTED]
To: Michael Reifenberger [EMAIL PROTECTED]
Cc: Matthew Jacob [EMAIL PROTECTED], FreeBSD-Current [EMAIL PROTECTED]
Subject: Re: -current crash
...
OK, this is what I was afraid
the vinum module looks to have been the problem..
not ethat you had stack elements at 0xc101exxx
vinum starts at 0c1011000,
On Mon, 18 Oct 1999, Michael Reifenberger wrote:
On Mon, 18 Oct 1999, Bernd Walter wrote:
...
What kind of modules were you running?
(nullum)(root)# kldstat
Id Refs
On Mon, 18 Oct 1999, Greg Lehey wrote:
Date: Mon, 18 Oct 1999 13:40:27 +1300
From: Greg Lehey [EMAIL PROTECTED]
To: Michael Reifenberger [EMAIL PROTECTED]
Subject: Re: -current crash
Ok, seems to be fixed.
A few stress tests which paniced reliable before do new work.
Thanks for the fast
On Sun, 17 Oct 1999, Julian Elischer wrote:
...
the vinum module looks to have been the problem..
not ethat you had stack elements at 0xc101exxx
vinum starts at 0c1011000,
Yes.
But you are too late :-)
The fix is allready commited.
Bye!
Michael Reifenberger
Plaut Software GmbH, R/3 Basis
18 matches
Mail list logo
